Quake 3 Hand-me-downs

[techhead]

The Quake 3 engine Trem uses has some problems and non-functionality in it. Whether or not they can be easily fixed, I don't know. However, I can think of 3 off the top of my head…

1. Player and building models don't stay loaded map to map. They are identical every game on every map, why waste processing power and time reloading them every time? It would be nice if they stayed loaded as long as you stay connected to a server.

2. Unresponsive client while map is loading. Cannot disconnect, use console, or otherwise interact with your client until the map finishes loading.

3. Unused cvars. There are at least 100 cvars handed down from the original Quake 3 engine that do absolutely nothing. Some of them are purely vestigial (eg. Railgun rendering). Others are useless currently, but could be useful at a later date (eg. Bots). Others might be useful in Tremulous as it is, but are currently nonfunctional (eg. Spawn-timers; team names).

I'm not asking people to fix these right now. Maybe just think about it and see what possibly is feasible. Probably others that I can't name off the bat, but others can.
Clean up Quake 3 for Tremulous!!!

[Odin]

1. I thought I was the only one who thought this was a problem. I wouldn't mind a little extra game loading time in the beginning(when you launch the executable) to make each map load faster.
2. Hitting escape is the only command that seems to work during map loading, and even then you have to wait for the game to finish loading for it to do anything. One game that doesn't have this problem is Legends. You can do everything but play the game during a map load. Also, Quake used to let you access the console during map load.
3. I think they're left in because Tremulous is basically ioQ3 with Tremulous features thown in. To remove these would make syncing with ioQ3 more difficult.

[jal]

1. Player and building models don't stay loaded map to map. They are identical every game on every map, why waste processing power and time reloading them every time? It would be nice if they stayed loaded as long as you stay connected to a server.

OpenGL needs to be restarted to clear the map textures from memory. This also clears the entities textures. There's no real point in keeping in memory the entities trisoups. Also, it's good to make this zoned memory clearing to be safe about memory leaks.

2. Unresponsive client while map is loading. Cannot disconnect, use console, or otherwise interact with your client until the map finishes loading.

The console could actually be enabled during the loading screen proccess. It "freezes" during the bsp file load, tho, cause it's big and made in the main thread. Could be skept by multithreading the load proccess, but... is it really needed? It's complex to handle and all you'd win is being able to open the console, cause you can't safely make it do other things on top while waiting, so after all you'll still have to sit and wait until it is loaded. All games I know have chosen the same approach of simply waiting for it to finish.

3. Unused cvars. There are at least 100 cvars handed down from the original Quake 3 engine that do absolutely nothing. Some of them are purely vestigial (eg. Railgun rendering). Others are useless currently, but could be useful at a later date (eg. Bots). Others might be useful in Tremulous as it is, but are currently nonfunctional (eg. Spawn-timers; team names).

This is not really an engine problem, most are cgame cvars. But yeah, they should have been deleted. The railgun rendering is still functional and important (it draws very fast beams, teslas and adv mara are probably using it), but just has a wrong name.

[techhead]

There are fully functional in Tesla cvars in the game, such as cg_teslatrailtime (might of spelt it wrong), which is defaulted to 250, the same as the Tesla's repeat rate. More stuff too, that one was off the top of my head.

[Risujin]

1. Player and building models don't stay loaded map to map.

OpenGL needs to be restarted to clear the map textures from memory. This also clears the entities textures. There's no real point in keeping in memory the entities trisoups. Also, it's good to make this zoned memory clearing to be safe about memory leaks.

Why should all textures be cleared from memory? A clever hashing memory manager could track whats already been loaded into both RAM and OpenGL and pull old data out when more room is needed. Then again, Timbo would never let a "clever" anything near the ioquake3 code.

2. Unresponsive client while map is loading.

The console could actually be enabled during the loading screen proccess. It "freezes" during the bsp file load, tho, cause it's big and made in the main thread. Could be skept by multithreading the load proccess, but... is it really needed? It's complex to handle and all you'd win is being able to open the console, cause you can't safely make it do other things on top while waiting, so after all you'll still have to sit and wait until it is loaded. All games I know have chosen the same approach of simply waiting for it to finish.

Hooray for single-threading!

3. Unused cvars. There are at least 100 cvars handed down from the original Quake 3 engine that do absolutely nothing.

You should see the amount of appendix code!

[Taiyo.uk]

Hooray for single-threading!

What kind of performance impact would multithreading have on current multicore and/or multiprocessor systems?

[jal]

That's a different threading. It's much harder to implement. The impact would be quite good.
The threaded loading would have no impact on performance appart of showing a smooth loading screen.

[next_ghost]

That's a different threading. It's much harder to implement. The impact would be quite good.
The threaded loading would have no impact on performance appart of showing a smooth loading screen.

It'd have terrible impact on developer performance.