News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Garyong

Pages: [1]
1
Personal Projects / Re: The Console Tool (by Low Lines)
« on: April 25, 2011, 11:49:37 am »
The old-new version with deleted .ini produces the same error.
The new-new version produces a similar error (which also happens after I delete the .ini file again) =/
Code: [Select]
Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
        at util.gui.CDragDrop.drop(CDragDrop.java:283)
        at java.awt.dnd.DropTarget.drop(Unknown Source)
[snip]

Caused by: java.lang.NullPointerException
        at util.FileAccess.endRead(FileAccess.java:62)
        at util.struct.DPath.closeSource(DPath.java:203)
        at util.Plugin.scan(Plugin.java:150)
        at util.struct.DPath.check(DPath.java:62)
        at util.struct.DPath.<init>(DPath.java:31)
        at util.struct.DPath.<init>(DPath.java:22)
        at util.struct.DPalette.<init>(DPalette.java:9)
        at ctool.Loader.<clinit>(Loader.java:14)

2
Personal Projects / Re: The Console Tool (by Low Lines)
« on: April 25, 2011, 10:04:24 am »
[snip]

I've also uploaded a modified build with these fixes applied to the project page. Keep in mind that this is using the old gui since I'm still working on the next version which has the more stable interface.

Let me know if you find any NSCRs that still display wrong...Also it would be helpful to include the location of the file like I've started doing in my posts...

