Basic Questions & Answers thread

I am attempting to make a new object, I have the basics down. I can get the art to display and have it react when sonic touches it, however I cannot seem to find a way to modify it's collision height. How can one do this?

 

In both Sonic 1 and Sonic 2 (Non SVN), there is a routine called "TouchResponse", this routine reads from a table of heights and widths called "Touch_Sizes", I'll explain specifically Sonic 1's way while assuming that Sonic 2 is similar.

The 20th (Hex) byte of the object is the collision it has with Sonic, it holds an ID from 00 to 3F, in the table there are 24 entries (24 lines) out of 3F (You could add more easily if you wanted really), the ID stored in the 20th bit decides which entry to use, the first byte of every entry is the width of that collision, the second byte of every entry is the height of that collision.

The most significant bits of the 20th byte (I.e. if it's +40, +80 or +C0) decide what should happen if Sonic has come into contact with the object's selected collision:

From 00 to 3F sets the object as an enemie (harmful enless Sonic is in ball mode or invincible/invulnerable).
From 40 to 7F sets the object to increase it's routine counter.
From 80 to BF sets the object as harful (Regardless of situation (Unless invulnerable [ Check that ]), Sonic is hurt).
From C0 to FF sets the object as a special type of collision depending on the object (The Yadrin is an example, harmful on to, destroyable on sides and below, a.k.a. special).

I "think" FraGag mentioned this in extreme full details pages back on this thread, but I couldn't be bothered finding it =P

For collision with blocks and objects with a solid cerface, these objects tend to call a routine known as "SolidObject" or "PlatformObject", but judging by the sound of your post, the above is probably what you're looking for.

Also wow, I feel like I'm on a roll here, hoggin up all the questions =$

 

There's always this you can help me with.

 

Is there an application anyone can recommend that can convert a bmp to Genesis colors, and then turn it into a .bin file of all the tiles? I've been trying to use ImaGenesis, but it's doing a god awful job, it never ever gets the palette correct and when I import the tiles into other programs they're always missing lots of details, as though the program eliminates pixels or something. I've tried using SonMapEd to import the bmp as a sprite but that too never gets the palette correct no matter what.

I'll wait on IRC in case anyone can give any live help.

 

Dude, just set the palette to whatever you need using hivepal and THEN import it into SonMapEd. That's the best, if not the only way.

 

I guess I should have been clearer, but I'm not working on anything Sonic related, I'm trying to make something for PlaneEd, which I'll then use in BasiEgaXorz.

Not Sonic related :x

 

Try this.

Put your art in "Bitmap.bmp" (Making sure it's 24-bit format, and uses 16 colours max or less). Put the matching colours in "Palette.bmp" in the order/slots you want (Again, 24-bit format, colours must have matching Green, Blue and Red values as in "Bitmap.bmp"). Run "GetArt.exe" and assuming everything is fine, it'll pad it out into multiples of 8x8 tiles, convert and output, a Palette, an Art full of the tiles, and a Map file while optimising tile for flipping and mirroring. Infact I'm not sure why imaGenesis doesn't support flipping and mirroring optimisation.

Note, make sure the bitmap art isn't too big (as in isn't too bigger than a megadrive's screen size), Sorry if this doesn't work for you, I figured it'd be worth a shot sharing.

Well it looks like the art starts at A960 insted of A980, but why it's not working on certain emulators is unknown to me =(

 

Still looks fine in GENS. However in GensKmod it does show up at all, both times.



You know, it could be only regular GENS shows the bullet because the BULLET is an emulator glitch that only happens in regular GENS.

 

This might work, I'll try it. One question though, I have more tiles than fits within a 320x240 screen. Plus as far as making a map file goes, levels usually would always go past 320x240, so that confuses me why it's a limit. Maybe I still don't understand how levels maps work.

Edit: I used a 224:480 bmp and it worked fine, so I guess there's no huge worry. But now I'm wondering about how to make a map with PlaneEd. What I've got is two sets of tiles I want to load into a level, both sets use different palettes. Plus as I said, I don't think I understand how maps work really. PlaneEd can make a whole level, or just one screen? I tried setting the parameters in a project file to have the x and y vales really high, and it apparently pushed all the tiles off screen so I can't see them. I guess I'm in over my head on what I'm doing.

BTW, is it OK to publicly share your GetArt program? Since the Genesis dev community NEEDS an alternative to ImaGenesis, and yours is the first one to actually output all my tiles and palette correctly.

 

Having an animation issue here, I've doubled the running frames (it had 4 frames before, now it has 8), and I implemented 8 for each angled ones too. Thing is when I go on a slope, it's loading the wrong ones...I assume cause it's looking for the amount the original running animation had. How would I fix this?

 

Feel free! Heck put it on the wiki for all I care =P

In "Sonic1.asm" at lable "loc_13A9C:" you'll notice these three lines:

Code (ASM):

1.         move.b  d0,d1
2.         lsr.b   #1,d1
3.         add.b   d1,d0

These multiply 0 to 0, 2 to 3, 4 to 6, and 6 to 9. With an extra command after it to multiply by 2, 0 to 0, 2 to 6, 4 to C, 6 to 12. (For 6 frames).

Replace those three instructions above with:

Code (ASM):

1.         add.b   d0,d0

That will multiply 0 to 0, 2 to 4, 4 to 8, and 6 to C. With an extra command after it to multiply by 2, 0 to 0, 2 to 8, 4 to 10, 6 to 18. (For 8 frames).

 

Wait, isn't that for the walking animation? Doing that made the walking rotated frames use 8 rather than 6. It's the running rotated frames I'm having issues with

 

Ah! Well in that case:

Code (ASM):

1.         move.b  d0,d1
2.         lsr.b   #1,d1
3.         add.b   d1,d0
4.  
5. loc_13AB4:
6.         add.b   d0,d0

Replace with:

Code (ASM):

1.         move.b  d0,d1
2.         lsr.b   #1,d1
3.         add.b   d1,d0
4.         bra SkipMultiple
5.  
6. loc_13AB4:
7.         add.b   d0,d0
8.  
9. SkipMultiple:
10.         add.b   d0,d0

 

hey markey, actually Jimmy is doing this for me so I've been trying to test it too, but actually is not working. With the code you just gave us, the background becomes a mess and the walking sprites are messed up. Any fix to this?

 

I think I've asked this before, but is there a way to extract sound effects from a Gens rom? Or would I have to disassemble it?

 

Assuming by Gens ROM you mean Genesis ROM, you can grab the sound effect data out of the ROM if you know where it is and how it's formatted. Porting sound effects between SMPS games is just like porting music — for anything else, it's a bit more complicated than that (especially if sound effects run on different things, like with GEMS where there's a dedicated SFX timing mechanism that I'm not entirely sure about).

What exactly did you have in mind?

 

I wanted to rip a few sound effects from Mega Bomberman 94 and possible export it as wave. It would nice if Mega Bomberman had a sound test or something.

 

When useing Aspect editor, in order to actualy use it, do you need a disassembly of either Sonic 2 Game Gear, Sonic chaos Game Gear, or Triple trouble depending on the game you want to hack?

 

I was using the How-Tos on the wiki for fixing the walk-jump bug, and now when I build the rom, it comes out only 128 kb. Just in case, I also removed the speed cap, fixed the sega sound, and applied Mercury's special stage fix.

EDIT: Okay, now I see whenever I use build.bat, it has an error message, but it closes out to soon for me to see the rest. And I have the project in C/Program Files/SonEd2/Sonic 20.

 

On the wiki page, it says that it can read resources from the ROM, so you don't need a disassembly. (Especially since there's not a public disassembly of Sonic Chaos or one of Triple Trouble) I've never used the program before, but I believe you would need to know where the palettes are located at in each ROM, along with each level's data. Of course you wouldn't have any trouble finding Sonic 2 ROM info as you could just look up the hacking guide, but the other two don't have proper hacking guides yet. (I've started working on a Sonic Chaos one, but it's far from being completed.)