[MainMemory]

Just pushed a new "MapMacros" branch which converts all sprite mappings to my macros while preserving bit-perfect builds.

[KingofHarts]

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?

[flamewing]

(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.

[KingofHarts]

flamewing, on 27 August 2012 - 08:36 AM, said:

(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.

[flamewing]

In build.bat; you find this line:

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:

IF "%1"=="-pe" ( "win32/asw" -xx -c -q -A s2.asm ) ELSE "win32/asw" -xx -c -E -q -A s2.asm

[MainMemory]

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).

[MoDule]

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.

[MainMemory]

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.

[MoDule]

I guess I'd better hold off on it, for now. At least until someone has an idea on how to handle this.

[MainMemory]

Just merge your changes with the default branch, and maybe later I'll do the other two branches, since I made them.

[MoDule]

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?

[MainMemory]

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.

[KingofHarts]

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.)

[MainMemory]

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?

This post has been edited by MainMemory: 22 April 2013 - 10:20 AM

[KingofHarts]

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?