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.
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.
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.
I have now this working, which is different from the examples:
.modifyMaterial {
case m: Material.Bitmap => m.toImageEffects.withSaturation(0)
case m => m
}
Is it like some stages, and it's always
Bitmap → Effects → ShaderData ?
They default to Bitmap because it's the least expensive/sophisticated.
Like, have a
Does this make sense?
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).
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. 🙂
This one allows you to have a scene camera:
PurpleKingdomGames/indigo#169
PurpleKingdomGames/indigo#169
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?
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.
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
@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.
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.
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.
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.
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?
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.
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.
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
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.
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.
@ziggystar a slight improvement to the camera situation will be in the next release:
PurpleKingdomGames/indigo#186
PurpleKingdomGames/indigo#186