Well it is more or less what I am doing, the quest is a big array that doesn't fit in memory, so I save it to disk (using mmap to simulate memory), and use it from there. But I can't map the source file, because it can be in compressed format, and it isn't seekable.grahf said:I have no idea what the code looks like for this, but would it be possible to pre-extract all the quest data into a file ahead of time? Pretty much the way that gngeo did it with the graphics extracted into separate files.
It sounds likt the Coders of the Original Zelda Classic doesn't watste Time for optimized and effective usage of the Programm resources.Hitnrun said:Zelda Classic loads the complete quest on memory at startup, this quest have a filesize of 3mb, but consists of 83 maps, each with 136 screens. Copied from other topic:
It is an array of very big structs (6272 bytes), multiplied by the a fixed number of screens (136), multiplied by the number of maps of this quest (83), which gives 70798336, or 70mb.
Plus the default data which accounts for another 30mb.
I think this is because of the PC "Original" of this Zelda project.craigix said:This sounds like one of the worst examples of RAM bloat I've ever heard of.
It's a 2D scrolling RPG from the early 90's and it needs more RAM than Doom3 on the Xbox.
I am amazed by this. What a shocking piece of coding.
I hope you can undo their crazy RAM antics
There is of course the added bonus of optimization with Pandora, in due course, of increased battery life. The more optimized something is the longer it'll run for - so even if the power is there, there's still a tangible benefit of doing the legwork; just maybe not quite as much as there was on the GP32/GP2x.craigix said:Because the Pandora has its roots in the GP32 and GP2X hardware we should not see any of this going on. I hope.