Archived

This topic is now archived and is closed to further replies.

Reduced loading times in future games...

This topic is 5671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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( );

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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"? =)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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).

Share this post


Link to post
Share on other sites
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 )

Share this post


Link to post
Share on other sites
These DDS-files... are they DirectX-only or can they be used in OpenGL? I''m planning to use OpenGL as the primary API. Anyway, I''ll keep the DDS-files in mind...

Share this post


Link to post
Share on other sites
1. Use an archive/wad/pack file. Open the file once at the start of the program - opening files is expensive - particularly on "secure" operating systems (Windows NT/2000/XP).

2. Where possible, sort the contents of the pack file in order of access, even if your access is seemingly random, there might be an access pattern which is more likely than others.

3. If you have portals, you can load on demand - but try and do some prediction so that likely cells data is loaded ahead of its portal being visible.

4. Consider LOD for the data in the cells - load the low LOD data for all cells neighbouring the current one - so even if the player takes an unexpected path, you can still show them something on screen and be loading the high LOD data while they approach the cell.

5. Compress the data - all of it - for geometry, pre-process the float values or LZ style compression won''t do much for you (the paper on the Java3D compression schemes might give you some ideas though the overall technique is patented). The CPU is always faster than any file access so compression is desirable.

6. If the data can be read from CD, take extra care to sort the pack file well - however some things like movies might do better on a different part of the CD. Look up "Constant Angular Velocity" - due to the physical nature of CDs, the data on them can be accessed at different rates at different parts of the disc. Seeks on CDs are very expensive - don''t do them unless necessary.

7. Use asyncronous file IO. However, beware that a) it doesn''t work on Windows95, only on 98 and above, b) some drivers for old hardware such as CD drives may say they support async mode and then end up stalling on data reads.

8. The fastest way to access a file under Windows is to hijack the virtual memory system. Check out CreateFileMapping(), MapViewOfFile() etc. Its also really nice too because the mapped sections of the file automagically become valid blocks of memory.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
quote:
Original post by Omaha
Um... *ahem* ...this has all been done.


Indeed, many of it years ago, many of it researched in greater depth by non-game parts of the industry (database apps for example)...

...but not by the original poster :

quote:
Instead of coding, I read a lot before, so I know what my future game engine will do and not do befode I start






--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites