Alright, done (at least, I hope). I do wonder what the best way to handle branches like this is? I'd imagine, in most cases changes to the default branch shouldn't conflict with the other branches, so merging should be OK. About the "ObjectMacros" branch: personally, I think it's a great idea. If an editor supported this, it would allow you to rearrange the object IDs, right? It would even let you have individual object listings per zone or something similar. Doesn't Sonic CD do this?
I'll give merging a try and see what happens. If nothing else I can continue to manually merge changes like I have been. As I said above, the problem with the macros is that there is no way to get the value of ObjID constants without assembling at least the object list and constants file, unless I could add a string based ID to SonLVL, which would require a much more strict ASM parser, because currently all unknown symbols are replaced with 0. Sonic CD does have different object lists in each Round, Sonic 3 & Knuckles has two object lists, depending on zone, and my Sonic 2 Lockon POC uses a two-tier object list, with the first half for common objects and the second half varying by zone.
Been doing some extensive testing with Triad, and came across a couple of things that I wanted to point out with regards to the art, and where the files are located. One of these is more of a question. 1. The Special Stage art that is located in the Kosinski folder. If I wanted to load and/or edit the art tiles themselves, what should I do in order to do this? I did a search for Special Stage art, and found stuff about editing Sonic's Special Stage art being a pain in the ass, due to the DPLC's. I'm just talking about editing the 8x8 tiles for the stages themselves. How can I edit that? 2. The file 1P and 2P wins text from 2P mode.bin is located in the nemesis art folder, though it is uncompressed art. If someone could please make a change to the disassembly to fix this error, would be lovely. (I lack write access, and don't know of everything that needs to be done to make such a change.)
I still think the folder structure should be changed to something more like the Sonic & Knuckles disassembly's. It's just that doing that effectively creates a third version (2007, old Hg, new Hg) that tools and guides have to support... But yeah, I'll move the art file. Edit: um, it doesn't look uncompressed to me... YY-CHR shows a bunch of random pixels. Perhaps you decompressed it and forgot?
Just downloaded a fresh copy of the disassembly and am getting that they are Nemesis compressed... Odd, every other copy I had was giving me problems... perhaps I just really screwed the pooch with my old copies and didn't realize it. Yea. My bad on that one... Any suggestions about the Special Stage art tiles?
So, I've just made some modifications to the disassembly that would give users the option to use macros for the title card mappings, allowing them to simply type the level's name as a string. However, these macros cannot exactly duplicate the original mappings, and it makes editing other parts of the mappings a bit difficult, so I thought I would get your opinions before I commit it. Here's a diff file for the latest revision b33615dd25a9 of the disassembly. Just to be clear, the original mappings are still there, and are enabled by default, so chkbitperfect.bat still returns no differences. Edit: should mention it requires SpritePiece.asm from the MapMacros branch in order to build.
As long as the original mappings are allowed to be used I don't see a problem with it. Though there is one part that bothers me. Can we see a comparison image of the original and the Macro version? depending on how that impacts the appearance, I may well be against it.
I'm not sure if it's in line with the project's philosophy to include something that can make the build non-bit-perfect, even if it's optional. I could be wrong, though. The feature does sound useful, so why not turn it into a guide, instead?
I dunno, I actually think it looks alright; the alignment issue isn't that bad. Maybe it could be tweaked slightly to fix it? Either way, I think it's fine, I'd use it. While the end result isn't "bit perfect" to Sonic 2, neither is a complete hack, and that's what this ASM is geared to, hacking.
That is well and good, but one of the main goals towards this ASM is also retaining a bit-perfect build.
There are already options in the disassembly that aren't bit-perfect: optimizing 0(aN) to (aN), extending the water table to encompass all zones, disabling the checksum check...
Then there should be no issue with making your macro an optional addition, then. I suppose? I'd personally prefer to use something like this over the original method...
Since I've already merged REV00 and REV02 into the disassembly, should I look into merging Knuckles in Sonic 2? Personally, I'm leaning less towards a toggle, like REV00/REV02, and more towards a branch, if only because of how major KiS2's changes are (the removal of just about all art, switching to S3K's mapping format, Knuckles). I'd rather it not be in a separate repository, so it can still be synced with S2 (though, I might be misunderstanding how Git works, here). I would still like a way to point out the differences from S2REV02, for the sake of documentation, maybe through comments containing a keyword like 'KiS2'. The disasm may also need some prominent labelling, to point out that it only produces the UPMEM, so people don't get confused and complain about the lack of SonLVL/SonED2 files, or that the assembled file doesn't work in emulators... though, I suppose a batch/python script can be provided along with S2+S&K's ROMs, which would build into an actual working copy of KiS2. Anyway, thoughts?
How would you handle things like reshuffled code and variables (remember, the level select flag in S2 is the demo flag in KiS2)? I wouldn't necessarily be opposed to adding some of the modifications KiS2 has into the disassembly as options, but I don't know if you can make a disassembly that can build S2 or KiS2 and have it make any sense to look at.
That's why I'd prefer a branch, so one can be 'just S2', while the other is 'just KiS2'. Shuffling the RAM for S2REV02 while making it toggleable was an ugly mess I'd rather avoid getting into again.
Speaking of shuffling RAM... I compared Sonic Classics' version of S1 to the usual S1 REV00, and I think it's safe to say there are some properties of Classics we can safely set apart from S2REV02. First up, Classics' S1 has no checksum code, its RAM is arranged differently, and it writes 'SEGA' to FFFFFFE4. The copy of S2 in Classics does all of this, too. I'm thinking of removing these from gameRevision 2, to get as accurate a version of S2REV02 as possible. On a similar note, ErrorTrap is different in Classics: Code (ASM): if gameRevision<2 ErrorTrap: nop nop bra.s ErrorTrap else ; REV02 ErrorTrap: bra.s ErrorTrap nop bra.s ErrorTrap endif I don't think this was a part of S2REV02; I'm certain S3 was based on S2REV02 (it has the JmpTos removed), and it uses the old ErrorTrap. Based on that, I'm thinking of giving this one the sack as well. I think I might start crossposting these as issues on GitHub.
