Minor thing I wanted to bring up, which goes without saying for those of us that are into compsci, however this is for those not so techy folks (or those who only have experience with ROM hacking): The OBJ folder found in the Feb '90 footage doesn't contain assets for objects as you may think like rings, or enemies, or what have you, Sonic 1's source code calls these actors. Instead it contains .o files, the results of the assembler building the code. These .o files then get linked together by the linker and becomes a binary, or ROM. This is because PCs back then couldn't just assemble the entire ROM at once like we do nowadays, the PC-98 Sonic 1 was developed on was just about as powerful as the Mega Drive itself (In the processing department not so much graphics or sound), so you had to break up assembling across multiple files. It also made it convenient if you just changed 1 file as you can just rebuild that 1 file, and link everything together which is much faster than reassembling every asm file. To be honest with how god awfully slow AS is and since every modern disassembly wants to rely on it, maybe maintainers should look into using linking. Or better yet, ditch AS. We should really look into ASMX.
Anyone know what's different about SolidObjectFull_Offset in the Sonic 3 & Knuckles disassembly compared to the other solid object collision detection routines? The disassembly has no comments and it doesn't seem to exist in Sonic 2. It's called by the rshoot object and one or two other (unknown) objects. Also, the collision routines return the type of collision that was detected in register d4. However, when two players are checked, that result is trashed after checking the first player. I wonder why it does that.
Quick sanity check for byte 0x2A of the sprite status object: is it correct that for players, bit 1 is set when facing left, while for all other objects bit 1 is set when they're facing right? EDIT: Oops, I meant bit 0.
Do you mean bit 1 out of 7 or bit 1 out of 8? If the former, it's the "in air" flag; if the latter, then it is an X-flip flag, but whether it means facing left or facing right depends on the object.
In the case of the flip flag, I did notice that enemy sprites tended to be drawn facing to the left, but player sprites are drawn facing to the right, so the inconsistency with the flag usage makes sense. My best guess for why is simply that the default direction the player faces is right, while enemies are made to face towards the player, so they go left.
Oops, I indeed meant bit 0. It sounds like bit 0 is basically a horizontal flip flag, then. Makes me wonder why they didn't just use actflg's bit 0, which is also a horizontal flip flag. Got some more info relating to SolidObjectFull_Offset usage. rshoot is the tube elevator in Launch Base Zone. The two other objects are platforms in Flying Battery Zone: a floating one and a magnetic one. So my guess would be that this is used for airborne objects that move vertically.
With the standard object animations, you can actually choose to flip an individual frame within the animation data itself (at least that is how it is in Sonic 1). With the player animation, actflg's X flip flag is also set according to the player's angle (i.e. running down a left wall uses a horizontally and vertically flipped version of the running up a right wall animation). As such, 0x2A's X flip flag is a logical object X flip flag, while actflg's X flip flag is a direct sprite X flip flag.
Another question for the Sonic 1 experts. Which variable in Sonic CD is the actual boss flag? There's bossflag and there's bossstart, and both seem to be used inconsistently. Then there's also boss_sound, which seems to be used only for what its name is.
bossstart is a variable derived from Sonic 1 that is set when the boss starts and is cleared when the boss ends. Its main purpose is to prevent Sonic from walking off screen to the right when the screen gets locked (the walking off screen logic is only for the stages with signposts), but this is effectively the actual boss flag. bossflag is a Sonic CD exclusive variable whose usage varies depending on which boss is being fought. boss_sound is another Sonic CD exclusive variable that gets set when the boss music plays, which overrides the invincibility and speeds shoes music. The purpose of this variable is to prevent the regular stage music from playing if the invincibility or speed shoes run out. From what I can tell, this does not get cleared when the boss ends, only when the stage ends or gets reset.
I've ported the code for item boxes / monitors, but haven't found where it decides that a monitor was broken. The code runs collision checks, but it doesn't do anything with the results. When a monitor breaks, what should happen is that the routine counter is incremented, but other than the init routine, that doesn't happen anywhere. The collision detection routines don't do it either. Referencing the Sonic 2 and Sonic 3 disassemblies hasn't turned up anything, either. The reason I'm trying to find out is because, according to the code, when player 2 (Tails) breaks a monitor with a Super Ring in it, player 1 gets 10 rings, but for player 2 it's as if he opened a Robotnik monitor. I tried to test that yesterday, only to find out that player 2 can't break any monitors!
It's handled in Sonic's object collision code, iirc it's called TouchResponse in disasms. Side note but it might be worth keeping these questions in your decomp threads? I don't mean to mini mod but it does bury discussion about Sonic 1's source code.
Since when was this thread about Sonic 1's source code? I thought it was for all the Mega Drive games's source code. As my question pertained to logic found in all of them, I asked it here.
Well the initial thread post lists off all sources of information regarding only Sonic 1's source code, such as Feb. 90' and J2ME. And the conversation that had followed also stayed within the scope of Sonic 1. With Sonic 2 and CD only being means to extrapolate more information about Sonic 1. Your questions though directly correlate to progress on your PC decomps, and could for the most part be answered with only a disassembly rather than source code. So in my opinion, your questions are better suited in your threads is all.
Are we reading a different thread? The first post clearly talks about "the source code of the original Sonic the Hedgehog games". The sources listed are, in order: Sonic 2 "Nick Arcade" Sonic & Knuckles Collection's symbol list Sonic CD's unstripped ELF files Yuji Naka's video (about Sonic 1) Patent US5411272A (Sonic 2) J2ME (Sonic 1) Sonic 2 "Simon Wai" prototype's unassembled Kosinski file 7 sources, and only 2 are about Sonic 1. I think my questions are on-topic because it is about understanding the forms of source code we have. If it's something specific to my decompilation and porting efforts, I'll ask the question in their threads (where it very likely won't be answered, unfortunately).
Well um you see when you say "Sonic the Hedgehog" we obviously mean Sonic the Hedgehog (2001 Sonic Cafe)!
Anyways. I wanted to talk about the cd prefix. From S2NA, we have cddat and cdsts which are object variables, what we commonly refer to as the status bitfield and respawn table index. From S2NA's debug mode code we also have the constants of cd_jump and cd_ball, being bits 1 and 2, flags representing when Sonic is midair and when Sonic is rolling/jumping. Feb 90' also has cd_walk, cd_up, cd_down cd_left, and cd_right, along with cd_jump, however with the extremely early nature of Feb 90' it's not known what these were used for. It's entirely possible that they may have even been deprecated by the time we saw them as every reference of them is commented out in FCOL3. My question is what does cd stand for? If you only had Feb 90' as a point of reference you may think it's collision detection, but with S2NA we know better. I'm proposing 'condition' with cddat being condition data and cdsts being condition status. And since we have cd_jump and cd_ball, I also wanted to come up with some names for the other flags we don't have. Bit 0 - Horizontal flip - cd_flip Bit 3 - Sonic is standing on top of an object - cd_ride Bit 4 - Roll-jump lock - cd_balljump Bit 5 - Push flag - cd_push Bit 6 - Underwater flag - cd_water It may also be entirely possible that bit 0 is still called cd_walk since it was bit 0 in Feb 90, and it's not a total stretch that it could somehow indicate a horizontal flip. Thoughts?
Condition for cd sounds plausible. At first I thought this was a really good idea. However, thinking on it, I'm not sure. From what I've seen, to "ride" something in Sonic has a different meaning than standing on it. Thinking on this some more, the only thing that's really 'wrong' is the description. The player can ride something without standing on it. For example, the player 'rides' the hollow tree in Sonic 3's Angel Island Zone when they're ascending it.
Oop- yeah I wrote this at midnight after work I definitely think that cd_ride may not be the term since as I said earlier on the topic of rideon subroutines Perhaps cd_hit? It's a bit vague and I suppose that could also technically be the name of the push flag, but it might be a better fit.
