Skeetendo

I am attempting to do this also, and get the error:

ERROR:  red/main.asm(2) -> main.asm(4760) -> engine/menu/party_menu.asm(34) :
        Macro 'coord' not defined

I'm not entirely sure why this would happen as the original party_menu.asm also used "coord" and had no problems???? Nothing has really changed that would have affected this so...

Last edited by KeiTaRo (2016-02-16 12:38:56)

Thanks for your response! I'm still really new to this, so I appreciate the help. Trying my best to learn as I go. Curious, what is the reason for using hlCoord instead of coord hl in this case (since the original seemed like it used to work, but no longer does?) Also, when attempting your fix, it gives me a different error now:

rgblink -n pokered.sym -o pokered.gbc red/audio.o red/main.o red/text.o red/wram.o
C:\pokered\cygwin64\usr\local\bin\rgblink.exe: Unknown symbol 'Func_71882'

I've really reached a dead end with this error. It seems Shichirobei had this same issue but I'm not sure if I really understood the fix. Danny-E 33 mentions that he may have been copying old code, but I was using Danny-E 33's code :P so I assume that would not be the case here. The only times I see Func_71882 mentioned even at all is in two seemingly unrelated files (naming_screen.asm and trade.asm)... using the code:

callba Func_71882

It shows up again in mon_party_sprites.asm in what I assumed was probably the culprit, but only in the comments. Also, this chunk of code does not differ from the vanilla PokeRed in this case, so I'm not sure why it would be an issue. it's listed on the following lines:

WriteMonPartySpriteOAMBySpecies: ; 71882 (1c:5882)
; Write OAM blocks for the party sprite of the species in
; [wMonPartySpriteSpecies].
xor a
ld [hPartyMonIndex], a
ld a, [wMonPartySpriteSpecies]
call GetPartyMonSpriteID
ld [wOAMBaseTile], a
jr WriteMonPartySpriteOAM

Again, I'm fairly new to this, so I apologize if I'm missing something obvious, but I'm treating this as a learning experience :P I feel like I'm missing a major step...also, I noticed that Danny-E 33's data/mon_party_sprites.asm is the same as the original....is that going to cause problems? do I need to define the new sprites somewhere? Again, I apologize if I'm asking obvious questions, I'd just like to learn as much as possible so I can hopefully be less reliant on others in the future x_x

also, if it helps to know what I've done so far, I've literally just replaced engine/mon_party_sprites.asm, engine/mon_party_sprites2.asm, and engine/menu/party_menu.asm with the ones Danny-E 33 provided. I added the approriate GFX file, and then added them to the end of main.asm by copying the code exactly as it was in the main.asm he also shared in this thread. To the best of my knowledge, I've been following the example code 1:1 (and yes, my game did compile before doing this...I was using pokered-gen-II if that has any bearing on this!)

I have not changed anything in any other file than what I've mentioned here. Really all I want to be able to do is just use the Pokemon menu icons from G/S/C :( so I guess what it comes down to is that I really just need it so the game displays two full sprite frames instead of two frames of mirrored halves. Surely it would be less complicated than all this?

Last edited by KeiTaRo (2016-02-16 22:25:32)

I've been using Notepad++ so far!

hlCoord is the old version of coord hl just like Func_71882 is the old version WriteMonPartySpriteOAMBySpecies. The code you're copying is old and some of the labels have been renamed since that code was written. Unknown symbol 'Func_71882' means that Func_71882 is referenced, but it does not exist. It indeed does not exist, because now it's called WriteMonPartySpriteOAMBySpecies. callba Func_71882 attempts to call a function called Func_71882, but since no such function exists, it doesn't know what to call. Replacing callba Func_71882 with callba WriteMonPartySpriteOAMBySpecies will fix this issue.

However, you'll run into one error like this one for every label mismatch. Copy-pasting his code straight away isn't going to work because there are a lot of functions and addresses whose labels have been updated since it was written nearly two years ago. You should stick to porting only the necessary changes of each file to your own repository, rather than the whole file because otherwise you're going to break everything. Then you would update all the labels that don't match their current name by looking at the most recent version of pokered. It's maybe a better idea to look at the related commits rather than the files. I think what you need is this commit and the nicknaming screen fix from this other commit.

Last edited by Crystal_ (2016-02-16 23:47:32)

Okay! Update on this issue: I was able to fix the issue with the pointers corresponding to only 1/4 of the sprite (updated the number for vSprites + [value] to be + $40 instead of + $20 from the previous) but still have no idea idea how to expand the pointer table or remove the weird functionality for the Ball and Helix entries...still, this is progress! yay!

It appears as though the second frame of every sprite is determined in the pointer table not by its physical location in the list but by the "vSprite + [value]" ...would appear whatever entry is + $400 higher than the previous entry's vSprite value become the second frame. I could be totally wrong, but by my experimenting, that is what I came across. It also severely limits how many sprites I could fit in to the list if this is true :( I will keep researching this further, unless anyone has any suggestions.

Figured it out! the answer is in the .animateSprite routine! specifically,

ld c, $40 ; amount to increase the tile id by