ie Game Title (Game Id) - filePath
I hope I'm not being picky, but the latest version (3.1a) cannot load any file (trying to do so results in a null-pointer (and subsequent errors));
Code: [Select]
Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
        at util.gui.CDragDrop.drop(CDragDrop.java:279)
        at java.awt.dnd.DropTarget.drop(Unknown Source)
        at sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(Unknown Source)
        at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchDropEvent(Unknown Source)
        at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(Unknown Source)
        at sun.awt.dnd.SunDropTargetEvent.dispatch(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processDropTargetEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$000(Unknown Source)
        at java.awt.EventQueue$1.run(Unknown Source)
        at java.awt.EventQueue$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at util.FileAccess.read(FileAccess.java:53)
        at util.struct.DPath.read(DPath.java:190)
        at util.struct.DPath.read(DPath.java:149)
        at util.Plugin.scan(Plugin.java:80)
        at util.struct.DPath.check(DPath.java:62)
        at util.struct.DPath.<init>(DPath.java:31)
        at util.struct.DPath.<init>(DPath.java:22)
        at util.struct.DPalette.<init>(DPalette.java:9)
        at ctool.Loader.<clinit>(Loader.java:14)
        ... 33 more

Also, if you truly want large NSCRs to test with, try the ones found in Izuna - Legend of the Unemployed Ninja (AHSP) -> contents/data/gra/village/
(eg; Dungeon01BG1.NSCR, which is 1280x1280)

Apparently the internal screen size functions as something to make large, composite tiles. When loading a large NSCR, a sequence of those internal screens are filled with those tiles. To display the full NSCR, those screens should be laid out in a standard tiling fashion (row by row). At least, that is how I got the example image from Izuna given above.
Note that only the first 2 bytes of the 4 labeled as 'Unknown' in your documents indicate the internal screen size; the other two are supposed to be the 'BG Type', which I think only indicates if the game should rotate/scale it at some point or not.


Also, regarding the compression of 'overlay' files; The format is indeed like the built-in LZ with 'type' 0x10 read backwards, but has a different header as well as a slight modification to the algorithm.
The 'header' format is:
Code: [Select]
{
    u8* padding; // 0xFF-s
   
    // length of compressed data. May be less than the file size (minus header size).
    // Same format as the decompressed size in the 'normal' compressed file formats.
    'u24' compressedLength;
   
    u8 headerSize;
   
    // The size of the decompressed file is the original file size plus this value.
    u32 extraSize;
}
The data is located in front of this 'header', so 'extraSize' is the last 4 bytes of the file. When 'extraSize' is 0, the rest of the header is absent.
Only the 'compressedLength' bytes directly before the header are compressed data, anything before that is uncompressed.

The algorithm is slightly modified in the sense that the 'Disp' given in the compressed blocks is 2 less than the 'Disp' that would have been given for the regular algorithm (so just add 2). It also appears to occur regularly that the 'Disp' is far too large for the amount of data that has been decompressed up to that point; in that case I've found that setting it to 1 gives results that appear to be correct.

3
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 28, 2010, 06:55:20 pm »
I knew it!!
I've been glaring at that flag for ages, trying stuff like dividing the x&y by two and getting the remainder etc and all sorts of dumb ideas with little luck. I also thought it was weird how your specs said it shouldn't be set and yet pretty much every animated sprite had it set so :crazy: Another conflict I've seen is generally the eye oam has its object mode set to semi-transparent according to your specs. I'm also seeing the R/S Flag set in some places too (typically most pokemon sprites, but some human sprites don't have it set for all oams).
I never said it should not be set, only that it could be ignored (since I believed it only affected the clipping rectangle) ;]
The R/S flag should coincide with OAMs that are rotated in the NANR animations (and should be set for the Double-Size bit to have that meaning), although they may just have set the flag for all OAMs

The 'Semi-Transparent' flag means that some sort of blending is applied with the background layer (not with other OAMs!). I suppose it could mean that the .dat contains a u16 for each semi-transparent OAM with the blending data. It may also be the unknown u16 in a CellData, but that would mean the blend factor would be equal for the complete cell (which wouldn't be very surprising).
For completion's sake, this would most likely be the format of the u16: (from GBATEK, obviously)
Code: [Select]
4000052h - BLDALPHA - Alpha Blending Coefficients (W)
Used for Color Special Effects Mode 1, and for Semi-Transparent OBJs.
  Bit   Expl.
  0-4   EVA Coefficient (1st Target) (0..16 = 0/16..16/16, 17..31=16/16)
  5-7   Not used
  8-12  EVB Coefficient (2nd Target) (0..16 = 0/16..16/16, 17..31=16/16)
  13-15 Not used

For this effect, the top-most non-transparent pixel must be selected as 1st Target, and the
next-lower non-transparent pixel must be selected as 2nd Target, if so - and only if so, then
color intensities of 1st and 2nd Target are mixed together by using the parameters in BLDALPHA register,
for each pixel each R, G, B intensities are calculated separately:

  I = MIN ( 31, I1st*EVA + I2nd*EVB )
'OBJs that are defined as 'Semi-Transparent' in OAM memory are always selected as 1st Target ..., and are always using Alpha Blending mode'


.... I suppose I should get used to calling the OAMs OBJs. (OAM = OBJ Attribute Memory, apparently  -.-)

4
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 28, 2010, 11:06:02 am »
 :banghead:

I do believe I have a solution to the 'cell gap' that is so obvious, it almost must be true.
It has to do with the 'Double-Size' flag in an OAM data, which indicates that the rendering rectangle should be double the normal size (which is the size of the OAM), since the OAM may be rotated/scaled. You may feel it coming, but the X and Y in each OAM are actually the X and Y position of its rendering rectangle. Since the rectangle's centre stays in the same location, the X and Y in the OAM are half the size of the OAM less than when the Double-Size flag would be 0.

In other words, for a quick fix, for each OAM add half its size to its location whenever the Double-Size flag is 1. (since you still need the centre of the OAM when rotating it, the rest should be the same code)
Some quick tests confirm the cell gap to be gone in the Cells; I'm currently working on my own NANR rendering, so I cannot be sure of anything else. (Of course, I could also have accidentally only tested files in which this particular fix worked, while others need something else to be fixed)

5
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 25, 2010, 06:00:55 am »
Still I think people are crazy if they're trying to rip all those animated sprites manually...I mean yeah back in the days, 151 pokemon is little work, but 649...that would take forever!!
You're underestimating the power of fanboyism. ;P

Quote
I had a brief heart-attack yesterday as I had been backing up my files before I went to sleep and so I immediately wiped all the stuff off my hard drive (had about 250,000+ files and 8000+ folders on it) when I woke up and then realized I had also deleted the folder with my program in it. So I copy it back across from my backup disk and reload it up in Netbeans and for a while I had thought it hadn't updated all the class files I had made changes to since the last backup I did just over a week ago. There's nothing worse than getting heaps done in a short amount of time and losing it in an instant. So I'm there scanning through a Deleted File Recovery app, trying to pick out all the changed files one by one, when I then realize that the files I had changed WERE updated, just some of them I had moved into different folders in the project manager and so the old ones were still there from the previous backup...Stupid me >_<
May I suggest some versioning system like Subversion? It'll prevent such (near-)mistakes, helps you keep track of what you've done when (if you get into the habit of writing 'proper' commit messages), and allows you to easily go back to any previous version of the tool or single files.
Assembla has a free private Subversion (or git, if you prefer that over SVN) repository package available. (I'm assuming 2GB is ample space for the tool's source)


@Lexou: I am indeed =)


[EDIT]

You've probably figured most of this out already, after you've posted your preliminary specs on page 10, but there are my notes on the NMCR anyway (or rather its MCBK section);
Code: [Select]
/* MCBK format:
 * <NitroSection("KBCM", sectionSize)>
 * u16 numMappings;
 * u16 beef;             // constant 0xBEEF
 * u32 mapHeadersOffset; // relative to section start + 8
 * u32 mapDataOffset;    // relative to section start + 8
 * u32 padding;
 * u32 padding;
 * MapHeader[numMappings] maps;
 * u8* padding;          // probably empty, since sizeof(MapHeader)=8
 * MapData* data;
 */

/* MapHeader format:
 *
 * u16 numParts;        // Number of MapData's used
 * u16 numAnim;         // the number of unique NANR entries used
 * u32 firstPartOffset; // relative to mapDataOffset
 */

/* MapData format:
 * u16 animIndex; // index in NANR
 * s16 xpos;
 * s16 ypos;
 * u8 unknown;    // 'const' 0x20 or 0x21. some flags?
 * u8 priority;   // low = draw in front, high = draw in back. (I think, although it seems to coincide with
 *                // the order of the data anyway. Certainly not NCER index though ;])
 */

Posting the NMAR format would be silly, since it only has an ABNK and LABL section. The ABNK section is the same as the NANR ABNK section, but the first unknown constant in an Animation is 2 instead of 1.

This means the 'cell gap' must be fixed by the .dat, or I was wrong and the NCER/NANR actually do contain enough data to fix it. =/

6
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 24, 2010, 05:02:56 am »
Filb appears to have links to large number of the animated pokemon sprites (forgive me if this isn't news...).


I wonder if they ripped them manually, or if someone out there actually has a complete spec :p
After doing some random pokemon ids and getting 404s I'm guessing that these were ripped manually otherwise it makes no sense why they aren't all uploaded to the site.
I find it quite unlikely they figured out the format. They probably took them from this topic (or a page with all the GIFs from that topic), or some other source of manually ripped animations.

Quote
@Garyong
Your app doesn't even load for me :'( Interesting name for it though :p
Whoops, packed the wrong .exe  :banghead:. Use this instead, although it doesn't contain the .XML with the documentation for the .dll (which you can copy from the other link if you want it).

7
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 23, 2010, 08:58:57 am »
My terminology sucks, in fact I'm going to go and fix all my naming right now. In MY terms, a cell is a bank and an OAM is a cell..Whenever I first started my notes, that's how I put it down and that's how it's kind of stuck >_<
Heh, I know the feeling. I probably still have some mis-named comments somewhere in my code as well; rarely anybody get them right the first time. =)

Quote
You are clearly much better at figuring this stuff out than me, and it didn't even occur to me to look at GBATek :p
I probably only have more experience at these things ;]
I started looking at DSTEK/GBATEK for the capabilities the DS/GBA have for rotating sprites, when I also noticed these very familiar format. Also, since these Nitro formats are built-in, it's more likely the Nitro formats use data structures the DS/GBA need in their memory anyway.

Quote
Just out of curiosity have you built a viewer along with your specs?
Yes, although it only displays NCER+NCGR+NCLR or NSCR+NCGR+NCLR triplets. It's a Windows-only viewer, partly because I dislike designing Java UIs, partly because I like the binary data handling of C# better.
I've not yet made it open-source, because I wanted it to support more formats before I did (and currently only the recently re-written NCER class is not mostly ugly code). The included Glycerin.dll should be accessible by other .NET apps though, which contains the file format classes.

8
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 22, 2010, 07:14:16 pm »
I'm quite positive the 'cell gap' (=the gap between OAMs in a Cell) is inherent in the NCER files, and should thus somehow be mended in the NCMR/NMAR files (I'm guessing with position scaling). Using more GBATEK specifications, I believe I've nearly got the complete NCER format (there's only two unknown values left);
Code: [Select]
/* CEBK section:
 *
 * <NitroSection("KBEC", sectionSize)>
 * u16 numCells;             // number of cells defined in this CEBK
 * u16 extendedCells;        // if 1, cell data is CellDataEX instead of CellData
 * u32 cellDataOffset;       // relative to section start + 8
 * u32 flags;                // 2 LSBs: left-shift all tile indices this much.
 *                           // 3rd LSB: if 1, use `sub-images' instead of normal
 *                           //           addressing mode
 * u32 partitionDataOffset;  // offset to partitioning data header.
 *                           // partitioning data is only present if this is non-0
 * u32 padding;
 * u32 padding;
 * CellData[numCells] cellData; // is CellDataEX[numCells] if extendedCells == 1
 * // no padding in-between; cell data is properly aligned
 * OAMData* oamData;
 * u8* padding;              // may be empty
 * // --- partition data header starts here. is not present if partitionDataOffset==0
 * u32 maxPartitionSize;     // not sure; could be something else.
 * u32 headerSize;           // partition header size, offset of first partition
 *                           // relative to this section, or just constant 8
 * PartitionData[numCells] partitions;
 */

