Basic Questions and Answers Thread

Thanks a BUNCH, nineko! Obviously you would prefer xm3smps tho
( ͡° ͜ʖ ͡°)

This is hard. Where can I find a YMX file? I've been trying to convert a Casino Night 2 Player MIDI to SMPS, but I can't find a YMX file! I'll upload the BIN file. If anyone can help, please let me know.

 

You have to create your own bank using instruments from other games. If I'm not wrong, you can save YMX banks with XM3SMPS. But the YMX banks are quite obsolete. If I was you, I'd go to try MID2SMPS to do your conversions. You can port voices from the OPM banks used by the VOPM VST. A full bank with the instruments from all the Project2612 website is easy to find in the internet. Otherwise, you can download the Sonic 2 VGMs and use the MID2SMPS bank load function to load the instruments straight from a VGM file to put in your song.

 

I downloaded the VGM, imported it into mid2smps, and it still sounds the same as it did without the VGM file! I presume this has something to do with the "mappings" that I've seen references to in the menu?

 

Are their any mappings editors that support using multiple different art tiles from various vram locations? The games do this all the time (1 up monitors do it, reusing the life icon artwork), but I've yet to stumble across an editor that actually supports this. I'm aware that it is very easy to undo this to edit artwork normally (I've done it myself), but actually want to use this for my own purposes, as I'm running very short on free vram space.

 

I'm trying to use PlaneED here, but every time I run it, it displays this error:

"The code execution cannot proceed because SDL.dll was not found. Reinstalling the program may fix this problem."

I'm not sure what SDL.dll is, but I do know that it's a system file (as any boy / girl / man / woman / hedgehog would ) . I don't know what's causing this error. Can anyone help?

 

Is SDL.dll in the same directory as PlaneEd?

And to note, DLLs aren't necessarily system files, rather they are files that contain a library of functions in which an executable can reference and execute functions from it. Windows uses DLLs to hold system functions, for example. In this case, SDL (Simple DirectMedia Layer) is a library of functions to handle drawing graphics, audio, etc. in a more simple manner.

 

I added the PlaneEd EXE to my disasm, as i couldn't get it to work otherwise. Should I add SDL.dll to my disasm root?

 

You should probably create a new folder for PlaneED, and then copy all the files from the archive you downloaded (assuming it is a zip or rar file)

 

Yeah, PlaneEd requires that you have the DLL in the same directory as the EXE, hence why I asked "Is SDL.dll in the same directory as PlaneEd?"

 

I don't believe there is, likely due to the difficulty of managing multiple art files when you're adding and removing tiles.

 

What roughly needs to be modified to change the size of chunks in Sonic 2? I have big plans, both current and for a later project, that heavily require me to do this, but I'm not sure what specifically needs to be changed.

I tried to compare between Markeys' 128x128 disassembly, a vanilla Sonic 1 disassembly, and Sonic 2, but Sonic 2 has different label names and slightly different code, and most of the "; MJ" comments appear to be related to the path swappers, which I obviously wouldn't need to add in Sonic 2. Its' been kind of confusing, so hopefully, a rough explanation of what needs to be done will put me on the right path...

 

It depends.

If you are making the chunks bigger, then you should only need to change code wise; the layout loading, collision reading, level drawing/rendering, and level chunk/layout swap instances (for levels that alter uniquely; like perhaps the HTZ lava/hill movements). Data wise; the layout and chunks. Everything else should function fine (including path-swapper related collision areas). What you are looking at are the X and Y positions being converted and calculated into layout address to collect the chunk ID, then the chunk ID collected and calculated into the chunk address at the right X and Y position to get the correct block ID. The blocks/tiles/collision should remain the same.

If you are making the chunks smaller, then the above is still needed, but you also need to take into account that you are shrinking the total available chunk space. Every chunk would need to be broken up into smaller chunks, meaning you're increasing the number of chunks used, and while some can be omitted as they may appear as a duplicate, you will have levels that just cannot have enough omitted to fit into the chunk limit. You could change the layout data to handle as one word per chunk rather than one byte per chunk which is possible, but you will also need to take into account that increases the layout data size by x2. In addition to this, because the chunks are smaller, the layout will need to now be bigger to compensate for the smaller chunks, and fill up the same 4000x800 pixel layout space (for example, if you made it such that you now have 64x64 chunks, you now need to multiply the size of the layout by x4, the chunks used will now be x4 (or less depending on omittence). The layout data may not fit into RAM, and you may need to have them stored in ROM, the chunks should free up some RAM space though now that they are smaller, but again, you will be limited to the number of chunks the layout can support, and if you expand that limit changing the layout from byte to word, you will limit yourself on RAM usage, so you'll be picking your own poison.

Do note, I know the above is quite vague, and there isn't 100% specific details on what needs changing, but this is because I don't currently have the time to give you specific routine names or instructions, I'm a little tied up and busy with things. I hope the above at least points you in the right direction.

 

I'm getting the general idea, but I'm still having trouble finding where specifically everything happens (at least in regard to drawing the chunks, I'm trying to do that first), and what should change. I've been searching through "; MJ" comments in Sonic128, but the only thing I was able to recognize as important and replicate was DrawBlocks, or GetBlockPtr as it's label in S2. As it turns out, that routine only has a role in dealing with the background deformation in certain levels.

 

How would I go about adding extended camera to Sonic 1? There are no comments in ScrollHoriz2, so I have NO idea what any of it means.
Anyone able to help the noob out?
P.S. As usual, this is the Hivebrain 2005 disasm.

 

Yes and while you guys are at it, can you add Sonic 4 into Sonic 1 for me? I am using drx's Sonic CD disassembly by the way.

So uh, I get that you are enthusiastic about hacking, but this community isn't about "explain to me how to do simple things because I am too lazy to find out", but more about "Hey, I've tried to do this thing, and I tried this and that, but I dont seem to really get it right". Do your research, learn how disasemblies, assembly and Mega Drive works, try to do simple things first, and move up to more complex things until you can do things. If you run into issues that seem like you should be able to figure it out, but you are missing something important, then come to us, ask nicely, and we will help you. But just coming here expecting us to do your research for you is a quick way to get no help.

 

OK, sorry. Thanks for the reply, though.

Note to self: Don't expect the tutorials handed to you. DO RESEARCH.

 

Hello guys once again!
I have a question regarding the Sonic 3 & Knuckles disassembly.
How would I make it utilize .snd files instead of .bin files?

 

what exactly are you trying to do? Just saying .bin files is rather vague, since in S&K Git disassembly almost everything is a .bin file

 

From what I can gather, he's just referring to SMPS files. I remember the Sonic 3 sound driver to Sonic 1 guide using SND files instead of BIN.

If I got that correct, they are both just SMPS files, just with different file extensions.

 

".snd" is quite ambiguous, there are certain audio types out there that use ".snd", some are simply sample based similar to RIFF/wave PCM, others can be tracker based (similar to midi).

You will need to clarify on what ".snd" format you mean. If you got it from the guide Novedicus is referring to, then as he stated, they are identical. If you are talking about something else, then while I don't wish to jump on board yet, I will say that there is a high probability that what you want support for, cannot be supported (either at all, or without some massive restructure/rewrite), but nevertheless, clarity needed.