Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2017-07-14 05:07:26

ShockSlayer
Member
Registered: 2017-06-17
Post 5/15

[pokecrystal] Porting ported prism party palette problems

Hello friends,

I've recently semi-successfully ported Polished Crystal's port of Prism's party screen's individual Pokemon palettes. It's a really nice feature, so thank you to everyone who worked on it. I gotta say it's a must-have for any hacks in progress.

Anyways, I was able to figure out most everything eventually, but there are two particular parts that've frustrated me a bit, so I'll try to detail them here. I'm also not 100% sure if this first one is a pre-existing bug or not.

1. For some reason, for about one/two frames when moving Pokemon, held items inherit the same palette as the party member:
1rWZd1I.png
Again I'm not sure if this is related to anything I may have missed when porting the code. It's absolutely minuscule, but hey; if anyone's got any suggestions - I'm game.

2. Custom palettes based on shiny status were something I couldn't port directly. The hack Noah and I are working on strives to be as vanilla as possible, so we've maintained a few rules to keep compatibility with the original games and things like Stadium 2. A weird goal considering the nature of romhacks, but so far everything still works fine on original hardware. One of those rules is to not modify Pokemon structure, which is the main reason I'm having trouble.
If you take a look at the previously linked commit's version of mon_icons.asm, you'll see that in four places(specifically lines 59, 92, 164 and 188), PC uses it's custom Pokemon structure to identify shiny status. TempMonShiny, MON_SHINY and SHINY_MASK are things that we don't have, and (likely) won't be able to use. In order to compile, we substituted in TempMonDVs and MON_DVS, but obviously these don't work in the same way. I've messed around with trying to farcall CheckShininess, and even tried using Prism's CheckShininessHL, but haven't had any luck. I know this is probably dead simple to someone who knows what they're doing, but I'm still learning.

Offline

#2 2017-07-19 08:54:28

ShockSlayer
Member
Registered: 2017-06-17
Post 6/15

Re: [pokecrystal] Porting ported prism party palette problems

Mission complete boys:
ca9UhCc.png

What's funny is that my methodology to fix this one happened almost accidentally. Something interesting about custom shiny palettes is that obviously, there are some shinies who's color changes don't differ that much, so the best matching icon palette is going to be exactly the same.

For example, Tentacool's normal and shiny palettes:
7aSLkzA.png
and it's entry in mon_icon_pals.asm

dn PAL_OW_BLUE, PAL_OW_BLUE ; TENTACOOL

