2 Sonic 1 Hacking Questions

Okay sorry- I suck at hacking.

   Question 1: How would I port a Sonic CD spindash?

Simple as the title states. How would I port a Sonic CD Styled Spindash to Sonic 1? I noticed how virtually no hacks use that kind of spindash, also I liked that spindash unlike most people.

I don't want to grab too much code from other games since i'm that kind of person who can't download too much on my 400 Dollar laptop or else it will explode.

Question 2: Sonic 3 Sprites for Sonic 1?

How would I port the Sonic 3 Sprites (Just for Sonic)? I can't use Sonik Sprite due to a lack of that ONE DDL file... I hate that file. So is there any way to port those over? I want to try porting them over... If it's possible.

Sorry for being that guy who questions things alot. I'm new to asm. Also, sorry for the overuse of gifs , I just like how it helps decorate posts.

 

1. You can follow the guide on the Retro wiki for porting the S2 spindash. Afterwards, you can modify it to function like the on in SCD by using a new animation with Sonic's rolling frames instead of the standard spindash frames, and having the spindash routine run a timer that makes Sonic stay in place instead of charging forward if down hasn't been held long enough. You could also have it check for a later frame in the spindash animation instead if you want to save one of Sonic's SSTs.

2. First, used SonMapEd instead. It'll be more helpful for sprite work and you can even find a tutorial for using it the useful links thread (which I highly recommend ALL newcomers take a look at). Load SonMapEd in S3 mode and load up the uncompressed art, mappings, and DPLCs for Sonic from the S3 disassembley. Then go ahead and set it to S1 mode (you'll have to fix the palette of course, something else SonMapEd can help you with) and save the 3 files for use in your hack. You'll also have to change the Sonic_Animate routine to work like the equivalent in S3, which would involve taking said routine from S3 and replacing the SSTs with the S1 equivalents (information you can also find on the Retro wiki page for S1 and S3).

I hope this information helps you out.

 

1:To your first question seeing as you are learning asm as you stated, the only simple thing to do really is just apply this into your hack and from there just study upon how it works and make your own asm edits from there into getting to the state you want it. not hard really once you get used to asm a bit more.

2:As for your second question, this would require that you know the basics how animations work. if not, then gladly feel free to use this guide I made sometime ago... that no ever uses... *Wah* ;_;.... but aside from the sillyness, this will also require that you use SonMapEd [At least thats how i did it] as well as expanding the limits of the art and mappings for him. not exactly the proper way of doing this but im sure this could prove to work just as well if done correctly.

EDIT: Crap... Shockwave already beat me to the punch. Still either way, hope this helps.

 

I like the idea of using small GIFs. Certainly gives these question topics an interesting new light.

Anyway, I want to emphasize this post on your first question. The CD-styled Spin Dash is really as easy as following the first part of the guide on Sonic Retro up until the "Adding new Tiles" section. Adding the delay then can be done in numerous ways.

One of them is making two new animation scripts (in _animSonic.asm), the first being a slowed-down roll animation, which then leads the script to the other one. That second script is also a roll animation, but much faster. Here's an example of how this could be done (this is just an example and will not actually work if you just copy it over):

SonAni_Spindash1: dc.b $02, $08,$09,$0A,$0B, $FD,$26
SonAni_Spindash2: dc.b $00, $08,$09,$0A,$0B, $FFLet's say the initial animation from the Spin Dash code is $25. That would be the SonAni_Spindash1 in our script. The "$FD,$??" at the end of it is a flag that moves the animation pointer to another one, allowing the engine to change animations without any great programming deal. An example of where this is used in the default game is the spring animation and the bubble-breathing animation. By setting it to $FD,$26 we can quickly jump to the animation with the ID $26, which we assume is SonAni_Spindash2. That animation ends with $FF, another flag, that simply tells the engine to repeat the animation over and over again.
With that done, just check if the second animation is being played in the Spin Dash code. If it's not, don't do anything when the down button is released, otherwise initiate it.

Code:

Spindash_CheckDelay:
		btst	#1,($FFFFF602).w	; is down button still pressed?
		bne.w	Spindash_End		; if yes, continue charging until Down is released
		cmpi.b	#$26,$1C(a0)		; is Spin Dash anim #2 being shown?
		beq.w	Spindash_Start		; if yes, do Spin Dash
	; abort spin dashing here (reset flags, stop sound, etc.)
		bra	Spindash_End

Spindash_Start:
	; do spin dashing here

Spindash_End:
		rts

Hope this helps.

 

I forgot to mention this,


I am using the GitHub disassembly. So a few hacks such as the spindash wont work. I implemented the Sonic 2 Beta spindash and it works pretty well, the only downside being Sonic floats in mid-air along with the fact that his animation is slow. My friend (Bagumba) did that coding for me, he is going to use it in his hack.

 

If you use SonMapED, you can edit the mappings and PLC's for the Spindash in Sonic's art to be lower. You  just go over to each frame one press the down key to move the sprite down 8 pixels or hold down the shift key and press down to move it down 1 pixel.

 

I'm having trouble with SonMapEd. I don't know what buttons to press, When I load something in the maps folder I usually end up with some gibberish

Edit-

I managed to load graphics, But It's unorganized. Is there a way I can fix this? I have ocd so it's verry annoying trying to edit these with it being mixed around.

 

It should be simple:

1. Load Sonic's art from artunc/Sonic.bin

