Basic Questions and Answers Thread

Very few people know that I am working on a rather ambitious project and what I am about to ask is related to it.


Does anyone know how spread out are hardware access related routines in Sonic3 / S&K ? By Hardware I mean VDP, controllers, sound stuff, but not RAM and CPUs themselves.


Is HW access happening throughout the code, like many small routines mess with VDP that are scattered around everywhere, or this is all more concentrated with only some bigger chunks of code doing actual HW access, kind of acting as a front-end for other routines ?


If you have not yet figured it out, this is all relating to putting the game on an incompatible platform (where CPU is same/similiar... i.e think Amiga)

 

In the "_maps" folder of my dissasembly, which object is the HUD?


I want to revert back to the old HUD setup in my hack. Also, is there an internet guide for this?

 

The maps for the HUD are in _maps\obj21.asm


And there's 2 guides to use SonMapEd


Part 1


Part 2


^^

 

A guide for mappings in general can be found here.

 

This is probably a very stupid question, but I can't really find this documented anywhere: How is the background color chosen?


I know in Sonic 1 it's the value of the first transparent of the third palette, but what I can't find is how it's set to use that one and not another.


More specifically, could there be a way to control which "transparent color" is being used in different areas of the screen without using horizontal interruption to change it?

 

This is a VDP quirk, as I stated here:

So if you wish to change to backdrop colour at any time, then perform this operation:



move.w #$87?!,($C00004).l



Where ? is the palette line ID, and ! is the colour ID in that line.

 

I wasn't searching the right words >_<


So, at best it can be changed during an horizontal interruption as there's only one at a time. :/


Thanks.

 

Ok, after following this guide, I've found that my spindash sound no longer does anything, rather irritatingly. When spindashing, no sound will play, and one FM channel will hold whichever note is playing. I've checked the sound-types, and tried a lot of possible solutions, but now I'm baffled.


I'm wondering if there's a way to fix it that doesn't involve removing the extra music slots.


Any ideas?


Edit: Upon further inspection, it also causes the Above/Under water pallets in LZ to swap for 1 frame when attempting to spindash too. (each time A/B/C is pressed)


Edit2: Found the problem, if anyone else experiences this after expanding the music slots after already adding spindash, here's the fix:


Find:




ContinueSound_ChkValue:


cmpi.b #$A0,d7


bcs.w locret_71F8C


cmpi.b #$CF,d7


bls.w Sound_A0toCF; sound $A0-$CF


cmpi.b #$D0,d7


bcs.w locret_71F8C


cmp.b #$E0,d7


ble Sound_D0toDF


cmpi.b #$E4,d7


bls.s Sound_E0toE4; sound $E0-$E4


cmpi.b #$FF,d7


bls.w Sound_E5toFF



Change to:




ContinueSound_ChkValue:


cmpi.b #$A0,d7


bcs.w locret_71F8C


cmpi.b #$CF,d7


bls.w Sound_A0toCF; sound $A0-$CF


cmpi.b #$D0,d7


bcs.w locret_71F8C


cmpi.b #$D1,d7


bcs.w Sound_D0toDF ; sound $D0-$DF


cmp.b #$DF,d7


ble Sound_D1toDF


cmpi.b #$E4,d7


bls.s Sound_E0toE4; sound $E0-$E4


cmpi.b #$FF,d7


bls.w Sound_E5toFF



And the bugs are fixed!

 

How can I replace all of the Plane B's layout by other one, and also back his X position to $0000?

 

I'm not absolutely sure since I never tried, but this should help.


After levload_clrram, you see this:




lea ($FFFFA440).w,a3 ; RAM address for background layout


moveq #2,d1


; End of function LevelLayoutLoad


; "LevelLayoutLoad2" is run twice - for the level and the background


; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||


LevelLayoutLoad2: ; XREF: LevelLayoutLoad


move.w ($FFFFFE10).w,d0


lsl.b #6,d0


lsr.w #5,d0


move.w d0,d2


add.w d0,d0


add.w d2,d0


add.w d1,d0


lea (Level_Index).l,a1


