[shobiz]

FraGag, on Oct 8 2008, 06:33 PM, said:

shobiz, the 15 characters limit comes from IDA, who suggests this by default, although it can be turned off.

Oh, you meant that, I thought it was either a guideline or a technical restriction we were following. Though yeah, it's possible to have much longer names in IDA, I even have a 50 character long name (Obj_LightningNullifiedInvisibleHurtBlockHorizontal).

FraGag, on Oct 8 2008, 06:33 PM, said:

Also, when replacing labels like "loc_ABC" to temporary symbols, should we really keep the old label? I know some guides reference a few of them, so it may be a bit difficult to determine if some label should be kept or not.

It's a bit of a slippery slope, but IMO it has the potential to clutter up the code quite a bit, so I feel we shouldn't.

FraGag, on Oct 8 2008, 06:33 PM, said:

Maybe we could use more temporary symbols? Nameless temporary symbols are already used, but maybe we could try using named temporary symbols in large blocks of code like objects, where some labels are only referenced within that object, but using nameless temporary symbols wouldn't work.

I really like the idea, but I believe you'd have to use a code section to achieve that effect, since, to quote the AS manual,

Quote

When a temporary symbol is defined or referenced, both leading dollar signs are discarded and the counter's current value is appended. This way, one regains the used symbol names with every definition of a non-temporary symbol - but you also cannot reach the previously symbols any more!

EDIT: On a different note, is it really necessary to have the original hex form of the command as a comment after almost each instance of the vdpComm function? I believe it was qiuu who added them, but I think they're pretty pointless since the point of that function is to save people the trouble of using that syntax.

This post has been edited by shobiz: 08 October 2008 - 10:56 AM

[qiuu]

shobiz, on Oct 8 2008, 05:02 PM, said:

[...] EDIT: On a different note, is it really necessary to have the original hex form of the command as a comment after almost each instance of the vdpComm function? I believe it was qiuu who added them, but I think they're pretty pointless since the point of that function is to save people the trouble of using that syntax.

I had added the vdpComm replacements to an older version of the disassembly the evening before they were uploaded by someone else (not sure by whom), but was without internet back then. I had done these changes manually so I left the original values commented there just in case I screwed something up.
As both my older non-uploaded disassembly as well as the new one online the next day had made some changes the other hadn't, I sort of merged them together leaving the comments from my version.
So yeah, I can simply remove them again.

As for the object labels, I'm pretty indifferent on this. Advantage of leaving the number perhaps is that Obj##_ can easily be added in front of object specific subroutines, while adding the object name would make these somewhat lengthy.
I also think some of my label names are longer than 15 characters, my use of abbreviations is also somewhat inconsistent as well, (like LevelSelect vs. LevSel, or abbreviating Horizontal with Hztl and Vertical with Vrtc). I guess it would be good for consistency's sake to decide on which abbreviations to use.

This post has been edited by qiuu: 08 October 2008 - 12:08 PM

[shobiz]

qiuu, on Oct 8 2008, 11:07 PM, said:

I had added the vdpComm replacements to an older version of the disassembly the evening before they were uploaded by someone else (not sure by whom), but was without internet back then. I had done these changes manually so I left the original values commented there just in case I screwed something up.
As both my older non-uploaded disassembly as well as the new one online the next day had made some changes the other hadn't, I sort of merged them together leaving the comments from my version.
So yeah, I can simply remove them again.

Ah, I see. I'll mass-replace them by regular expression then.

Update: Done.

qiuu, on Oct 8 2008, 11:07 PM, said:

I guess it would be good for consistency's sake to decide on which abbreviations to use.

Agree completely, it would make coming up with new names a lot easier as well.

[Sik]

ICEknight, on Oct 8 2008, 12:07 PM, said:

shobiz, on Oct 7 2008, 04:26 AM, said:

I agree, though I'd prefer ObjSonic or Obj_Sonic over just Sonic.

Or obj01_Sonic, so you don't have to look for its object number somewhere else?

Also, having the object number in there will allow to put certain objects as obj45_unk, obj46_unk, etc, when they're unknown, without reusing the same name.

I'd use the object name for known objects and "Obj##" or "ObjUnknown##" for unknown ones, and leave the usage of both only when there's a name conflict =P

[FraGag]

ICEknight, on Oct 8 2008, 10:07 AM, said:

shobiz, on Oct 7 2008, 04:26 AM, said:

I agree, though I'd prefer ObjSonic or Obj_Sonic over just Sonic.

Or obj01_Sonic, so you don't have to look for its object number somewhere else?

