In fact the whole thing then becomes a standalone function which takes Location and other relevant parameters and returns the computer sunrise/sunset values. Pure function and super easy to unit test.

If one needs to do a lot of "mockups" for your unit tests then maybe one needs to consider the API and class design. Removing needless coupling helps testability by removing the need to use mocks in the first place.

"Hot reloading is a good example."

Again. You don't need WASM for hot reloading.

Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.

Well, ... the Qt3D is a higher level framework that isn't really relevant to the stuff I'm doing considering that I'm basically running my own "framework", i.e. my game engine that renders to my rendering surface.

In my use case what I really need is just to have Qt provide me a rendering surface with good performance (and ideally with working integration with the rest of the widget system) and then get out of the way.

The demo games have Emscripten filesystem images that vary from 6mb to 100mb. These sizes reflect the combined size of the raw game resources (i.e. fonts, textures, audio files etc)

I chose Qt because I'm already very familiar with it and I know that it can do so much stuff out of the box and I want the editor to work as any other app as much as possible, i.e. tooltips, shortcuts, cut/copy/paste keyboard focus etc.

So everything works fine (as long as you know Qt's quirks) except that:

OpenGL support is kind of a mess. You have QOpenGLWidget, QGLWidget,QOpenGLWindow, QGLwindow which can all support OpenGL rendering. The problem is that while QOpenGLWidget works nicely with the rest of the toolkit ( context menus etc) the Performance is very suboptimal. I found it to be an magnitude of order worse than just using a window. I'm sure there's something else going other than just FBO overhead.

Another problem related to this but not unique to Qt is how to render to multiple window surfaces but to keep to a nice framerate. If you use vsync on each surface your framerate will be your display sync divided by the # of your surfaces. If you don't vsync then you're running a busy loop and burn cycles in a busy loop. I've tried many ways to do this nicely and haven't found a perfect solution yet. Would be very happy to hear some suggestions. Currently I'm just adding a little thread delay to cap the CPU use but this creates little hiccups in animation sometimes.

Just wanted to show this little 2D game engine that I've been working on for some time (around 2 years on the editor part, longer on some of the components).

It's quite full featured but obviously this a project of such magnitude already that the work never really ends. That being said it's definitely already at a point where games can made and published. The editor runs natively on Windows and Linux using Qt5. The games can run on both Win and Linux as well as on WASM with WebGL.

Feature wise there's a bunch of the stuff you'd expect.

Audio, graphics, scripting, animation+entity+gameplay systems, physics and UI are all there. Scripting is through sol3 + Lua, physics with Box2D. Audio, graphics, UI and game play stuff is all done by me.

License is currently GPL.

Source code is on github https://github.com/ensisoft/gamestudio

Some games are available on my site at https://ensisoft.com/games.html

Comments URL: https://news.ycombinator.com/item?id=30620897

Points: 121

# Comments: 21

The reality is just like with sellable (software) products (code) quality doesn't matter when it comes to "success".