[Spanner]

*bump*
Okay, I was thinking, wouldn't it be better if variables were used for the sounds? It would save issues for example, let's say you ported the Sonic 3 Sound Driver to S1. It may be unpopular due to how it works but sounds are practically everywhere and using variables in place of the audio $** request would probably be better. For example:

Syntax Highlighted Code: ASM

audio [color= #ff0000;]$[/color][color= #ff0000;]8C[/color]

Would become:

Syntax Highlighted Code: ASM

audio Music_Boss

And if you wanted to change the music:

Syntax Highlighted Code: ASM

Music_Boss = [color= #ff0000;]$[/color][color= #ff0000;]8C[/color] [color= #adadad; font-style: italic;]; change the $** to another music ID[/color]

Just saying.

This post has been edited by SOTI: 05 February 2009 - 06:35 PM

[FraGag]

I've implemented this in the Sonic 2 disassembly (in a more clever way, even, similar to how object IDs are currently defined) and it would indeed be a nice addition for this disassembly.

[Spanner]

It was in the Sonic 2 Split Disassembly, which was the inspiration for my post. Still, variables and equates are useful as long as you don't get over the top with them.

[Hivebrain]

I will be doing this soon. IDs would be defined more like this though:

Syntax Highlighted Code: ASM

bgm_Boss:[color= #00CC66;] equ[/color] (ptr_Music_Boss-Music_Index)/[color= #ff0000;]4[/color]

That's how I've been doing other IDs. Palette scripts and PLCs could probably do with being IDed as well.

[Sik]

The Sonic 3D disasm also has this kind of IDs too - especially since the SFX ones aren't so obvious as you have to add $32 from what appears in the Sound Test =/

[JoseTB]

Took a quick look on the project, just out of curiosity. I like the direction it's taking so far, but some suggestions for the variable naming:

Quote

v_scrolltable: = $FFFFCC00 ; scrolling table data ($400 bytes)
v_sprites: = $FFFFF800 ; sprite table ($200 bytes)

I would rename these to v_hscrolltablebuffer and v_spritetablebuffer, since they aren't the actual sprite table or hscroll table data, but a mirror that is copied, I think once every frame, during the vsync, I don't fully remember the details.

Quote

v_anglebuffer: = $FFFFF768 ; angle of collision block that Sonic or object is standing on

I would change this to the following since it's not entirely correct:

Quote

v_anglehotspot_r: = $FFFFF768 ; Sonic's rightmost hotspot angle
v_anglehotspot_l: = $FFFFF76A ; Sonic's leftmost hotspot angle

Aditionally I'm gonna suggest to use another prefix after the "variable" or "flag" identifier for the "environment" in which the variable is used. For instance: v_level_rings, v_camera_screenposx, v_snd_fm1_ptr, v_pal_fadestart - you get the idea. Also, the prefix "v" for "value" could be extended to specify the variable length (b, w, l, or array)

[NeKit]

Looks like I have found a bug. When time is 9 minutes, and you have more than 0 rings, the time counter label doesn't swap red/yellow colors, it just stays yellow.

This post has been edited by NeKit: 29 June 2009 - 05:37 PM

[Alriightyman]

I just had to comment on something. Having played around with this disassembly, the only thing I find annoying, as of now, is with mappings. For those of us who use SonMapEd, you would get an error for replacing them and would have to re-add the label to it in the included file. In the old disassembly, they were labeled then included. I think it would be better if it were the other way around. Just a thought though. Other than that, I really like the way this is headed.

[Spanner]

Okay, what pisses me off with this disassembly is that previous labels aren't referenced. If possible, could a list be added to the disassembly containing the original 2005 labels and the current ones. You could also contribute to the SCHG:Equivalent Subroutines.

[Hivebrain]

Took a quick look on the project, just out of curiosity. I like the direction it's taking so far, but some suggestions for the variable naming

Thanks. I'll make those changes in my next update.

I just had to comment on something. Having played around with this disassembly, the only thing I find annoying, as of now, is with mappings. For those of us who use SonMapEd, you would get an error for replacing them and would have to re-add the label to it in the included file. In the old disassembly, they were labeled then included. I think it would be better if it were the other way around. Just a thought though. Other than that, I really like the way this is headed.

I thought about that, but I'm not keen on adding lots of extraneous labels. Maybe we could beg Xenowhirl to make a version that preserves labels.

Okay, what pisses me off with this disassembly is that previous labels aren't referenced. If possible, could a list be added to the disassembly containing the original 2005 labels and the current ones. You could also contribute to the SCHG:Equivalent Subroutines.

Many labels were changed because they were inaccurate, unhelpful or just plain wrong. I've no intention of putting them back. However, I will add labels from the latest S2 disassembly.

[Andlabs]

Question: why is the asm68k error log redirected to errors.txt? Logging errors to a file doesn't show anything on the console (not even an "assembly failed with errors; see error.txt for details" message), and there's no error checking in the build.bat file, so I can never be sure unless I cat error.txt each time to make sure it built right.

This post has been edited by Andlabs: 12 April 2010 - 11:40 PM

[Hivebrain]

Question: why is the asm68k error log redirected to errors.txt? Logging errors to a file doesn't show anything on the console (not even an "assembly failed with errors; see error.txt for details" message), and there's no error checking in the build.bat file, so I can never be sure unless I cat error.txt each time to make sure it built right.

I find errors.txt extremely useful. What's the alternative?

[Andlabs]

I can see how errors.txt is useful, but the problem is that when you have it on, asm68k doesn't report anything to the console, and there's no error checking so the rest of the batch file runs, so you'll never know whether or not the build succeeded until you play your ROM, realize it didn't change, then check errors.txt. If we could do something like

CODE

asm68k blah blah blah
if errorlevel 1 goto error
rem rest of stuff
goto end
:error
echo build failed; see errors.txt for details
:end

this problem would go away.

[FraGag]

Or just add

CODE

type errors.txt

[Oerg866]

While doing some bits here and there for my SMPS player, I came across this code snippet:

CODE

word_72790:     dc.w $25E, $284, $2AB, $2D3, $2FE, $32D, $35C, $38F, $3C5
                dc.w $3FF, $43C, $47C, $A5E, $A84, $AAB, $AD3, $AFE, $B2D
                dc.w $B5C, $B8F, $BC5, $BFF, $C3C, $C7C, $125E, $1284
                dc.w $12AB, $12D3, $12FE, $132D, $135C, $138F, $13C5, $13FF
                dc.w $143C, $147C, $1A5E, $1A84, $1AAB, $1AD3, $1AFE, $1B2D
                dc.w $1B5C, $1B8F, $1BC5, $1BFF, $1C3C, $1C7C, $225E, $2284
                dc.w $22AB, $22D3, $22FE, $232D, $235C, $238F, $23C5, $23FF
                dc.w $243C, $247C, $2A5E, $2A84, $2AAB, $2AD3, $2AFE, $2B2D
                dc.w $2B5C, $2B8F, $2BC5, $2BFF, $2C3C, $2C7C, $325E, $3284
                dc.w $32AB, $32D3, $32FE, $332D, $335C, $338F, $33C5, $33FF
                dc.w $343C, $347C, $3A5E, $3A84, $3AAB, $3AD3, $3AFE, $3B2D
                dc.w $3B5C, $3B8F, $3BC5, $3BFF, $3C3C, $3C7C

I noticed something similar. Then I looked and... It's the FM note values present in the RAM. I've made a little table:

CODE

025e = (b-0)

0284 = c-1
02ab = c#1
02d3 = d-1
02fe = d#1
032d = e-1
035c = f-1
038f = f#1
03c5 = g-1
03ff = g#1
043C = a-1
047C = a#1
0A5E = b-1

0a84 = c-2
0aab = c#2
0ad3 = d-2
0afe = d#2
0b2d = e-2
0b5c = f-2
0b8f = f#2
0bc5 = g-2
0bff = g#2
0c3c = a-2
0c7c = a#2
125e = b-2

1284 = c-3
12ab = c#3
12d3 = d-3
12fe = d#3
132d = e-3
135c = f-3
138f = f#3
13c5 = g-3
13ff = g#3
143C = a-3
147C = a#3
1A5E = b-3

1a84 = c-4
1aab = c#4
1ad3 = d-4
1afe = d#4
1b2d = e-4
1b5c = f-4
1b8f = f#4
1bc5 = g-4
1bff = g#4
1c3c = a-4
1c7c = a#4
225e = b-4

2284 = c-5
22ab = c#5
22d3 = d-5
22fe = d#5
232d = e-5
235c = f-5
238f = f#5
23c5 = g-5
23ff = g#5
243C = a-5
247C = a#5
2A5E = b-5

2a84 = c-6
2aab = c#6
2ad3 = d-6
2afe = d#6
2b2d = e-6
2b5c = f-6
2b8f = f#6
2bc5 = g-6
2bff = g#6
2c3c = a-6
2c7c = a#6
325e = b-6

3284 = c-7
32ab = c#7
32d3 = d-7
32fe = d#7
332d = e-7
335c = f-7
338f = f#7
33c5 = g-7
33ff = g#7
343C = a-7
347C = a#7
3A5E = b-7

3a84 = c-8
3aab = c#8
3ad3 = d-8
3afe = d#8
3b2d = e-8
3b5c = f-8
3b8f = f#8
3bc5 = g-8
3bff = g#8
3c3c = a-8
3c7c = a#8