Why should we care about object IDs? The original IDs are still in comments in the dynamic ID declarations in s2.constants.asm. The point of the dynamic IDs is that you can completely remove several useless objects in a hack and still have the game reference the correct objects (the object layouts would have to be changed, but I couldn't make them use the dynamic IDs and make them usable in SonED2 at the same time).

Sik, on Oct 8 2008, 01:19 PM, said:

I'd use the object name for known objects and "Obj##" or "ObjUnknown##" for unknown ones, and leave the usage of both only when there's a name conflict =P

I pretty much identified every object; the entries in Obj_Index without a name are most probably not used at all in the game; I also inspected the object layouts using a small program I made, but I may have missed some. Anyway, it's probably not very important to work on those unused objects. (The only objects marked as unknown are $AB and $BB.)

About the routine names and such, I thought we could make a function/macro to prepend the name of an object (stored in a global variable) when declaring a label inside an object's code.

shobiz, on Oct 8 2008, 01:15 PM, said:

qiuu, on Oct 8 2008, 11:07 PM, said:

I guess it would be good for consistency's sake to decide on which abbreviations to use.

Agree completely, it would make coming up with new names a lot easier as well.

If we have a list of "standard" abbreviations somewhere, I'm fine with that.

[Spanner]

Small request if possible, since the 2P zone names, Options screen text and the credits text can be changed easily in the asm file, would you be able to implement a system for the Level Select text?

[shobiz]

FraGag, on Oct 10 2008, 10:21 PM, said:

About the routine names and such, I thought we could make a function/macro to prepend the name of an object (stored in a global variable) when declaring a label inside an object's code.

That could be potentially confusing for someone just glancing over the code though.

FraGag, on Oct 10 2008, 10:21 PM, said:

If we have a list of "standard" abbreviations somewhere, I'm fine with that.

Apart from that, if we could also agree on some sorta common name templates that'd be good. For example, Xenowhirl uses XXX_SwitchTbl, XXX_States, XXX_subtbl, and possibly others for jump tables, while Hive just uses XXX_Index for everything. I personally like Hive's system more.

SOTI, on Oct 10 2008, 10:44 PM, said:

Small request if possible, since the 2P zone names, Options screen text and the credits text can be changed easily in the asm file, would you be able to implement a system for the Level Select text?

It is possible, but it'd be very hard to do since the text is stored as an Enigma-compressed plane map. It's probably a better idea to have an external program which can uncompress the plane map, convert it to text form, and then re-convert the edited text file back.

[nineko]

[shobiz]

[Overlord]

STE can do it too.


....just only for the original ROM =P

[qiuu]

shobiz, on Oct 8 2008, 05:02 PM, said:

[...]

FraGag, on Oct 8 2008, 06:33 PM, said:

Also, when replacing labels like "loc_ABC" to temporary symbols, should we really keep the old label? I know some guides reference a few of them, so it may be a bit difficult to determine if some label should be kept or not.

It's a bit of a slippery slope, but IMO it has the potential to clutter up the code quite a bit, so I feel we shouldn't.[...]

I agree, for nameless temporary symbols, it is cleaner not to keep the old label.

shobiz, on Oct 10 2008, 06:58 PM, said:

Apart from that, if we could also agree on some sorta common name templates that'd be good. For example, Xenowhirl uses XXX_SwitchTbl, XXX_States, XXX_subtbl, and possibly others for jump tables, while Hive just uses XXX_Index for everything. I personally like Hive's system more.

A few times JmpTbl_ is used as prefix.

Even though it might be useful to easily distinguish between jump tables and data pointers, I guess it's best to simply use _Index as suffix.

nineko, on Oct 10 2008, 07:00 PM, said:

I once wrote a Sonic 2 Level Select Text editor for R.Solaris, it was intended to stay private, right now it's crappy as hell, but if there is popular demand I can clean it up a bit and release it, I guess:
[...]

Now that looks interesting. Does it support different plane sizes (I.e. not only 40*28)?
Also like the existence of the option "show pure hex". Feeding it with 8x8 tiles and displaying these would be a bit too much to ask I guess though...

[nineko]

[Hivebrain]

It's possible to have a macro convert nonstandard text strings from ascii.

I've dropped the "Obj01_" prefixes from Sonic 1. The only reference to object numbers I've left is in the names of the object asm files (and the object layout itself, which can't easily be changed).

[shobiz]

Hivebrain, on Oct 11 2008, 04:35 AM, said:

It's possible to have a macro convert nonstandard text strings from ascii.

Yeah, and it's done a lot of places already in the disasm (off the top of my head, intro text, credits text, 2P zone names, options text, title card letter selection text). The problem here is that the data is being compressed after conversion, so implementing it in the disasm itself would probably require modification of s2p2bin, similar to what Xeno had to do to get the sound driver working.

Hivebrain, on Oct 11 2008, 04:35 AM, said:

I've dropped the "Obj01_" prefixes from Sonic 1. The only reference to object numbers I've left is in the names of the object asm files (and the object layout itself, which can't easily be changed).

Speaking of this, any chance of posting some of the new labels from your S1 disasm, so we can get an idea of what sort of names you've been using?

[Puto]

shobiz, on Oct 11 2008, 08:29 AM, said:

Hivebrain, on Oct 11 2008, 04:35 AM, said:

It's possible to have a macro convert nonstandard text strings from ascii.

Yeah, and it's done a lot of places already in the disasm (off the top of my head, intro text, credits text, 2P zone names, options text, title card letter selection text). The problem here is that the data is being compressed after conversion, so implementing it in the disasm itself would probably require modification of s2p2bin, similar to what Xeno had to do to get the sound driver working.

Or you could put it in a separate file, and in build.bat, assemble it separately, compress it, and incbin/binclude it.