Basic Questions and Answers Thread

Is it possible to workshop the A button as a hold-to-run function ala Mario? This is for a secondary project using the Github disassembly, just for clarification.

 

Yes. You could write a simple subroutine that sets your speed values to one of two sets of values depending on whether or not your. Ideally, you would call such a subroutine before the code to handle any of your playable character's moves, as I imagine you'd want the run button's effects to apply regardless of state. Obviously, you'd have to change all of the button combination checks that depend on A, B or C being pressed and are related to player control to only support B/C presses.

 

I need help with porting the sparkling zone bg to the final (art,cycles and stuff) also how do i import chunks into ghz without them being a mess and how to assign collision properly?

 

At some point in time, I ported Green Hill Zone to Sonic 2, but I can't find the disassembly (it was Xenowhirl). Although this is for Sonic 1 and I used Sonic 2, here's how I did it. (warning for some, this is gonna trigger some people as I know this isn't the proper way to do it)

One more thing:
I didn't bother to port the music. Don't pull it off in the same way for everything. Follow a tutorial to do that.

Porting data:
I first converted the collision data to Sonic 2 format (you're gonna have to do the same for the art, mappings, other stuff) and then opened SonLVL (if you use a different program such as SonED2, you should be able to figure where is where) twice. I opened the Green Hill Zone data as well as the ported one. I then shaped out broken and corrupted collision tiles to avoid falling to my death while play-testing the level. Sometimes, the converted data will be unsorted and some parts will also clip you into the bottomless pit. I changed the collision tiles on each chunk and tile to get everything working.

From here:
I ported everything else in the same way, play-testing, and fixing bugs. Opening the level data did cause some interesting results similar to that of Scrap Brain Zone Act 3 from the Nick Arcade prototype, but once I compiled everything together, it works smoothly. Only thing I couldn't get working was pallet cycles. I planned to do that the next day, but my hard drive crashed by that point.

Hope this helps!

 

So, I'm trying to replace Kosinski with Kosinski+, and was easily able to do so with the chunk data thanks to SonLVL supporting it, but the sound driver isn't so easy. For a bit of context, the assembler I'm using is a lightly modified version of the recent AS branch of Sonic 1, applied to Sonic Clean Engine. There's a lot of reasons I did that, but the main reason was replacing the Z80 sound driver compression

The Z80 portion of the sound driver (in this case, MegaPCM) is compressed in Kos by the assembler, with its compression code being in C. Mdcomp (the place I got Kos+ from in the first place) has compression code similar to that, but all of it's in C++ and is pretty different in general. Just looking at the assembler Kos and mdcomp Kos, the formats are completely different. Even if they did work, I'm not confident that I'd be able to install them.
If anyone else has done this before, can you help me on this, or at least point me to the right direction? I have some ideas on where to go from here, but they're sort of last resorts...

 

How to make a 2 zone demo in sonic 1 (for my hack)?

 

change the level order to go to the ending after two levels, it may do the titlescreen and not the ending, that is fine.

 

Thainks and yeah basically do plan on it just going to the title screen

 

If it's a demo, it might make more sense to have it jump to the ending after the Got Through Card, but only if you're on a particular act. That way, you don't need to change your level order for every demo.

 

Hi, I'm hoping to be mostly self sufficient in learning how to set up some basic rom hacking (sprite swaps and a couple of alternate sound effects), but with information as to how to do it spanning back over a decade I'm a little lost as to how one goes about rom hacking the genesis games in todays age; would someone be able to point me towards where a newbie goes to learn the basics?

 

sonicretro has some disassemblies, tools, tutorials & guides, as well as on here,

 

Asked this on Sonic Retro, might as well ask here:

My hack currently has hit a snag. This is with the implementation of uncompressed chunks and its co-operation with water. My model 2 Genesis and the recent public Blastem release (0.6.2) freeze when loading in on Labyrinth Act 1/2 (basically when water's on screen). I was told that another hack also had the same problem, and was clued in how they fixed it: apparently they redid the HBlank (PalToCRAM) code, and that's the weird part. I was trying to figure out what could've caused the freeze when I came across it, and I was worried that the implementation had something to do with it. It came into play with the integration of uncompressed chunks, the lack of the surface object didn't change anything (was ported to a different project without those chunks, it worked). When stripping away the code within PalToCRAM, it doesn't freeze in that spot on the aforementioned devices. How can I optimize it to work with uncompressed chunks?

 

Hi, I'm trying to convert vgm files to asm files, but they turn out to be very large. Almost everywhere the smpsAlterNote and smpsNoAttack commands are written, the note is divided into several such blocks and as a result the file weighs about 400 kb and it is not accepted by the driver (I have a clone driver). Tell me, please, have you encountered this and how did you solve the problem? What can you offer instead of all this? I convert from vgm to smps (version for Sonic 1), then smps to asm. The program vgm2smps by NBAH (aka Ivan YO), smps2asm v0.2 by flamewing.
I tried to convert via midi (vgm -> midi -> smps -> asm) but the problem remains.

 

Is there any way to make the S monitor function work like a Chaos Emerald monitor?

Edit: im using the hivebrain disassembly.

 

it is
If you look at Obj2E_ChkS you will find a NOP. delete it and add

Code:

 
addq.b #1,($FFFFFE57) 
Move.w #$XX,d0 ; where XX is whatever sound you want to play 
Jmp (playsound).w

It will increase the emerald count and play a sound to confirm

 

True, but the emerald will always be blue. Additional logic is needed to ensure the variety in colors.

 

Thank you warr1or2!

 

A couple ago I discovered that using the extended camera of sonic cd, you could make a bug (modifying it, obviously).


I don't consider it a bug, but rather a code remnant that allows you to go to the previous level.
The "bug" what it does is that when you exceed the limit of the camera at the beginning of the level, it will load the objects of the previous level if you go back.

I think it may be code remains that have not yet been discovered.

 

May I ask how you implemented this extended camera? There isn't any code in Sonic 1 that is purposely designed to go back to a previous level by going past the camera boundaries.

 

Basically what I did was make the camera "try" to go further back than it can. In the video I show how I do a spindash so that the camera teleports back, but since there is nothing else behind it it fails and for some reason loads the objects from the previous level. It's really just that, I don't have anything programmed to go to a previous level (nor am I going to have it xd)