|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
![]() |
Goto page Previous 1, 2 |
Author | Message |
---|---|
|
![]() |
Thanks so much for the explanation. |
|
![]() ![]() |
|
|
![]() |
Hi Ershei, directly changing the palette only affects the palette that is currently loaded in the emulated system. If you want to permanently change the palette, you need to find the data or code that is responsible for loading the palette, i.e., the source of it. Emulicious's Memory Tracer helps finding the source. With the source you can modify the rom and save the modified rom. |
|
![]() ![]() ![]() |
|
|
![]() |
I experimented with the correct aspect ratio, by resizing the Genesis version to 70%x80%. I had a hard time squeezing details in the "too wide" version, but this will be even more challenging. As Sonic needs to be thinner, even less pixels will be available horizontally. Even more details from the Genesis will be lost, so it probably will not look like it anymore. |
|
![]() ![]() ![]() |
|
|
![]() |
I'm surprised and have no expected work for it (faithful 4:3 strechted), I suggest you to pack a patch for it along with the one already released so that people can choose their favourite. Your efforts are welcome and my personal opinion is that with the faithful 4:3 strechted version, Sonic would fit the graphics better than the current release as this is the way the graphics are supposed to be displayed for the game, the current release looks great and next will be great for sure even with less pixels to work with. By the way I like more the blue pixel deleted next Sonic's eye from 0.1.4 that pixel makes the eyes look rounder but that's just an opinion, Great job!, thanks. EDIT: My mistake is not a blue pixel but another design. |
|
![]() ![]() |
|
|
![]() |
Hi Emuboarding. When in Sonic the hedgehog I edit the palette example 39 ... with Hxd, and then I open the rom, the color I edited blinks, why does that happen? Thanks |
|
![]() ![]() |
|
|
![]() |
Yes, Sonic will fit better with the correct aspect ratio because he will be thinner. But the smaller he gets, the less detail will remain, and less pixels to works with. For example in v.1.0 his legs are 2 pixels wide in the standing frame. But in aspect ratio corrected version, this does not look right. His legs too wide compared to the rest of his body. And 1 pixel wide legs will look too thin. Also his mouth/cheeks i need to find another way to make it look right again. I suppose something like in the screenshot. I've attached a the first test version ( facing right only). Although the aspect is correct, all frames will need a lot of manual editing to make it look good as you can see. Basically i will have to start all over again. Honestly, it will be too much work/trouble for a slightly thinner Sonic... Do you like his eye in 0.1.4 better than v1.0? |
|
![]() ![]() ![]() |
|
|
![]() |
Please give us more information, like a screenshot or even an ips patch. What do you mean by 39? What exactly did you change in HxD? Offset? Old value? New value? |
|
![]() ![]() ![]() |
|
|
![]() |
It's because there is a command for the colors of the water in the back to change. These other colors follow these commands. You just edit all the colors that change to the color you want. Use the emulator's "pause" to get the right offset for each color. |
|
![]() ![]() |
|
|
![]() |
It looks good so far just comparing 16bit vs 8bit no strechting vs 8bit with strechting. I like the 0,1,4 better because in 1.0.1 there is a white line down the eye standing out to first view a bit, looks strange in 8bit not in 16bit Sonic. |
|
![]() ![]() |
|
|
![]() |
The compressed data blob seems to start at 0B:3AF8, I can't tell which compressor is used but I've seen it just often goes over the same 4 bytes from ROM and writes them all 4 times in a row, not sure why. I hope this helps anyone in identifying it. The unpacker code is at $405 and gets called with DE = $3000 (the VRAM destination address of the data blob, as it's not copying only the tiles you want to hack). The data for the tiles you need to change seem to begin at 0B:3BB0 as that's what gets into VRAM $3300, where you have those shoes. Good luck! |
|
![]() ![]() ![]() |
|
|
![]() |
What white line do you mean exactly? The one under the blue and grey pixel? I tried to make his stand frame to look as good as possible because that is what you see first. I've attached a couple of considerations going from v0.1.4 to v1.0.1. I minimized the use of the dark brown color, which is replaced by red to turn his shoes red. Too much red in his face or belly does not look good imo. |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks! For anyone who haven't found these links yet: Decoder code: https://www.smspower.org/Development/SonicTheHedgehogTileDecoder And more info here: http://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_%288-bit%29#Header |
|
![]() ![]() ![]() |
|
|
![]() |
oh, I had never seen that page before. Good you found it, so you probably know how to fix the source data now :) | |
![]() ![]() ![]() |
|
|
![]() |
I'm pointing out the ones that stand out white color, it is like the eyes look bigger on the other hand ok for the 16bits's because the sprite is bigger, thanks for considering other people opinions since people is sometimes jelaous of their work. |
|
![]() ![]() |
|
|
![]() |
I still have no clue where to start :). |
|
![]() ![]() ![]() |
|
|
![]() |
I like those 3 on the right. His mouth/cheeks are slightly bigger, so his eye may look smaller in comparison. |
|
![]() ![]() ![]() |
|
|
![]() |
There is still hope. In the first attempt i used the original genesis sprites and resized those. But next attempt i will use my already resized and optimized the frames from v1.0.1 and resize those. It should give much better results right away. However everything that got cut off, i have to add again. |
|
![]() ![]() ![]() |
|
|
![]() |
Yes, it turned out much better this way. Check it out.
|
|
![]() ![]() ![]() |
|
|
![]() |
Looks good! Still I find too much of white cheek/eye part, It feels like Sonic is out of place since the shadows colors of another sprites in the game use dark colors, yours is a port from 16bits where there are more colors to deal with so Sonic should fit a bit more the 8bits graphics and consider the tweaks I did the one within the red block if I'm not wrong is the one of the latest patch, just 2 pixels one light orange for the cheek instead of a white and one blue instead of light gray. Still fantastic work thanks. |
|
![]() ![]() |
|
|
![]() |
Yeah, i understand what you mean.
At least you only changed 2 pixels, and not the entire frame ;). I didn't add the orange pixel there because i did not want his cheek to be too "tall". I used grey pixel instead of blue for more smoothness. In the aspect ratio corrected version, this issue is even tougher, because there are less pixel to use for his eye and mouth (in some frames). Attached you will find a new version. I've added the left facing frames. It is unfinished but at least it's complete and playable. |
|
![]() ![]() ![]() |
|
|
![]() |
Well, I don't know how you're changing the art at the moment. If you are changing uncompressed art only, you have to figure out how to update compressed art. I would probably use BMP2Tile, provided there's a SonicTile compressor plugin ( Otherwise, I hope there is some other tool that you can use, but I'm not an expert on ROM hacking tools so I can't help you much here. |
|
![]() ![]() ![]() |
|
|
![]() |
Yes, so far i just changed uncompressed tiles with Master Tile Converter.
Thanks for your instructions. I've downloaded BMP2Tile and the Sonic1compressor. Then i loaded the my changed tile (8x8 bitmap) and saved it as shoetip.soniccompr (32bytes). I only know how Master Tile Converter and a hex editor works. So i'm not sure what "bank 0B" means. And i don't know how to insert shoetip.soniccompr there. Can you explain? |
|
![]() ![]() ![]() |
|
|
![]() |
There is a chunk of several tiles decompressed including this one. You need to extract that whole chunk, which is a bit tricky, then edit, recompress and re-insert - hoping the data does not get bigger than the original. | |
![]() ![]() ![]() |
|
|
![]() |
you should probably screenshot the VRAM contents from an emulator, convert them to a paletted image using the same palette the game uses, then modify that image the way you like it.
now you have the source for BMP2Tile and you save your Sonic1 compressed data you copy that data (with an hex editor) into the ROM at location 0B:3AF8 over the existing data. Since each bank is 16 KB the location of 0B:3AF8 is 0B×16KB + 3AF8 = 2FAF8
edit: actually the compressed chunk of tiles you have to replace starts at 0B:392E (or as they wrote in the code, at 09:B92E) that is 0B×16KB + 392E = 2F92E
|
|
![]() ![]() ![]() |
|
|
![]() |
How many tiles should the chunk contain? The full vram? Or only a part of it?
|
|
![]() ![]() ![]() |
|
|
![]() |
from VRAM $3000 to VRAM $3800, that is from tile 384 (the big white digits) to 448 excluded: 64 tiles total
edit: I |
|
![]() ![]() ![]() |
|
|
![]() |
Thank you so much sverx!!! It turned out perfectly!
Looks like it is smaller than the original because I can see some repetition after the inserted hex values. 38 00 38 38 10 00 38 38 7C 00 7C 7C FE 00 7C 00 7C 7C FE 00 I did not notice any issues while playing so far (first 2 levels). |
|
![]() ![]() ![]() |
|
|
![]() |
good, you can leave those values there, they won't disturb |
|
![]() ![]() ![]() |
|
|
![]() |
Right now i'm trying to change the background tiles of Greenhill.
It seems to be stored in a different way than the compressed shoetip. I noticed the shoetip starts with HEX values "HY", but level art does not. I believe Greenhill "tiles" start at $337A8 according to the information here: http://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_%288-bit%29#Level_Art Is that the right place? Should i use different compression settings with level art? What is the difference between "level art" and "tiles". |
|
![]() ![]() ![]() |
|
|
![]() |
I think the “header” offsets are what you want. The compression format is the same for all sprites and background tiles (where compressed). | |
![]() ![]() ![]() |
|
|
![]() |
Excellent, i was indeed looking at the wrong offset. It works now.
Thanks for the super fast answer! |
|
![]() ![]() ![]() |
|
|
![]() |
Unfortunately there is very little room for changes. Any alteration will result in a bigger compressed chunk. I tried a couple of different tile changes but no luck, all of them turned out bigger.
How does the compression work? Does it look at lines of 8 pixels wide, to find duplicates? It will be hard to adjust the my new "artwork" to that. |
|
![]() ![]() ![]() |
|
|
![]() |
The Sonic compression works by matching rows of 8 pixels that are identical within the entire set of tiles. To do a more advanced hack, you might try to rearrange the data automatically, and/or replace the compression algorithm with a better one. | |
![]() ![]() ![]() |
|
|
![]() |
I like it already. What tool can i use for that? Compression sounds a bit more (too) complicated to me. I guess i have to replace the decompress code in the rom somehow. Is recompression of all compressed tiles needed? |
|
![]() ![]() ![]() |
|
|
![]() |
It’s not easy. I’d use WLA DX to background the ROM, unbackground to remove the compressed data, then reinsert it all as separate files, with the necessary references inserted using labels. Then in theory i can rebuild the ROM but I can also resize some of those data chunks. Finally if I cover all the data, I can also swap out the decompression code. It’s a fairly large undertaking for an experienced ROM hacker. | |
![]() ![]() ![]() |
|
|
![]() |
Well, that sounds very complicated that i won't be able to do.
Would it be possible to create an uncompressed rom? I guess not, but i just wondered. Is that easier to do? Another question. Does anyone know where the animal capsule sprite (at the end of a level) is located in the rom? I was not able to find it. And would it be possible change the bridge zone music to marble zone music? |
|
![]() ![]() ![]() |
|
|
![]() |
Replacing graphics with uncompressed graphics is if anything slightly harder than repacking or changing the compression algorithm.
One thing that would be simpler - but probably still require an experienced coder - would be to patch the code to load your changes on top of the existing data just after decompression. |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks Maxim. I guess I'll have to make the graphics fit with the original compression. Not easy either :), but i'm making some progress. It's hard to predict how big compressed graphics will be compared to the original compressed graphics.
B.t.w What does "background the rom" mean? |
|
![]() ![]() ![]() |
|
|
![]() |
Go to location $C718 and replace 4A 57 with 0A 4D. |
|
![]() ![]() ![]() |
|
|
![]() |
This is a concept from WLA DX whereby you put the original ROM in the background and then build patches on top of it. It’s like editing in a hex editor built in to the assembler process. |
|
![]() ![]() ![]() |
|
|
![]() |
[quote="Tom"]
I was hoping it would be this easy to change. Thanks Tom! |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks for the excellent and brief explanation. I might (need to) try it some time. |
|
![]() ![]() ![]() |
![]() |
Goto page Previous 1, 2 |