How we tell if a map is running...

[mh]

...and what we need to skip if one isn't.

Quake is rather crap in this regard. In the stock engine I'm seeing a number of different ways of detecting if a map is currently running:

Code: Select all

if (cl.worldmodel)
if (cls.state == ca_connected)
if (!con_forcedup)

etc.

This is crap. There should be a single cls.maprunning or similar flag which is set in R_NewMap and cleared in CL_Disconnect_f. One way in, one way out, less error prone, less bugs.

What do we need to skip? V_RenderView, R_RenderView, intermission screens, the status bar, I don't see why we need an FPS counter if we're not in a map, centerprints should go, etc. These all have their own different ways of being skipped, they're checked in the individual functions, and again it's crap. The checks should be all together in SCR_UpdateScreen:

Code: Select all

if (cls.maprunning)
{
   // draw stuff that's relevant for an active map
}
else
{
   // just the console and menus, really
}

Again it's the "one way in, one way out" thing at work.

Another chunk of messy Quake code that's been a source of bugs in the past.

[Baker]

I like this one ... a lot.

I've been trying to sort through that spaghetti lately.

CL_Disconnect does not do what it should. Not even close. For example, there is a ton of stuff in R_NewMap that clears out things. Every state should have a beginning and an end.

You get an error or disconnect from a server, it should clear the memory right then, reset the lightmaps, unload the textures for that map (in theory ... in reality maps share a lot of textures).

Plus there are 2 or 3 weird situations. The brief time in between maps (startdemos queue, before and during the reconnect command in client-server connection, etc.) Situations where technically the client isn't playing a map at that precise instant, but treating it like no game is running is wrong ... DarkPlaces does this and if you hold down a key in between maps, it gets typed into the console.

I'd argue that there are 2 distinct states ...

1. A map is running
2. A game is running

A game can be running without a map running at a precise instant.

If I am sitting at the console due to an error or a disconnect, no map is running and no game is running. If the loading plaque is up, a game is running but no map is running.

Mentally replacing "show loading plaque" with "game_running = true" is probably a start.

[mh]

A little gem from SCR_SetupToDrawConsole:

Code: Select all

con_forcedup = !cl.worldmodel || cls.signon != SIGNONS;

Aaaargh! These states have NOTHING to do with the console. This is a rubbish way of determining whether or not to draw a full console. (cls.signon != SIGNONS is a fourth way that's used elsewhere; yes it's relevant info in places, but it should have nothing to do with the renderer).

[Baker]

A little gem from SCR_SetupToDrawConsole:

Code: Select all

con_forcedup = !cl.worldmodel || cls.signon != SIGNONS;

Aaaargh!

Yeah

Brief infos for the unknowing ... Quake does a sequence of information exchanges (basically the connection handshake) with the server even in single player where the client and server exchange info. cls.signon begins at (I'm thinking 0) and after each exchange, increments cls.signon. The client is not fully signed on until cls.signon == SIGNONS (fully signed on) because it does not have enough of the game state data to render the game state (properly). Like it knows the map name, but hasn't received all the entity info and doesn't have enough info, for instance, to show the scoreboard correctly. If cls.signon != SIGNONS, the client has some but not all information about the game state is essentially in a state of partial knowledge about the game world state but not in a state of complete knowledge.

[Spike]

if you have no map, or partial game data state, then the game cannot be reliably rendered yet.
forcing the console to be 100% visible at that point makes sense.