Jump to content

Tabun_ne

Member
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

13 Good

1 Follower

About Tabun_ne

  • Rank
    Member
  • Birthday 01/01/1991

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Tabun_ne

    banner.bin

    banner.bin and banner_s.bin are both found in the /FONT/ folder. They contain data for the dungeon title font. File Structure The file uses SIR0 headers to store its pointers. General SIR0 details can be found in the main SIR0 documentation. The sections below will cover only banner.bin-specific blocks of data. Name Offset Size (Per Element) # of Elements Description SIR0 Header 0x00 16 Bytes 1 Details in the SIR0 documentation Glyph Textures Poi
  2. Finally got back to this place. Thought I'd have to reset my password because of the security issue so I kept putting it off... But I picked up on the effect bin again. And now it is finished. https://www.spriters-resource.com/ds_dsi/pokemonmysterydungeonexplorersofsky/sheet/85692/ A few closing notes for posterity, as an addendum to the info I posted up there in Section 2 is definitely responsible for some form of Draw-behind shenanigans. I went through the whole list of effects and all of the components that don't use a "0" for that value tend to appear behind the pla
  3. I'm taking a break from VFX ripping... I got pretty far, but the last step demands more free time than I have at the moment... I'm more curious about dungeon data now. Has there been any headway made in the past regarding the stats for the dungeons? According to the notes I was able to find on the subject, that data seems to be found in /BALANCE/. But which files would they be?
  4. After playing around with the ROM a bunch, it looks like this is how the meta-frames work: Example Metaframe: FF FF 00 00 ED A1 E9 04 00 7CSections: 00 00 11 22 33 44 55 66 77 89 Section 0: ALL FFFF Section 1: ALL 00. Section 2: 00 or FB. Maybe determines draw-behind? Section 3: Y Offset Section 4: Dimensions in Binary Flags: 0123 4567 01: 00 in Sharpen and Barrage, 10 in Embargo 2: Unknown (ALL 1) 3: Mosaic Mode (ALL 0) 45: Unknown (ALL 00) 67: Upper Bits for Y offset Section 5: X OFfset? Section 6: Dimensions in Binary Flags: 0123 4567 01: Size; 00=8x8,
  5. Given how both the screenshots are at "Main Spr Ext PAL 7" I can't think of any way the palettes aren't set to the correct slot... I just needed some sanity check to make sure I wasn't making some silly mistake with my emulation. I guess if all else fails I'll skip right to editing the image datas to reference every palette index possible and see what the colors are that way...
  6. It's odd... for some reason, the colors in the palette view don't match up with the tile view. For instance in that earlier image with Embargo: http://i.imgur.com/VtxmdYn.png The shades of purple found on the embargo diamonds don't match any of the purple in Main Spr Ext PAL. It's messing with my attempts to investigate palette. Might this be an emulator problem? (I'm using DesMuMe) Have you or anyone else run into this issue?
  7. http://i.imgur.com/H4koduf.png There's the meta frame data, palette data, and data for both textures of Embargo there. Looking at the palette data, I couldn't find any colors that the actual in-game sprite used. However, I remembered something about the way palettes worked with moves in the past: there's always this list of about 8 to 10 palettes that gets loaded in "Main spr EXTPAL", and (nearly) all of the moves in the game use this as a sort of "master" palette. There's still a small amount of exceptions that use their own palette instead of the "master" palette- something I noticed wit
  8. Yeah, it looks like the last files aren't WAN and happen to be some other format... I actually ran a script to first rewrite that one byte all the sir0 files since the gfxcruncher didn't work with my current version of c++ (and I'm wary of getting the new Visual studio currently...) http://pastebin.com/z6rwsX9q These are my notes for the garbage texture data- I wasn't really aiming for completeness so much as trying to find points of interest to deduce from. There were in fact a number of effects that showed up with the same palette as in the game! For everything else, though, it looks li
  9. I had some time today and ran through a list of all the sir0 files found in the effect.bin, and what WAN-like filetypes they are, assuming they're WAN at all. http://pastebin.com/UrAGG3TU I also force-converted the files with the image type of 2 through the gfxcruncher, just curious of the results https://www.dropbox.com/s/yi904m0da78m4s3/forceChar.zip?dl=0 Even though the palette and image sizes are garbage, the converted product actually survived the process! There's definitely some familiar effects in there that have the same silhouettes as what I manually ripped before... I'm consider
  10. http://pastebin.com/JtUTvrR3 These are the results I got when I opened up effect_0117_0x100610.sir0, extracted from the effect.bin and followed the WAN reference of pointers. It was the smallest file on the list, so I went through the whole thing manually. All of the pointer data appears to be consistent and the format seems to fit perfectly, with a few things to note: ln174: The sprite type reads out as 2. According to your notes, you've never found files with that number before... ln13 and 27: Meta-frames read out for some wonky results. -1 frames the only meta-frames in the list. Re
  11. I ran effects.bin through the ppmd_packfileutil this time, and now things start making much more sense. I'm not very well-versed with rom hacking (I've only just now downloaded HxD and tilesGDD to work with), but I think I'll try to research on this effects.bin format as well, probably cross-referencing with the existing WAN format due to how much sense it makes that they would be similar. I don't have much else to do in the immediate future...
  12. As a needed step towards finishing my standalone game, I've come to the challenge of having to obtain the graphical effects used in Pokemon moves. Traditionally I've done this by ripping them through emulator tile view, but that involves going through every single move manually. Does there exist the means to extract these graphics from an unpacked rom? I tried running the gfx cruncher on /EFFECT/effect.bin, but the resultant files seem to be in an unspecified format. And on the topic of ripping sprites from a live game... Regarding dungeon tiles, would it help your research if I provided a
  13. I tested the monster and m_attack animations after porting them directly into my standalone application. I suspect there may be a few bugs, but just testing out charmander, charmeleon, and charizard revealed a few things. monster 0- walk 5- sleep 6- hurt 7- idle m_attack 1- regular attack 2- kick? (charmander kicks, charmeleon and charizard scratch) 3- shooting (flamethrower) 4- attack with arm/shooting? (charmander scratches, charmeleon/charizard shoots) 8- spin around attack (fling, feint attack) 9- double team/agility 10- jump a little, while in shooting animation (maybe diggi
  14. Alright, these last few days I've been writing some conversion scripts to check things out. Firstly, I wanted some more confirmation on the reverse-drawing method, so I assembled every FrameGroup that had overlaps, and drew them all out in reverse order: https://www.dropbox.com/s/pkgvs9g7u5bod1r/MONSTER_overlap.zip?dl=0 Just having them all on preview in that one folder seems to confirm it as a consistent rule- at least enough to convince me. The images that start with an underscore denote that they have -1 frames and aren't completely reliable, which led to another question... One thing d
×
×
  • Create New...