You are not logged in.
Posting a pic shortly:
I'm working of a pokered from November 2014 and just gotten back around to tinkering with it again.
I stopped because I was having issues with my Professor Oak script, at the start of the game: it would essentially glitch out, and none of the Oak scripts would behave, garbage would appear on the screen, the NPCs don't stay pointed in their proper directions, etc.
In working on it the last few days, I learned that a tweak I made in WRAM to give me two named spaces for new map CURSCRIPT values was causing a greater share of errors; by commenting these out, the errors occur about 1/3 of the time instead of every time.
Additionally, a persistent issue has been the wild pokemon; the 3rd Pokemon on the list appears as a Level 0 instead of their intended value.
I have added the following, which are likely to have an impact on memory:
- Gender Selection
- Expanded Pokedex to account for 255 Pokemon
- Higher-res Background images
- Two new maps and the slots for all potential maps allocated
Any tips for how to run down the issue?
Last edited by daMoose52 (2016-04-14 03:21:40)
I've seen that effect a few times when playing around with Pokemon corruptions. It's probably something going out of bounds and causing a corruption of every five bytes somewhere in wram. You could start by checking with a debugger if trash is being written to the tilemap, and if so, what's causing it to happen. The wild pokemon data corruption is probably due to a similar effect. If you messed up with wram and shifted stuff around, it might only an inconsistency in the save file that will be gone if you start a new game.
It looks like it was where I have/had my expanded flags for Pokemon owned & pokemon seen. Something was accessing data that is still hard coded to an address in my version. I moved it around a couple places and presto-change-o both my Oak script and the wild monsters work perfectly.
I'm guessing your copy probably still has "wram constants" (It does, unless you've manually removed it, since this was changed in 2015) which are hardcoding various addresses in order to overload values in the middle of other defined structures. Current copies don't have that, so you might want to look at this commit and also this one as well that take care of removing that so you don't have hardcoded addresses accidentally causing issues for you.
Last edited by Mateo (2016-04-14 15:43:47)
I will take a look at those; but, I think I nailed the issue: sprites.
How many sprites can be on the screen at one time?
Because at that point, you have 9: Oak, Rival, Player, 3 Pokemon, 2 Pokedex, and intermittently the girl wandering around Oak's lab.
In further tinkering, I had originally moved Oak's Aides up one space to accommodate a staircase; with my revised story, Oak's lab acts as a boarding school for new trainers, so the 2nd floor is the dorm where you begin the game. Because of where you dropped in, the Aides were in the way, so I moved them...and they would make a 10th and 11th sprite actively on the screen for a split second. I correct this and PRESTO, it worked. (I had originally reset Oak's Lab to its normal files, which lead me to think part of this was related to accessing wram issues, due to other changes I had wrought) Thus far, this is the only reliable fix for that experience. BUT, it did lead me to find the wild Mon data being overridden~
Alright, bug largely fixed: My Oak Error was the number of sprites on screen. I commented out the girl and it works perfectly with my aides placed where I wanted them.
This came up in the thread about altering the system to use two ID bytes for Pokemon instead of one; I've rewritten and added tags to my wram, added the larger sram details to the end of my wram file, and updated my save.asm to account for much of this.
NOW, I am not holding onto my sprite data on loading a saved file. The new tags and labels look right, the body of the script was copied over (some of the original labels remain so I don't break stuff on my copy), and it compiles, but whenever it loads a game no map sprites are loaded with it. They load into the RAM fine when you re-enter the map, but I tested it in Oak's lab before choosing a monster and all of the scripts still load, trapping the player because the sprites are not there to interact with.
Sounds like you made a mistake when copying over changes in the save routine, causing it to not save all of the sprite data. (or potentially, missed something in the loading routine, causing it to not load it when you resume the game) Without seeing your actual changes to see and point out anything specific, all I can say is to go back and double check and make sure you ported everything over properly, and didn't skip anything or make a typo in the process somewhere.
Last edited by Mateo (2016-04-15 22:00:37)
I'm using ConTEXT, which has a fun compare feature; I've managed some of these updates by downloading the modern copy and running a file compare and seeing where the actual differences lie.
I can post and link my copies of the files (w/sram and save); I didn't know if it had happened often enough someone had a quick answer or not.
I'll post those and go back over with a fine tooth comb.
Some of the constants will be different; I either adapted it to the constants already in the file with the new code or added them as what amounts to a dual definition.
Last edited by daMoose52 (2016-04-15 22:40:05)
I'll take a look at it and see what I can find. For reference, here is the commit where I fixed save routines. Red++ was forked around the same time yours was, so it is a relevant comparison.
EDIT: I think I see your problem. In this part right here:
SECTION "Sprite State Data", WRAM0[$c100] wSpriteDataStart:: wSpriteStateData1:: ; c100 ; data for all sprites on the current map ; holds info for 16 sprites with $10 bytes each ; player sprite is always sprite 0 ; C1x0: picture ID (fixed, loaded at map init) ; C1x1: movement status (0: uninitialized, 1: ready, 2: delayed, 3: moving) ; C1x2: sprite image index (changed on update, $ff if off screen, includes facing direction, progress in walking animation and a sprite-specific offset) ; C1x3: Y screen position delta (-1,0 or 1; added to c1x4 on each walking animation update) ; C1x4: Y screen position (in pixels, always 4 pixels above grid which makes sprites appear to be in the center of a tile) ; C1x5: X screen position delta (-1,0 or 1; added to c1x6 on each walking animation update) ; C1x6: X screen position (in pixels, snaps to grid if not currently walking) ; C1x7: intra-animation-frame counter (counting upwards to 4 until c1x8 is incremented) ; C1x8: animation frame counter (increased every 4 updates, hold four states (totalling to 16 walking frames) ; C1x9: facing direction (0: down, 4: up, 8: left, $c: right) ; C1xA ; C1xB ; C1xC ; C1xD ; C1xE ; C1xF ds $10 * $10 SECTION "Sprite State Data 2", WRAM0[$c200] wSpriteStateData2:: ; c200 ; more data for all sprites on the current map ; holds info for 16 sprites with $10 bytes each ; player sprite is always sprite 0 ; C2x0: walk animation counter (counting from $10 backwards when moving) ; C2x1: ; C2x2: Y displacement (initialized at 8, supposed to keep moving sprites from moving too far, but bugged) ; C2x3: X displacement (initialized at 8, supposed to keep moving sprites from moving too far, but bugged) ; C2x4: Y position (in 2x2 tile grid steps, topmost 2x2 tile has value 4) ; C2x5: X position (in 2x2 tile grid steps, leftmost 2x2 tile has value 4) ; C2x6: movement byte 1 (determines whether a sprite can move, $ff:not moving, $fe:random movements, others unknown) ; C2x7: (?) (set to $80 when in grass, else $0; may be used to draw grass above the sprite) ; C2x8: delay until next movement (counted downwards, status (c1x1) is set to ready if reached 0) ; C2x9 ; C2xA ; C2xB ; C2xC ; C2xD ; C2xE: sprite image base offset (in video ram, player always has value 1, used to compute c1x2) ; C2xF ds $10 * $10 wSpriteDataEnd::
You have a SECTION heading in between the wSpriteDataStart and wSpriteDataEnd labels. That section heading in the middle is supposed to be removed or commented out. In looking back over this, I seem to remember having this exact same problem while working on it, and I think that ended up being the cause.
Last edited by Mateo (2016-04-15 23:11:23)
I was skimming yours and saw it commented out and started to wonder about that; I'll give that a go! Thanks!
No problem, hopefully that takes care of it. If not, well, I'll keep looking.
And thar she blows! Works perfectly!!
This is nice; getting some solid progress, I had given up after the earlier botched Starter Oak script headaches and a little time off was just what was needed; new eyes :D Thanks for the hand!
So my breakdown, if anyone else looks in on the thread:
- The initial corruptions posted about the Oak script stemmed from the sprites in the room: by moving the position of Oak's aides, too many sprites were on screen at one time and overflowed.
- The Wild 'Mon data resulting in a Level 0 encounter for the 3rd monster in a route's listing stemmed from overflowed PokemonOwned, PokemonSeen values
- The saved file issues stemmed from the SpriteData having the "Section" marker within after I added the SpriteDataStart, SpriteDataEnd markers.
Last edited by daMoose52 (2016-04-16 02:50:00)
No problem, glad to help. And feel free to snoop around in Red++ in the future if you're curious or running into problems with something I might have already fixed.
I'm going to roll up the sleeves and dig into yours, but in the mean time I'm seeing another funny memory issue: the items are not saving properly either. I save, reload, and the items are rubbish as well.
Will be reading over yours, but figured if you had similar memory issues you might be able to point me at the matter easily. If not, I can always read :D
That I'm more confused about. The way you described it, it sounds less like a new-item related issue and more of a wram or sram issue, like something might still be hardcoded and causing the data to be overwritten or something. Or am I misunderstanding the problem you described? Is it only an issue with your new items, or is it just the pack in general becoming corrupted?
Nope, you've got it as-described~ The whole pack is corrupt on reloading the save file.
*I* relocated my Pokemon data elsewhere because of the prior issue, but I left a padded set of bytes at the top of the file to accomodate and keep the structure intact as somethings still appear hardcoded, which is what that wild pokemon issue I mentioned above was.
So I figure this is an SRAM save issue I would think instead of wram issue like the earlier matters were.
Something about the locale of the wPokemonOwned block of flags is important when it comes to storing the item data; relocating my flags back to the top of the MainData block restored the saving of the items as appropriate but restored some sprite errors in scripts and the Level 0 Pokemon in the wild. Adjusting the apparently blank run of bytes just after "wDestinationWarpID" to account for my expanded PokemonOwned etc flags to keep the following addresses "the same" restored the wild 'mon levels and prevented the sprite errors in the scripting.
In Red++, I also experienced some issues with lv0 Pokemon in the wild. This was caused by wram_constants.asm still being a thing, causing it to attempt to load the Water Rate in the middle of grass encounter data, setting one of the levels to 0 in the process, among other things. This came from not always remembering to fix the offsets it manually allocated to account for dynamic things that had expanded (in this case, pokedex flags and stuff like that). I'm not really sure why you felt the need to move some of the pokedex flags around instead of keeping them in place and dynamically allocated based on NUM_POKEMON, unless by only being slightly more outdated than mine, yours still has a ton of hardcoded ram addresses somehow or something.
I do think there's more hardcoded addresses than I realized~ It is working now, and I'll be sussing more of that out as I go along, but I at least know what the cause is and have a rudimentary fix while I update the files.