This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Thanks justin3009, this looks like it will be helpful. Two lines of significance:
$00/B22A BD 23 86 LDA $8623,x[$08:8A70] A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36Graphics number is well-known. You can see that in the event editor window + compression/decompression programs spit out all the addresses and sizes of each graphic in a txt file. I don't get why the accumulator value doesn't reflect that though. A:0174. Why is it not A:036, or A:054 (decimal)?
Someone can help me?
I need change part down of "D" for down "E"
the game repeats the high part of D turned
now it looks just like that, Need fix "T".
Help me please.
And if you're on a cell phone... Why do you want to browse hacks on the cell phone? Do you have roms and a patcher on mobile?Well because of my current situation over the past 4 years all I have is my cell phone to get online. And no, I don't. Hopefully soon when I buy my house I'll get my desktop back online. So right now all I have is my cell phone and it would be nice to be able to access the desktop version from my phone till I get my desktop back online. Most other websites have the option to choose the desktop version from your phone but I can't seem to be able to access the desktop version of the new site from my phone. Is the new site set up to use the desktop version from a cell phone?
The scene map in RAM (composed of tile maps) starts at 7E:2800 and I think the next valid thing in RAM is at 7E:F000 (background scene map).
$60 scenes * $40 blocks per scene * $4 tile maps per block * $2 bytes per tile map = $C000 bytes
$FF scenes * $40 blocks per scene * $4 tile maps per block * $2 bytes per tile map = $1FE00 bytes
($100 might be possible, but I'm assuming that a value of $0 actually means $0 unique scenes in the code right now and would need to be changed to represent $100)
It looks like the code copies all the scene data to RAM at the start of the level and leaves it there. So without changing the way it's stored it would use almost all of 128KB of WRAM for $FF scenes. Some ideas:
1) Store the tilemaps as blocks in WRAM and get 4x savings. Not sure how much it will slow down the in-level scene management code to have to read the block to get the tile. It should just be an extra 1-2 LDs with some address arithmetic.
2) Dynamically load the scene mapping data and have the level designer setup events to identify which scenes are active at different parts of the level. I don't like this idea.
3) Some other form of compression.
I prefer (1) if we want to increase the limit. (2) seems like too much extra work for the level designer to worry about. They already have to manage VRAM. And (3) would require compression that supports random access and the editor checking that the scene definitions would actually fit in the allocated WRAM space.
Expanding the number of unique scenes seemed like an important part of designing larger and more detailed levels. It ended up being $60 for a weird reason - the code runs out of space in RAM with larger values and starts overwriting other things. I originally tried to add $FF total but it ended up wrapping around in RAM and overwriting all sorts of important things like the controller input and sound related stuff.