/* CellData:
 *
 * u16 numOAMs;
 * u16 unknown;
 * u32 firstOAMOffset; // relative to first OAMData
 */
/* CellDataEX:
 *
 * <CellData>
 * s16 xMax;
 * s16 yMax;
 * s16 xMin;
 * s16 yMin;
 */

/* OAMData:
 *
 * u16 OBJAttribute0;
 * u16 OBJAttribute1;
 * u16 OBJAttribute2;
 * (see also GBATEK, http://nocash.emubase.de/gbatek.htm#lcdobjoamattributes)
 *
 * Attribute0: ABCDEFGH IJKLMNOP
 * IJKLMNOP : Y position (signed, range [-128,127])
 *        H : R/S flag (Rotation/Scaling flag)
 *   if R/S flag = 0:
 *        G : OBJ Disable. (if 1, do not display) ignore.
 *   else
 *        G : Double-Size flag. (if 1, double-sized display reactangle) ignore, unless some
 *                developer purposefully used a larger/smaller clipping rectangle for displaying
 *                the rotated/scaled sprites properly for some obscure reason.
 *   endif
 *       EF : OBJ mode. 00 -> normal.
 *                      01 -> semi-transparent.
 *                      10 -> 'OBJ Window' (some sort of masking; see GBATEK).
 *                      11 -> Invalid.
 *                      Should be 00 for NCER values.
 *        D : Mosaic flag. Should not be set in NCER.
 *        C : Color Depth. 0 -> 16 colors, 1 -> 256 colors. (can technically be ignored, since the depth is also known from NCGR/NCLR file)
 *       AB : OBJ Shape. 00 -> square
 *                       01 -> horizontal
 *                       10 -> vertical
 *                       11 -> Invalid.
 *                       
 * Attribute1: ABCDEFGH IJKLMNOP
 * HIJKLMNOP : X position (signed, range [-256, 255]. read as unsigned, subtract 0x0200 if X>=0x0100)
 *   if R/S flag = 0:
 *       EFG : unused.
 *         D : Horizontal flip.
 *         C : Vertical flip.
 *   else:
 *     CDEFG : R/S Parameter selection. Should not be set in NCER.
 *   endif
 *        AB : OBJ Size. (resulting OAM size depends on this and OBJ Shape from Attr0)
 *       
 * Attribute2: ABCDEFGH IJKLMNOP
 * GHIJKLMNOP : Tile index
 *         EF : Priority relative to BG (usually not set in NCER, but sometimes is)
 *       ABCD : Palette index
 *       
 *
 * OAM size table:
 *
 * Size  Square   Horizontal  Vertical
 * 0     8x8      16x8        8x16
 * 1     16x16    32x8        8x32
 * 2     32x32    32x16       16x32
 * 3     64x64    64x32       32x64
 *
 */

