[Tiddles]

It's efficient enough, it's just horrible to read and work with because of all the weird edge cases.
It also results in the instashield graphics replacing the main shield rather than overlaying it because of the shared VRAM. As it happens, that works pretty well with the classic shield. I don't know that it would with the elementals.

If you want to stop the shields from running their animations, within the double-jump code we were tweaking before, look for any lines that set $FFFFCD08. From the shield's point of view this is $20(a0), I.e. it sets the animation. That should keep them from kicking up rough.

As for the CNZ/MHZ error, I managed to recreate this by changing the line at loc_68D8 from

cmpi.w	#1,(Player_mode).w

to

cmpi.w	#2,(Player_mode).w

.
So you probably want to change that back to #1 if it's set differently.

[E-122-Psi]

Yep, it's me again...

Those fixes have been placed in and work fine. Thanks again...but I've managed to screw up again *shot*

Recently I've been editing the spring mechanics, and now for some reason all the forward and diagonal springs have disappeared in game. Any idea why this has happened?

EDIT: Never mind, Fixed it. I must have been using a flag used in the spring data for the hammer recognition that cancelled them out.

This post has been edited by E-122-Psi: 21 April 2012 - 07:06 PM

[Vexus]

I bet you guys get this quite a lot, but I searched 'freeze', 'not responding', and 'lock up' with no luck.

I can't open up any levels to edit in SonED2. I ran the split txt file on my clean Sonic 2 ROM, but when I try and open up a level in the Project folder, nothing happens. SonED2 just freezes and goes all [not responding] when I click on it.

I have Windows 7 Ultimate 64-bit with 2.00 GB of RAM, if that helps any.

[KingofHarts]

Ok... I got bored, and wanted to take a hiatus from my fangame. So I took up learning hacking... and I decided, I wanted to learn how to hex edit, and learn the ins and outs of how it works. I am picking things up just fine, all is well. It's a LOT easier than it looks once you give it a try.

SO, I am, to some people's knowledge, writing my own hex editor program using GML, that is meant to be used to hack Sonic 1-3K. I've only been at it for a week, and already I have an early palette editor that works perfectly. ROM tested... everything. (I'm not giving it out to everyone... only some select people to test for bugs for me. I will publicly release a more complete editor later on) Things are going good. Now I want to expand this to tile editing (I'm taking baby steps...) NOW, I understand how to edit uncompressed art... That is easy enough... each 8x8 tile being 1 nybble, and each nybble's value is equal to a position on the palette line... I get that.

The part I am having trouble with now, is editing the zone art. You know... those bits of art that get put together into 16x16 blocks, and placed into 128x128 (or 256x256 for Sonic's 1 & CD) metatiles. I'm having trouble, because it is compressed. I am aware of what Nemesis compression is... but I don't know EXACTLY how to work around it... So, my question is...

Can I find someone who could teach me how to hex edit the compressed art? (OR just PM me with a direction to a tutorial of sorts.) I've looked this up on SEGA Retro... and I still feel stumped. Basically I'm looking for a tutor OR tutorial.

Any help is appreciated.

[flamewing]

The best way to edit compressed art is: decompress, edit uncompressed, recompress. All other ways lead to madness; particularly since Nemesis format compresses sequences of nibbles into sequences of bits.

[Sodaholic]

I don't want to stay terrible at ASM, I want to learn and improve so I can do things on my own, so if you answer the following, please explain what is happening in the code and how to better navigate it instead of just doing it for me. I understand how ASM itself works, it's just the Sonic engine itself I'm not too familiar with.

What's the best way to make the player only lose 20 rings when they're hit in the 2007 disassembly of S2? (Don't question the game design choice, I'm repurposing the rings) I've looked at the code, and being ASM illiterate for the most part, am not sure what to do.

HurtCharacter:
move.w (Ring_count).w,d0
cmpa.w #MainCharacter,a0
beq.s loc_3F88C
tst.w (Two_player_mode).w
beq.s Hurt_Sidekick
move.w (Ring_count_2P).w,d0

What is the line highlighted in red doing? If I'm interpreting it correctly, I assume that this is doing something like telling the HUD to update how many rings it says you have, due to the order the Ring_count and the number appear in (why would a RAM address be this short though? aren't they usually a bit longer?). If that's the case, then where is the code that clears the ring count?


Also, could I have an explanation of how the HurtCharacter routine works in general? Like, a description of what each line does or something. Thanks.

This post has been edited by Sodaholic: 24 April 2012 - 09:14 PM

[Hitaxas]

It's storing the number of rings, which is contained in Ring_Count into d0. This is used later in the next part of the code that test for d0, in which either loads the rings or kills sonic.

