Basic Questions and Answers Thread

I had those errors after I fixed the undefined errors. All of those labels are in the asm file.

 

Maybe they're too far away?

lea AnimPatMaps(pc,d0.w),a0

How far away is "AnimPatMaps" from this command?

 

loc_402FA: to ;off_40350:

 

Well I tried to comment out with the ; symbol on the undefined errors and the rest did fix itself but the game no longer works when I play it(black screen), so would you go over with me the proper steps to fix this?

 

It won't work when you've commented out them errors because now it's not loading anything.

You need to find out what it's referencing.  If this guide is meant to be covering the HG disassembly, then download it and search for "Kos_Z80".  Then see if you have anything similar in your asm file.  You might have it already just under a different label, like Z80_Kos (example).  IF you can't find it, then copy the code over instead.  Do this with the others.

 

Nope, Kos_Z80 doesn't exist in the HG disassembly or the Xenowhirl one I tried Z80_Kos you said and still nothing. Kos_Z80 was added during the guide inside of the unused subroutine to load the sound driver. So I guess I can delete it right?

And after that only 15 more and they come from the S1 Sound Driver.asm the guide told me to download.


s2.sounddriver.asm(2807)
> > >S1 Sound Driver.asm(5): error: symbol undefined
> > > SoundD0Index
> > > Go_SoundD0: dc.l SoundD0Index
> > >S1 Sound Driver.asm(30): error: symbol undefined
> > > Music81
> > > MusicIndex: dc.l Music81, Music82
> > >S1 Sound Driver.asm(31): error: symbol undefined
> > > Music83
> > > dc.l Music83, Music84
> > >S1 Sound Driver.asm(32): error: symbol undefined
> > > Music85
> > > dc.l Music85, Music86
> > >S1 Sound Driver.asm(33): error: symbol undefined
> > > Music87
> > > dc.l Music87, Music88
> > >S1 Sound Driver.asm(34): error: symbol undefined
> > > Music89
> > > dc.l Music89, Music8A
> > >S1 Sound Driver.asm(35): error: symbol undefined
> > > Music8B
> > > dc.l Music8B, Music8C
> > >S1 Sound Driver.asm(36): error: symbol undefined
> > > Music8D
> > > dc.l Music8D, Music8E
> > >S1 Sound Driver.asm(37): error: symbol undefined
> > > Music8F
> > > dc.l Music8F, Music90
> > >S1 Sound Driver.asm(38): error: symbol undefined
> > > Music91
> > > dc.l Music91, Music92
> > >S1 Sound Driver.asm(39): error: symbol undefined
> > > Music93
> > > dc.l Music93
> > >S1 Sound Driver.asm(79): error: symbol undefined
> > > loc_7g
> > > bne.w loc_7g
> > >S1 Sound Driver.asm(81): error: symbol undefined
> > > loc_71B9E
> > > bne.s loc_71B9E
S1 Sound Driver.asm(82)
> > >S1 Sound Driver.asm(82): error: symbol undefined
> > > sub_7
> > > jsr sub_7
> > >S1 Sound Driver.asm(82): warning: address is not properly aligned
> > > jsr sub_7
> > >S1 Sound Driver.asm(82): error: addressing mode not allowed here
> > > jsr sub_7
rom size is $200000 bytes (2048 kb). About $F15D6 bytes are padding.
s2.asm(88998)

So if Undefined Symbol means it doesn't exist but I don't know how to approch this. Would it involve editing the S2.asm or S1 Sound Driver.asm?

 

I think you should read this post. It should help you to fix all the errors.

 

Thanks it worked, but of course the sound effects are missing and the music is way off and the spindash crashes the game, but I can't download the clone driver for some reason. Can someone who has it send it to me?

Also will music that is written in Sonic 1 format still work?

 

Ah, sorry.  That was just me assuming it would be in one or the other =P

Yes, porting the S1 driver means you can use any SMPS files in S1 format.  This obviously means SMPS's in S2 or later format won't work, but are easily converted into S1 format with the handy tools to offer.

Obviously this means that the songs and that won't be as good as S3K's for example, but it's just miles easier to work with.

 

Ok but do you have the S2 Clone Driver? I tried to get it from Sonic Retro but I can't download it and even tried it with Internet Explorer.

 

I'm actually surprised that no one has asked that question yet.

I haven't found a valid link (where I don't need to register) of the S2 Clone Driver anywhere lately, but I found it on my HD a while ago.

Anyway, Sonic 2 Clone Driver_fixed.7z. "Fixed" means, that I fixed the bad pointer in soundEC.bin that caused the sound driver to crash.

I don't think the Sega sound plays properly though, the entry for it is obviously missing in the PCM_Table.

 

Thanks. Actually none of the music plays correctly and the level layout became slightly broken(random weird looking tiles appearing on the stage), sound effects don't work and the for the songs that actually do play they sound terrible and sometimes crashes the game but the spindash doesn't crash anymore.

I don't know what I did wrong and the same thing happened when I ported the Sonic 1 Sound Driver(except the spindash crashes the game).

 

Ohh, looks like you have the sound driver spilling over. Normally happened to me with corrupted sound effects (The joys of trial and error). Double check your set up of the driver. Worse comes to worse revert to a backup and try porting it again.

 

I don't know how basic this is, but I have questions...

I decided to use s3's mapping format in my hack. Little did I know it would totally break my hack for quite a few hours with a variety of apparently random visual glitches and errors (depending on the emulator used). I finally fixed all this but to be perfectly honest, I'm not sure why it went so wrong.

