ROM Hack help with resizing sprites

[sandwichwater]

hello , im new to rom hacking and im trying to create a hack for the game kingdom hearts 358/2 days

ive extracted some of the menu sprites (not sure if this is the right term , my apologies) via tinke such as the mission and world info that shows on the bottom screen when you do a mission then resized the image by 2x but when repacked and tested in game the textures//sprites dont show up, almost as if i removed them

however when viewed in tinke they show up just fine , i was wondering if someone here could help me with this issue or point me in the right direction if theres a way to properly resize sprites to be 2x or 4x or etc higher than their default size

any help would be much appreciated

[edited for easier to read formatting]

 

[FAST6191]

Two things.
The DS uses both 3d graphics and 2d graphics. These will necessitate a different approach depending upon what they are (3d inherently scales up as part of it all, though you can still have some trouble with animations, and 2d does not outside of limited things). Menus overwhelmingly are 2d affairs and looking at a video then most likely is here.

The DS has two main means of considering 2d.
1 is BG, aka background, and is what does most text and menus and background art.
2 is OAM/OBJ aka sprites. This is for things that commonly move around the screen but there are some games that will do things with menus (especially markers/this is the selected option) and related things.
http://www.coranac.com/tonc/text/video.htm is for the GBA but it is more or less the same ideas, http://problemkaputt.de/gbatek.htm#dsvideo has hardware if you want that.
Both have slightly different approaches beyond both using tiles and palettes (though there are some bitmap options for BGs). Sounds like I don't need to cover that though.
Sprites by their nature move and change a lot, so have their own dedicated area (the Object Area Memory handling location, visibility and a few minor things like reflection).

BGs will often be paired with a so called map (there is a reason the view map command in various emulators will bring up a fairly complete version of the background art compared to the basic VRAM tile viewer). You may have even loaded that file to change it from a mess of tiles (the edge of the menu tile might be repeated many times and to save memory http://pineight.com/gba/managing-sprite-vram.txt the map will repeat it and thus not need to be stored in the ROM or the RAM that many times compared to a PNG you and I might send each other). Sometimes BG maps are basically screen wide and can be edited accordingly, though I am not sure what tools we have even for known map formats.

Sprites being twice the size might well run into memory issues as well, and invisibility is one way that can manifest.

Short version there is you might have collided into the world of assembly hacking as you then get to find the code handling the fetching, drawing and location (and possibly memory handling if there is a lack of space) and alter that. Altering sizes like that is often a thing fraught with difficulty (the maps thing being a known format for some DS games being something most hackers of older consoles would be delighted to see). It is occasionally done -- sometimes you want more text on screen, or a screen text box to not be halfway up the screen with a gap below but most times people will try to explore alternatives before resorting to it.

 

[sandwichwater]

hmm thanks for the info , ill look into these things you linked and let you know how it goes

 

[sandwichwater]

Two things.
The DS uses both 3d graphics and 2d graphics. These will necessitate a different approach depending upon what they are (3d inherently scales up as part of it all, though you can still have some trouble with animations, and 2d does not outside of limited things). Menus overwhelmingly are 2d affairs and looking at a video then most likely is here.

The DS has two main means of considering 2d.
1 is BG, aka background, and is what does most text and menus and background art.
2 is OAM/OBJ aka sprites. This is for things that commonly move around the screen but there are some games that will do things with menus (especially markers/this is the selected option) and related things.
http://www.coranac.com/tonc/text/video.htm is for the GBA but it is more or less the same ideas, http://problemkaputt.de/gbatek.htm#dsvideo has hardware if you want that.
Both have slightly different approaches beyond both using tiles and palettes (though there are some bitmap options for BGs). Sounds like I don't need to cover that though.
Sprites by their nature move and change a lot, so have their own dedicated area (the Object Area Memory handling location, visibility and a few minor things like reflection).

BGs will often be paired with a so called map (there is a reason the view map command in various emulators will bring up a fairly complete version of the background art compared to the basic VRAM tile viewer). You may have even loaded that file to change it from a mess of tiles (the edge of the menu tile might be repeated many times and to save memory http://pineight.com/gba/managing-sprite-vram.txt the map will repeat it and thus not need to be stored in the ROM or the RAM that many times compared to a PNG you and I might send each other). Sometimes BG maps are basically screen wide and can be edited accordingly, though I am not sure what tools we have even for known map formats.

Sprites being twice the size might well run into memory issues as well, and invisibility is one way that can manifest.

Short version there is you might have collided into the world of assembly hacking as you then get to find the code handling the fetching, drawing and location (and possibly memory handling if there is a lack of space) and alter that. Altering sizes like that is often a thing fraught with difficulty (the maps thing being a known format for some DS games being something most hackers of older consoles would be delighted to see). It is occasionally done -- sometimes you want more text on screen, or a screen text box to not be halfway up the screen with a gap below but most times people will try to explore alternatives before resorting to it.

hello again , ive looked into assembly hacking that you mentioned and i think i understand it to some degree , from what i understand in the sense of what im trying to do is if i can edit whatever it is that shows the sprites//backgrounds in game that i can make the 2x resized graphics show up as if they were normal default resolution ¿

i tried once again with reinserting and packing the new backgrounds and sprites into the rom and they didnt display correctly which is the cause of im guessing the game not understanding that the graphics have been resized and is instead pulling them from where they normally would be at default size , resulting in a messed up graphic

is the graphics issue something that i can fix with assembly hacking or is there another way to do it ¿

 

[FAST6191]

hello again , ive looked into assembly hacking that you mentioned and i think i understand it to some degree , from what i understand in the sense of what im trying to do is if i can edit whatever it is that shows the sprites//backgrounds in game that i can make the 2x resized graphics show up as if they were normal default resolution ¿

i tried once again with reinserting and packing the new backgrounds and sprites into the rom and they didnt display correctly which is the cause of im guessing the game not understanding that the graphics have been resized and is instead pulling them from where they normally would be at default size , resulting in a messed up graphic

is the graphics issue something that i can fix with assembly hacking or is there another way to do it ¿

If it is a mapped background image (which UI stuff can be) then you would want to find the map (and tile data and palettes) and see about editing that. Can still have memory issues but those will be a different thing -- I might start by just reusing some tiles and having those appear where the 2x scaled stuff might end up and then work on getting new data in or adapting existing tile types to give you some more to play with.

If it is sprites then yeah the part of the console that handles the on screen location of such things is the OAM. You would want to change the code that handles that to also read the extra data into VRAM and handle the location of the new stuff. Alternatively for a 2x scale you might be able to do http://problemkaputt.de/gbatek.htm#lcdobjoamrotationscalingparameters but looking at the video I could see the background character be the default size and the player character being already scaled up.