/* PartitionData:
 *
 * u32 start;   // (in pixels)
 * u32 length;  // (in pixels)
 */
I find it unlikely (although not impossible) the unknown value in the CellData can fix the gap, since values at 'broken' cells also appear for non-'broken' cells. (was this the value you mentioned? I'm interpreting 'bank header' as the CEBK section header however, since the CEBK is a singular Cell Bank / Bank of Cells ;])
The other unknown value has to do with the partitions, so that's certainly not the fix-it-all value.

9
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 22, 2010, 06:25:43 am »
Will this support .ob, .pb, .ab, .nbfc, .nbfs, .nbfp formats?

Curious because the game I'm looking at right now uses those formats.
Extensions are only weak indicators of the content of files. I know the .nbf* formats should be just raw graphics, tile maps and palettes, which could be supported. I think it's unlikely the others will be supported however, unless you can provide example files (or mention the game you're looking at) ;].


By the way, I've unfortunately not yet had the opportunity to test the GBATEK formula for 2D tranformation. However the expected results of applying the formula to the values in the pokemon files match the actual animation too closely for it not to be a coincidence.

10
Personal Projects / Re: The Console Tool (by Low Lines)
« on: November 22, 2010, 04:49:00 am »
The rotation data is stored in the NANR file, in the Frame Data field. I'm assuming you've already figured out some of the Frame Data format, since you've shown an animation loaded into the tool, but these are my notes on NANR so far (ignoring the generic file header and LABL and UEXT sections);
Code: [Select]
/*
 * ABNK; Animation Bank
 * <NitroSection("KNBA", sectionSize)>
 * u16 numAnimations;
 * u16 numFrames; // total number of frames. not really necessary, since they have various sizes and can only be read once the format is known from the animation.
 * u32 animationOffset; // relative to section start + 0x8
 * u32 frameRefsOffset; // relative to section start + 0x8
 * u32 frameDataOffset; // relative to section start + 0x8
 * u32 padding; // is it?
 * u32 padding; // is it?
 * Animation* animations;
 * u8* padding;
 * FrameRef* frameRefs;
 * u8* padding;
 * FrameData* frameData;
 */
