Cheb's project will be here.

[Chebmaster]

P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).

Alas, the said support became an unsustainable effort sink. All for a vanishingly small fraction of hardware that
1. is compatible with Win98
2. has Directx9 - class video card
3. has OpenGL 2.0 drivers for Win98 for said video card

I should have done this much, much earlier. It was Ok while my target was OpenGL 1.2 or even when I updated that to 1.4. But when I mage my absolute minimum GLES2 and its desktop substitute GL 2.1 it was time to bury the venerated dead.

The last nail into coffin was my decision to drop support for video cards without NPOT2 support (I have one, GeForce FX5200). Incidentally, FX5200 was the only video card I have that has Win98 OpenGL 2.0 drivers.

As a result I am free to drop supporting Free Pascal 2.6.4 (hello, generics, I missed you so much)

Rest assured, I am still supporting WinXP. I cannot find reasons not to.

[de_jean_7777]

P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).

Yeah, it's not worth it. WinXP is still supported by FPC, so that works more or less with no effort. My engine will support gl 1.2 as one of the renderers, so there's hope I'll be able to port it for older platforms, but really not a priority.

[Ñuño Martínez]

P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).

Alas, the said support became an unsustainable effort sink. All for a vanishingly small fraction of hardware that
1. is compatible with Win98
2. has Directx9 - class video card
3. has OpenGL 2.0 drivers for Win98 for said video card

I should have done this much, much earlier. It was Ok while my target was OpenGL 1.2 or even when I updated that to 1.4. But when I mage my absolute minimum GLES2 and its desktop substitute GL 2.1 it was time to bury the venerated dead.

The last nail into coffin was my decision to drop support for video cards without NPOT2 support (I have one, GeForce FX5200). Incidentally, FX5200 was the only video card I have that has Win98 OpenGL 2.0 drivers.

As a result I am free to drop supporting Free Pascal 2.6.4 (hello, generics, I missed you so much)

Rest assured, I am still supporting WinXP. I cannot find reasons not to.

Curious: I'm doing exactly the opposite. Too soon to announce though...

[Chebmaster]

In the end it all depends on system requirements. When I learned GLSL and realized how much freedom it gives I was firmly set on using it. I also implemented physics in a separate thread so multi-core CPUs became a great bonus if not outright requirement.

This resulted in my target hardware being a Core 2 Duo + a DirectX9c class video card. That's around 2007. While Windows 98 with drivers available to it barely reaches 2004.

[Chebmaster]

It seems COVID did not simply damage my brain making me tire out rapidly. It also dislodged thought processes long ossified in their infinite loops.
I looked back at my code and was horrified. Those paths led me astray, into deep madness and unsustainable effort, already feeding a downward spiral of disheartening and procrastination.
The best excuse I could come with was "Tzinch had beguiled me".

So I am now performing a feature cut with all the energy of an industrial blender. Returning the paradigm back to the simplicity it had in the early 2010s while salvaging the few real good things I coded since.

* switching modules in-engine has to go. Every module (game, tool) will have its own mother executable with release version of game logic built in.
* only one thread for logic, ever. No ""clever hacks"" to utilize more cores by loading several copies of the same dll. My beard is half gray already and i am still nowhere. The crawling featurisis has to stop *now*.
* the reloadable-on-the-fly DLL is for debugging only. No stripping. The complicated mechanism of storing and processing debug info for it has to go.
* the GUI dealing with logic crashes must have no supoport for the debugging DLL crashing and resolving it. The simple console will do.
* the mother GUI need not have support for the DLL loading progress. The simple console will do.
* the debugging DLL uses the mother executable's memory manager, GREATLY simplifying the mother API. No more need for converting arrays to pointers and strings to PChar and back on the other side.
* the debugging DLL is always version-synced with the mother executable. No more need for complicated version checks and compatibility mechanisms.
* all assets are owned by the mother executable (hello, TMap specialization) thus turning the asset juggling phtagn of old into a complex but manageable mechanism. In the same vien directories and pk3 files are also owned by the mother executable. Need to refresh assets? Restart the exe.

And a major new feature
* all calls to the GAPI (GLES2 or GL 2.1 with extension) are made via new abstraction layer that borrows heavily from Vulkan.

All in all i hope to have the rotating cube back this autumn And then, finally, MOVE FORWARD for the fist time since 2014.

[Jonax]

Sounds like a good plan. SImplify and move forward. I look forward to see the rotating cube

[Chebmaster]

Me too Can't wait ...

I cut one more unnecessary thing. My unconventional developer mode is revolutionary (for 2008 when it was conceived it would have been world-changing) BUT it is also *horrifyingly* costly in man-hours to get it up and running on each platform.

By abandoning it for *all* platforms except win32, I make completing the current refactoring possible during my lifetime.

I spent around a year of my life building foundations for the megahack that worked around exception handling not working in DLLs in fpc 2.6.4 -- but that bug was closed in 3.2 requiring NO such effort. Still no luck in Linux, but then my future Linux and win64 versions won't have any DLLs at all. Only one release build in one executable using one thread for logic.

Enough that I *could* have moved forward with full RPi support as far back as 2016 -- if not for the fact that fpc 2.6.4 for arm was unable to generate working DLLs and I stalled waiting for 3.0x, then procrastinated, slowing down... Had I made this reasonable decision back then... I'd probably have a working game now (even if simple asteroids test). And would not have had that close brush with depression, too.

The quote of my favorite writer applies, "a bullet wonderfully clears your brain even when hits you in the ass" but why did I have to eat covid to realize such simple things?
Trying to learn being more flexible.

On a positive note I finally wrangled the .BAT syntax into submission and redid my entire build.bat for the new paradigm. Short story: use SETLOCAL ENABLEDELAYEDEXPANSION and !MYVAR! instead of %MYVAR% lest woe betide you.

[Jonax]

I haven't used DLLs in ages. In fact DLL troubles was one reason motivating me to switch from Visual Basic to Pascal (Delphi) back in the 90ies. I So far I haven't had to use any for the Pascal. But I've only done simple stuff.

Anyway.. getting rid of them DLLs sounds good. And concentrating efforts on fewer and perhaps simpler areas sounds good too. Though that RPi is an interesting and promising platform. And from my point of view win32 is the platform I use the least nowadays.

Anyway I look forward to see more Cheb stuff in the future. Keep up the good work. I'll try to get my act together and create some new programs too. Though I'm afraid it tends to get delayed.