ThomasSpeedrunner Help Thread

...Whaaaaaaaaaaaat? That homing attack stuff sounds pretty complicated.

Now, about the SFX/sound driver thing, it's more of a "How the hell do I add music with this?" problem. The Sonic 2 sound driver is pretty much the hardest sound driver to work with.

EDIT: For freeing move_lock's second SST ($2F), do I change lines like this:




    move.w    #5,move_lock(a1)



To this?




    move.b    #5,move_lock(a1)



EDIT 2: Just tested the above method. It works. Now which other SST's should I try to free up?

 

The guide from Alriightyman I showed you will help free up more of Sonic and Tails' SST's, and my guide found here will help you free up two Universal SST's.

 

Well yes, that's why not everyone has it. I required a bit of help myself.

 

Redhotsonic: Okay then. I'll need all the SST's I can free up if I want to correctly implement everything I want to implement. Right now I have a large ass list of things I want to implement in my hack, including but not limited to:

 - the secret character

 - a homing attack and a proper Super Peel-Out for Sonic (and if I decide to include Shadow, he may or may not get the homing attack as well)

 - Super Tails (because he's OP and I think a lot of us like to be OP sometimes )

All of which I know are gonna take me quite a while. And having a few free SST's definitely helps during that process.

EDIT: There's apparently a problem with the guide you've shown me. Once you hit the monitor with the invincibility ability, you end up keeping it for the rest of the level or until:

A) You fall to your death or something along those lines (read: until you die)

B) You enter and come back from a Special Stage.

Trying to fix it. Will report back soon.

MainMemory:  That surprises me. But then again, as much as we may not want to admit it at times, we've all needed some help at one point or another. So I guess it makes sense.  :mellow:

 

(sorry for double post)

I know this is probably a stupid question that I should be experimenting with, but I'm already experimenting with enough stuff as it is.

How can I make an enemy have a ring come out instead of an animal?

 

Object $27 is the explosion object that normally loads the small animals and points (object $28). Maybe you should look at object $27.

Adding things like this into your hack, it isn't going to help people stop with the megamix comments that seem to bother you.

 

You've followed the guide incorrectly then. You've probably gone wrong at the mathmatical bit. Or possibly you've forgotten to change a .w to a .b somewhere.


Re-follow the guide carefully and slowly. Check every single bit again. I went by it years ago and it worked perfectly for me.

 

I'm not only getting ideas from Megamix; I'm getting ideas from several other fan creations (read: hacks and fangames) as well, including but not limited to:

 - Sonic: Before The Sequel

 - Freedom Planet

 - Sonic: After The Sequel

There are a few others as well. It's just that a lot of my inspiration comes from Megamix, mostly because it can end up giving one so many ideas. As we speak, I'm coding a new badnik for Corrosion Plant Zone that's similar to the Rollbug (which is used in Sonic Boom and Sonic: Before The Sequel, just to name two), with a few exceptions:

1) He rolls by himself and doesn't really react to Sonic approaching.

2) He has two spikes on him that look like a straight line since they are directly across from each other.

So yeah.

You've followed the guide incorrectly then. You've probably gone wrong at the mathmatical bit. Or possibly you've forgotten to change a .w to a .b somewhere.


Re-follow the guide carefully and slowly. Check every single bit again. I went by it years ago and it worked perfectly for me.

Hmm...what is $FFFFFE05? That's where I need help.

EDIT: Wow...stupid me. I forgot to change the move.w in the invincibility monitor to move.b. It was only one line. I can really fuck stuff up sometimes.

 

In my topic for speeding up several subroutines in Sonic 2, why is it showing a bunch of strange bits? It only happens with that one guide.

 

Those are html tags, maybe you enabled or disabled html at a certain point in time, or maybe that's yet another side effect of IPB updates being retarded. Since I have mod powers now I might as well see if I can fix your post.

 

Just fixed it. Apparently the update automatically set the post to HTML. I had to enable and disable HTML, then turn BBCode Mode off as well. Sometimes things love to annoy me.

 

Whoops, I fixed it too. Sorry about that.

 

Well, at least the post works

Anyway, I'm currently working on speeding up my hack, and improving the aforementioned guide as I go, adding more routines and fixes. Speaking of which, does anyone have any general tips on speeding up a hack?

And on a different note, am I doing the Homing Attack code right? Note that I added two equates here to enhance readability.




cmpi.b #$100,(Enemy_X_dist).w

bgt.s   return_1AD8E ; if there are no enemies close enough on the X axis, return

cmpi.b #$100,(Enemy_Y_dist).w

bgt.s   return_1AD8E ; if there are no enemies close enough on the Y axis, return

 

First off, you're using the value $100, a value which cannot fit in a byte, in a cmpi.b instruction, so it won't work. Secondly, that would result in a square-shaped homing attack radius, which is fine since mine does too. Although my homing attack doesn't use any RAM variables, and only two bits of a byte in the SST (one for homing attack and one for jump dash).

 

Damnit. Okay, here's the code so far:

Code:

cmpi.w #$100,(Enemy_X_dist).w

bgt.s   + ; if there are no enemies close enough on the X axis, perform a jumpdash instead

cmpi.w #$100,(Enemy_Y_dist).w

bgt.s   + ; if there are no enemies close enough on the Y axis, perform a jumpdash instead

Is this a good start?

And just curious, is it possible to do something different and still trigger a homing attack?

 

Two pairs of compare/branch instructions are not nearly enough for me to say if it's "a good start".

 

Well, I think explaining this might be a good idea.

Enemy_X_dist and Enemy_Y_dist are used to store the "x_dist" and "y_dist" values (respectively) of a badnik or monitor in relation to Sonic. I would make a Monitor_X_dist and Monitor_Y_dist, but, in all honesty, I don't feel like using a separate set of cmpi.w functions for just monitors.

For example, assume the "x_dist" value of a Buzzer is #$50, and its "y_dist" value is #$120. Since the Buzzer is not close enough on the Y axis, Sonic cannot home in on it.

Next, assume the "x_dist" value of a different Buzzer is the same, but its "y_dist" value is #$40. Since it is close enough on both axes, Sonic can perform a homing attack on it.

...

Something in the back of my head is telling me that I can just use SST variables and still accomplish the same type of thing.

 

If you don't calculate which object is the closest one, your code will trigger the homing attack on the first object within the radius, which depends on the object order in RAM, which is unpredictable for the most part.

 

You don't need RAM variables. This can be done entirely with registers. You have six (d7 is used by the object manager) data registers and five (a0 is the current object, a7 is the stack pointer) address registers.

If you would rather have it 'remember' which object you lock on to once you start homing, then that's at least one variable (the address of the object, or its index in the list).

 

Wow. I'm surprised that you can do something like this entirely with registers. I find it astonishing what you can do with a Genesis.

And yes, I would rather have it 'remember' which enemy or monitor Sonic (and Shadow, should I decide to implement him) has locked on to once the homing attack is initiated, and stay that way until the monitor or enemy is destroyed.