ROM Hack Resize sprites

[hackotedelaplaqu]

Hi mens,

I'm looking for a way to enlarge an image (composed by sprites additions). We are talking about an nds game.

Let's say one sprite in this image is 8*8 px and I want it to be 32*32 so I can fit more text in it.

Where and How I'm supposed to :
- tweak those dimensions
- and repoint the sprite to another location (end of file) ?

One more thing : my image is a raw binary files (no header, just raw GBA 4BPP graphics).

Help is welcome.

 

[FAST6191]

I will forgo all talk of more traditional image editing/scaling methods- you are on your own there but that seems to be besides the point.

"One more thing : my image is a raw binary files (no header, just raw GBA 4BPP graphics). "

Were it a proper format I might have had more hope; for all the annoyances associated with having to reverse engineer a format they are usually more pliable once it is known (music hacking on the DS with SDAT versus most of what came before will provide a good mirror situation).

If indeed it is a raw image it might be (read probably is) just be a straight copy by whatever means into the VRAM and manipulated from there on by code.
You say sprite as well so I assume OBJ/OAM rather than BG (BG has some scaling/compositing options- text is often kicked to BG so there are some "known" methods there).
I will assume the game does not have a larger pseudo format in/defined by the binary somewhere (it is fairly pointless as the hardware effectively is a format by itself).

This is dancing about the point though so getting back on topic if is a raw image this changes things.
The game likely copies the would be tile (you say raw so I am not anticipating any compression related issues/stops in other ram first), any palette info (although I imagine this will stay the same for your hack) and throws it around the screen (as well as provides an initial definition) via OAM. Games do not tend to fill the VRAM (granted this is an opinion based on when I am using emulators I will often look at the OBJ/map viewer for no real reason) so you should still have some space in there somewhere (I certainly hope so as trying to handle this otherwise is not going to be fun).
Multiple tile sprites are one of two things
1) Actual OAM defined large sprites (more on that later)
2) Sprites the game code handles at code level (outside of a format) where it knows what goes (add or subtract X accounting for offsets as demanded by the game at a given interval (usually related to vblanks and what have you)). This is usually to avoid having to handle the display register as much.

8x8 is a standard tile size/ obj format in the hardware (things will use this just leaving everything they do not want as transparent and handle everything else in OAM)
I will also mention phoenix wright at this point; it had a very interesting animation format born of very creative OAM handling.

This places you in ASM territory although chances are it is not a hard ASM hack as cousins to it might be (you are expanding the functionality of a compiled embedded program with addresses largely already coded).
You get to find and modify
the sprite loading command/routine and change it to add your new tiles (if it is raw/otherwise without format I would add the next tiles to the file and just change the read length although you do run the risk of overwriting something important if you simply change it- consider kicking all to somewhere else in the VRAM)
any OAM handling after this you will have to account for as well although it should not be too hard
a) the other three sprites are probably immediately surrounding this sprite at a known, fixed distance or you prefer there is a sprite size option in the OAM but that might involve changing the VRAM layout stuff) although if you are using the hardware or some other routine to scale/mirror the sprite at some points you will have to account for this (probably not for text but who knows).
b) you used the large tile/composite options with relevant video modes. Get this handled and the game should take care of the rest (although you might have to change some OAM stuff to stop it falling off the edge of a screen.
Whether the game has something else on top of this or some quirk is a matter for testing at this stage.
I mentioned the display register earlier- depending on what goes you might have to handle this. For a homebrew/something you can compile this would be no problem but the game might be using 8x8 deliberately.

Naturally you will need to understand the GBA/DS video (you can skip the DS 3d stuff though)- gbatek http://nocash.emubase.de/gbatek.htm#lcdobjoverview has good stuff but in addition I will suggest tonc http://www.coranac.com/tonc/text/video.htm (GBA but still good), cowbite http://www.cs.rit.edu/~tjh8300/CowBite/Cow...ware%20Overview (another GBA doc but has a lot more in somewhat more plain English then gbatek) and http://www.pineight.com/gba/managing-sprite-vram.txt (GBA and more of a coder's reference/thought exercise but no less valuable than the links I just gave).

 

[hackotedelaplaqu]

Thanks FAST6191 !
I think I found my answer in OBJ Attribute 1 (R/W) bits 14-15 (OBJ Size)
Since I already managed to trace back OAM datas to ARM, and play with x-y coordinates, I'll try to change those bits.

By the way, I'll code an "OAM calculator" and post it back here to share with the community.

 

[hackotedelaplaqu]

Ok I just finished my "OAM Calculator".

Download Here

First function (Get Attributes) works like Oam viewer of most emus.
Function "Calculate OAM" does the trick backward : it produces a 6 bytes value with the arguments you feed.

Now it's time to play with sprite size in my project since I found OAM values in Arm9.

Thanks again for your help FAST6191 !

 

[FAST6191]

Ooh a new tool to play with. I can not say I do much OAM work these days but having something rather than have to think in bits suits me nicely.

Edit- some point in 2012 - filetrip mirror
http://filetrip.net/nds-downloads/utilities/download-oam-calculator-10-10-f29054.html

 

[hackotedelaplaqu]

Last feedback : I successfully managed to enlarge my sprite.
See : Last sprite was 8*32 and I had no space for the "s" of argument.
Issue is now solved, sprite is 16*32.
Thanks again for your help.

 

[Poryhack]

Hey FAST I have a semi-related question. Pokemon uses the standard Nitro format for images but they are always zeroed where the dimensions are supposed to be. there's gotta be dimension specs somewhere but how would I got about finding them?

 

[FAST6191]

There was some pokemon work going on in http://www.romhacking.net/forum/index.php/...c,8407.315.html and you also might want to poke around http://www.romhacking.net/forum/index.php/topic,12682.0.html .

Back on topic and ignoring the above I would think one of three things-
1) it is hardware a like format (links on the subject above) and thus does not really need specs like that. Kind of like how the non SDAT audio tends to be PCM of a form you can more or less (give or take a header) pipe directly into the DS sound chips.

