ThomasSpeedrunner Help Thread

Well, I fixed the issue with DEZ's new art. Apparently I was an idiot and didn't check to see where Death Egg Zone was loading its art from. It was apparently loading its art from the CHEMICAL PLANT ZONE ART FILE, so it kinda failed to load the correct art. Fixed now.

 

If you'll ever edit Hill Top Zone get ready for another surprise

 

I know. HTZ loads its art from EHZ's art file, so when I edit HTZ's art (I won't be doing it anytime soon, though), I'll have to modify the SonED2 project files and the art loading code to work right. Otherwise I'll get the EXACT same problem I did here

 

Okay. So I had fixed the SEGA sound in my hack, and I wanted to align the code in the Sonic 2 Clone Driver with the code in the rest of my ASM files. But when I tried to build, I got this set of errors:


> > >s2.clonedriver.asm(284): error: addressing mode not allowed on 68000
> > > move.b byte_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(284): error: addressing mode not allowed here
> > > move.b byte_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(295): error: addressing mode not allowed on 68000
> > > move.b Tom_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(295): error: addressing mode not allowed here
> > > move.b Tom_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(306): error: addressing mode not allowed on 68000
> > > move.b Bongo_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(306): error: addressing mode not allowed here
> > > move.b Bongo_71CC4(pc,d0.w),d0
> > >s2.clonedriver.asm(738): error: addressing mode not allowed on 68000
> > > jmp Sound_ExIndex(pc,d7.w)
> > >s2.clonedriver.asm(738): error: addressing mode not allowed here
> > > jmp Sound_ExIndex(pc,d7.w)
> > >s2.clonedriver.asm(1058): error: addressing mode not allowed on 68000
> > > movea.l dword_722EC(pc,d3.w),a5
> > >s2.clonedriver.asm(1058): error: addressing mode not allowed here
> > > movea.l dword_722EC(pc,d3.w),a5
> > >s2.clonedriver.asm(1925): error: addressing mode not allowed on 68000
> > > jmp loc_72A64(pc,d5.w)
> > >s2.clonedriver.asm(1925): error: addressing mode not allowed here
> > > jmp loc_72A64(pc,d5.w)
> > >s2.clonedriver.asm(2195): error: addressing mode not allowed on 68000
> > > move.b byte_72CAC(pc,d4.w),d4
> > >s2.clonedriver.asm(2195): error: addressing mode not allowed here
> > > move.b byte_72CAC(pc,d4.w),d4
> > >s2.clonedriver.asm(2441): error: addressing mode not allowed on 68000
> > > lea PCM_Table(pc,d1.w),a2
> > >s2.clonedriver.asm(2441): error: addressing mode not allowed here
> > > lea PCM_Table(pc,d1.w),a2



I've tried quite a few things, but it's not letting me build. Would someone please be so kind as to explain what the fucking hell is going on with my driver?

EDIT: Just tried replacing the Clone Driver in my disassembly with a clean one, and the same thing happens.

EDIT 2: Oh, and here's the disassembly for those who are kind enough to help me: http://www.mediafire.com/?45h75nox3i8fap4

 

Since all the errors involve instructions with PC-relative addressing (pc,d#.X), I would guess that your tables are too far away from the code that references them.

 

There isn't much information to say anything for sure, but seeing what errors you get, I think the reason is those labels getting too far from the instruction that refer to them, due to padding data.

All of the listed instructions use d8(pc,dn) addressing mode, where d8 is a 8-bit displacement. In this mode the effective address is calculated by adding the program counter (PC, the current instruction offset), contents of a data register (D0-D7) and a displacement value.

Here, the labels are used to calculate displacement. When compiling the code, the assembler will replace these labels with the values, showing how far these labels are from the instruction (in bytes). The displacement takes only 8 bits in this mode, so the label must be within 128 bytes range from the instruction. If it's any farther, the assembler just can't compile the opcode.

Another reason, that could cause a similar problem, is bad alignment. If you somehow align the code on the odd address, you may have troubles with compiling it as well (as far as I remember, AS can throw errors in this case). This is because the Motorola 68000 cannot read or write words or long words from odd addresses.

But again, there's not much info besides this errors log, which is good, but doesn't help much in this particular case (and many others). The problem is obviously not with these instructions, but with what you've done about aligning code or whatsoever, which, in turn, caused issues with compiling the code after that. It would be more helpful if you showed us what did you change in the first place.

 

When I say "aligning code" I mean instead of having this:


lea PCM_Table(pc,d1.w),a2


I would have this:


lea PCM_Table(pc,d1.w),a2


I don't understand how that could cause anything, though, because this worked perfectly fine after I fixed the SEGA sound.


I just tried moving PCM_Table to above CalcPCM2, but with no luck. It doesn't fix anything.

 

Just tried replacing one of those .w's with a .l, but that didn't work. I have a DEZ2 port I need to test AND I'll have the Sonic 2 Game Gear boss theme SMPS soon! Oh, what am I going to do? </enteringpanicmode>

EDIT: Oh, and BTW, I'm currently trying to implement the reverse-gravity gimmick from Death Egg Zone from Sonic 3 & Knuckles. I have the flag and all, so I'm currently working on putting that flag to use.

 

I am just as confused as you are, it seems to be perfectly valid code that's refusing to assemble. I did find one other problem though: under PLC_DYNANM you commented out DEZ's entry. This means that DEZ now uses ARZ's animations, ARZ uses Sky Chase's, and Sky Chase uses invalid data which will cause it to crash if you try playing it. Instead of commenting it out, change the first line to point to Dynamic_Null and the second line to Animated_Null.

 

I know. It's perfectly valid code that worked absolutely fine after I fixed the SEGA sound. I honestly have no clue what's going on.

Ah, now I know what that table is used for. Changed it, although it doesn't really help me all that much

 

...Hold the fuck on. How the hell is it that the "aligning code" thing I was mentioning a few posts ago fixed the problem? I have a suspicion it was due to the way the data was spaced, but I don't know for sure......how the fuck does that even work?

 

Well, regardless of how the problem was fixed, I have a question for everyone.

Who here has ported (or tried or wanted to port) the reverse gravity gimmick (from Sonic 3 & Knuckles) to Sonic 2? I've been toying around with it for about a day and I can't get the gimmick in question to work properly. Here's Obj47_Main with code inserted that activates the reverse gravity gimmick:

Code:

Obj47_Main:

tst.b render_flags(a0)

bpl.s BranchTo_JmpTo12_MarkObjGone

move.w #$1B,d1

move.w #4,d2

move.w #5,d3

move.w x_pos(a0),d4

bsr.w JmpTo6_SolidObject

move.b #0,mapping_frame(a0)

move.b subtype(a0),d0

andi.w #$F,d0

lea (ButtonVine_Trigger).w,a3

lea (a3,d0.w),a3

moveq #0,d3

btst #6,subtype(a0)

beq.s +

moveq #7,d3

+

move.b status(a0),d0

andi.b #standing_mask,d0

bne.s ++

bclr d3,(a3)

cmpi.w #death_egg_zone_act_1,(Current_ZoneAndAct).w

bne.s ++

cmpi.b #1,(Reverse_gravity_flag).w

beq.s +

move.b #1,(Reverse_gravity_flag).w

+

move.b #0,(Reverse_gravity_flag).w

+

bra.s BranchTo_JmpTo12_MarkObjGone

Anyone see what I'm trying to accomplish here?

 

EDIT 1: Changed the last bne.s to beq.s.

 

NOTE: Also, if anyone cares, I think I'll write a guide on this as I go along. I have the guide ready: http://sonicresearch.org/forums/index.php?showtopic=3495

 

(sorry for double post within a 24-hour time period, and for quadruple post within a 48-hour time period )

ERM...is it possible to get a specific zone to load a different collision array than the others? Probably a stupid question since I've already fixed the collision for most of the chunks in Death Egg Zone, but I just wanted to know if there was a way to get certain zones to load different collision arrays than usual.

 

If you can find how the game normally loads the collision arrays (hint: search for the file's name, then search for the label attached to the file), you should already know how to make the game do different things depending on the zone right?

 

Yes, I do already know how to make the game do different things

I'm thinking about having the game load a different collision array for Death Egg Zone.

 

Erm...probably one of my biggest problems yet. So I extended the level index, right? Not only does the game hang when I select the Options screen, but here's the result when starting up Winter Hill as normal (I did walk to the right a bit):



Disassembly for anyone who can help me fix this:

http://www.mediafire.com/?ruuw1jn39vastoz

I only extended it so that each level could have an act 3. I don't see what could possibly be causing the problem.

 

Just claim that you're porting the Glitch City from the Gameboy Pokémon games and you'll be good.

 

XD

 

That wasn't necessarily my intention

 

I looked at your disassembly out of some sheer morbid curiosity, and all you've done is extend the level pointer table without actually changing the code that retrieves the data from that table. I can't say for certain if this caused your problem, but I can say with 100% certainty that it will not load 3 acts properly. I won't be telling you which lines of code to rewrite or how to rewrite them either, as this topic only proves to me that everyone is holding your hand through every step you take and very little of this is actually of your own making. In fact, I'm close to locking this topic just to force you to actually learn this stuff for yourself like the majority of other people had to. I didn't have anyone showing me code and doing it for me when I wanted to extend my hack to have 3 acts, I just used my brain and worked out what the original code was doing and how it worked. The only info you'll get from me is to read loc_14720, understand what it's doing, and then see how you can change the way it manipulates the data to achieve what you want. It's really not that hard.