Ben_Hurr
|
|
« on: February 01, 2010, 11:37:52 AM » |
|
Hey guys, is it good form to load game levels directly from disk every time you need them? Or would I be running people's hardrives to an early grave? At the moment we're talking about 2D tile-based levels that are only about 2KB big. edit: As opposed to say, preloading all the levels once at program start.
|
|
« Last Edit: February 01, 2010, 11:57:06 AM by Ben_Hurr »
|
Logged
|
|
|
|
Ivan
Owl Country
Level 10
alright, let's see what we can see
|
|
« Reply #1 on: February 01, 2010, 11:42:59 AM » |
|
hwat?
as opposed to what?
|
|
|
Logged
|
|
|
|
moi
|
|
« Reply #2 on: February 01, 2010, 12:52:12 PM » |
|
Nowadays there are few differences between ram and HD anyway, OSes spend all their free time loading/saving shit on the HD anyway.
|
|
|
Logged
|
subsystems subsystems subsystems
|
|
|
Impossible
|
|
« Reply #3 on: February 01, 2010, 01:02:16 PM » |
|
If your levels are only 2KB including per level resources, you might as well load the entire game into memory at start up and be done with it. This is assuming you don't have billions of levels in your game, of course.
In practice if for some reason its easier for you to reload levels from the disk it doesn't matter if you do it that way as long as you aren't constantly reloading the level every time you want read data from it.
|
|
|
Logged
|
|
|
|
Ben_Hurr
|
|
« Reply #4 on: February 01, 2010, 01:29:31 PM » |
|
In practice if for some reason its easier for you to reload levels from the disk it doesn't matter if you do it that way as long as you aren't constantly reloading the level every time you want read data from it.
Haha, that's exactly what would happen, since we're talking about a metroidvia type game. So you'd be loading up maps every time you go to a new room.
|
|
« Last Edit: February 01, 2010, 01:35:19 PM by Ben_Hurr »
|
Logged
|
|
|
|
Average Software
|
|
« Reply #5 on: February 01, 2010, 05:02:03 PM » |
|
Hey guys, is it good form to load game levels directly from disk every time you need them? Or would I be running people's hardrives to an early grave? At the moment we're talking about 2D tile-based levels that are only about 2KB big. edit: As opposed to say, preloading all the levels once at program start.There's a good chance a file that small would be sitting in the hard disk buffer anyway, if you're accessing it frequently. It may actually only be physically loaded once.
|
|
|
Logged
|
What would John Carmack do?
|
|
|
nikki
|
|
« Reply #6 on: February 02, 2010, 04:06:49 AM » |
|
maybe you could make your levels have the data of a level, (instead of 1 room) then the size probably increases, and then it might be better to only load the level once.
but i don't know if this is better.
|
|
|
Logged
|
|
|
|
Hajo
|
|
« Reply #7 on: February 02, 2010, 05:05:35 AM » |
|
If that'd be floppy discs it might be a problem. Not for hard drives. If the levels are that small, and you want to avoid loading, you could easily cache them yourself possibly? Kind of java inspired wannabe pseudocode: class Loader {
private Hashtable levels = new Hashtable();
public Level load(String name) { Level level = levels.get(name); if(level == null) { // do real loading here levels.put(name, level); } return level; } }
|
|
|
Logged
|
Per aspera ad astra
|
|
|
skyy
|
|
« Reply #8 on: February 02, 2010, 05:28:45 AM » |
|
One way of doing it: on level load load data required for that level into memory (unless running 3D worlds or insane amount of stuff). use the data
on level end unload all the data specific for that level and save all what you might need in the next level
But since metroidvania style game, I'm guessing your world is node/grid(rooms) based ? What you could do, is to figure out what node/grid you are on and load in fex extra rooms when changing room. Like x3 to every direction (testing required anyway). And once you get out of the loaded areas, you would then again load in the new room + good chunk of "possible" rooms to follow. This way you would have to spend few milliseconds loading in new room data every now and then and would minimise the "need to load rooms all the time" by having as many of the possible following rooms in memory as possible. So possibly using some sort of tree based room sorting system that allows you to prune out unecessary rooms based on your current location and allows you to easily define how many possible rooms to load in.
|
|
« Last Edit: February 02, 2010, 05:35:04 AM by skyy »
|
Logged
|
|
|
|
Christian Knudsen
|
|
« Reply #9 on: February 02, 2010, 05:38:13 AM » |
|
They're only 2KB each. He could preload 1000 levels and it'd only take up 2MB of memory. Just load it all on program start -- not to save the harddrive from wear, but because I can't see any reason not to.
|
|
|
Logged
|
|
|
|
Hajo
|
|
« Reply #10 on: February 02, 2010, 05:39:59 AM » |
|
Loading on demand would reduce the startup time though - opening a large number of small files needs a while, too.
|
|
|
Logged
|
Per aspera ad astra
|
|
|
Akari
|
|
« Reply #11 on: February 02, 2010, 05:50:35 AM » |
|
RAM acccess will always be faster than HDD access, so I'm all for preloading. I once tried doing a SHMUP where all the enemy data in a level was read from an INI file during runtime. The game had a noticeable pause everytime a new enemy was spawned. When I changed the code to preload the whole level data into memory on startup, unsurprisingly the pauses were gone
|
|
|
Logged
|
|
|
|
Christian Knudsen
|
|
« Reply #12 on: February 02, 2010, 05:51:32 AM » |
|
Then just combine all the levels into one big file and separate them in memory when reading from that file at startup. Generally, I prefer that a game has a longer startup time instead of many small loading times while playing... but then again, loading a 2KB level file when the game is running isn't going to be noticeable.
|
|
|
Logged
|
|
|
|
Hajo
|
|
« Reply #13 on: February 02, 2010, 05:56:54 AM » |
|
Then just combine all the levels into one big file and separate them in memory when reading from that file at startup.
That's definitely the most efficient way. Zip files come in handy, since they are compressed as a bonus, and only a minimal amount of data must be read - CPU will happily uncompress the data while reading.
|
|
|
Logged
|
Per aspera ad astra
|
|
|
skyy
|
|
« Reply #14 on: February 02, 2010, 06:01:50 AM » |
|
Obviously for most small games the loading "should" (not written in stone) be done during startup and then just use that data to roll around. But at times if the game is HJUUUUGGE on demand loading is more or less the way to go.
As long as it works and doesn't bother the player then it should be all good.
|
|
|
Logged
|
|
|
|
Ben_Hurr
|
|
« Reply #15 on: February 02, 2010, 08:02:22 AM » |
|
At this point, preloading the entire game world or loading each room on the fly is entirely feasible. Even if the rooms are like 15x15 game screens big hoho. I only asked about hard drive usage because I read a Gamesutra article about it... but it probably only would've concerned AAA type games that shuffle around 200MB of level data, wouldn't it?
|
|
|
Logged
|
|
|
|
nikki
|
|
« Reply #16 on: February 02, 2010, 08:12:52 AM » |
|
it's more that the access-time to get a file thats on your disk instead of memory is 'long' so if you have many many files, and you need accessing them regularly, you win speed by making a single file out of many files. then reading it into the memory then you access the data from memory instead disk
but in alot of cases your data that you've once read stays in memory anyhow (i believe)
|
|
|
Logged
|
|
|
|
Martin 2BAM
|
|
« Reply #17 on: February 02, 2010, 09:03:15 AM » |
|
Early optimization is the root of all evil.
With that said, load on demand (init speed) and keep them loaded (replay speed).
Regards
|
|
|
Logged
|
|
|
|
skyy
|
|
« Reply #18 on: February 02, 2010, 09:34:25 AM » |
|
Nice point nitram. I didn't even think of loading them in as needed and then keeping them in there.
|
|
|
Logged
|
|
|
|
Ben_Hurr
|
|
« Reply #19 on: February 02, 2010, 09:39:48 AM » |
|
Ah, there's another wrinkle to the puzzle! I plan to modify some of the maps geometry with scripts upon entering them, like say an event flag for FUCKING_ROCK_SLIDE is tripped. It's loads easier to just load up a fresh copy of the room from file and play with that, rather than make a working copy in memory.
|
|
|
Logged
|
|
|
|
|