I've been trying write a game from scratch (emphasis on "scratch" considering the scale of the itch) as a side project, but that quickly evolved into an excercise in overcoming analysis paralysis.
I'm currently stuck on "can I count on the HTML Canvas to optimise cases where a tile is out of view or should I make a fancy system to calculate that now?"
I get an average of 2h a week to do this, so I need to be really careful not to go into one of the many rabbit holes there.
In any case I recommend Entity Component System as an architecture for games. You can write 20 lines of code at a time and still make demonstrable progress.
I am not sure if I understand you correctly, but since I did wrote a canvas game from scratch, I can tell you that you cannot count on the canvas to optimize anything (and likely not what you want in this case)
Every browser does it a bit different and it will depend on the hardware and OS what optimisation features are avaiable.
On average the canvas is quite performant, though.
Performant enough, that in my case, I draw everything on a big map - zoom in and then move the map around, when the player moves.
On a gaming PC, maps can be quite large - but on an average mobile not so much.
But I autogenerate the levels which means I can dynamically adjust size, so this works for my game.
But in general yes, you want a small canvas, the size of the screen - and then only draw what is needed.
EaselJS may help with that. It is basically flash on the canvas, but does exactly this. You put all your graphic objects on the stage - and easelJS will figure out which one of those needs to be drawn at the current frame. I initially used it, but not anymore as it was not optimized for my use case, making LOTS of new draw calls on the map every tick. But for a classic game with limited entities, it is very performant.
Bad wording on my part. I noticed somewhat of a performance difference when drawing an image at coordinates that are outside of the canvas boundaries and was wondering if the scale of this is significant.
Do you have the source of your game published anywhere?
You mean you have a canvas of 1000 px size and make a drawImage at x> 1000?
Well in that case the image does not get drawn at all, so most browsers should indeed be more performant by ignoring this call. But there might still be a overhead of loading the image, so I would check the boundaries and not make that call, if it is not necessary.
(The canvas itself is just a large array of numbers after all. And if you do not manipulate that array when your new values are outside of that boundary, nothing happens. And a image is usually just a pointer to another large array/blob, so if the browser is smart, it does not load that array, when it finds out it does not have to)
"Do you have the source of your game published anywhere?"
Unfortunately not yet, but soon I will release. I hope.
By the way I wonder if it is reasonable to expand the "requirement" to - wasming is ok if you are writing the game from scratch in say rust instead of just compiling old binaries to wasm?
I'm terrible at making games but working on them brings back the joy I had when I first learned to program. The feedback loop between code and something interesting on the screen is quick and refreshing. Lately I even managed to make a basic VR game with my Quest2.
I've also found the unity editor to be pretty unstable on Linux so if you happen to have any tips there I'd be all ears
I was also looking for books, and the Unity 2020 Virtual Reality Projects Book[2] looks promising, and I just got a used copy (still being sent to me). Again since it's from 2020 there might be a couple things out of date, but it looks like it could be worth it.
I use Unity in Windows so I can't help on the Linux front.
Good luck! You can ping me if you get stuck somewhere, I might have had the same issue and might be able to help you get unstuck.
[1]: https://www.youtube.com/watch?v=gGYtahQjmWQ
[2]: https://www.amazon.com/Unity-2020-Virtual-Reality-Projects/d...
Another, way more generalist source for tilings :