Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    ziggystar
    @ziggystar
    I'm also curious how long it will last.
    Dave Smith
    @davesmith00000
    Here is the ticket for cameras, in fact. Made in April.
    PurpleKingdomGames/indigo#124
    Even though I mentioned that you can simulate this with scale, this is an advantage to doing this "in engine", because it would allow the notion of "static" things that could be rendered once and never change, but would still move when the camera moves. Good for complicated backgrounds.
    ziggystar
    @ziggystar
    How do I apply the ImageEffects? Am I supposed to downcast my Graphics to a Bitmap, then turn it into an ImageEffect, and then add the effect? The downcasting is quite annoying. I stored my sprites/images as a Map[MyType, Graphic]. Should I do this differently?
    ziggystar
    @ziggystar
    And another question: I tried opening the index.html in a browser (both Firefox and Chromium), but I get a "Security Error" on startup. Any ideas?
    Dave Smith
    @davesmith00000
    Hang on, which version are you using now? 🙂
    ziggystar
    @ziggystar
    The latest now.
    Dave Smith
    @davesmith00000
    ImageEffect is a material, you can apply it the Graphics or Sprites.
    Dave Smith
    @davesmith00000
    Regarding the index.html, you need to load it via an http server. The easiest one to use is "http-server" that you can install via npm. There's a python one too that's pretty easy to use. I use the former, and do http-server -c-1 from within the folder I want to server, the argument disabling caching.
    ziggystar
    @ziggystar
    Yeah, I have http-server installed.
    I have now this working, which is different from the examples:
    .modifyMaterial { case m: Material.Bitmap => m.toImageEffects.withSaturation(0) case m => m }
    ziggystar
    @ziggystar
    That code is not very nice, actually. I want to apply my effect, and I do not want the m => m path to happen.
    Is it like some stages, and it's always Bitmap → Effects → ShaderData ?
    Dave Smith
    @davesmith00000
    When you make the graphic you can set the material. There is also a withMaterial method. The modify is supposed to be convenient but yes you have to do the bothersome pattern match because you loose knowledge of what type of material it has.
    They default to Bitmap because it's the least expensive/sophisticated.
    ziggystar
    @ziggystar
    I think that information should be retained in the type.
    Like, have a Graphic[M <: Material](material: M, …).
    Does this make sense?
    Right now I have a problem of how to store graphics. If I store them as Bitmap, I know how to apply effects, but I cannot crop and such. If I store them as Graphic, I do not know whether I can apply any effects to them anymore (maybe they are already ShaderData).
    Dave Smith
    @davesmith00000
    It does, and I've thought about it.
    Hang on, you can do graphic.withMaterial(Material.ImageEffects(..))
    Then you get both.
    Btw for some reason gitter doesn't give me notifications on my phone so apologies if my replies are slow. 🙂
    Dave Smith
    @davesmith00000
    No pressure to move at all, but the discord chat is a little busier - and notifications work!
    Dave Smith
    @davesmith00000
    I'll reconsider adding the material as a type parameter to the primitive types. Prior to materials it wasn't a problem and I've been trying to keep the APIs looking friendly / approachable. But perhaps in this case the juice is worth the squeeze.
    Dave Smith
    @davesmith00000
    @ziggystar Thoughts?
    PurpleKingdomGames/indigo#168
    Dave Smith
    @davesmith00000
    So the one above is the Material's as a type param thing.
    This one allows you to have a scene camera:
    PurpleKingdomGames/indigo#169
    ziggystar
    @ziggystar
    @davesmith00000 I'm completely pro adding the type parameter. It could be dropped, if handling graphics would not require knowing the internals. But since this is not the case, I would definetely add it in my code.
    Regarding the camera. Is it tied to a subset of the scene elements, because it is added to an fragment? So if I want buttons that are not affected by camera, I would add them in another fragment, right?
    Dave Smith
    @davesmith00000
    Damnit I didn't think of that. 😄
    No it's scene level, but you're quite right that would totally mess up your UI.
    Both of those things are available in release 0.9.0 that I pushed out yesterday, but I'll put in another issue for applying the Camera per layer. Applying per scene fragment doesn't work because they're all squashed together in the end with no way to identity one fragment over another. But by layer will do it.
    Thank you for the suggestions by the way.
    Dave Smith
    @davesmith00000
    The workaround for now is that you'll have to store or calculate the camera position, and when you do that you just move the UI by that amount. That would get complicated with zooming... :-P
    ziggystar
    @ziggystar
    That's actually the same as it was before, when you had to do the pan&zoom for the non-ui elements yourself. But even more confusing. :)
    Dave Smith
    @davesmith00000
    Sometimes I miss the days before Indigo was public, when I could add and remove stuff on a whim to try it out and it didn't bother anyone if I changed my mind or did something silly. Oh well. High quality problems. 🙂
    Dave Smith
    @davesmith00000
    @ziggystar Metals 0.10.5 is out. Trying it with VSCode, Bloop, and Scala 3.0.1 - much, much better Scala 3 support. (Disclaimer: I’ve had it for 5 minutes. Early excitement may yet prove premature. But hopefully not.)
    ziggystar
    @ziggystar
    @davesmith00000 That's great to hear. I'm going to try this.
    Yes, I know that problem. Professionally I'm working on a large legacy C++ code base that's rolled out in about 50 critical applications. It's difficult to undo things. But you might introduce a new interface and deprecate the old one. Just don't do this with too many thinsg at once.
    Dave Smith
    @davesmith00000
    Hmmm. It's something I wrestle with a bit. Indigo is still in alpha, my time is limited, nobody is using it for anything serious (that I know of) and so part of me thinks: Now is the time to just break stuff. Most of the time the compiler will tell you where you need to change things between versions anyway.
    Once it's in beta or even a full release I'll have to be careful about not breaking things too much.
    At the same time, it would be nice to be able to label things that are really new with some sort of "This is one of Dave's flights of fancy, it might be terrible, he probably hasn't thought this through all the way yet" warning. :-)
    Of course, all these things could go away if I had the time, i.e. the money, and I could quite do other things that would otherwise break the project by sheer maintenance overhead if I did them now, like support the JVM and Native. But as long as it's just me doing it in my own time... there's a balance to be found between fearlessly trying/changing stuff and not annoying people too much.
    ziggystar
    @ziggystar
    I think I would go for breaking things. Make it so that you have fun with the project. As long as no one complaints, I would not care.
    I switched my tiny project back to Scala 3 in vscode. It's really usable now. Code formatting is not working at all. Is it working for you?
    And what is the state of the zooming support?
    Dave Smith
    @davesmith00000
    @ziggystar Code formatting, if you're using scalafmt make sure you do this (this fixed it for me - there might be a newer version...):
    version = 3.0.0-RC4
    runner.dialect = scala3
    No change on zooming, I'm current trying my best to finish the roguelike tutorials. :-)
    https://github.com/davesmith00000/roguelike-tutorial
    After that I'll no doubt end up looking at some of the issues I've found along the way.
    Dave Smith
    @davesmith00000
    Also, Scala 3, I've switched back to Bloop. Interesting thing: Bloop itself is far less confused that VSCode is.
    So what I'm doing now is:
    Start VSCode and do "Metals: Import Build" - this lets metals run the latest and greatest version of bloop for you.
    Then if your build is going weird, you can do bloop compile <sbt projectname> e.g. bloop compile roguelike from the terminal. If it compiles then bloop is fine and VSCode has lost it's connection. You can try doing (from inside VSCode) "Metals: Connect to build server" and that often fixes the problem.
    The drastic remedies if things still aren't working are first, try closing VSCode, reopen and reimport the project. And the other - which I haven't had to do for a long time now - is to remove the .bloop and .metals folders and reimport.
    Dave Smith
    @davesmith00000
    But otherwise I now have a pretty reasonable VSCode + Metals + Bloop experience. It's not intellij, but I get code click through, find refs, go to type, auto imports and all the stuff I basically need.
    Dave Smith
    @davesmith00000
    I'm actually compiling in bloop over sbt on the command line now because it's way faster.
    Dave Smith
    @davesmith00000
    @ziggystar a slight improvement to the camera situation will be in the next release:
    PurpleKingdomGames/indigo#186