Cheb's project will be here.

[Chebmaster]

Then you can create as many log objects you want (maybe just an empty one) then you can assign them to each engine's subsystem.

Nice
I couldn't do that, simply because I am restricted to procedural APIs: the devmode module DLL cannot use classes of the mother executable.

For me, there's also a question of performance, any logging has to be wrapped into
if Verbose then AddLog(...)
because sometimes I stick logging in time-sensitive areas.
If I do simple
VerboseLog()
instead, which checks conditions on its own, that's still a lot of passing around strings, "array of const", maybe IntToHex here and here - and hello, slowdown.

So as I do that anyway, I just upgraded from
if Mother^.Debug.Verbose
to
if Verbose(<condition>)
, which simply checks an enum against a set.

for example,

    if Verbose(vla_Chepersy) then AddLog(
      'Freezing the database state, the memory manager has %0Mb committed'
      + ' in %1 blocks'
      ,[Cps.MemoryManager.TotalAllocatedSysMem div (1024 * 1024),
         Cps.MemoryManager.NumBlocks]);
    MOVE(chepersy.Cps, SavedChepersyState, sizeof(chepersy.Cps));
    FillChar(chepersy.Cps, sizeof(chepersy.Cps), 0); // NO deinit!

But! More importantly, I finally found a good alternative to LGPL, which I used since the very beginning in 2006, and switched my engine to MPL 2.0
It allows what I am aiming for (static linking with map scripts of questionable reputability auto-converted from the ACS language to Pascal) while still allowing to use my code in a GPL project if someone so wishes.
Turns out I had accumulated lot of third party code, with a zoo of different licenses, all of that had to be reviewed and addressed.

Chentrah
Copyright (C) 2002-2021 ChebMaster (user5543@chebmaster.com)

The source code is covered by following licenses:
The OpenGL and OpenGL ES 2.0 headers
under SGI Free Software License B

The JEDI DirectSound headers
under dual MPL 1.1 and LGPL

The Broadcom library headers (c) 2012, Broadcom Europe Ltd
under custom free permission
- see un_gles_raspberry_pi.h

The Vampyre Imaging library
(see the 3rdparty folder)
under dual MPL 1.1 and LGPL

The modified part of paszlib (un_unzip.pp)
under custom free permission
- see LICENSE-paszlib.txt

The modified parts of Free Pascal RTL (various parsers of debugging info)
under modified LGPL 2.1 allowing linking into executables regardless of license
- see LICENSE-FPC.txt

The rest of the engine
under MPL 2.0 - which allows use under GPL/LGPL 2.1 or later

If some source file does not contain license information
it means I forgot to embed the MPL2.0 notice.
Poke me with a stick.

Please see how I handled a dwarf parser unit borrowed from RTL and tell me I didn't do it wrong

{
    Modified by ChebMaster in 2018 to integrate into Chentrah

    This file is part of the Free Pascal run time library.

    Copyright (c) 2006 by Thomas Schatzl, member of the FreePascal
    Development team
    Parts (c) 2000 Peter Vreman (adapted from original dwarfs line
    reader)

    Dwarf LineInfo Retriever

    See the file LICENSE-FPC.txt, included in this distribution,
    for details about the copyright.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 **********************************************************************}

This is the file LICENSE-FPC.txt, it applies to modified fragments of
the Free Pascal Run-Time Library (RTL)
distributed by ChebMaster (user5543@chebmaster.com).

The source code of the Free Pascal Runtime Libraries and packages are
distributed under the Library GNU General Public License
(see the file LICENSE-LGPLv2.txt) with the following modification:

As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your choice,
provided that you also meet, for each linked independent module, the terms
and conditions of the license of that module. An independent module is a module
which is not derived from or based on this library. If you modify this
library, you may extend this exception to your version of the library, but you are
not obligated to do so. If you do not wish to do so, delete this exception
statement from your version.

If you didn't receive a copy of the file LICENSE-LGPLv2.txt, contact:
Free Software Foundation
675 Mass Ave
Cambridge, MA 02139
USA

[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.