Reduced loading times in future games...

Started by
13 comments, last by ALiENiD 21 years, 10 months ago
Hi everyone... I''ve been thinking about doing a game. I have "some" OpenGL experience, but not a lot. Instead of coding, I read a lot before, so I know what my future game engine will do and not do befode I start. Well... enought talk about me... The idea I wish to share with you was that my goals of this engine was to have very little or no loading time. I''ve grown tired of long loading times in games when you switch levels and have been thinking about how an "instant" loading system could work. The lack of experience I hope to fill up with your replies. I''m thinking a portal engine. Each one with a PVS with other portals. This could be extended to what textures, sounds and other portals which would be needed further ahead. These could be placed in a queue to be cached. Textures and sounds not needed anymore should be freed instantly. The loading on the other hand is a little more difficult. Working with hard drives is negative on performance. For this problem, I''ve thought of two sollutions: 1) Load everything in the beginning to RAM + Fast access - Huge loading time in the beginning - Requires A LOT of RAM in case of big worlds 2) Load a texture/sound/portal every five frame or so + Little slower - Damages performace (how much though?) - If all the textures wasn''t loaded in time, the program has to stop and load, but this should only happen on slower computers or bigger portal sections Do you guys think this could be done? Any other suggestions/comments are welcome! /ALiENiD
Advertisement
I think the slowest part is opening files. To speed up the game, you can use archives instead of lots of individual files. The archives wouldn''t need to be compressed (though it helps).

Loading more into RAM than you need is definitely a bad idea, because you''ll end up using a lot of RAM and needlessly increasing the system requirements of your program.

And when loading a new level, you can keep whatever textures and other resources from the last level that will be used in the new one, as opposed to freeing them and then reloading them.

~CGameProgrammer( );

~CGameProgrammer( );Developer Image Exchange -- New Features: Upload screenshots of your games (size is unlimited) and upload the game itself (up to 10MB). Free. No registration needed.
Reducing loading times is a good idea. I remember one game(SiN) being trashed totally financially by long load times. It came out in a patch but that ship had already sailed.
1) You might want to take a look at compression schemes as well. You reduce to one-tenth to one half of the hard-drive access-time and that''s a good use of time.
2) I''ve also seen discussions on the console side about improving access times including using lossy techniques and smaller file formats .jpeg .png
3) Know when to break it into pieces - Base load-in versus level Load-in


ZoomBoy
Developing a iso-tile 2D RPG with skills, weapons, and adventure. See my old Hex-Tile RPG GAME, character editor, diary, 3D Art resources at Check out my web-site
Sin was bug-ridden because they had Half-Life due to be released at roughly the same time, so they did a rush-job and kicked it out the door. It didn''t work though. On the other hand, at least they''ve released the source code so we can fix the bugs .

I suspect that accessing the hard disc continually would trash the frame rate. I seem to remember that (on an old hard drive, though) in Half-Life, bits were loaded up in advance and that you could tell when this was happening. I''m not sure of the situation now, though...

Your best bet would be compress as much as possible (e.g. vector quantization or hardware texture compression).
Here are some of my thoughts about improving loading times.

A Virtual filesystem to reduce opening/closing times for files.
Pack all files into a large archive.

Load data in a separate low priority thread.
Divide the map into zones and add a load requests to the low priority thread when the player is getting close to a new zone.

Add textures, models, sounds etc to a manager and have the loading thread check if the data is loaded before trying to load it again. Maybe using a system similar to windows dll files, every program that need a file add 1 to a counter for that file.

This is just my own thoughts about it.
Also, sorry for spelling errors, Im from Sweden
So what you''re saying is that it isn''t worth it? The "dream goal" is to have very small impact on performance and no visible loading times (maybe a small in the beginning).

But what if I used compressed archives, say one per section (one section could be x number of portals with textures and sound, related to each other). If I loaded the archive into RAM and then extracted the files a little ahead of when they were needed. The algorithm should not be strong, otherwice it would take too much CPU time to decompress.

How about that?

Any other suggestions to achive my "dream goal"? =)
I liked your idea Cruath. =)
Just what I was thinking of...
I had a little nosey on Google and it seems that Legacy of Kain 2: Soul Reaver had virtually no loading times. Can anyone confirm this from experience and/or give a link?

Btw, another possibility: generating textures, etc., on the fly. This might be a good way to go.

I think that having a goal of ''no loading'' is admirable. However, bear in mind that many games nowadays have large enough levels to justify the loading times - you get quite a lot of gameplay from one level.
I dont know how they did it, but Dungeon Siege has no loading times at all. Its just one large game world, with the loading running in a seperate thread in the background (I presume).
when it comes to textures, DDS files using DXTC/S3TC compression are ULTRA fast loading. I''ve recuded 15 second loading times to almost instant in some things I''ve done...
It''s because when it''s loaded, it''s just whacked straight accross onto the card/agp memory.. in it''s existing compressed form.. mipmaps included, the compression ratio maximum is something insane, like 1/12... not to mention that you don''t have to generate mipmaps (in the texture already), etc.
software decompression when hardware isn''t avaliable is a problem though, as it''s about 50% slower than a generic texture. (I''ve found). but that trade of is worth it, imo. Not to mention how much disk space they save. And they save the space on the card too. (all round awesome texture format, in other words )

This topic is closed to new replies.

Advertisement