2) it is somewhere in the binary.

3) The standard format is not quite so standard or it was not reverse engineered "properly"- the thread above covers that and pokemon has a long history of this sort of thing (see the stuff with NARC files earlier on in the DS history).

Either way it will land in the OAM at some point or be built up if it is a background and you just have to work backwards from there in similar fashion to how you might find a palette in a rom (snatch it from the ram, search the rom for it or part of it and if that does not work start on the assembly type methods (watch the ram, find the instruction that feeds it, trace it back to the next level and so forth)).

@hackotedelaplaque nice work. If you wanted to write up a rough overview there would be a few people quite happy to read about it- not so much stuff like this has been done on the DS.

 

[hackotedelaplaqu]

I encounter a new problem, look:

Actually, the last tile that should be at 0x6408000 was crushed.
I find it in the dump of the ram (so my binary image is good).
However, it is not loaded into the tile bank 0x6408000 (or if it is, it is overwritten).

How can I upload my sprites in a tile area where I have free space available?

About my OAM calculator, I have little time now to write a whole review but I can share the source (PureBasic).

 

[FAST6191]

I have a feeling more of what I am about to write will be of little use or indeed more of a stream of conciousness on the problem you seem to face. Certainly I can not think of something obvious it could be although it would not surprise me in the least if it was something simple like a couple of faulty OAM values. Indeed if I had to say anything it would be look very closely at that code and what you might have done there.


The problem is obviously in the bottom right of the top screen (a 64 x 64 block) although I am curious about those books on the case that appear to be in working order.

An image I am working with throughout this

It is annoying having to account for the cloak and the speech bubble being similar colours (especially on the edges).

I also dug up http://img32.imageshack.us/img32/3701/6873...2310141022b.jpg which is not ideal for use but I figured worth having.

When you say crushed do you mean corrupted or originally compressed or do you mean the image is a squashed version of what it is meant to be.
It appears to my eye to be a priority issue- the clothing of the person behind the speech bubble appears to be there.

By what you said I have to ask whether you edited this part of the image (that is to say used some of this OAM stuff to allow more space).

You say the sprite apears to be correct when looked at in a ram dump. Is this somewhere else in the ram (is it copied to the WRAM on the way to the VRAM) or do you mean the VRAM. If the WRAM or something else it might be an alignment issue- the VRAM (or more accurately some of the methods than can be used to copy things around- granted not what we are dealing with here but the differences between the VRAM and WRAM related BIOS compression functions for one.) but otherwise I would look to faulty OAM values.
For the purposes of this I assume the whole speech bubble got overwritten and you can see. Alas we have probably both stared at a tile editor and saw nothing, moved one slider one movement and had a complete image or near enough for in front of our eyes so I am hesitant to speculate too much on what might actually be happening using that as a base (if I had to guess I would say that looks like what happens when you decode an 8bpp image as 4bpp or vice versa and the white being decoded as transparent).

Anyhow if I am to understand the image is made up of the background (the bookcase), the character with a cloak and medal and on top of that a speech bubble (another sprite I imagine) which appears to be causing the problem here. Rather than simply not being there is appears as though it has corrupted three quarters of the affected section along with another few random (at this point anyway) sections.

The complete lack of any white (the remains of the speech bubble) and there being rather more shades of red than the bottom of the exclamation mark might reasonably have and certainly not in the proportions I might expect.

