Basic Questions & Answers thread

Does anyone have a fix for the parallax scrolling bug in Sonic 2's EHZ? By this I mean the stuck rows of pixels at the bottom of the level - I think this was fixed when you locked it on with Sonic + Knuckles.

 

I didn't get the art from the SCAA, I got it using SonMapEd.

 

Read the bottom of this post, it explains how to do it.

http://forums.sonicretro.org/index.php?s=&...st&p=202132

Enjoy

 

Cheers SMTP

 

I've a problem with HTZ. Since it was completely separated from EHZ, this leaves a problem to those "EHZ"/ half of the entire set garbled.
I've managed to restore/remake those chunks, but upon playing in-game, those "EHZ" chunks are garbled. Is there a fix to this mess?

 

Elaborating on my previous post on that matter:

I assume that you want HTZ completely independent from EHZ. If you haven't already done so, first make separate entries for HTZ in LevelArtPointers.
EHZ and HTZ share exactly the same chunks, so just copy the EHZ chunks file and use it separately for HTZ. Blocks and tiles however are not exactly the same as they are patched ingame. So to have HTZ display properly, use the already patched files HTZ(8x8) and HTZ(16x16) for tiles and block mapping respectively.

Only thing left to do is disabling the patches in the assembly, namely at sub_4E98 and loadZoneBlockMaps where the additional tiles and blocks respectively are loaded for HTZ. (cmpi.b #7,(Current_Zone).w is where it checks for HTZ).
It seems that at loc_407C0 some HTZ cliffs are loaded into the block table additionally (the condition checking for HTZ is at loc_402D4), iirc I didn't include that in the patched block mappings file above. I'll look into that again, but iirc when I separated HTZ from EHZ it works without a change there. It's got something to do with a few animated tiles in the background that simulate a third layer (at the bottom between the red rocks).

Ah and of course update SonED's project files, obviously.

 

The problem is, since half of the entire set is unused, they're garbled when I place them in-game upon remaking them. In other words, about everything else is restored. I'm trying to have HTZ load the other half of the set correctly I.e. chunk 26 which was the EHZ waterfall that I'm trying to use, chunks that were never used in HTZ. Everything is independent, it's just those unused halves that I'm trying to get around to.

 

I don't understand how the whole "loc_*number*:" system works. If I were to make an object and make a "loc_*number*", how would I know what number to put there? Would I just make something up (ex. "loc_3F85") or is there a specific way of doing it?

 

You can make an object labeled as anything. Even if the label has nothing to do with the code itself, it would still work. All it needs to be connected to something.

E.G.

Code (ASM):

1.  
2. Tetris:                
3.                 move.w  #$F1,d0         ; Set to musicF1 (Tetris)
4.                 jsr (PlaySound_Special).l ; Play Tetris song
5.  

 

Ok, thanks. One more question, how do I change the music for each zone? I've tried to edit sound 81 into sound 82 in the DASM, but so far it either cuts off the music for green hill or seemingly does nothing. This usually works, like with the continue screen, but not for Green hill. Do I edit a different file?

 

Change the mentions of 81 in misc\muslist1.bin & misc\muslist2.bin to 82.

 

Those labels are the default names generated by IDA. The number (in hex) is the address where the following instruction/data starts. This can be useful when "ROM hacking" using the disassembly (until you add your own code and make the addresses wrong). The prefix depends on what comes after: if it's an RTS instructions, the prefix will be locret or return; if it's any other instruction, it will be loc; if it's data, it will be byte, word or dword according to the size of the first DC directive; if it's an offset table, it will be off; if it's unknown data, it will be unk. There may be a few others, but I can't recall any others right now.

Since these names don't tell anything about what the data or the code is used for, it's better to give meaningful names so you can quickly find what you are looking for. Names like "cock" and "fuck" seem popular amongst some lazy coders and programmers, but are not very meaningful.

AS has a nice feature that doesn't force you to find stupid names for your labels: nameless temporary symbols. Also, most assemblers, including AS, offer to use "temporary" labels; by adding an assembler-specific prefix, you can reuse the same label name but only in a close range (usually between 2 "global" labels).

 

I'm trying to remake the enemy from Sonic Triple Trouble in S2.

It's replacing the buzzer. I got as far, as to make it not shoot, but now I'm stumped, on how to make it stop, and then fly away.


Not trying to copy rika, I just love those annoying bastards.

 

In order to stop it and then get it to fly again first you'd have to literally stop it:

Code (ASM):

1.              move.w   #0,$10(a0)
2.              move.w   #0,$12(a0)

Then you'd probably want to set a timer. First find scratch RAM that the object doesn't use ($29-$3F is scratch ram, which is pretty much just blank where you can store things and such). Then move a time into it in a routine that isn't used more than once (you wouldn't want to keep adding to the timer).
So say you have in a routine that isn't called on anymore once you go on to the timer's routine. I'll use $32(a0) as an example (may not be the same).

Code (ASM):

1. move.w   #$300,$32(a0)
2. Timer routine:
3.                sub.w        #1,$32(a0)
4.                bmi.s        Fly_Away    (branch if equal to or less than zero)
5.                rts
6. Fly_Away:
7.                (however you want the object to fly away)

Or alternatively you could do:

Code (ASM):

1. move.w   #$300,$32(a0)
2. Timer routine:
3.                sub.w        #1,$32(a0)
4.                bpl.s        No_Fly   (branch if equal to or greater than zero)
5.                (however you want the object to fly away)
6. No_Fly:
7.                rts

 

Thanks, got it working.


Now I'm going to port tails flying. =D

 

I keep getting this message when I type in sonicretro.org:

Hey, it worked !
The SSL/TLS-aware Apache webserver was
successfully installed on this website.

If you can see this page, then the people who own this website have just installed the Apache Web server software and the Apache Interface to OpenSSL (mod_ssl) successfully. They now have to add content to this directory and replace this placeholder page, or else point the server at their real content.

ATTENTION!
If you are seeing this page instead of the site you expected, please contact the administrator of the site involved. (Try sending mail to <webmaster@domain>.) Although this site is running the Apache software it almost certainly has no other connection to the Apache Group, so please do not send mail about this site or its contents to the Apache authors. If you do, your message will be ignored.
The Apache online documentation has been included with this distribution.
Especially also read the mod_ssl User Manual carefully.

Your are allowed to use the images below on your SSL-aware Apache Web server.
Thanks for using Apache, mod_ssl and OpenSSL!

Is something wrong with the main page, is this only temporary, or am I doing something wrong?

EDIT: It just started working again this morning.

 

That should work properly... except for the actual water, which was used for HTZ lava :v

 

That's not what I meant.

 

Specifics are the gold of descriptions.
Nonsensical descriptions aside... have you edited the chunk?