Calamity Engine
- 4 Devlogs
- 21 Total hours
A 2D portable game engine written in C++ with SDL3 targeting older platforms (such as the Sony PSP)
A 2D portable game engine written in C++ with SDL3 targeting older platforms (such as the Sony PSP)
we back baby
I finally figured out what was going on with the github workflow! The issue was that I was using an outdated version of download-emscripten and the emscripten version being downloaded was fried and that would mess up the loading. In the process of fixing the runner, i also migrated it to an arch container for no specific reason other than I like arch.
I refactored every example (except graphics-settings and multi-window) to run on console platforms and work with controllers! The code in the examples is now a better resource for learning the ins and outs of Calamity Engine.
You can now see what modifiers are active in a key event now (look at InputEventWithModifiers)
visible and enabled properties on NodesBefore alpha 1.1, components (i.e. sprites) handled visibility individually but I decided that I don’t like that and now visibility a property of the node class! It is also inherited down the node tree to the children of the node.
I also added the enabled property to Nodes! While visibility affects the rendering, the enabled property basically stops all lifetime functions such as update, physicsUpdate and input along with render.
Windows is now fully supported and every issue I have encountered is ironed out. The console is now hidden in release builds, etc, etc
I added the graphics-settings, multi-window, button and raycast examples. You can check these out on the website (except for graphics-settings and multi-window because those are desktop specific)!
And with this devlog, I will be publishing Calamity Engine 1.1! i really don’t know what else to say so i attached a video of the new node-tree example
i’m back with another fire devlog
I made a lot of changes to the Physics service, including adding the SegmentShape, Raycasts and overall tidying up the service by creating the PhysicsBody class. Every physics body (Rigidbody, Staticbody) inherits this class.
Also, every physics body now has a signal for when the mouse enters and leaves the shape! This allows the creation of ui elements (i.e. look at the button example)!
You can build the game on Windows either using mingw64 or MSVC! There are a couple of issues though…
Windows support isn’t necessarily a top priority for me right now, but I will be working on it and hopefully getting it ready for when I create the next release! (also there’s some edge cases regarding the calamity folder on MSVC and especially on mingw64 where you have to manually copy over the dll of every vendored library)
I’m working on tidying up all the example code and adding console platform support to every example! (for example, the node-tree example didn’t have any console support). I also added two new examples - button and raycast. These demonstrate how to use the new additions to the Physics service!
I want to fix the GitHub workflow that runs every push, it compiles every example for emscripten and builds the website. But, for some reason, the examples don’t load properly when the runner pushes the website. It works properly when I do it manually and the workflow runs the exact same commands I do… It’s a pretty weird issue and it’s very hard to debug but I want to get it fixed for alpha 1.1.
After I fix the runner and finish tidying up the examples, I will create a new alpha 1.1 release! I don’t know if I will ship the project yet, I don’t think I have enough hours and I kinda want a bigger payout xD
Because of a lot of internal changes (i.e. multi-window support), the node-tree example broke :(
Saving and loading sprites and textures was broken however i got it working again! Saving and loading any physics shape was also broken but now it’s also fixed!
(i still have to fix loading for animated sprites/animations which will also be a pain in the bum bum but it is what it is…)
lookAt() on TransformsPrimarily, I want to ship a more definitive version of Calamity Engine. I want to expand to more platforms, add networking, improve audio, add a ui library among other smaller things.
Instead of one big release (alpha 1.0), i will probably be splitting ships across smaller releases (i.e. i want to release an alpha 1.1 version when i’m done with some smaller fixes and physics additions).
When all of my goals are achieved with Calamity Engine, I want to work on a separate project that uses Calamity Engine - a cross-platform Navidrome client! I’ve always wanted to use my PSP as a music player but because I can’t be bothered to keep updating my playlist/redownloading music, I never got around to it…
I also want to remake simulator canalizare 2019 in Calamity Engine and ship it to whatever platforms my engine will eventually support (technically, PS2 support is possible! Cross platform support really depends on how good the homebrew SDK’s are though. For each and every platform I want to get Calamity working on, I basically have to port spdlog, cereal, fmt and box2d myself unless i get really lucky and there are already maintained packages for all of those like on the PSP.)
calamity engine will resume development on stardance