(maybe teal would look good, but I haven't bothered messing with any palettes other than magnemite/swinub)

So, while I didn't check or change all of them, I knew that chances were, there would be gift/starter pokemon that people might want to reset for a shiny, and if they were going use the name screen icon to check(or wanted to,) it wouldn't work for every Pokemon. So my solution was to add the shiny icon to that screen. However, my initial solution wasn't great, and it also tricked me since I didn't properly test it.

I copied this code from stats_screen.asm and changed the hlcoords to a better spot, as well as changed <SHINY> to <SHINYB>, which was also ported from an older version of polishedcrystal, since the shiny character is not available by default in the loaded font.

And, it "worked." It would show the icon if you caught a wild shiny Pokemon, but not if you received one, and it also wouldn't show up if you took the same shiny Pokemon to the name rater. Naturally this frustrated me, as the whole reason I added it was for gift Pokemon. So I kept messing with it, but it wasn't until I stumbled upon the "GetGender" function that I was able to come up with a solution. I realized that since it was being called on the naming screen so that it could place gender, it had to be reading DVs from the proper place. So I took a look at it, and was able to quickly smash it together with the "CheckShininess" code. And it worked like a charm. Originally I had left in all of the different types of detection, but quickly realized that during battle, checking the party screen would apply shininess to all pokemon based on the enemy Pokemon's DV's, so I just deleted stuff until it worked properly. The best solution.

Anyways, here's the code:

GetShiny: ; called at nicknaming screen, party screen, move screen
; this is based off of the GetGender function below; however we only need to call the one type for the affected areas to work

    ld hl, PartyMon1DVs
    ld bc, PARTYMON_STRUCT_LENGTH
    ld a, [MonType]
    and a
    jr z, .PartyMon

.PartyMon:
    ld a, [CurPartyMon]
    call AddNTimes

.DVs:

; Attack
    ld a, [hl]
    and 1 << SHINY_ATK_BIT
    jr z, .NotShiny

; Defense
    ld a, [hli]
    and $f
    cp  SHINY_DEF_VAL
    jr nz, .NotShiny

; Speed
    ld a, [hl]
    and $f0
    cp  SHINY_SPD_VAL << 4
    jr nz, .NotShiny

; Special
    ld a, [hl]
    and $f
    cp  SHINY_SPC_VAL
    jr nz, .NotShiny

.Shiny:
    scf
    ret

.NotShiny:
    and a
    ret

It would probably be a lot more efficient just to "farcall CheckShininessHL" instead of copying the entirety of the code, but this works just the same.

So, I was able to use this function like so on the naming screen:

.Pokemon: ; 1173e (4:573e)
    ld a, [CurPartySpecies]
    ld [wd265], a
    farcall LoadNamingScreenMonIcon
    ld a, [CurPartySpecies]
    ld [wd265], a
    call GetPokemonName
    hlcoord 5, 2
    call PlaceString
    ld l, c
    ld h, b
    ld de, .NicknameStrings
    call PlaceString
    inc de
    hlcoord 5, 4
    call PlaceString
    callba GetGender
    jr c, .genderless
    ld a, "♂"
    jr nz, .place_gender
    ld a, "♀"
.place_gender
    hlcoord 1, 2
    ld [hl], a
.genderless
    call .StoreMonIconParams
.shinyicon
    callba GetShiny ; works as a catch-all for determining shininess
    ret nc
    hlcoord 1, 3
    ld [hl], "<SHINYB>"
    ret

That was the easy part. After realizing it worked, I had to go back to mon_icons.asm and try it out to see if it would work. Basically, all I had to do was comment out all of the aforementioned MON_DVs and TempMonDVs, since the places those were at were also where GetMenuMonIconPalette was called, and add this to the top of GetMenuMonIconPalette:

GetMenuMonIconPalette::
; check shininess
    callba GetShiny
    jr nc, .not_shiny
    scf
    jr GetMenuMonIconPalette_PredeterminedShininess
.not_shiny
    and a

And then suddenly everything worked perfectly!

Here they are working in tandem:
JLFI6tb.png
I'm so happy this is working, this was one of the major remaining engine-related things we needed to tackle for our hack.

Last thing I'd like to mention; testing shiny gift Pokemon. This one actually didn't bother me as much as everything else. I'd remember reading through this thread once and seeing it mentioned, so I tried the first thing I could think of:

.generateDVs
    ld a, [CurPartySpecies]
    ld [wd265], a
    dec a
    push de
    call CheckCaughtMon
    ld a, [wd265]
    dec a
    call SetSeenAndCaughtMon
    pop de
    pop hl
    push hl
    ld a, [wBattleMode]
    and a
    jr nz, .copywildmonstats
    ;call Random
    ld a, ATKDEFDV_SHINY ; very useful for testing shiny "givepoke" stuff
    ld b, a
    ;call Random
    ld a, SPDSPCDV_SHINY 
    ld c, a

And it worked. Naturally, this can't be left in as is, as every gift pokemon would be shiny(any maybe other things idk where all this is called from) but just for testing purposes it was fine. I also triple checked by setting up some pixel detection AHK scripts and verified by resetting for some real shinies.

Anyways, hopefully this'll be helpful to someone, and if there's anything wrong with this stuff please let me know. I'm really glad to have this forum as well as the source from other projects available as a resource.

Offline

#3 2017-07-19 13:50:15

rbroab
Member
Registered: 2017-06-13
Post 50/86

Re: [pokecrystal] Porting ported prism party palette problems

Nice work, looks awesome!
Definitely want to use this for my rom hack
I've been having issues with the icons, definitely need some help.
Not sure if you'd be interested

Regardless, this looks great! Can't wait to implement

Offline

#4 2017-07-19 14:57:07

ShockSlayer
Member
Registered: 2017-06-17
Post 7/15

Re: [pokecrystal] Porting ported prism party palette problems

I'm definitely not the greatest, but I'll do what I can, 'cause I worked pretty hard on them too. I may just need to make a full port of what I've got on a default build of pokecrystal or something. Would that be of use?

Offline

#5 2017-07-20 05:32:55

rbroab
Member
Registered: 2017-06-13
Post 51/86

Re: [pokecrystal] Porting ported prism party palette problems

My issue mainly stems from the fact the base of my rom comes from TPPCrystal251pub
Essentially the build of the game is slightly different compared to that of pokecrystal

Certain files don't exist because they've been moved or combined into other asm files.

I actually spent a couple weeks making individual menu sprites for each and every Pokemon...and in the end only about 20 of them worked. Everything was done correctly, just ran out of room on the rom? Any attempt to fix it only resulted in more errors while building the rom. It'd be awesome if you could take a look and see what you find. If not, no worries! Not a lot of people working with tppcrystal251

So if you could implement your work into tppcrystal251pub, I'd be forever in your debt

Offline

#6 2017-07-20 08:40:04

ShockSlayer
Member
Registered: 2017-06-17
Post 8/15

Re: [pokecrystal] Porting ported prism party palette problems

I'll take a look at it when I can; I've got a lot of projects to work on. In the meantime, I'd love to see the sprites you've worked up if you're willing to share!

Offline

#7 2017-07-20 12:07:37

rbroab
Member
Registered: 2017-06-13
Post 52/86

Re: [pokecrystal] Porting ported prism party palette problems

So I was able to get all the menu sprites to work
Even work for the overworld/daycare
Had some trouble porting the color scripts you used as well as from the prism github

I'll keep taking a look, but would you be interested in helping when you've got the time?

Last edited by rbroab (2017-07-26 01:13:13)

Offline

#8 2017-08-01 00:41:46

ShockSlayer
Member
Registered: 2017-06-17
Post 11/15

Re: [pokecrystal] Porting ported prism party palette problems

Sorry I missed this; been swamped with my own hack as well as other priorities. I haven't forgotten about you man, but I've got a lot on my plate!

First, I've gotta post a revision to the code from before; the previous code will work for almost everything...but if you have a full party and you catch a pokemon, the naming screen will inherit the shiny status of your last pokemon instead of the caught pokemon. Basically, the fix was fairly easy, but I couldn't really wrap my head around what was going on with the OG gender code so I just did things the way I know how:

GetShiny: ; wip
; MonType
;PARTYMON   EQU 0
;OTPARTYMON EQU 1
;BOXMON     EQU 2
;TEMPMON   EQU 3
;WILDMON    EQU 4

    ld a, [MonType]
    cp PARTYMON
    jr z, .PartyMon
    cp BOXMON
    jr z, .BoxMon

.PartyMon
    ld hl, PartyMon1DVs
    ld bc, PARTYMON_STRUCT_LENGTH
    ld a, [MonType]
    and a
    jr .continue
    
.BoxMon
    ld hl, sBoxMon1DVs
    ld bc, BOXMON_STRUCT_LENGTH
    dec a
    
.continue
    ld a, [CurPartyMon]
    call AddNTimes
    
    ; sBoxMon data is read directly from SRAM.
    ld a, [MonType]
    cp BOXMON
    ld a, 1
    call z, GetSRAMBank
    
.DVs
; Attack
    ld a, [hl]
    and 1 << SHINY_ATK_BIT
    jr z, .NotShiny

; Defense
    ld a, [hli]
    and $f
    cp  SHINY_DEF_VAL
    jr nz, .NotShiny

; Speed
    ld a, [hl]
    and $f0
    cp  SHINY_SPD_VAL << 4
    jr nz, .NotShiny

; Special
    ld a, [hl]
    and $f
    cp  SHINY_SPC_VAL
    jr nz, .NotShiny

.Shiny:
    ; Close SRAM if we were dealing with a sBoxMon.
    ld a, [MonType]
    cp BOXMON
    call z, CloseSRAM
    
    scf ; set carry flag 
    ret

.NotShiny: ; doesn't set carry
    ; Close SRAM if we were dealing with a sBoxMon.
    ld a, [MonType]
    cp BOXMON
    call z, CloseSRAM

    and a
    ret

Again, not the most efficient thing in the world, but it should work under all circumstances? I guess I'll find out eventually if it doesn't.
EDIT: Apparently right after catching a pokemon and sending it to the box, the party screen loads the wrong palettes. Argh.
Before calling GetMenuMonIconPalette in LoadPartyMenuMonIconColors, I had to update the MonType back to 0.

I struggled with a stupid bug for a while before I realized this code was okay. I had an NPC who would always use givepoke regardless of circumstance, and I noticed that if I had a full party and it was sent to the box, it wouldn't show as shiny even though I'd forced it in move_mon.asm. So just to verify, I actually looked at the pokemon that was sent to the PC, and they weren't shiny. But whether they were forced shiny or not, they all had the exact same DVs: 08 11 03 07 (and an HP DV of 07.) So, I guess the givepoke function was never intended to send pokemon directly to the PC, which is why every instance of it checks to see if your party has 6 pokemon. Things are starting to make sense now, haha.

Anyways, if it helps, here's my entire mon_icons.asm: https://paste.ee/p/x4DiO EDIT: Updated w/fix
It's basically identical to polishedcrystal's, except with the single shiny function, and the non-descriptive SPRITE_ANIM stuff.


..I still wish I could figure out that pokemon switching item color bug.

Last edited by ShockSlayer (2017-08-01 02:27:09)

Offline

#9 2017-08-01 17:26:27

rbroab
Member
Registered: 2017-06-13
Post 59/86

Re: [pokecrystal] Porting ported prism party palette problems

No worries, you're good!

Is this the only script I need to make color menu icons work?
I've been working on using the code from Prism, but it's scripted so differently than TTPCrystal
Seems like it's structured differently as well. Plus, it has changes to files I don't even have haha.

But I'm about to try your code!

Offline

#10 2017-08-01 18:43:41

ShockSlayer
Member
Registered: 2017-06-17
Post 12/15

Re: [pokecrystal] Porting ported prism party palette problems

As best as I can remember it, there's a handful of places that call the icons, and then mon_icons.asm takes care of the rest. If you can still find where those places were(for example, the naming screen) then you can probably just call what's in there.

Offline

#11 2017-08-01 18:54:23

rbroab
Member
Registered: 2017-06-13
Post 60/86

Re: [pokecrystal] Porting ported prism party palette problems

Well I appreciate the help, but I guess the setups are just too different. Going to build the rom comes up with a bunch of errors. Like depixel being an unknown symbol. Just things like that. I'm guessing the two games use the same functions, they're just under different names so it gets confused when calling for certain functions.

Offline

Board footer

Powered by FluxBB