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. |
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. |
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 |
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. |
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 |
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) |
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. |
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. |
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). |
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, excluding 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 compilation 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 |