123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|29|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Preloading assets in C#

Mon, 22 Oct 2012, 07:58
Afr0
Does anyone have any idea about this?
I think I have an idea in my head about how to do it (load three or four random archives into a hashtable, then replace loaded entries with new entries when needed) - the question is if the loaded data will be deleted by the GC when not used.
Basically I'm thinking that loading everything on the fly (which is what I'm currently doing) can't be a (the most?) effective way of doing it, even though it should be perfectly passable because of the GC.
What's the common way of doing this in Java?

-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Mon, 22 Oct 2012, 13:53
JL235
It depends on what you really mean by 'preloading'. If you mean whilst the level is loading, before the actual gameplay starts, then yes, that is normally the best approach.

If you mean when the game starts up, that is the most ideal scenario, however it depends on how much memory your assets will take up. If it's 100mb, that's fine. If it's over 500mb, it will be too much.

However plenty of games also load on the fly, whilst the game is playing. The 3D Elder Scrolls games are good examples of this, however it also happens on much smaller games too. Ideally you would want to avoid this, because of the complexity it brings to your game. It's not just a case of saying "I need x asset now", many games will try to predict what assets should be loaded/unloaded, seconds or whole minutes before they are needed. For example if you are a 30 second walk away from a new area, then it will be loaded in.

Games often also take into account which direction the player is moving and looking, so they would only load in the areas 30 seconds in front of you (and 10 seconds in every other direction). For example John Carmack said at one QuakeCon keynote, that if you want to mess up the loading algorithms in Rage, walk through large sections of the game backwards.

Ultimately, what you use depends on what you are building. There are different approaches, because there is no one size fits all. It also has very little to do with the language it's self; many JavaScript based games will have some kind of resource management built in (Play My Code too).

As for the GC, the same rules apply as anything else. Barring a few corner cases (which practically speaking do not apply here), if you can get a reference to it, then it will be kept in memory. If you don't have a reference, then it won't be kept in memory.

However in Java we do have 'weak references', and I'd expect C# has something similar. It's like a normal reference, however if the application runs out of memory, then the GC is allowed to reclaim it. This is useful for caching, such as pre-generating lots of images.

However I've only ever had to use them in Java to work around the performance issues of Java2D, such as rotating and scaling (which are dog slow). After I moved to OpenGL, they just became unnecessary for saving memory (although I have used them since to help work around issues with GC pauses).

Hope that helps!
Tue, 23 Oct 2012, 02:27
Afr0
Hm, well TSO is 1.5gig in size, so obviously I can't preload *everything*.
The original game had a loading screen that loaded resources, but I've no idea what they were! But I know that initially I'll need the textures for the GUI. I'm also going to be needing the models and textures for the Create A Sim screen, but those are wayy to big to load all of them, so I'll have to load a random bunch of them.
Initially one of the guys I was working with, Nicholas, implemented a loader that loaded *everything*!
Literally, every texture and object in the entire fucking game! Needless to say, I've disabled the loading screen by now. But I figured it was time to do something about it, and do it properly this time...


-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Wed, 24 Oct 2012, 02:55
Afr0
I discovered that Nicholas had already implemented what I was thinking of doing, only he was doing it with archives instead of files. Problem was that he wasn't ever deleting an archive after loading it, so I ripped out his code for now.
I'm thinking 100 megs is probably too tiny though, I probably want the cache to be between 150 - 300 megs.
The way I'm seeing it now, by keeping the cache at that size and filling it with files instead of archives, I'll minimize cacheswitching.

-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Sat, 27 Oct 2012, 09:44
Afr0
Soo... does anyone have any idea how to make this more random? Preferably as random as possible. Any ideas and suggestions are welcome!



-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Sat, 27 Oct 2012, 14:58
JL235
Why would you want any randomness when loading assets?
Sat, 27 Oct 2012, 15:29
Afr0
Because I can't preload all the assets? The meshes alone are 100megs compressed! If the cache is at 250 megs I might be able to fit it all in, but decompressing all that data takes time.
Anyhow, here's my current approach:



The problem with this approach is that I can't control the exact size of the data I'm loading in. Does anyone have an idea for a more precise way of doing this?
Here's how I cache assets:



Edit: Whoah, logging reveals that I'm currently only loading 2mb! Is the below formula correct?



-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Sun, 28 Oct 2012, 06:30
Afr0
So I've run some tests and changed the code around a little, and somehow the cache ALWAYS ends up being EXACTLY the same size, down to the last byte. Can someone PLEASE explain what's going on? I'll paste the entire class, minus the methods that aren't being used.



-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Sun, 28 Oct 2012, 13:27
JL235
If you can't preload them all, then just preload the ones you need. Why pick at random?

If you want to preload some you might need, then preload the most common assets, or preload the smallest.

No point in just picking at random.
Sun, 28 Oct 2012, 14:29
Afr0
Yeah, that's the issue. There's no way to know which assets are used to create sims. But me and Andrew found out through a lengthy conversation on Facebook that packingslips.dat are used in conjunction with *.xml files in the packingslips folder to map the assets.
As it turns out, packingslips.txt contains a few bogus entries (that were removed before the game was shipped), and packingslips.dat a lot more (since it is 5+ megs, versus 2 megs for packingslips.txt).
This should have been obvious from the start, as it is a totally maxoidian thing to do - ship an outdated mapping with the final game, and use it in conjunction with other maps that are up to date!

|edit| This doesn't actually explain anything.
Basically, I found out that generating random IDs didn't seem to work, and then I decided to try to load all the meshes. When I tried doing that, the process started crashing because of the bogus entries in packingslips.dat.
So now I need to parse the entries in the *.xml files as well... |edit|


-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!