As for the writeup/source do as you please. I was thinking more a quick guide to finding out what instruction wrote the OAM values and how you watched for it, edited and so forth (similar to http://www.romhacking.net/docs/361/ but for DS OAM manipulation)

 

[KiC]

VRAM is split into 9 pieces. The games can allocate these pieces to specific tasks, but not everything can be used for any task. I don't know how it is in that case, but it's possible that the OAM memory is only 32kb at that time. You'd have to look into it in a debugger if that's the case, and see if there are any unused memory banks that can be used for this purpose.
It probably wouldn't matter anyway though, as you can only address 1024 tiles, which, in 4bpp mode, take up 32kb.
But if you used a 64x64 sprite for that piece, chances are you are using big sprites elsewhere too. Every sprite has to be completely saved in VRAM in one piece. Lots of empty tiles eat up space. So try to divide sprites with many empty tiles into smaller sprites with less redundancy, and try to reuse parts of the graphics if possible.

 

[hackotedelaplaqu]

you can only address 1024 tiles, which, in 4bpp mode, take up 32kb.
32kb limit was the problem.
Tile bank starts at 0x06400000 and the missing sprite starts at 0x06407F00 so I guess we exceed the size limit here.
Difference is 0x7F00 (32512 decimal) + 2048 bytes (64*64 sprite)

QUOTE(KiC @ Jun 13 2011, 11:44 PM) So try to divide sprites with many empty tiles into smaller sprites with less redundancy, and try to reuse parts of the graphics if possible.

I thought I could avoid this painfull work but I guess I won't.

Unless someone here knows a tool that can easily split an image in smaller pieces basing on transparency infos and redundancy ?

By the way, here is the source code of my tool.

 

[hackotedelaplaqu]

Just to let you know that it worked after splitting the image and removing empty tiles.

Thanks again to both of you.

 

[hackotedelaplaqu]

Sorry for the revival of this old topic but since my first OAM calculator, I made an NCER Editor for the Ace Attorney 2 translation project.
It should works for other NCER/NCGR files.

Download Here

How it works :
1/ At startup, the app will ask you to feed nclr, ncgr and ncer files
2/ Choose your cell bank (layer) and export PNG
3/ Import button to import your translated PNG
4/ Use window gadgets to move the sprites cells to fit the new picture.
5/ If image is bigger and sprites already maxed out (64*64 like the picture above), use add sprite to create a new sprite (you'll have to manually change tile value here - automatic otherwise, even if you enlarge sprites)
6/ When you're done, click Build NCGR and build NCER.
7/ Enjoy and provide feedbacks.

Please note that if sprites overlap, you'll have to "dispatch them" before export. I know no other way to edit those overlapping cells.

If you want to add such feature to romhack tools (Tinke, MKDS modifier..) feel free to ask the source by PM.

 

[rastsan]

Thank you.
I'll be using your oam calculator for Itadaki street ds. (custom map file format that is used for animation also)
I'll also be using the ncer tool for the digimon story lost evolution graphics (ds).
More than likely both tools for other projects.

Edit: the oam calculator link is down. can you please fix it?

edit yet again: nope it appears that this particular ncer is too troublesome. AAI 2 actually crashes. Tinke can load it but with errors. If you need the files in question let me know. I'm off to use a different palette just in case that is somehow an issue.

Edit again: No palette isn't an issue both 8bpp and 4bpp palettes do not really affect things. Well its enough to have a general idea where things go.
Still thanks.

 

[Auryn]

Here for you Rastsan.
http://www.mediafire.com/?t55cdav86io62vm

You are working at Itadaki Street??
Poor you...I looked at the rom a while ago and what a mess it is graphically.

 

[rastsan]

thanks Auryn

oh the graphics aren't a mess its the map files that are. i tried file comparison and oy. If the files in question kept to the same format I may not even need this. I suspect but am not sure that the coordinates are being stored matrice style. the only way to check this is working backwards from coordinates and with some math against what appears to be matrix (matrices matri?) stored in file. according to ct2 and idapro, itadaki does have matrice code (tied in some way to the graphics). So this might save me some trouble. its just identifying the 2by2 3by4 4by4 matrice and the conversion (math/code) bteween them that is giving me a headache. Which speaking of: Any programmers that want to tackle that send me a p.m. I am at the point where I would pay for help with this (though i cannot afford much- right now). the main font for itadaki is stored with a space saving map file (there is more to this that I won't go into here). worse certain other animated menu graphics need a coordinate switch for me to work with them at all. The one letter in the middle stretches out and moves the other letters which are also bouncing). I know it should be simple just to edit them but its a space saving graphic. the letters are all over the place and the map(s) picks from them. anyone who with translation experience can tell you that put letter a with letter b means one thing but put letter a and letter c together letter a's meaning changes. So no one translation per character will work, I need to edit the map file. (sigh)

 

[hackotedelaplaqu]

Are you sure it's ncer files and not simple tilemaps ?
In Ace Attorney, some graphics (often backgrounds) were raw bins. Then follow palette raw bin files and tile map file.
If your files have no headers try this little tool.

 

[rastsan]

ah no. Sorry to be clear the ncer (from digiomon story lost evolution) is unsupported in both Tinke and AAI 2. I tried the tool you just posted on the itadaki graphics, no luck.

Although thankyou.

Trying on the ncer from dsle just in case you meant that... will edit later... and no, that didn't work either but...

the link for the files in question here.
The nclr may need a slightly different offset than usual as it was unpacked by a previous program in-correctly. I usually end up up going grayscale for that game and have yet to see whether this is going to bring me problems as I am still editing and not in the re-insertion into the archive phase yet. please note I posted files form digimon story lost evolution specifically for the ncer that isn't working. i am going to send pleonex that zip just in case.
Thanks for the interest.

 

[hackotedelaplaqu]

I checked your files in hex editor and they are screwed.
They did not match specs.
See here
Your extractor somehow corrupted them.