macroquad VS pixels

See the macroquad docs for full details on building a WASM game.

Any opinion on ggez? I don't like how everything in macroquad is global state https://github.com/not-fl3/macroquad/issues/333

I prefer examples like the ones in Macroquad: https://github.com/not-fl3/macroquad/tree/master/examples. I'm not against advanced examples, but the priority should be extremely clear, minimal, self contained ones.

There were even discussions about deprecating static mut. Even if you think you got it right, there are too many things that might go wrong, like aliasing. For example, macroquad needs a complete rewrite because of their static mut.

It's based on macroquad and you can play the wasm version here: https://unvirtual.github.io/yinsh-rs/

The reality is that I have used unsafe that is also unsound out of convenience because fixing it is a papercut too many. And this tends to be common! I know enough to spot unsoundness in other projects (sometimes even early). But not enough to be confident in my own abilities to write sound unsafe code. Why? Because it's really flipping hard, that's why!

Given that you are making a game, you might want to consider using a game framework such as https://github.com/not-fl3/macroquad/.Macroquad has full support for WASM, and will allow you to render your game both locally and in the browser via WASM depending on how you compile it.

https://github.com/parasyte/pixels

That gives you a simple software framebuffer, and it builds as a native app or for the web.

On a more recent machine, that same (well, more primitive) app with pixels or softbuffer struggled beyond acceptable. But was definitely poorly written.

I’ve ported the application from being based on pixels crate to the powerful bevy game engine

Well, it depends on how you use it; writing to an image buffer isn't much less efficient than writing to any normal buffer (in fact, although displaying your scene to a window efficiently is important, your main bottleneck will be the actual ray tracing loop). You may want to read this article for a practical example of using an ImageBuffer to create and draw a texture with Piston. Other window backends you could use, apart from pixels which was already mentioned in another comment, include minifb and Mini GL, though I haven't personally used them.

You can use wgpu instead of opengl as in the pixels example: https://github.com/parasyte/pixels/tree/main/examples/minimal-fltk

It might be possible but with a raycaster you probably want to be able to easily set all pixels and create your own small engine. Something like the pixels crate should fit your purpose: https://github.com/parasyte/pixels

The reality is that I have used unsafe that is also unsound out of convenience because fixing it is a papercut too many. And this tends to be common! I know enough to spot unsoundness in other projects (sometimes even early). But not enough to be confident in my own abilities to write sound unsafe code. Why? Because it's really flipping hard, that's why!

Also, if you just want to get-things-done, then https://github.com/parasyte/pixels might be a bit better, to avoid reinventing the wheel.

However, I recently got a new M2 Macbook Air and started noticing some super weird behavior. While playing Pokemon Silver with an unlocked framerate, I'd notice that the game would slow down to below 60FPS, even on a release build. After printing a little debugging info I found the culprit in the rendering logic which was handled by the MiniFB crate. At first I thought switching to a GPU renderer (such as https://github.com/parasyte/pixels) would help, and it... kinda did?

pixels uses wgpu and runs fine.