• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Our weekly protagonist poll is now up! Vote for your favorite Conquest protagonist in the poll by clicking here.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[pokeemerald] Sprites and GPU Registers Updating at Different Rates?

  • 6
    Posts
    1
    Years
    • Seen Dec 26, 2024
    I might be in way over my head here but I've sloppily pulled together some code to prototype a scrollable list of moves for each species in the Pokédex. I've also added the relevant move type sprite icon alongside each move in the list - I've added these as sprites rather than background tiles so I can attribute the right palette colours to each one, and because all backgrounds are in use.

    [PokeCommunity.com] [pokeemerald] Sprites and GPU Registers Updating at Different Rates?

    I have the list working and scrolling almost exactly as I want, but there's a small issue which is driving me mad. The function which updates the scrolling animation is a modified version of UpdateDexListScroll and works by incrementing the GPU register REG_OFFSET_BG3VOFS at the same time and increment as the move type sprites, so that they would move in unison. However, despite debug statements confirming that the increments are identical each frame, the visual rendering is not. The list in BG3 begins updating its position on screen before the sprites do, and sometimes either jumps ahead or skips a frame when moving. Here's how that looks in practice (notice the 'jostling'):

    [PokeCommunity.com] [pokeemerald] Sprites and GPU Registers Updating at Different Rates?

    I thought this may have been due to how unoptimised the code was, and that there was just too much going on between each frame, but I get the same behaviour when reducing down to a single sprite with hardcoded increments. My guess is that the GPU register and the sprites are updated visually on-screen at different points, and that's what's causing the discrepancy. But since I mostly just tinker with game logic rather than graphics programming, I don't really know where to start on finding a solution. I did wonder if there was a way to force the frame to be drawn later, so that both the sprites and the background would be in sync, but I've not figured that out yet.

    Any help would be appreciated, as I'm struggling to find much I can read up on to understand the cause of the issue.

    I will also share the function which scrolls the list below (apologies, I know it's gross - the idea was to get something working and then tidy up from there):

    Spoiler: UpdateMovesListScroll
     
    Last edited:
    Quick self-update in case anyone else stumbles upon a similar issue or finds it useful - As far as I can tell, GPU registers are buffered immediately, and so updates are rendered pretty much as soon as they occur. Sprites are double-buffered, so that their updates are applied during VBLANK and rendered after that. I'm not sure how accurate this is, but it matches up with my experience here.

    My solution has been to buffer the update to REG_OFFSET_BG3VOFS, and apply it after the updates to the sprites in VBlankCB_Pokedex. This is for sure not the best way of doing things, but it does seem to have solved it.

    [PokeCommunity.com] [pokeemerald] Sprites and GPU Registers Updating at Different Rates?
    I'll share the changes here, but again I don't recommend anyone copy this work, I'm just sharing to provide some insight.

    Spoiler: UpdateMovesListScroll

    Spoiler: SyncBg3VOffset

    Spoiler: VBlankCB_Pokedex
     
    Last edited:
    Back
    Top