I've no idea about the AS assembler, but why are those temporary labels starting with a $$? I always thought they start with @.
I'll assume that this is a feature in a later build of AS which the SVN disasm uses. The 2007 disasm gives off errors when used. In any case, would it be possible to have an equate which turns $$ into @, therefore labels could be @something instead of $$something?
The label name generated by AS is different between the passes. In the listing, I see ENOUGHBITS1107 and ENOUGHBITS1574, as well as MASKVALUE1107 and MASKVALUE1574 (the numbers may differ as I have some uncommitted changes). I get errors saying that enoughBits1574 and justEnough1574 are undefined. From the AS User's Manual: It seems that 467 more symbols are defined in the second pass. I don't know which ones though. I'm sure SOTI would be pleased to learn that it's caused by my wizardry in the RAM declarations. :P Also, SOTI, there's no way to change the syntax for named temporary symbols in AS. Equates wouldn't work because they don't just do text replacement (like, e.g., the C preprocessor), they must have a value like an integer, a floating-point number or a string.
Wait, so if you declare RAM variables using equates instead of phase it works fine? How odd. I've changed them to nameless temporary symbols for the time being.
I've committed project files for SonED2 v11.02.24 that match the directory structure of the disassembly in revision 267 and revision 268. <a href='index.php?act=findpost&pid=562504'>The warnings I made regarding starting positions in Sonic 1</a> also apply here.
After looking through S3K's new Split, I really like the file structure. Should this structure be added to the SVN S2 version? I think it would help make things easier to find.
I think it would be good, but you would have to change the ASM, SonED2 projects, S2LVL INIs, and tutorials that reference files. AFAIK the SVN version still has all the same filenames as the 2007 disassembly.
Just pushed a new "MapMacros" branch which converts all sprite mappings to my macros while preserving bit-perfect builds.
I have a question about this. I just recently (as in last night) started moving the objects code from s2.asm into their own individual .asm's in an "objects" folder. I have placed the "includes" and all that stuff, and everything is rebuilding and working just fine. Now you ask, why did I do such a thing... what is the point? WELL... I did it because I love how the Sonic 1 disassembly is split up, as its easier to work with, and I wanted to emulate this in Sonic 2. Now, I have TWO questions regarding this: 1. Is it bad to rearrange the order of the code? Like, if I put all the object code in hexadecimal order in the s2 asm file? Does this do anything wrong or bad? I assume it would since the order in the asm is the order it is built in the ROM, and messing with that can have bad effects... But maybe I'm mistaken? I've left the order alone for now... 2. When splitting the object code, and building, it doesn't display on the prompt window as just the objects folder, much like it would for something like the mappings folder or something else... it shows EVERY SINGLE asm individually. I have noticed NO slowdown, but that irks me and I wanna fix this. How would one go about doing this?
(1) Rearranging the order of the code will not result in a bit-perfect build. For the repository, this is not good. In general, the repository version is well enough disassembled that changing the order of stuff is unlikely to result in bad results; there may yet be a couple spots where there could be trouble, though, so you can do it for a hack without too many worries. (2) You have to use -q on the AS invocation.
Stupid question alert... This is in as.msg, right? Just wanna make sure before I mess with stuff that I really don't know what to do with.
In build.bat; you find this line: Code (Text): IF "%1"=="-pe" ( "win32/asw" -xx -c -A s2.asm ) ELSE "win32/asw" -xx -c -E -q -A s2.asm and add -q like this: Code (Text): IF "%1"=="-pe" ( "win32/asw" -xx -c -q -A s2.asm ) ELSE "win32/asw" -xx -c -E -q -A s2.asm
Another new branch, "ObjectMacros" (branched from MapMacros branch), which converts all object/ring/bumper layout files to macros, using ObjID constants. Hivebrain gave me the idea. In all likelihood, no level editor is going to be able to support editing these, due to the difficulty in retrieving the ObjID constants' values, unless I require the user to provide a pre-made list (extracting IDs from AS' MAP file is easy enough).
Oh God, I've been out of this for way too long. I've got a 7 month old changeset still sitting around. So about those branches, is it enough to merge my stuff with the default branch, or do I need to merge it with both branches? I don't think I've ever dealt with branches before, and it's been ages.
I always made my changes to both branches before, but now that there's three, it's getting kind of complicated. I don't know.
I guess I'd better hold off on it, for now. At least until someone has an idea on how to handle this.
Just merge your changes with the default branch, and maybe later I'll do the other two branches, since I made them.