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.
Reply With Quote
Bookmarks