Tremulous Forum
General => Feedback => Topic started by: waflz on October 28, 2007, 03:27:13 am
-
I've always thought it would be convenient to just 'not have' load times, even the short ones associated with Tremulous. Something that I would really like is an option to load all of the maps onto RAM when the game starts instead of when they're needed. I think this could potentially be implemented because the game uses little system memory as far as I know.
First, I know that it would depend quite a bit on how many maps you have and how much RAM you have, but maybe there could be some cvars that determine what maps will load early, if any.
Second, a hybrid option/cvar so that only part of the map is stored on the RAM and part is still loaded from the hard disk if there isn't enough for the desired amount.
I don't know how this could possibly work out from the developer 's perspective or if it's even the read-from-source time that determines the speed but I still love the thought of no load times.
-
Or loading all the game models to memory to skip that altogether, since this isn't like Quake 3 where some maps might not have a certain weapon, or might not have a certain player model. Every round in Tremulous features the same weapons, structures and player models so loading them at every round is useless.
-
Yes!! I also think that this should be an option for the client. He/She should be able to choose to 'pre-load' all the models, textures, weapons, etc to effectively 'remove' load times.
Not sure if this is real or not, but a player on a server I regularly play on says he can already do this, is it really possible?
-
How much RAM do you think you would need to load all the maps, textures, models, skins and sounds at once?
-
How much RAM do you think you would need to load all the maps, textures, models, skins and sounds at once?
8MB....Oh wait, are you being serious? :) I have no idea, but I would very much like to know.
Hmm, now that I think about it - if the entire map is loaded, most maps seem to be 5GB or more, then we'd all need to start using 64 bit OS's. Oh well, was a good idea.
-
How much RAM do you think you would need to load all the maps, textures, models, skins and sounds at once?
That's not the point. The point is to load the game models/textures/sounds, like for weapons and players, not the maps. These things are in every map. Why should they be loaded every time a map is loaded?
Just clear the map memory on every new map and load the new one, instead of clearing everything.
-
How much RAM do you think you would need to load all the maps, textures, models, skins and sounds at once?
That's not the point. The point is to load the game models/textures/sounds, like for weapons and players, not the maps. These things are in every map. Why should they be loaded every time a map is loaded?
Just clear the map memory on every new map and load the new one, instead of clearing everything.
So, you actually think it is worth the effort of coding, for a (and I am being very progressive here) 5 second decrease in loading times? Don't you think there is a profound reason why everything gets flushed upon mapchange? Also, what will this do to people with a small amount of RAM?
Really, this is not worth the effort.
-
5 seconds _EVERY_ time, which adds up pretty quickly
-
It actually takes about 15 to 30 seconds for my laptop to load the player and buildable models.
Given that they were loaded the first time a map was loaded, and stuck for the rest of the game, it would improve a lot.
-
Loading each map is a terrible idea. Loading the weapon and player models however, could work
-
Please explain to me what the benefits are of rewriting the way Quake3 handles the loading of assets. A 5 or 10 second increase in loading times does not even come near justifying it.
After you have explained that, I would like to know if this is just random chatter by people who only talk, or if someone is actually going to take up this ridiculous gauntlet.
-
5 seconds _EVERY_ time, which adds up pretty quickly
Pffffft get serious you moron.
Your "_EVERY_ time" is just in regard to when the map changes.
Before you even try to argue in unknown waters, please do us all the favor and finish kindergarten first.
Hasn't it come to your attention that those "5 seconds" do not add up to anything?
-
Please explain to me what the benefits are of rewriting the way Quake3 handles the loading of assets. A 5 or 10 second increase in loading times does not even come near justifying it.
After you have explained that, I would like to know if this is just random chatter by people who only talk, or if someone is actually going to take up this ridiculous gauntlet.
(http://pcmedia.gamespy.com/pc/image/article/653/653516/quake-4-20050923035238966.jpg)
Gauntlet. :D
-
Why not ?
This is actually one of the reasonable ideas floating around here. 5 seconds is a lot. Programmers do optimize to shave off even milliseconds of processing time. And we don't know if it will only amount to 5 seconds max. This idea is always good, unless it has already been implemented.
I hope you guys don't really restart your OS and wait 30 seconds every time you want to run a different application just to be sure that the system works properly. That's so Win95.
-
Timbo> not really realistic
Timbo> the trouble is people see the benefit (faster loads)
Timbo> but don't see the drawbacks
Timbo> which is a lot of extra complexity
Timbo> and a risk of memory leaks
-
While I understand and support Timbo's viewpoint of "if it works, don't touch it", he's not quite correct about this. There is no chance of a memory leak because the main engine acts as a memory manager. Every time an asset needs to be loaded it is done via handles and syscalls. It isn't difficult to check if you've already loaded the data or if you need to flush data to free up room. You can use either resource paths or checksums of data files to track what's loaded.
Quake 3, by the way, did not load all models for every map and the concern there was probably memory limitations (the game was made almost a decade ago!). If you notice, many maps only had as few as two or three guns and you never loaded all player models. Caching did not make a lot of sense.
For Tremulous, ALL models are always reloaded. Not caching this data causes a needless 15-30 second delay (as noted above). Lets at least be clear here, it's not that there isn't a tangible benefit, it's that the lot of us devs are too lazy to code this. :)
-
The real issue is if it's really worth coding to save a few measly seconds.
Most servers are running the warm-up patch anyhows...
-
A slight decrease in loading times is not what I would call a 'tangible benefit'.
-
it's that the lot of us devs are too lazy to code this. :)
Sad but true :/
It would be already a great surprise for me if 1.2 really make it. Not like I am blaming the devs in any case.
There are multiple attitudes in this community which kill whatever mood you have left to code.
-
It would be already a great surprise for me if 1.2 really make it. Not like I am blaming the devs in any case.
There are multiple attitudes in this community which kill whatever mood you have left to code.
It's not even 2 years after the 1.1.0 standalone release and already your determination wavers?
It's not so much that certain attitudes in the community are killing the 'mood to code', as it is that most of the Tremulous developers have already worked on this game for a very long period. While this does not mean that they have no more interest in Tremulous, it does mean that work is progressing a noticable slower (read: 1-legged turtle) pace.
Another effect is that any 'big' code changes, like the suggested changes to the memory managing, are less probable, since they require quite an amount of coding and testing, maybe even further delaying the moment at which you will be surprised with a next release.
-
While I understand and support Timbo's viewpoint of "if it works, don't touch it", he's not quite correct about this. There is no chance of a memory leak because the main engine acts as a memory manager.
...which, like any non-automatic memory manager, is still vulnerable to leaks. Clearing the hunk on every map change avoids this since you can't actually leak since you can't actually free any allocated memory. This linear memory manager is entirely by design.
it's that the lot of us devs are too lazy to code this. :)
Sad but true :/
Those of us that are actually doing the working are managing just fine.
There are multiple attitudes in this community which kill whatever mood you have left to code.
Some of which are on display right here. ::)
-
Wow, Timbo I gotta say, it's good to have the devs back on the forums. Not because we must all be sycophantic nut-huggers of the mighty devs, but because we actually have some connection with what really is going on, not just the usual rampant speculation. Welcome home, to your own house. Nice to see you around the old village green, on occasion.
-
I'm checking things a lot at the moment because of the new forum software, but I do keep half an eye on things here semi-regularly. Sorry if I come across as a bit grumpy from time to time. I tend to post when things irritate me; I probably should restrain myself ;).
-
While I understand and support Timbo's viewpoint of "if it works, don't touch it", he's not quite correct about this. There is no chance of a memory leak because the main engine acts as a memory manager.
...which, like any non-automatic memory manager, is still vulnerable to leaks. Clearing the hunk on every map change avoids this since you can't actually leak since you can't actually free any allocated memory. This linear memory manager is entirely by design.
You still clear the hunk on every map load. Instead of dumping the memory in there however, you mark it as "cached". When you load a new resource, you either clear out unused cached memory or maybe you have a cache hit and your resource is already loaded. There is a problem with hunk fragmentation because of this, but if you order the loading so that you get all of your cache hits in the same order and right away (by loading player and weapon models, textures, and sounds first) you won't have any issues. Since the game uses handles anyway, you can even move memory around within the hunk if you want to bother.
Either way, I don't think there is any point to an argument over this because neither of us is going to code this. You won't for obvious reasons, and I won't because you'd never so much as look at a patch of mine to begin with. ;)