Hi. I’ve talk with Michalis about this so here I go.
I’ve published version 1.0 of my Amateur 3D Game Engine.
This engine is based in the one I wrote for my 2nd PGD Challenge back in 2012. Such engine was written in about one single week and was pretty buggy because the hurry and also because Allegro.pas 5 was in a very early development state in that moment. I’ve fixed a ton of bugs, changed a bit the API and added some basic functionality.
Right now the engine is very simple and lacks a lot of functionality. I have a roadmap but since I’m working on this in my free time it will take time. Note that the engine is Amateur so it won’t be as big or advanced than other engines. If you need something professional, please use Castle Game Engine; the latest releases are really good.
At the moment you can get the engine from here:
Someday I’ll have a proper webpage. You can see some screenshots at the summary page.
Thanks for this information. As I mentioned also in private, we welcome talk / announcements about other game engines, and announcements about new game engines in Pascal / open-source are esp. welcome 
Some notes:
Thanks Michalis. I’m always open to sugestions. 
I have my concerns about glTF maybe because I find it quite “over-engineered”. That doesn’t mean I won’t add support glTF for models or something in the future, I’ll certainly do but I don’t think I’ll use it as main format. I don’t believe that “one solution for everything” is a good idea.
About octrees, yes, currently A3DGE works with octrees in mind. I understand it will be a problem to integrate with any existing physics engine. The idea (for version 2.0 and beyond) is that the world container (my TWorld3D
class) will be an abstract class and extend it as a couple of containers: an octree-based (without physics) and a sector-based (Build Engine or IdTech1, again without pysics). Maybe also a container based on a pysics engine but I didn’t decided wich one yet. This way you can select the best way for your game, or even create your own crazy container (the engine is for amateurs, and amateurs love to do things by ourselves
).
The reason I didn’t it this way is because the lack of planning. Version 1.0 is mostly a bugfixing of the original engine I wrote back in 2012 and back then I didn’t plan a lot (I did the whole thing in a single week which amazes me today!). For A3DGE I initially planned a different engine from scratch and started to develop it but I found it would be a little bit complicated so I decided to step back, store what I did (it’s in /branches/pre-2.0), fix the old engine and then use both experiences for version 2.0. And I think it was a very good idea because I made version 1.0 in a few months while it would take years to finish the engine from scratch, and the work revealed that some of the ideas I had for the engine were bad ideas.
Thanks for the advice about the webpage. I was planning a more complicated one, similar to the one I made for Allegro.pas, but I think you’re right: a single README.md
with an introduction and a link to the online API documentation should be enough.
I’ve uploaded a bug-fix version number 1.0.1. I found a few little bugs that didn’t prevent to build simple games but were a bit annoying sometimes. Also, I have a proper website now: A3DGE - Downloads
BTW I found that Free Pascal has a bug that prevent to compile the Wavefrong .obj unit with optimizations due to an “internal error”. It seems to be fixed on fpc 3.3 but it’s not in the stable branch yet (yuck!).
Also I was testing the new Debian 13 in my brand new computer and I’ve found tha the mouse input is very delayed when compiling for debug (it happens also with Allegro.pas). I have to do more testings. Quite annoying.
1 Like