2. Load Sonic's mappings from _maps/Sonic.asm

3. Load Sonic's dynamic pattern load cues from where ever it's located

4. Do what ever

5. Save things in their respective locations

I really don't like the GitHub disassembly. The main reason is because if you're trying to find something, you have to search through EVERY SINGLE FILE and once you're done, instead on just having to quickly saving sonic1.asm, you have to save every object file you saved. I swear I almost went mad trying to find where Sonic's DPLC's are located. If you haven't made much progress on your hack, please switch to the Hivebrain disassembly or, better yet, use MarkeyJester's original Sonic 128 disassembly which uses the Hivebrain disassembly as a basis but improves on it with stuff like small chunks for creating levels and the plane switcher which can be used to do some cool stuff along with being able to customize your loops. I've even been able to port zones from other games (without the objects) which couldn't be done with the original Hivebrain disassembly. Sorry for going off-topic. Anyways, just don't use the GitHub/SVN/Whatever it's called. Don't get tricked be claims that say it's better because it's more "up to date." (Please note that I may not be 100% correct and these claims are based on my opinion)

 

I agree with you 110% here. I've used the S2 Git disasm in the past, and while it's the most sane of the three it's still not very usable. Xenowhirl's aging disasm may be seven and a half years old, but at least it's able to handle some larger operations without too much hassle provided you have necessary knowledge. The Git disasms are a pain in the ass, hands down.

 

I actually greatly disagree with this sentiment. I'd honestly hate having all of my work in one huge stream of code. I like being able to flexibly switch to the right file that I need for the relevant code that I'm looking for. It's also much easier to track changes, mistakes and accidental loss of work, because Windows Explorer already notes things like date modified, file size, etc. Honestly, use whatever you find comfortable, don't be dissuaded by people telling you something is a better or worse format.
EDIT: Darn Touch Screen

 

Well, you could always just do what I do and make reasonable splits of the code into separate files, such as having each character in his/her own file. .-.

 

Come on, guys, don't turn another simple question thread into a disassemblies war again! Its rather rude and confusing!

 

I dunno, exploring the pros and cons to help the asker decide if it would be in their best interest to switch disasm is anything but rude. They are asking questions after all.

That said, I spent a lot of time making that improved Git Two-Eight disasm. The original Two-Eight has a handful of annoying bugs, and Hivebrain's disasm is virtually undocumented.

For the latter, if you're only interested in following guides, that won't be a problem; but if you want to experiment with the code yourself, it may be best to use the disasm that better tells you what you're looking at. Not to mention, in recent times, there have been made Git-based guides, that can't immediately be used with Hivebrain's disasm.

With the way things are, it would be best for you to learn to work with the code and tools; know the differences between the two disasms, so you can port between them; know how basic tasks are performed in the Sonic engine, so you have an understanding of what others are telling you, allowing you to expand on what's been said and take it further. But it should be said, the Sonic object is a tricky area. I'm scared to go there, myself. If you want to work independently, you should try somewhere else. And, of course, there are guides for using SonMapEd. As for figuring out the controls... mashing the keyboard's worked well for me. Also, your problem with loading Sonic's mappings is likely because, as the guide would tell you, you need to load Sonic's 'pattern queues' (this is 'Sonic - Dynamic Gfx Script.asm' in the _maps folder) in addition to his normal mapping file. Be aware that, when saving your modified mappings, you're going to encounter a series of errors, brought on by a wonderful Git quirk: the mapping file contains equates and additional labels, which SonMapEd will remove when saving. Making the file SonMapEd-friendly requires a bit of work, such as moving the equates, found at the bottom of _maps/Sonic.asm, to a different file, preferably the Constants.asm file, and hardcoding them, to not be reliant on the additional labels in _maps/Sonic.asm, so this:


fr_Burnt: equ (ptr_MS_Burnt-Map_Sonic)/2 ; $4B

...would become this:


fr_Burnt: equ $4B

Then you have to relocate one of the additional labels, namely Map_Sonic. In sonic.asm (the main one), find the 'include "_mapsSonic.asm"', and, above it, put the label 'Map_Sonic'. You may also want to go back into the mapping file, and replace all of its instances of 'Map_Sonic' with a different label, so they don't conflict with the one you just added in sonic.asm. You'll also have to do this with 'Sonic - Dynamic Gfx Script.asm', and its SonicDynPLC label. Once you've done all that, you should be free to meddle with the mappings to your heart's content.

Anyway, I recommend working alone because some of the people here who could easily answer your questions simply don't want to. I mean, they spent the time and effort figuring it out for themselves, why would they give that up to the guy who jumps to asking?

But, yeah, tread carefully. You'll get silence, people criticising your choice in disasm, and rarely an actual, good answer. I'm honestly surprised at the amount of genuine help that's been given so far, but I don't think you can sustain yourself like this; I've seen the answer well go dry for many people.

 

If you would like more SonMapED help I would go here:http://www.youtube.com/playlist?list=PLG5pDqi1j9JDWkmJ4qGHhvuoni7zvhnj9. Well thats why I did the tutorials, I'm not showing you how to port the spindash art but I do for the most part try to explain how SonMapED works. I have autism/learning difficulties so I can somewhat sympathy.

 

Yeah I'm moving to the sonic 128 disassembly because it allows better level design. My goal is to do a Sonic CD styled game with a few touches of Sonic 3 here and there.