Increasing this means I can add on to the pointer table entries, it seems! yay! By how much? Guess I will find out :P The issue with the weird hardcoded Helix and Ball thing still stands

EDIT: Further update! under LoadMonPartySpriteGfxWithLCDDisabled, there is a "ld a, $1c" which hardcodes the entire number of entries in the pointer table. This too must be updated. That answers my question of how much I can increase it by, I guess (I hope?) Also, I was able to disable the routine which forces Ball and Helix in to a single bouncing frame as opposed to an animated sprite sprite, but still have no idea what code is at play to determine where the Helix entry is getting loaded from. If anyone has insight, that would be fantastic.

EDIT EDIT: .....oh....kay. So, it turns out all you need to do is set a pointer entry in the space between Ball and Fairy (and increase the table length to $1e) and make sure that it corresponds to vSprite + $80 and it automatically becomes assigned to the helix slot? wh....I'm not going to pretend I understand <i>how</i> this works, but it does work, so okay, not gonna argue.....heh. I'll probably write up a tutorial here in a bit on how to do all of this using the original icon engine.

Last edited by KeiTaRo (2016-04-08 23:58:22)

This might be of some help.

Originally, there are only 10 party menu sprite ids. Since there are so few, all 10 can be loaded into vram before exactly which sprites are needed is determined.
When the sprites are being loaded, the actual address of the helix sprite, OmanyteSprite (omanyte.2bpp), is never directly referenced since it is in rom immediately after BallSprite (ball.2bpp) which also must be loaded.

You might notice that MonPartySpritePointers references BallSprite, which is a single 2x2 tile image. Since each tile is $10 bytes, this image must be $40 bytes. But MonPartySpritePointers says to load $80 bytes starting at BallSprite. This guarantees that the helix sprite will be loaded and also that it will immediately follow the ball sprite in vram.

Secondly, GetPartyMonSpriteID gets the sprite id for the currently loaded pokemon from MonPartyData. Remember that valid numbers for this id are from 0 to 9. But before this routine returns the result in a, it actually returns the id << 2.
This guarantees that instead of returning $0, $1, $2, $3, $4, $5, $6, $7, $8, or $9, it returns $0, $4, $8, $c, $10, $14, $18, $1c, $20, or $24.

If you run the game in an emulator like bgb and open the vram viewer while the party menu is open, you will see that these values correspond to the tile ids of each sprite.

For example, SPRITE_HELIX has the value 2. So 2 << 2 is 8. In the vram viewer, tile $8 is the base tile for the helix sprite.

Next, you might notice that the return value (from GetPartyMonSpriteID) that is in register a immediately gets stored in wOAMBaseTile, which gets used by WriteAsymmetricMonPartySpriteOAM and WriteSymmetricMonPartySpriteOAM when constructing the oam data for each pokemon in your party.

I'm not sure how much of this helps clear up some of your confusion, but I hope some of this information is of use to you. It should at least solve the mystery of how the helix sprite gets correctly loaded and used.

Have you checked this out? https://github.com/dannye/pokered-proto … it/bb22063

I know this is an old post, but I want to add this sprite to the party menu, should I proceed to do aaall these steps?
(Btw, the same sprite is repeated serious times because I only want to add 1, just did it that way because is based on what I found on pokered)

Near as I can tell, its not updating the index properly. When I reload the menu, the sprites are the proper sprite, but do not update on shifting them.

There we go :D
Its exactly as I expected, but not where I expected it to be :D I knew the routine wasn't reloading the new sprites right and was looking for somewhere the refresh occurred, but I was looking in the actual party_mon files~

Quick Edit: Any way to address the flicker/garbage that appears on the redraw?

Last edited by daMoose52 (2016-10-14 22:58:03)

For a split second, when it reloads the sprites, there's some garbage on the screen:
http://projectneo.retrogaminggear.com/i … licker.AVI

Yup, routines have the LCD Disabled and re-enabled as appropriate.
My core ASM is a little old so the function names don't always line up but its there~ Both on the old routines and the ones I imported as a part of this feature.

Here's my initial portion of the party_mon.asm file:

DrawPartyMenu_: ; 12cd2 (4:6cd2)
    xor a
    ld [H_AUTOBGTRANSFERENABLED],a
    call ClearScreen
    call UpdateSprites ; move sprites
RedrawPartyMenu_ReloadSprites:
    callba LoadPartyMonSprites ; load pokemon icon graphics ;callba Func_71791 ; load pokemon icon graphics

RedrawPartyMenu_: ; 12ce3 (4:6ce3)

I do note the difference in the function name, but that's mostly a difference of age and not function. Here is that routine though, straight from your mon_party_sprite2.asm file in my build:

LoadPartyMonSprites:

    call DisableLCD
    ld de, vNPCSprites
    ld hl, wPartySpecies
.loop
    ld a, [hli]
    cp $ff
    jr z, .done
    push hl
    call LoadPartyMonSprite
    pop hl
    jr .loop
.done
    jp EnableLCD

Last edited by daMoose52 (2016-10-15 17:16:16)