Cheb's project will be here.

[Chebmaster]

Correction: it seems i mixed things up. SSE has 8 registers, not 16 - that is a latter extension. 8 is still a lot.

[Chebmaster]

After a BIG sidetrack to finishing up my favorite author's DooM mod without his permission (beware of a rabid fanboy and all that) -- a work that took literally months, since June to September,
I am beginning curve back to my own projects.
Remembering what was I doing took some effort, even switching back to Pascal from the horrible twisted hacks of ACS and DECORATE scripting.

I have finished (in theory, mind you: my code still does not compile) several "required secondary powers" without which the basics of layered architecture were not possible.
Did you know that <= and >= operators require their own versions when you do operator overloading? Not a surprise, really, after thinking about it.

Then, after those parts of the foundation were maybe-ready, it was time to think with pen and paper in hand.
Because my habit of keeping everything in my head would have made it explode in this case.

Now, with this sketch in hand, I can plan finer details and class relationships.
There are several consequences:

1. There should be support for several completely self-contained worlds. In practice, two: the lobby and the map. So that the lobby does not reset on map change, for example. But I can also make each team's dressing room a separate universe -- OR make the lobby itself the dressing rooms, separated by a glass wall for taunting.
2. UI cannot just affect the worlds willy-nilly, it must be linked to an agent -- let's call it "player character". Even if it is a dumb spectator camera, or even a placeholder waiting for the player to teleport from the lobby to the map. All effects are called "player inputs" and must go through the multiplayer manager, which gathers all inputs from all players to drive a 100% reproducible layered world. All such inputs must be as lightweight as possible since they are serialized and transmitted over network.
3. When UI reads the world, it reads the "Present surface" layer, which is the cherry on top of the lag compensation. So UI must be prepared for radical changes to the world and the player character between frames, since full-world lag compensation could introduce or cancel results of, say, player nuking half the map.
4. UI cannot reliably link (for monitoring it) to any object except the local player's character and objects created in the base layer. Because, due to lag compensation, objects created in intermediate layers are transient and are replaced by "the same" object from the lower layer when that layer bubbles up -- actually, a separate object unrelated to the previous one.

[Jonax]

Thinking with pen and paper is a good thing. I try that too often. Though my doodles are not as well organized as yours

[Chebmaster]

Well, some things are hellishly hard to develop without drawing signal diagrams on a millimeter grid paper -- namely, thread syncing algorithms. Luckily for me, I still have that *huge* roll of it, probably ten meters or so by one meter. It is quite yellowed and prone to cracking, tho... How long ago did I buy that thing? Or was it bought by my *parents* for my school activity in the 1980s...?

I wasn't going to necro this thread for the time being (until I have at least *some* progress to show), but since you did that anyway, I can say this:
I am not going to achieve progress in the near future: work projects at work demand my attention.
All the free time I had the last year went into this: https://www.doomworld.com/forum/topi...-day-beta-001/
On the plus side, I've finalized the architecture of my engine, the only thing left is coding and coding and coding it into reality.

I have nearly created another Lovecraftian monstrosity in this "carousel of per-tic graveyards". Luckily I ate vitamins, came to my senses and realized that it is enough to have per-layer graveyards and make any layer use the *upper* layer's graveyard.
The *sole* reason to keep instances after the current tic's end is the links to those instances that could be leading from the upper layer via accelerated fields (another invention of mine, managed by the memory manager). But, when the upper layer floats to the very top and vanishes, that's when those stop being a concern. So, the natural decision was to just use that layer's graveyard. When layer vanishes, all the instances vanish -- without calling destructors or even cleaning the graveyard, because I upgraded my memory manager for using different memory pools for different layers. Erasing a layer is as simple as dropping the pools associated with it.

My second big decision was making the architecture a bit more complex, which will include some painful juggling and having several "worlds" in the base layer, each of which could be at a different tic and could be downloaded from the server independently. My main reason was a dream of having a lobby (with the chat being its part) that does not disappear on map transition.
It is an *old* annoyance when you want to type something profound like "Lol ez wusses" but the map changes and your words of wisdom are lost.
So if the lobby (thing TF2's dressing room) and the actual map are two universes inside the same server the client connects to independently, then, since the lobby is featherweight and could be connected to nigh instantly:
1. You start choosing your class and cosmetics, seeing other players and the in-game chat/voice communication right away, before the engine finishes the "download the snapshot + fast-forward the snapshot to the actual tic" combo on the main map.
2. Reconnecting after losing connection would feel much less frustrating if you could spend most of that time in the lobby, aware what is happening.