/*
 * Animation:
 * u32 numFrames;
 * u16 dataType; // Type of FrameData used for this animation. 0: 2 (4) bytes. 1: 16 bytes. 2: 8 bytes
 * u16 unknownConst; // always 1 it seems
 * u32 unknownConst; // always 2 it seems
 * u32 frameRefOffset; // offset of first frameRef, relative to start of frameRefs.
 */
/*
 * FrameRef: (frame reference/pointer)
 * u32 frameDataOffset; // relative to start of frameData.
 * u16 delay; // duration in #frames. ~= (1/60)s?
 * u16 beef; // always 0xBEEF?
 */
/*
 * FrameData:
 * - Type 0:
 * u16 cellIdx; // cell of the NCER to display
 * u16 garbage; // if this is the last frame data for an animation, this is 0xCCCC. Otherwise this is the first u16 of the next FrameData. Just ignore it.
 * -------
 * - Type 1:
 * u16 cellIdx;
 * v16[5] transform;
 * s16 xDisp; // displacement of cell in x-direction
 * s16 yDisp; // displacement of cell in y-direction
 *
 * The transform is usually of this format:
 * {B, A, C, D, E}, with:
 * E = 0
 * A,B,C,D as used in the formula in the bottom of this section in GBATEK: http://nocash.emubase.de/gbatek.htm#lcdiobgrotationscaling
 *
 * However C and E can be 0xFFFF sometimes (pokemon B/W file 505, pikachu), which seem to be some special marker. Not sure yet what they mean.
 * -------
 * - Type 2:
 * u16 cellIdx;
 * u16 beef; // always 0xBEEF
 * s16 xDisp;
 * s16 yDisp;
 */