move.w (a1,d0.w),d0


lea (a1,d0.w),a1


moveq #0,d1


move.w d1,d2


move.b (a1)+,d1 ; load level width (in tiles)


move.b (a1)+,d2 ; load level height (in tiles)


LevLoad_NumRows:


move.w d1,d0


movea.l a3,a0


LevLoad_Row:


move.b (a1)+,(a0)+


dbf d0,LevLoad_Row ; load 1 row


lea $80(a3),a3 ; do next row


dbf d2,LevLoad_NumRows ; repeat for number of rows


rts



That's basically how you load the background layout in S1. You only have to make a few changes to load another layout, that one is based on level number (unless you directly change that number in game).


It looks like it should be ok to do it on the fly. Loading different art may take some time though.


As for the plane position, it's a word in $F708 and another in $F70C. You may also need to clear bg deformation data, that's the bytes from $F754 to $F75B.

 

What are the "scrollblock" subroutines really doing in s1 rev1 and what are the differences between them?

 

Okay. I need change the sonic's collision size. Where's that data?

 

Hitbox height and width are in $16(an) and $17(an) in s1 & s2, $1E(an) and $1F(an) in s3k.

 

Thanks, friend. This will also help me to define the other object's size easily

 

Be careful, it may not work in S1 (don't know about the other ones).


There's a parameter in $20(an), the "collision response bitfield". The two higher weight bits (7 and 6) are the type of the object (00: enemy, 01: increments routine counter, 10: harmful object, 11 is used for some special objects) and the other bits (5 to 0) are an entry in the "touch_sizes" array. That's where the size of the hitbox is defined for most of the objects.


So, for example, if you want a proper size/width for an enemy you have to look in that array and set $20(an) accordingly. The array only has 35 sizes defined though, and since with 6 bits you can have 64 values, you can add your own there.


---


Edit: I have a question, not something really important but it's bothering me and I'd like to know. I think I've seen it discussed before, but I can't find where and can't remember what was said.


In the v_int routine there's this:




btst #6,($FFFFFFF8).w


beq.s loc_B42


move.w #$700,d0


loc_B3E:


dbf d0,loc_B3E



It happens twice. FFF8 is the region code, bit 6 is set on the US Genesis (I think I read it wasn't on the European and Japanese megadrives though I'm not sure, it doesn't really matter anyway). Obviously, this is only delaying the execution of the program, it loops an insane 1792 times, wasting a handful of yummy processor cycles, but why? I mean, I don't think it's only that Yuji Naka decided to be mean and artificially made the Genesis slower than the Megadrive, so what's the technical reason, if any?

 

That loop is only run when the console is in PAL mode. I think it's done because because PAL only runs at 50fps (as opposed to 60fps in NTSC mode) and there are extra processor cycles left over. I might be wrong, but it actually seems unnecessary to do?

 

I'm having trouble.... I added the Sonic The Hedgehog REV01 background effects to my hack some time ago (following the Sonic Retro guide for that). I noticed that I have a bad deformation in a mountain in Spring Yard Zone. The mountain is cut vertically...


Well, I did it again in a clean rom (following the guide again), and same bug is there.... anyone has noticed that? any idea of how to fix it?

 

I have no idea because I don't understand the deform format too well. Anyway, I recommend you that you can keep using the normal deform system, and create your own deformations with this (also, look the other posts in that topic to know where to put the code)


EDIT: GRAMMAR

 

Thanks, I have seen that, but I would like to know what is wrong in that guide and how to fix it...

 

100% correct, your genius is showing! =)


The processor itself doesn't change speed, but the framerate of the TV does, and as most games use the vertical interrupt as a general program speed synchroniser, 50hz games appear slower due to that extra time necessary to wait for, this also means extra processing time to do additional tasks, as mentioned above, that loop is designed for 50hz machines in order to waste that extra bit of time left, the reason for it is unknown as like you said, it's just wasteful.


Perhaps it's just to ensure that the 50hz games lag at about the same amount of processing as the 60hz games, to preventing 60hz console owners from complaining or thinking that the 50hz system is somehow more powerful? =P