After long investigation and with the help of a glowing egg, the source of the glitches finally appeared (at this point, if you don't think "blablabla to the point dammit", you're probably really bored haha).

Anyway, it seems like the bug was caused by objects with a displaysprite but no mappings. You may think it's an heresy, but there had never been any problem about it before. Actually, it can happen with a mostly unmodified buzz bomber (or maybe the projectile, hard to tell).

Therefore, in buildsprites, I've had to add a check to make sure the object actually had a mapping and skip it otherwise.

Was there such a thing before? In which case I'd like to know because I probably broke it at some point. Or is there an explanation as to why it had never been a problem with s1's mappings in those cases?

Also, another question: While comparing the routines used to transfer the mappings with its s3 equivalent, I noticed this (this is the original not the one I modified):


sub_D762:
cmpi.b #$50,d5
beq.s @end
move.b (a1)+,d0
ext.w d0
add.w d2,d0
move.w d0,(a2)+
move.b (a1)+,(a2)+
addq.b #1,d5
move.b d5,(a2)+ ; save counter?
move.b (a1)+,d0
lsl.w #8,d0
move.b (a1)+,d0
add.w a3,d0
move.w d0,(a2)+
move.b (a1)+,d0
ext.w d0
add.w d3,d0
andi.w #$1FF,d0
bne.s @notnull
addq.w #1,d0
@notnull:
move.w d0,(a2)+
dbf d1,sub_D762
@end:
rts

Well, yes, it's hard to miss. It's the line with a comment.  Removing it (and increasing the address instead of course) will just make most sprites invisible.

But I don't understand why it's needed, especially when it looks like there's no such thing in s3 and unless I'm totally mistaken, this is the data being transferred to the vdp. :/

Or maybe it's done another way?

 

All I know is that if you port S3's mappings, you have to port S3's Render_sprites.  I have S3's render_sprites in S2R but not it's mappings (Had to do some mathmatical changes for it to work because I'm too lazy to change every single mapping into S3's format.  If you know an easy way to change all the mappings, let me know!).

I can take a look when I get home tonight, but it might be worth asking flamewing for a bit of help on this one as I got a bit of help from him.  He's ported both render_sprites and mappings format perfectly into S2Heroes.

 

Well, there is MappingsConverter...

 

Where the fuck?  Nice one!  Going to give this a go.  Cheers.

 

That line is necessary for linking sprites. D5 is used as a sprite counter throughout the BuildSprites routine, it's incremented by one once a new sprite is generated. The number is used to check for sprite overflow (to stop rendering sprites once 80 ($50) sprites were rendered), but, most importantly, during sprite generation, it always points to the next number of sprite in the VDP table, it is used to link the currently rendered sprite with the next sprite to render.

The format of the sprite entry in VDP is the following (in brief):


$00 w Y-position ($80 = top edge of screen)
$02 b Size field
$03 b Link field
$04 w Pattern field
$06 w X-position ($80 = left edge of screen)

Byte $3 must point the the number of next sprite in the table to process. If this field is zero, VDP stops fetching new sprites from the table.

Actually, you can program VDP to render sprites in the order you want. For example, you can process sprite $23 after the first sprite, if you put a corresponding number into the link field. In sprite $23, you can jump back and process sprite $01. You can even create loops, like processing some group of sprites all over again or endlessly rendering the same sprite (by putting its own ID into the link field). However, those tricks are useless. VDP stops sprite rendering, if 80 sprites were processed anyways.

Making use of the link field is a really low-level sprite programming. You can skip sprites you want wherever they are, without rebuilding the whole sprite table. However, games with a complex sprite system, games that use sprite mappings to create bigger sprites never use this model - they completely rebuild sprite table every frame and they link sprites one by one, without doing jumps within the sprite table.

 

@RHS & MainMemory: That's indeed what I used, though it looks like sonmaped doesn't like it (which is a minor issue, I can simply load the original s1 mapping and save it as s3 in

sonmaped when necessary). So keep a copy of your original mappings. Still a very good converter MainMemory.

Edit on this point: The mappings are actually fine, I had added s3map_ at the beginning of all labels to avoid duplicates, but MainMemory found it's actually the number in 2nd position that sonmaped doesn't like.

@Vladik: That's a very good thing to know, thanks. At first I thought it could be a kind of flag, so a 0 would have meant "stop here", but incrementing it didn't make sense. I guess s3 puts the counter there at a different moment.

By the way, I think I understood that bug with the objects with no mappings. It's probably obvious actually... If I'm not mistaken, address $00000000 is simply the beginning of the ROM, it contains 00FFFE00. So when s1 was loading a byte at $00000000 (no mappings = blank address = 0), it was a 0, therefore there was no sprite piece in the frame and the object was skipped. Since s3's mappings require to load a word, the game is loading 00FF from address 00000000, ie FF sprites with all the beginning of the ROM (beginning with the vectors) being used as mapping data, therefore the tons of visual glitches.

Well, that's what I think, I could be mistaken.

 

Ok I have a little issue with SonMapED. So recently I have been adding peelout sprites so far I have 6 of them as showen here



now when I add more tiles load the sprite into the tiles and save the art, mappings, and DPLC when I load the game the sprite is glitched as showen here



I made sure it wasn't that I missed saving anything by starting over on the sprite, but the same thing occurs. So my question is, could it be that I have too many sprite tiles that SonMaped can not keep them streight anymore when they are saved?

Edit: what I can tell is that it is getting my new sprite confused with the first sprite and loading the first sprites art with the wrong mapping and DPLCs