Basic Questions and Answers Thread

I added a new zone to my Sonic 1 hack and it works fine except that going back to the title screen by pausing and pressing a when in debug mode causes the game mode to be set to the title screen but the game to still use the level routine (I checked by adding flags at the beginning of both the level and title screen routines and using Gens' RAM watch). Also, the game either comes up with an error or makes the background blank when trying to use vladicomper's deformation engine with the level.

 

Hello, how to make floating clouds in GHZ?

 

You'll have to be more precise. Depending on what you want it to do, you'd either have to make a new object, or modify an existing one, like the floating platform. Neither of which are exactly basic things that can be explained in a paragraph.

 

Depends on what exactly you want the floating clouds to do. Do you want them to be basic platforms? Or springs like in Sky Sanctuary? Or do you want them there for decoration? Things like this will help us help you make them.

It'd also help if you posted what all you have done thus far, if anything. I will say though, if you expect the members here to code the clouds for you, then you're coming to the right place. This thread is primarily used for members who are having issues with their code and need help fixing it, or members who want specific nuggets of information to help them along, not to ask other members to do your stuff for you. On top of that, no one here wants to do your stuff for you. We want you to implement features by yourself.

 

So, the game may crash randomly when returning to the Title screen in debug mode? Does it happen only in that new zone?
The fact that you say, the game uses Level game mode while displaying the title screen is really weird. How did you use the said debug flags to come to this conclusion? Ensure that level or title screen don't reset your flags in their memory clearing loops.

My deformation engine is hard to crash, unless you're running it with a broken or non-existent script, however, if you followed my installation guide correctly, each zone to use it manually loads the correct script before calling ExecuteParallaxScript, so it should never get the wrong data, unless the ExecuteParallaxScript itself is jumped to randomly, due to, say, loading a broken offset in DeformBgLayer.

Moreover, the crashes and glitches may have nothing to do with my engine in particular, there might be a subtle bug, an overlooked line or forgotten table entry; the bugs may simply hide, corrupting memory without any visible signs, unless certain conditions are met. As it's a new zone that you've added, you possibly had to append a lot of offset tables and add various subroutines to handle that zone. Make sure you followed all the steps correctly; pay a special attention to the code you're about to replace, according to the guide. If the code you had looked different from what the guide suggested, there may be where the most of your problems come from.

But to begin with, make a worthy use of the errors you receive. Error messages are way more better than the glitches, trust me. It gives you a chance to hunt down problematic code and fix it completely, instead of thinking of different theories, trying to add extra conditional checks here and there. Even though Sonic 1's native error handler isn't really informative, it shows the offset at which the error has occurred. Use the LST-file to track down this location and see what code goes by.
The Address error is the best error you may get, so be sure to run your ROM in Regen or other accurate emulator to get it. The other errors like Illegal instruction and Line 1010 and 1111 emulators usually occur on memory corruption or mishandled jumps, you will need to examine stack to find which subroutine call caused this.

P.S.: *vladikcomper's deformation engine

 

What I mean is that when returning to the title screen (pressing start and A in debug mode), the game uses the title screen's background deformation and level resizing routine I set for it but the game still acts if it's playing a level even though the game mode is set to the title screen (meaning that Sonic can be controlled, objects appear, and no title screen objects show up) and it only happens for that one zone. The game doesn't crash when that happens.

The game crashes when trying to use your deformation engine with that level. Unfortunately, it only shows an illegal instruction on Fusion, Gens, and Regen and then the level plays without a background when pressing C. I went through your guide to see if I did everything I was supposed to and I did. Using other types of background deformation like Selbi's Parallax Editor works fine.

 

Could you by any chance PM me that ROM you have troubles with? Sounds like a really interesting and complex case, provided that everything was installed and applied correctly; nothing is supposed to crash really, which makes this case interesting. I'll try to investigate it and tell exactly what went wrong there.

 

Okay. I'll PM you when I get home.

 

To free a good chunk of RAM and processor cycles on my s1-based hack, I have switched to a z80-based sound driver, this case being @Flamewing's.
Because I like to keep things in order, I have removed the Sega's vocal, and I have redone all the playlist; I have $0B songs right at the start, and next to it I have the sonic 1's original sfx in the exact same order but the ring's sound (with the two versions for left/right speakers are next to each other). I do not know the z80 instruction set, but in order to keep the Ring sfx in a different ID than the first, while consulting a z80 instruction set document I done the following fix:

Code:

;loc_6A9
zPlaySound_CheckRing:
        sub    SndID__First
        cp    SndID_Ring-SndID__First
        jp    nz, zPlaySound_Bankswitch
        ld    a, (zRingSpeaker)
        xor    1
        ld    (zRingSpeaker), a
        add    a, SndID_Ring-SndID__First

;loc_6B7
zPlaySound_Bankswitch:

The driver works just fine most of the time, although sometimes it triggers a glitch that break my nerves... it seems to be one of those "fragile" parts that needs to be in account, because this one is just the same as seen here, in minute 1:33 or 1:40 (just as example, I hope to not look like being against this project, which I personally love). So far only the PSG channel(s) seem to be affected, and had no issues with the FM at all.
What might it be? After many days I still could not find what causes this issue.

 

The noise channel? Your code looks fine, but I don't know how tweaking the ring SFX code would trigger that channel's weirdness. Flamewing's S&K driver is pretty outdated, and a lot more bugfixes to the driver have been added to the Git disasm. One in particular fixes some noise channel oddities. Maybe that's what you're looking for?

 

I did not think the ring sfx code had anything to do, but I just wanted to give all possible details if anything is necessary; I had some issues with the UVB just because of its location in ROM, so...

That fix did the trick though. Thank you, Clownacy.

 

Now I've got a problem, and all this happened after porting Knuckles to Sonic 2 following the guide by MainMemory (I followed every instruction, too):

Code:

> > >s2.asm(44726): error: jump distance too big
> > > -   bsr.w   SingleObjLoad2
> > >s2.asm(45047): error: jump distance too big
> > >    bsr.w   SingleObjLoad
> > >s2.asm(45247): error: jump distance too big
> > >    bsr.w   SingleObjLoad
> > >s2.asm(45843): error: jump distance too big
> > >    bsr.w   PlatformObject
> > >s2.asm(45980): error: jump distance too big
> > >    bsr.w   PlatformObject
> > >s2.asm(46038): error: jump distance too big
> > >    bsr.w   SolidObject
> > >s2.asm(46516): error: jump distance too big
> > >    bsr.w   SolidObject_Always
> > >s2.asm(47087): error: jump distance too big
> > >    bsr.w   RideObject_SetRide
> > >s2.asm(47115): error: jump distance too big
> > >    bsr.w   RideObject_SetRide
> > >s2.asm(47243): error: jump distance too big
> > >    bsr.w   RideObject_SetRide
> > >s2.asm(47448): error: jump distance too big
> > >    bra.w   SlopedPlatform
> > >s2.asm(51668): error: jump distance too big
> > >    bsr.w   ObjCheckLeftWallDist
> > >s2.asm(51680): error: jump distance too big
> > >    bsr.w   ObjCheckRightWallDist
> > >s2.asm(51848): error: jump distance too big
> > >    bsr.w   ObjCheckFloorDist
> > >mappings/sprite/Knuckles.bin(1): error: invalid symbol name
> > > <0x01><0xf6><0x01><0xf8><0x02>
> > > öø

 

Isn't this the problem you had last time? Just change the bsr.w to jsr.

 

... and do not forget to change that "include" command to "binclude", for the file mappings/sprite/Knuckles.bin.

 

Okay, that's fixed. The only thing left for me is to find SK_ArtNem_EndingKnuckles in the Sonic 2 and Knuckles disassembly, since MainMemory's guide calls for such, but MainMemory never finished that part (specifically, the part for where to find the SK_ArtNem_EndingKnuckles in its disassembly). Nevertheless, this shouldn't be hard to do.

 

My most sincere apologies for double-posting, but after working with the Ending sequence while following the guide, I tried to build the rom again, and I came across this error:

Code:

> > >s2.asm(13113): error: addressing mode not allowed on 68000
> > >     move.l    word_A656(pc,d0.w),d1
> > >s2.asm(13113): error: addressing mode not allowed here
> > >     move.l    word_A656(pc,d0.w),d1

That's the thing that some hackers, even starter hackers such as myself, come across while porting Knuckles to Sonic 2. How shall I fix it? (Sorry if this gets repetitive)

 

That one's similar to the 'branch out of range' error. Those labels are too far away from the instruction that uses them. You can work around this problem by splitting the instruction into two others, which have a longer reach:

Code:

lea    (label).l,a1
move.l    (a1,d0.w),d1

You have to be careful with which address register you use, though. Make sure nothing else is using it.

 

I have another big issue with my custom warp door object (object $4F) for Sonic 1. For some reason, entering a bonus stage via a door subtype and then exiting it from door subtype #$00 causes Sonic to be stuck infinitely in the same bonus stage zone, instead of returning back to the prior zone (though at a new location). Specifically, from a RAM watch, the variables "v_zone" (the current zone/act) and "v_warp_zone" (a custom variable holding the zone/act prior to entering a bonus stage, and to which to return to after exiting a bonus stage) are somehow being set equal to each other, even though I am quite sure I coded not to do so. A function named "DoWarp" changes the appropriate game variables to warp to another zone at a new position, and to set a custom variable called "f_warp" to a certain value to actually handle the warp type elsewhere in the main level code. The function ends by setting f_restart to actually restart the level with the changes.

Does anyone see any logic issues in the object code?

 

I can't view the code for some reason. Can you Pastebin the code instead?

 

I could get it, RHS. Here it is for interested parties:

http://pastebin.com/zvjBdX0E