• 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!
  • PokéCommunity's Easter Egg Hunt is now on! If you're interested in looking for some eggs and earning badges, click here!
  • 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.
    Register

Pokemon Emerald 80x80 Sprites

FroggestSpirit

FroggestSpirit

    • 19
    Posts
    13
    Years
    • Seen Apr 11, 2021
    Not sure if this is the best place, but wanted to drop this here:
    https://github.com/froggestspirit/pokeemerald/tree/80x80Sprites
    I recently released a branch for those who use the decomp, that replaces the 64x64 sprites with the DS's 80x80 ones.
    For a long time, people said it wasn't possible, or it was too much work. It's not perfect, but I'm pretty happy with the results. This works by creating additional sprites that mimic the main sprites position, rotation, etc. I've adjusted the positioning of the healthboxes, and moved the main battle textbox down 8 pixels. All Pokemon should be using their D/P sprites, with the exception of Castform and Unown. Trainers are the same emerald sprites, but on an 80x80 canvas, so they can be upscaled/replaced if needed.
    There's a few known bugs as mentioned on the github, and there can be breif moments of a sprite being cut off during an animation (like when smoochum is sent out in the gif attached). This generally only happens in double battles, since the GBA has a sprite limit per scanline (Transformations double the sprite canvas size).
     

    Attachments

    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      8080.gif
      509.5 KB · Views: 546
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      80802.gif
      807.5 KB · Views: 479
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      80803.gif
      1.3 MB · Views: 402
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      pokeemerald_modern-0.png
      8 KB · Views: 463
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      pokeemerald_modern-1.png
      9 KB · Views: 434
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      pokeemerald_modern-2.png
      7.3 KB · Views: 376
    • [PokeCommunity.com] Pokemon Emerald 80x80 Sprites
      pokeemerald_modern-3.png
      7.8 KB · Views: 413
    huh, this looks like a potential game changer, when(if) everything's ironed out.

    I can see re-creating gen 4 in gba, so we can use all the gen 3 tools. XD
     
    marios92 said:
    This will be possible on Fire Red too? 🤔
    Click to expand...
    If it was possible to accomplish in Pokeemerald, it should be just as possible to do in Pokefirered, yeah.
    Hunch says it'll need some extra tweaks to make it work there though, and you may need to take different edge cases into account, such as the animation that is triggered when you give a medicine or a Rare Candy to a Pokémon.
     
    Is it possible to only replace the trainer sprites with 80x80 ones? And the pokémon sprites stay the same size (64x64).
    Or are they somehow tied together?
     
    Great job
    By the way, are those biggus size sprite take lots of space such as OAM VRAM?
     
    Something I'm hoping to see from this is to have the this being toggable via a script. So you can use normal sprites for 99% of the game (so double battles and such aren't affected), but then have the 80x80 sprite for special boss battles.

    My main concern is the hassle of getting the sprite engine being swapped being stable, but more so weather the player's side is tied to the enemy sizes or not.

    The other obvious use for this is Gigantamax, though that would involve changing a 64x64 sprite to a 80x80 sprite mid battle, which I'm sure would be much harder than setting sprite sizes pre-battle.
     
    Hi!

    I've been trying to compile this code, but I keep getting this error:

    Code: 
    `rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/battle_anim_mons.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/battle_anim_mons.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex_cry_screen.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokemon_animation.o: defined in discarded section `COMMON' of gflib/sprite.o

    I've tried merging with a more updated version of pokeemerald, and adding an extern definition for rawMatrix to sprite.h, but I couldn't get that to help. Do you know what might be causing this, or how I can fix it?
     
    CassiLightning said:
    Hi!

    I've been trying to compile this code, but I keep getting this error:

    Code: 
    `rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of gflib/sprite.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/battle_anim_mons.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/battle_anim_mons.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokedex_cry_screen.o: defined in discarded section `COMMON' of gflib/sprite.o
`rawMatrix' referenced in section `.text' of src/pokemon_animation.o: defined in discarded section `COMMON' of gflib/sprite.o

    I've tried merging with a more updated version of pokeemerald, and adding an extern definition for rawMatrix to sprite.h, but I couldn't get that to help. Do you know what might be causing this, or how I can fix it?
    Click to expand...

    You can solve this by changing the declaration of rawMatrix in gflib/sprite.c to:
    Code: 
    EWRAM_DATA struct ObjAffineSrcData rawMatrix[OAM_MATRIX_COUNT];
     
    You must log in or register to reply here.
    Back
    Top