(the terminology is most likely different again)
A v16 is a 1.3.12 fixed-point number, as defined here.

11
Personal Projects / Re: The Console Tool (by Low Lines)
« on: September 27, 2010, 08:40:03 am »
Wrote a quick batch routine and exported all single frame sprites (normal, shiny, gender, forms) for BW to PNG :) Some of the new ones look awesome! I'm not going to put them up since this image ban is on, and I also doubt I'm the first to extract the images, but its an odd feeling, going back several years I was one of those noobs following fileb and all those other hackers as they hacked the games :)
You are correct. The palettes at the end are alternate palettes for Acreus (#493 = files 9860-9879) by the way.

Quote
Also with the nmcr and nmar, this is still an theory but seeing how the ncer and nanr handle animations of a pokemons limbs separately, I think these last two files are like layer on top of that. So the nmcr would position each body part (which are a group of cells), and the nmar would manage the animation for them. I'm still only up to adding NCER cells so I can't test my theory yet, but due to the similarities in the file structures and the way pokemon sprites are animated, I think it's highly likely :)
I suppose I'll put my info so far on the NCER format here, if you need it or want to compare notes;
Code: [Select]
/*
 * NCER:
 * <NitroFile("RECN",version,fileSize,headerSize,numSections)>
 * CEBK cells;
 * LABL labels; // not always present.
 * UEXT uext; // ?? only has one value, 0 or 1. not always present.
 */
/*
 * CEBK; Cell Bank. header size: 0x20
 * <NitroSection("KBEC", sectionSize)>
 * u16 numCells;
 * u16 extendedCells; // 0 or 1. if 1, uses extended cell data
 * u32 unknownConst; // always 0x18 ?
 * u16 padding; // is it?
 * u16 flags;
 * u32 partitionOffset; // if 0, no partitions. rel to section start.
 * u32 padding; // is it?
 * u32 padding; // is it?
 * CellData[numCells] cells; // CellDataEx if extendedCells == 1
 * OAMData* oams;
 * u8* padding; // may not be present
 * PartitionData[numCells] partitions; // partitions the graphics for each cell
 *
 *
 * flags: ABCDEFGH IJKLMNOP
 * A->M: only seen 0 here
 *    N: if 1, uses sub-images
 *   OP: all tile indices in OAM data should be left-shifted this much  (and then right-shift 1 if 8bpp image)
 */
/*
 * CellData:
 * u16 numOAMs;
 * u16 something; // ????
 * u32 firstOAMOffset; // rel to first OAMData of section
 */
/*
 * CellDataEX:
 * <CellData>
 * s16 xMax;
 * s16 yMax;
 * s16 xMin;
 * s16 yMin;
 */
/*
 * OAMData:
 * s8 xpos;
 * u8 xflags;
 * s8 ypos;
 * u8 yflags;
 * u16 data; // &0x07FF = tile index. >> 11 = palette index(/offset?)
 *
 * xflags: ABCDEFGH
 *  AB: 1st index of dimension matrix
 *   C: ??
 *   D: ?? only seen 0
 *   E: ?? only seen 0
 * FGH: ?? PKMN BW has 111 or 011 here; which is the only game I've seen non-000
 *
 * yflags: ABCDEFGH
 *  AB: 2nd index of dimension matrix
 *   C: 1 -> mirror Y
 *   D: 1 -> mirror X
 * EFG: ?? only seen 000
 *   H: ??
 */
/*
 * PartitionData:
 * u32 start; // in pixels
 * u32 length; // in pixels
 */
The dimension matrix indices are the 'width' and 'height' on your old(?) format page.
'sub-images' means the graphics data is non-tiled, and the referenced OAMs are sub-images of the complete graphics. The start offset remains the same however.

This used to work for most games, however for this latest pokemon game, the OAMs in a cell do not seem to be put in the correct place any more. (unless they do not use the NCER, which I find unlikely, or the NMCR/NMAR can correct that) There's about 4 pixels between the OAMs =/

I'm available if you want to collaborate on this by the way. I know I'll be continuing my own investigations in any case. =)

