Zelda Classic 2.11 B18 Gp2x 0.3alpha


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.
 
If I had to hazard a guess, it sounds like this was done to make it easier to edit maps/screens and then test them immediately? It seems like this could be streamlined. Fixed or not though, everyone's impressed with the way you've taken the reigns of this port Hitnrun. Thanks a lot! :)
 
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.
 
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.
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.
 
Last edited by a moderator:
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.
It sounds likt the Coders of the Original Zelda Classic doesn't watste Time for optimized and effective usage of the Programm resources.

Very interesting when you compare the Size of a Typical SNES-Zelda Game. I don't know exactly numbers or "Measurements" but afaik Nintendo put into 2-4 MB Module Size (and a little bit of RAM) a HUGE Game. What method Nintendo use which is not possible onto PC?
Is it just the old Story of the different Coding philosophy for PC (unoptimized) and Console (high optimized)?
Or use Zelda Classic just much bigger Graphics/Graphic formats than the old Consoles did?
 
Last edited by a moderator:
grahf said:
SNES games are put together with tiles, and are stored as such.
Zelda Classic uses tiles as well, although I'm sure there are differences.
 
Last edited by a moderator:
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 :)
 
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 :)
I think this is because of the PC "Original" of this Zelda project.
Sadly, as more powerful a platform is, as more unoptimized is the Software. In the early days, the limited Hardware of the Computers result in very optimized Software jewels. (Turrican on C64, Donkey Kong Country on SNES etc...)
But today it seems that nobody wastes Time for optimizing Code (I know it is not THAT needed today at least not onto modern PC's).
I hope, the Pandora as a modern Console will not be part of this trend for "wasting resources" because of its huge rough power.
 
Last edited by a moderator:
Yes, programming on the desktop pc these things don't matter too much, there's swap files and all, Zelda Classic came first in dos so there's years of compatibility to take care, maybe this have something to do with the huge structures that takes lots of memory.

But well, if there are more challenges than it is more fun to the programmer! :lol:

What I am liking in programming for low-spec devices is that little changes make huge differences, for code like this there's endless possibilities of optimization (at the cost of some hair hehehe).
 
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.
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.

Compared with a PC where the tangible benefit only arises if you're trying to run umpteen proggies at the same time. Or if the program actually would require very very high-end machines regardless (say, almost any demo based on realtime raytracing at a decent resolution).
 
Last edited by a moderator:
Keep working on this, looks great so far.
It would be great to see even more of a speed boost and to be able to load those >800 kB quests in the future.
EDIT: Oh wait, you can.

Good luck. :)
 
Back
Top