; loc_3F878:
HurtSonic:
        move.w	(Ring_count).w,d0       ; Move/Store the Ring_count into d0
	cmpa.w	#MainCharacter,a0       ; Is this Sonic?
	beq.s	loc_3F88C               ; If yes, continue to loc_3F88C
	tst.w	(Two_player_mode).w     ; Test if this is 2P mode
	beq.s	Hurt_Sidekick           ; If yes, continue to the routine that handles Tails getting hurt
	move.w	(Ring_count_2P).w,d0    ; Move/Store Ring_count_2P into d0

loc_3F88C:
	btst	#0,status_secondary(a0) ; Does Sonic have a shield?
	bne.s	Hurt_Shield             ; if he does, continue to the routine that handles getting hurt with a shield on
	tst.w	d0                      ; Does Sonic have any rings?
	beq.w	KillCharacter           ; If not, Kill him!
	jsr	(SingleObjLoad).l       ; Run SingleObjLoad
	bne.s	Hurt_Shield
	_move.b	#$37,0(a1)              ; load the scattering ringsobj
	move.w	x_pos(a0),x_pos(a1)     ; match the loading x_pos of the object to Sonic's
	move.w	y_pos(a0),y_pos(a1)     ; match the loading y_pos of the object to Sonic's
	move.w	a0,parent(a1)

I quickly commented that little bit. Hope it helps a little.


Edit: I suppose if you wanted to make the scattering rings ALWAYS spawn 20, you could go to Obj_37_sub_0 and add
move.w $14,(Ring_count).w

right underneath it.

This post has been edited by Hitaxas: 24 April 2012 - 11:31 PM

[Aerosol]

Here's a general 68k asm question.

Logic statements always fuck me up. How does one go about making decisions with asm? "If x = y, do z" sort of things.

[Ravenfreak]

In 68k assembler, this is what an if else statement could look like : (note this code is from Sonic & Knuckles' Spindash routine in the latest S3k disassembly, and yes they share that code. )

move.b	(Ctrl_1_pressed_logical).w,d0 ; get joypad 1's input
		andi.b	#$70,d0                       ; was either A,B,orC pressed? (If a,b,c was pressed)
		beq.w	locret_11C5C                  ; if not, skip over this step  (else branch)
		move.b	#9,$20(a0)                    ; otherwise play Spindash animation (do Spindash) 
                move.w	#$FFAB,d0
		jsr	(Play_Sound_2).l                   ; play revved up sfx

I hope this helps a bit.

[Aerosol]

I see. andi.b sets the Z bit to clear. If it doesn't set the Z bit to clear, then beq.w picks that up and branches to locret_11C5C. I don't understand which conditions andi.b would clear the Z bit under, though. The 68000 instruction set PDF I'm reading doesn't make that clear, exactly.

edit: I've been skipping words in my sentences all day today. Goddamn.

edit2: I think I understand. the result of andi.b would be 0000 0000 if not a single button was pressed. That's what clears the Z bit of the CCR, right? Similarly, if the result of andi.w was 0000 0000 0000 0000, the Z bit of the CCR would clear. But if it was something like 0000 0000 0001 0000, the Z bit would be set, and beq.w would be ignored, since the Z bit was set.

Is my understanding flawed?

edit3: Okay I get it, I totally get it. Is there a reason why this isn't done, however?

andi.b #$70,d0
bne.w (label where the spindash code is)
[continue from locret_11C5C]

This post has been edited by AerosolSP: 27 April 2012 - 08:59 AM

[Vexus]

I bet you guys get this quite a lot, but I searched 'freeze', 'open', 'not responding', and 'lock up' with no luck.

I can't open up any levels to edit in SonED2. I ran the split txt file on my clean Sonic 2 ROM, but when I try and open up a level in the Project folder, nothing happens. SonED2 just freezes and goes all [not responding] when I click on it.

I have Windows 7 Ultimate 64-bit with 2.00 GB of RAM, if that helps any.

[Knucklez]

Vexus, on 28 April 2012 - 02:14 PM, said:

I bet you guys get this quite a lot, but I searched 'freeze', 'open', 'not responding', and 'lock up' with no luck.

I'm sure we do, especially when you post the same exact post you did a week ago..

[Aerosol]

Well, this topic doesn't get a lot of posts in it, even when tech members pop in. I guess he just figured that nobody saw it yet.

This post has been edited by AerosolSP: 28 April 2012 - 02:37 PM

[Ravenfreak]

AerosolSP, on 26 April 2012 - 12:41 AM, said:

edit3: Okay I get it, I totally get it. Is there a reason why this isn't done, however?

andi.b #$70,d0
bne.w (label where the spindash code is)
[continue from locret_11C5C]

Because then it would branch to locret_11C5C (which contains just a rts), and the next part of the code handles revving up the spindash. So it'd mess up the spindash code, and the player wouldn't be able to charge the spindash.

[Aerosol]

I see. I guess there is a way to rearrange all of the spindash code so that you can test to see if one of the buttons IS being pressed with bne rather than testing to see if they aren't being pressed with beq, but it was a lot simpler for them to test with beq and code the spindash that way, right?