Sonic Retro on GitHub

I think it's fine to have diverging branches. Also, I updated the MapMacros and AS branches against master.

 

I've done some more research on this and I'm beginning to think it was the rebase command I was looking for. I've read that the merge command by nature creates an additional commit, which is what I was trying to avoid.

 

We should not use rebase here. Rebasing a published branch is highly discouraged, because rebasing recreates the commits on the branch, and pulling a rebased branch tries to merge the old commits with the new commits by default (pull --rebase might get confused too). If you made local changes on a branch and some commits were pushed to the branch on the public repo before you got to pushing your local changes, rebasing your local branch is a good idea (it keeps the history linear). But for a published branch, it's easier for everyone to avoid rebasing.

 

Bump. As of the latest commit, the AS Sonic 1 branch is now producing bit-perfect REV01 builds. The REV01-only code has a bunch of branches with undefined sizes. It seems that asm68k doesn't give them any thought and automatically makes them word-sized, while AS optimises a few of them to byte-sized, causing differences in the built ROM that we don't want.

I fixed that, but still managed to mess it up. I'm just gonna use Git Shell from now on, that other program, the GUI thing, managed to not check for the whole 'MERGE_MODE' thing, and pushed it as a separate commit. Dammit.
Making real good use of my Techie privileges aren't I? :v:

 

There appears to be a problem with S1's AS branch's p2bin.exe. It gives 'Overlapping Memory Allocation' errors when zero-offset optimisations are disabled, likely to do with the org usage in insn1op and insn2op. Replacing the branch's bundled p2bin.exe with the S2 disasm's s2p2bin.exe stops the warnings from appearing. I have little to no understanding of the build process, but to me it seems that there's some kind of workaround or exception for the zero-offset optimisations in s2p2bin.exe that p2bin.exe lacks.

If anyone with the right know-how can implement the feature into p2bin.exe, then the build process can be made a bit nicer: Right now, I can't get build.bat to output an error log because every build would be interrupted and stopped because of these warnings.

 

Er, okay, how about this? I don't speak this language (C++?), not at all, but I copied a block of code from s3p2bin.cpp and it seems to work.

 

Something needs to be done about the zonewarning macro. Its constant outputting of warnings continues to mess with the log output. I could disable the build halt in build.bat when a log file is detected, but I'm thinking of something more direct. That macro's annoying: it hides all of the real errors in a sea of ohnotheendingisntproperlyimplemented, and I've seen it confuse and even drive away Hivebrain users looking to migrate. I can't think of any fixes that aren't hackish and/or completely miss the point of the macro (have a flag for if the list is meant to contain the ending, that stuff).

While I'm at it, the music and sfx macros are almost pointless too. There only exist ones for jsr/jmp, not bsr/bra or even ones for if the move is a byte... Then again, I think I can repurpose those so that a variable at the top of sonic.asm can optimise them all. I think I can cover those macros.

So, any ideas on tackling this zonewarning over-warning problem?

 

Yes, that's probably the best way. It's just, the macro's there to tell you when something doesn't support all 7 zones, but the thing is that that's always going to be the case, unless you were to revamp the ending.

music and sfx macros have been expanded. Their usage isn't as simple anymore since you can't leave any arguments undefined. I dunno, it was going to happen eventually. It's a macro, all it'd do is make usage more complicated with the upside being batch modification. Speaking of which, an optimisation is in place. It's nothing too great, I don't know how to calculate when to use a branch over a jump through a macro (especially asm68k macros), so the only optimisation there is to force all moves to use byte-sized operands. I would say that since the input is always 8 bits, moveq would be appropriate, but apparently it sign extends the byte to a long. By default, all sound IDs are $80+ so that 8th bit would be set... In my testing, moveq had no negative effects, but I'd rather play it safe. I still don't know if, when d0 is moved to RAM, the sign bit is moved back into the byte space.

Thinking back to it, the usage of move.b may be in vain: It seems that the execution times of a move.w and a move.b are the same, and the size doesn't differ, either. I probably shouldn't have doubted Regen and stuck with moveq.

 

Since the disassemblies page lists it among other non-historical disassemblies, would it be right for there to be an up-to-date GitHub Project Two-Eight branch of the S1 disasm? The official one that's hosted on info.sonicretro is based on the historical Hivebrain disasm, and contains a major bug/oversight in which the good ending doesn't have the layout change when the emeralds vanish. I'm not talking Kraminator Special or anything like that, just the conversion to the 128x128 chunk system.

I've already created a Two-Eight disasm based on a newer copy of the Git disasm, and it seems to be too extensive to just cram into a guide. It probably could be done but... it sounds like it would be one of those pain-in-the-ass guides that you'd have to follow every time you start with a fresh disasm.

On a similar topic, again about the S1 disasm, what should be done if someone wants a MapMacros disasm using the AS Macro Assembler? Should there be a branch that combines the two, or is there an easy way for the user to merge the features themselves?

 

Holy cow, finally! The fustercluck that is Git Project Sonic 1: Two-Eight is complete. It's hard to evaluate your changes when the changelog alone is a small book! The branch's name is big and clunky, but I preferred it to be descriptive instead of brief, though I won't stop any changes to it.

Rambling:
It's based on the master (asm68k) branch, at least until hybrid branches become a thing.
There was a bug mentioned here that existed in both the original Two-Eight and King's updated version, but it's been fixed in this one. The cause was dodgy object definitions for the path-switchers at the height of the loops (they're meant to be ground-only but weren't).
Code has been optimised from the original Hivebrain-based source in several areas.
The path-switchers have had a feature added from the S2 betas: With the debug cheat enabled, the path-switchers are visible (using ring graphics) and, when crossed, play the checkpoint sound. It really is a practical feature! It's strange that it was took out in the first place.
The original Two-Eights missed some areas when it comes to dynamically modified layouts: The LZ splash object checks for if the LZ3 layout has been modified, and the good ending attempts to modify two 256x256 chunks. These instances have been fixed.
SonLVL and SonED2 (non-v1.0x) compatibility is there. v1.0x didn't seem to have a mix-and-match format system, so I couldn't make that work. Both programs can modify the good ending (post-emerald vanish) and LZ3 (when the wall is gone).
SYZ's background is a little messed up. The number of chunks had to be reduced, and the background took a blow because of that. This has been a problem since the original Two-Eight. Both REV00 and REV01 now use the same background layout.

 

A revision toggle has been added to the S2 disasm. Now both REV01 and REV00 can be built.

The build.bat file has been modified to produce a ROM even if there are warnings. This is because REV00 causes one by default, making it otherwise unbuildable.

 

Little late in saying this: Sonic 2's disasm can now build REV02. A bunch of additional toggles have been added to make this work, most of which are linked to the allOptimizations option, because who wouldn't want to get rid of those awful JmpTos?

Currently, these optimisations are limited to how well they were done in REV02, and could stand to be improved, while allowing the inferior REV02 way for bit-perfection reasons. For example, REV02 tries to optimise as many add/subs to addq/subq as possible, but misses a few. The same applies to the JmpTo removal.

 

Somewhat of an odd question but I'm curious; if it can now build REV02, does this include the broken Wing Fortress Zone rising/falling staircase platforms that, for some reason, were broken in REV02, but not REV00 or REV01? This is the only new issue I can think of right now that arose between them.