To be Done Before Rotating Cube #21 is Released

Hurdle Status Reason
Making "game modules" for all platforms except Win32 full-fledged executables thus limiting the developer mode to Win32 only. Arrrrgh Free Pascal isn't there yet, exception handling in threads created by a DLL in particular and DLL support in general aren't too good. I managed to patch that for Win32 at the cost of titanic effort (and fpc 3.2 patches it as well making my patch redundant) but Linux versions aren't that lucky. I have to work around that and making each module a complete engine executable is a viable method. It removes the necessity of making such patches, which take too much time and effort.
Finishing moving the entirety of mother GUI locic to a specialized module Almost done, one error screen left to perfect. What I created initially was a mess too complex to support. Unification is in order, so that the mother can only display console with one built-in bitmap font. This would allow support of FreeType in the future.
Rehauling GUI classes I'm shoveling and shoveling and it doesn't end. Testing my ideas on a mock game menu for a competition revealed many small flaws that have to be addressed. Other than that, it is done, just very alpha. I failed to make it in time for the annual GUI contest of September 2018 but I made it for the one in September 2020.
Catching horrible bugs in the asset loading code My work is cut out for me :( Even the rotating cube now crashes! The rehaul wasn't kind to my mechanisms of background resource loading.


Postponed for the Rotating Cube #22

Hurdle Status Reason
Memory manager with heap tracing switchable on the fly Foundations, laid. There is no other way to find object leaks. Heaptrc won't work with my screwy engine structure (meaning: I often forgo freeing memory, before unloading the module DLL)
Laying foundations for layered game world Paradigm, chosen. Specialized memory manager, completed. Now to implement the logic of it. This has to be done for my engine to have any worth. See the "Multiplayer based on lockstep-in-the-past with full-world lag compensation via layered physics: allow for MMO-level numbers of players, also epic floods and epic scale destruction with zero impact on network bandwidth." killer feature.
Creating an exception catching hack for Linux Planned, mandatory Turns out, exception handling in Linux in threads created by a DLL does not work without creating a hack similar to the ones I created for Win32 and Win64. The try..except operator simply doesn't catch them because for it to work, the signal from the OS has to be converted into a language exception. The default mechanism of the FPC RTL is simply not designed to cope with threads in a DLL.
Perfecting window manager for Linux (32 bits only) Gathered enough samples and howtos, so far. Note that I am using a slightly, ahem, outdated XUbuntu 11.04 32-bit running my file server. As well as Raspbian 10, also 32-bit I need to make fullscreen work, at least. And mouse capture. And re-check if the pen tablet support (hakkus horriblius) still works
Making the RPi version work Besides lacking a fully functioning window management for Linux, the RPi version starts up but crashes after several seconds (unaligned memory accesses much?). Raspberry Pi 2/3 is the ultimate test platform, bro. It can barely run Quake 3 at 60..80 FPS. Lowest of the low. My strategy is: if RPi can't support something, that something has to be optional. Optimizations for GTX 1060 and Vulkan support are in the tail end of the queue, right after gaining world-wide popularity and hiring a team of 3d artists.
Support custom swap files in my class instance memory manager It's already Designed with support of this feature in mind I'm afraid I would need this on RPi with its measly one Gigabyte of RAM.


Postponed for much later

Hurdle Status Reason
Making x86_64 version for windows work I think I got rid of most of blunders in pointer arithmetics. At least the x86_64 version is much less crash-happy now. Restricted to the incomplete fpc 2.6.4 or unreliable trunk version until fpc 3.2 is out
Making Linux version work always Waiting until Free Pascal 3.2 is the default one in Debian (which would take forever and a half considering it's not even out yet) Linuxes are 64-bit nowadays but porting Chentrah to x86_64 is not really possible until we get line info working again, for which you either need trunk fpc (I'm not using that in Linux) or the final 3.2.0


Obstacles Left Before The Rotating Cube Curse is Lifted

FYI: impressed by Fidel Castro's resolution, I swore an oath to never shave until my engine passes the rotating cube stage. After awhile, my beard stabilized at 15cm length, its growth balanced by shortening from me combing snags out, which often ends in tearing a chunk off. I sincerely hope I would not be buried still unshaven like him.

Hurdle Status Reason
Streamlining the mother-to-module interface API I'm shoveling, and shoveling... Mah eyes are bleeding!
Rehauling text rendering and fonts handling Requires texture atlases The old one was convenient but not extendable (if I ever want support for FreeType or Chinese). Plus I have nice pixel fonts I spent a lot of time drawing many years ago. The old system could not utilize them.
Texture atlases In line... Will serve for both player models and terrain meshes
Md3 and md2 with animation Shoud not begin until I have texture atlases One of the necessary tools
Multitextured, cheaply modifable terrain mesh Shoud not begin until I have texture atlases This will be the staple of terrain rendering
Fisheye viewport with 120 degrees support After I have terrain mesh This is how the game will display, once and for ever
Get rid of OpenAL, add support for ALSA and make the sound system at last! Plans only, for now. This is low priority, but necessary. OpenAL has horrible support all around, has terrible latencies and is generally very limiting. I have to build a sound system anyway, on top of low-latency APIs like DirectSound 8 and ALSA (provided by the mother as an opaque abstraction layer).
OpenCL support Contemplating Let's see how physics turns out, first.


Platforms Supported

Platform CPU Support Unicode file path support OpenGL OpenGL ES
Windows (XP..10), Wine x86 For now this is the only supported platform where most development is focused. This will be the only platform where the developer mode is possible! Yes 2.1 2 (testing only)
x86-64 stalled, scheduled Unnecessary
Linux x86 Dropped: no reason to support, the platform is gone. Major distros only support x86-64 nowadays. native utf-8 2.1 Unnecessary
x86-64 stalled, scheduled
Raspberry Pi 2 to 4 (as ARMV7R EABIHF, 32-bit) Work-in-progress
(intended as stress test for the engine and for bragging rights) 		n/a 2
Android No. Making a Java framework would be too much bother. Besides I haven't got to trying smartphones yet, quite content with my 12-years old cellular telephone. What did you expect?
Mac OS X, iOS   No. Because I consider all Apple products spectacular waste of money. Whenever I can spare that much I use it for a vacation at a 5-star Carribean resort instead.
Any BigEndian platforms PowerPC, Sparc, ... No. Because the porting cost for my database engine would be prohibitive


Minimum system requirements

Support Hardware Details
Work in progress Raspberry Pi Model 2 B While it keeps working, I will strive to supportit. May have to change to RPi 4 later, though (I bought a RPi 3 as well but it failed: one tiny capacitor fell off, now the board always trashes filesystem on shutdown necessitating fschk via separate Linux PC each time I turn it on)
Current Core 2 Duo / Athlon X2 / GeForce 8400 GS / Radeon HD 2600 The hardware of 2007 that has reasonable feature support allowing me to develop without too much hassle. I feel comfortable with SSE2, FBO and GLSL. Nothe, though, that any video cards without NPOT texture support are out (including GeForce FX 5xxx)


Graphical APIs Supported

API Versions Support In detail
OpenGL 2.1 Primary My main target GAPI for the PC platforms (Windows, desktop Linux)
3.2 Planned Just because forward contexts may have better support / optimization. Definitely after I have a couple working games.
OpenGL ES 2.0 Yes Primary for Raspberry Pi 2. Other than that, supported in the formn of Win32 + ANGLE (to better debug and catch bad shader code on a fast machine).
3.0 Planned For Raspberry Pi 4
Direct3d 9 and up No need There is such thing as Google's ANGLE (GLES over DirectX). I already use it for testing purposes. Future-proofs my engine nicely.
Vulkan ? At the tail end of an impossibly long queue I probably should, someday, but there is no pressing need: there is such thing as GLOVE (GLES over Vulkan). I want to make a working game first anyway. Then, object-oriented API headers would be a colossal pain to convert to my unconventional split architecture where one executable module loads and initializes the API which is then used by another executable module in a DLL that can be unloaded and re-loaded at any time.


Sound APIs Supported

Note: the sound subsystem is currently an unimplemented mess that can only do simplest "play a .wav file" as was required for the menu.

My target is implementing my own sound engine with sound effects processed on the GPU to allow effects only usually available to select EAX enthusiasts for everyone and their dog with a piss-poor Realtek chip.

API Support In detail
OpenAL Will remove Whatever little there is now, I will cut it out and drop support. As soon as I implement ALSA so that I have sound in Linux.
ALSA Planned This will be the only sound API supported in Linux.
DirectSound 8 Yes Intended for WinXP and below, it will stay the sole API for the Windows platform for a while until I get to implementing Core Audio support
Windows Core Audio/WASAPI Planned Intended for Windows Vista and later, this is required for acceptable latencies as DirectSound is a stuffed animal on modern Windozes.


Windows Versions Supported

Version Supported Details
Wine YES I was always aiming at Platinum level of Wine compatibility, from the very beginning: I was using Linux as my primary OS when I was laying foundations for my engine. Runs fine in Wine versions as early as 1.3
98 / Me NEVER It was a cool idea at first but became an unsustainable effort sink as time marched on. I am mortal, I ain&t got an eternity for such frivolities.
2000 Unknown In theory, there is nothing preventing me from supporting Win2k. It's just a hatchling of WinXP, after all. Would require me to install it on one of my Core 2 Duo fossils to check if it works or not, though.
XP YES There is nothing in my code that would prevent it from running in WinXP. I regularly check if Chentrah still runs on my Core2 Duo fossils with their relic video adapters.
Vista Probably Skipped it. There should be no obstacles to Chentrah running.
7 YES It's where my development is focused. I will keep supporting it for as long as I am alive.
8 & 8.1 Probably Skipped these steaming piles. There should be no obstacles to Chentrah running.
10 YES With a few quirks (Chentra reports to Win 10 it is DPI aware while in reality it is not, it just always stretches the game menus to the whole screen).


Free Pascal Versions Supported

Version Supported Details
2.4 No Missing language features make building the project impossible.
2.6.4 ABANDONED This was my primary development platform until 2020, but time came to bury the venerated dead. 3.x is finally mature enough not to crash on my source code and 2.6 is stifling.
3.0.0 No Both the x86 compiler and the cross-compiler to x86_64 were crashing with internal errors, unable to build my project at all.
The ARM version in Raspbian 9 @ Raspberry Pi 2 worked fine, but that's historical curiosity now as Raspbian 10 with fpc 3.0.4 superseded it.
3.0.2 Unknown Skipped it
3.0.4 Yes, exclu­ding x86_64 Works perfectly fine for x86 and Raspberry Pi, but the x86_64 versions have stabs disabled (see bugs 23365 and 34234), which makes debugging impossible.
3.2.0 Yes, but com­pi­la­tion is slow Everything works fine except compiler crashing unless I delete all *.ppu from the previous run, thus forcing me to do a full build each time. See bug 37746.
3.3.1 trunk YES Finally compiles without the compiler crashing. It is trunk, though.
3.4 My distant target This would probably be my "recommended" version -- unless some lingering bugs are fixed in 3.2.2