NEStroid tweaks and hexedits

[Stinktier]

Snarfblam, how difficult of a task would it be to add another byte of 'unique' item data? And associate them with items placed on the map? If there's not enough memory to save/password, i'm okay with replacing the samus age variable. I think i've got some good leads on itemable upgrades.

[snarfblam]

There are some unused bits of password data. If you're writing your own ASM, you could hook into the password encoding/decoding routines and set/read them as appropriate to handle some additional data. It's not something that would be supported by Editroid. If you want to use it to track items/doors on the map, you'd just have to manually examine/modify the gotten-item-list. If you're using the saving hack, half the work is done for you already. There are already saving/loading routines you can modify, and there are unused bytes of save file data (and even if there weren't, it's easy to increase the save file size).

[Stinktier]

Thanks! Hm, maybe it is time to implement the save reconstruction hack before i go on with the level design. I don't want the possible extra items to be completely peripheral.


EDIT - i didn't want to start a new thread so i put it here:
Another thing i've been looking at many times but never quite understood in its whole, but one thing i'd really like to mod since it is such a major roadblock. Enemy Slots. Here's how i understand it:

Enemy data is collected from room data and stored into temp byte $00. This is masked with an AND #$F0, so the engine will only work with value 0-F for now, which indicates available slots. Sadly, these slots are shared by enemies and doors (i think broken tiles have their own slot 'bank', can't remember which for sure right now but i might be missing something since i can't figure out a reason why more than a few doors should be held in temp memory).

So, there we are with 16 slots but only 6 of them available for enemies because of doors. In real gameplay, it's seldom you can cram in 6 enemies into one screen because some slots are already occupied by enemies from the previous screen. This is bad because it sets a cap on how hard (and also, how living) a corridor can be, and that is not very hard at all once you get a few upgrades, which halts game difficulty progression pretty quickly. The platforming element of the levels in themself lose the player's interest as more and more upgrades are collected. And it also encourages the player to exploit this bad feature by running through as to skip a few enemy loads ahead. Running through is a perfectly fine strategy as any other, but at least it should mean an even level of resistance.

If there were more enemies on screen at the same time, i think (speculative, i know) the choice of weapons would become more important - and balanced. It would be more imperative to collect all missile expansions. Wave beam would steal back a little glory from ice beam, while ice beam would still be stellar in a corridor with lots of respawning enemies.

There are lots of unused (and currently unused depending on where in the game loop we are) zero page bytes which could be used for storing door and enemy slots separately. Even in the unlikely event that all of them would be in use by some mod, there are ways to compress as you don't need a whole byte to tell if a metroid is on samus or if missiles are toggled, for example. There aren't however, that much space left in the engine bank to separate the routines into two. It could probably be solved, i'm not just there yet in my learning process. And then there's editroid compability issues, of course, which means enemy slots would have to be hand edited beyond number 0-5.

[snarfblam]

Adding more enemy slots is more complex than using some free memory you have laying around. There are two blocks of memory used for enemy variables. To add more enemies you need each block to be, itself, contiguous. Lots of code also depends on enemy data, door data, and Samus data being in the same memory page (block of 256 bytes). A more practical approach might be to modify the game to ignore the enemy slot specified by the screen data and pick the first available slot. You would be able to have up to six enemies on the screen at once, which is still a lot (and past the point where slowdown occurs), but you might run into issues with off-screen enemies holding on to a slot until you get far enough away or an enemy that must spawn not appearing because there are no free slots.

[Stinktier]

That does seem a lot more practical. Much like how it cycles through available bomb slots and broken bricks. I'll look into it, thanks again!

As for slowdowns, i think there are a bunch of places that are always called that can be cut down in terms of speed, for example a lot of subroutines that are only called one specific time per loop and therefore could use a jmp but currently uses jsr->rts. Haven't looked too closely at it yet, though. I've made projectile updating  and acceleration quite a bit faster in execution time as an exercise, but that isn't always called so naturally it matters less. With enough speed optimizations accumulated, though, it might make a difference.

[Grimlock]

Since you and Snarf are actively discussing various M1 optimizations I'm curious if either of you have attempted to look into the palette bug that randomly creeps into structure appearance while falling vertically?  I have a few passageways in Rogue Dawn that have this bug nearly every time.  It cycles to a palette reserved for a certain effect, somewhat spoiling the effect before it's experience as intended.

[snarfblam]

I've looked into this bug in the past. While it's present in the original game, it seems to be more noticeable in hacks because more varied palettes are used and the screens take longer to load, which seems to increase the probability of this happening. I'm guessing it's some sort of race condition where the NMI is interfering with the attribute (palette) table updating. I've never been able to sort it out, but I'm more than willing to take a crack at it at some point.

[Stinktier]

My concept of interrupts, hardware registers, palettes and a lot more is still very foggy, so i don't know if i have much to contribute there.

But if it helps narrowing down the issue, i can add that it's not a bug specific to vertical rooms/scrolling. The key is scrolling speed. I found out while trying out a couple of different methods to achieve a speed booster mechanic/item upgrade. In normal gameplay, you can only accelerate up to a very moderate (and fail safe) maximum running speed of $18, while jumping and falling goes a lot faster which provokes the bug only in vertical corridors under the normal circumstances that vanilla provides. But at speeds somewhere between 30-45, there is a point where it is almost sure to happen.

So, fast scrolling equals some parts get loaded with inappropriate palette. Maybe (totally guessing here) they are loaded at a specific time where palette is switched/overwritten with something else/reset to a specific value under the presumption that nothing of that sort should have been loaded at that point?

Picture of palette failure in a horizontal test room:
[spoiler][/spoiler]

[Flower]

Snarfblam, I'm planning on using the GFX bank swapping technique to change out my air tiles to text (at the end of areas).  The plan is to use the last set for in game text to implement the storyline.  My question is in regard to the CHR cycling order.  I can still do pretty much all of the animations I plan on doing with 3 banks if the swapping order is as follows : 1 2 3 2 - 1 2 3 2 - 1 2 3 2  and so forth.  That would leave "4" for where I need the text.  How would you recommend I achieve that order of swapping, or is it even possible?

I plan to do a similar thing with a frame reserved for the spaceship. How can i achieve that?



EDIT:
:bounce:
After examining this i found out. Cool, this way you save up graphic space when you plan carefully. :

DAMN IT STOP HAVING MY IDEAS!  :FURY:

Yes, this is easy to do.

$7801 - First CHR page
$7802 - Last CHR page
$7803 - Current CHR page
$7804 - Number of frames to display each CHR page (lower value = faster animation)

You'll want to update $7801-7803 any time you want to change the animation sequence (change all three to the same value to use a single, unanimated CHR bank). $7804 only needs to be updated if the animation rate needs to change.

So, for example, to change background animation to CHR banks $10-$11, you would do this:

Code Select Expand


lda #$11
sta $7802
lda #$10
sta $7801
sta $7803


Easy. :stern:

[Flower]

EDIT2 :
Well, i was not 100% correct. I found the way how to change the displayed frames, but not how you change the animation order. Does anybody know how to achieve that?

And several other assembly related stuff breaks my head. Is there anybody nes asm experienced guy out there who likes to help? I would basically ask that in the specific area of this forum and on RHDN, too. I would be pleased with a helping hand!