12
Personal Projects / Re: The Console Tool (by Low Lines)
« on: September 26, 2010, 07:21:34 am »
Since files with a LZ77 stamp do not get passed on directly to the decompression routine, but first through the code of the game itself, I haven't included such format(s) in DSDecmp. (and, to be fair, I didn't encounter such files while creating the tool)

This archive contains several files with huffman compression. I think they're from Summon Night: Twin Age, but they can also be from Summon Night X.

13
Personal Projects / Re: The Console Tool (by Low Lines)
« on: September 24, 2010, 05:57:29 am »
@Low Lines: The GBATEK-like specification of the compression was indeed more geared to how I interpreted it, instead of how it actually should be. I thought I got the format right, but apparently not (which is why I didn't use bit-numbers in the in-line comments).

Also, when LEN is composed of LENx's, it should be +0x11 and +0x111, instead of -0x11 and -0x111 ;]
(Oh, and would you mind crediting me as either Barubary or Aygox if you decide to upload the specs somewhere? I've no idea why I used another username when registering here =/)

@Zerox; I sent you a PM instead, since we do not need to derail this topic. The answer's yes by the way.

14
Personal Projects / Re: The Console Tool (by Low Lines)
« on: September 21, 2010, 07:04:03 pm »
Plus, no offense to Garyong but knowing what keywords to write to actually find the site I think would be hard since typically if I were to search for LZ77 decompression, I'd write that or maybe "ds lz77" etc which doesn't put his google page within the first page of results (and probably not the second or third either). Whereas if you put in "console romhacking" you get this forum as the second result, which is a more likely kind of search a person would make.
None taken, as I have to admit I just filled in some terms that came to mind when filling the tags.

I must admit most file formats I've hacked only have a somewhat-documented format on my own computer, scattered over the various tools I made (most of which were for personal use only). That is, unless I hacked a format to fulfil a request, the format is still not known to the general public (although most are just simple formats, or slight derivatives of more well-known formats). The formats hacked for requests usually get their format posted at the place where the request was made, but I don't have an organized online storage of any of these.

15
Personal Projects / Re: The Console Tool (by Low Lines)
« on: September 21, 2010, 06:08:28 am »
I've hacked the 0x11 compression format quite a while ago already. I've uploaded a C# and Java source of the decompression code here; http://code.google.com/p/dsdecmp/ feel free to use it however you like =). (you can also find a compiled version of the Windows command line version there)



By the way, the pokemon list file order is actually like this:

Code: [Select]
#1 NCGR (front, single frame)
#2 NCGR (front, single frame, female. pointer to previous is no gender difference)
#3 NCGR (front, frame parts. (limbs, eyes, etc. used for animation))
#4 NCGR (front, frame parts, female. pointer to previous if no gender difference)
#5 NCER (I think this is only for NCGR #3 and #4, looking at the labels stored in the LBAL section)
#6 NANR
#7 NMCR
#8 NMAR
#9 raw data file
------------------> end of front sprite data
#10 NCGR (back, single frame)
#11 NCGR (back, single frame, female)
#12 NCGR (back, frame parts)
#13 NCGR (back, frame parts, female)
#14 NCER
#15 NANR
#16 NMCR
#17 NMAR
#18 raw data file
------------------> End of back sprite data
#19 NCLR (normal)
#20 NCLR (shiny)

Pages: [1]