Underneith the crushers, in the floor, is an object which kills the player if they are touching the top/bottom of it. It's there because the crusher pushes Sonic through the floor instead of actually killing him. The floors in Marble Garden Zone are not flat, they ramp up and down. Under some of the crushers the floor is such that it ramps down just before ramping up where the crusher is. If Sonic is moving fast enough, he can be "technically" inside the ground because of the down ramp, and next frame, the collision system will put him on top of the up ramp floor so you don't actually see him inside it. Unfortunately, he can touch the killing object before that happens.
How can I edit sprites for Sonic 1 PC decomp? I try to edit it in MSPaint- FAIL! Ok, it compress image, but I try to edit in Paint.NET, and it not compress my gif, but game still show random graphics instead of what is needed
I should mention the reason why MS Paint and Paint.NET won't work is because RSDK actually utilizes the palette/color indicies in the image data itself. Resaving in either of those will mess it up.
Given the latest progress in extracting stuff from Saturn games, does anyone know if anyone's tried to mod assets from Sonic 3D Saturn to the PC port?
I managed to decode the sprite format, to some extent. Haven't tried to inject new ones. There's a Discord for Sonic 3D Blast modding, but it's pretty quiet most of the time.
You have a link to that server? It'd be mainly to my brother. He was searching for potential Saturn mods to PC Sonic 3D.
Here: https://discord.gg/R2ndqjhgXZ I don't know that there's ever going to be any kind of Saturn restoration mod though, considering that the Special Stage would take an enormous amount of work to port, and I don't know how any of the other missing effects would work.
Not sure if I can ask it here... Anyone knows if S2HD is still under development? If there's been progress in the game's completion.
Exists any way to "emulate" lock-on technology, or something? I need to test compatibility of my Sonic 3 and Sonic and Knuckles modifications..
Lock-on technology just maps the locked on ROM to the $200000-$3FFFFF region in ROM space. Couple notes on that, though: The latter 2 MB of the ROM is locked on. ROMs <= 2 MB are mirrored, which makes it visible in latter 2 MB region. Otherwise, larger ROMs will have their data located at $200000 and above mapped. The Knuckles in Sonic 2 UPMEM is mapped to $300000-$3FFFFF if you set the SRAM enable flag. So, to "emulate" it, if the ROM is <= 2 MB, you can just take a Sonic & Knuckles ROM, and append the ROM at $200000 via a hex editor. If the ROM is > 2 MB, then you take the data at $200000 in the source ROM and copy it to $200000 in the S&K ROM. To "emulate" Knuckles in Sonic 2, you also take the UPMEM and copy it to $300000 in the S&K ROM. Genesis Plus GX also natively can automatically map the ROMs. Just some examples to help illustrate my point:
Bringing up a bizarre bug with my Simon Wai disassembly; for whatever reason, the palette cycles have a chance to corrupt randomly (mainly after the player takes damage and then exits to a new level), and this bug ONLY occurred when moving it to AS. Is this an AS-specific bug, or something else? https://github.com/AlexField442/Sonic-2-Simon-Wai-Disassembly
Oh boy... I took a look at both the final ASM68K-based commit and the first AS-based one, and while I can't confirm that this is the cause of the problem, there is a deep-rooted issue with the disassembly that, combined with a particular behavior difference between ASM68K and AS, might be a factor. The disassembly has tons of bsr, bra, and conditional branch instructions without length attributes, as well as a number of lea instructions, including every instance in the palette-cycling routines, whose source operands lack length attributes. If the goal is bit-perfectness, this is a recipe for disaster, since the two assemblers handle these very differently: for branches, ASM68K always treats these as word length, while AS will optimize them to short on the second pass if possible; for leas, ASM68K appears to treat these as absolute long, but AS optimizes them to words if possible. These two differences alone are causing the two builds to differ significantly: my hex editor found 5429 differences between the two commits! I don't think these optimizations would cause problems, but you never know... Code (Motorola 68000 Assembler): lea (Pal_GHzCyc),a0 ; For this, ASM68K would produce the following: $41F9, $0000, $xxxx... lea (Pal_GHzCyc),a0 ; ...but AS on the other hand produces this: $41F8, $xxxx lea (Pal_GHzCyc)l.,a0 ; forcing absolute long produces the intended result in both: $41F9, $0000, $xxxx... Before anything else, I would try correcting the lea instructions in the palette cycling routines so that they are absolute long instead of word. Longer-term, might be a good idea to use the listing file from the final ASM68K build to find and fix all of the branches, jumps, and leas without lengths, and address any other issues needed to get things building to the correct offsets again (that is, the offsets in the left column of the listing file match the IDA-generated labels; bit-perfect is a completely different story).
Thanks for the information (although you wrote (Pal_GHzCyc)l.,a0 incorrectly); I also wouldn't be surprised if this is why the Special Stages also crash in the AS version, but not the ASM68K. Looks like my next update will just be fixing this. EDIT: Tried replacing all bsr/bra with .w and "lea (xxx)" with "lea (xxx).l", but it didn't fix the issue; at least it's closer to the original ROM?
That the palette issue was not related to the instruction length issue was not too much of a surprise, but nevertheless it is much closer to the original ROM. Still needs some more work to get bit perfect, but that is something I could easily help with (spent several hours getting my yet-to-be-released Sonic 2 ASM68K disasm bit-perfect after the first successful build).
(EDIT) Imma just start over from scratch. Heyo! I was working on a rom hack and I added a SEGA jingle that is using SMPS and not PCM format. While building, unfortunate things happened. No matter what I did, it would always build with Code (Text): J: J:\S1SPINDASHASM\SONIC1.ASM(39018) : Warning : Instruction has been word aligned move.w #$100,($a11100).l J:\S1SPINDASHASM\SONIC1.ASM(39035) : Warning : Branch to odd address bra.s sub_71b4c Errors during pass 1 - pass 2 aborted Assembly completed. 1 error(s) from 48235 lines in 0.17 seconds Reported Size: 100303C Reported Checksum: 0 Size applied: FFFFFFFF Checksum When this happens, the rom doesn't work. and the code in question? Code (Text): ; --------------------------------------------------------------------------- ; Music Pointers ; --------------------------------------------------------------------------- MusicIndex: dc.l Music81, Music82 dc.l Music83, Music84 dc.l Music85, Music86 dc.l Music87, Music88 dc.l Music89, Music8A dc.l Music8B, Music8C dc.l Music8D, Music8E dc.l Music8F, Music90 dc.l Music91, Music92 dc.l Music93, Music94 ; --------------------------------------------------------------------------- ; Type of sound being played ($90 = music; $70 = normal sound effect) ; --------------------------------------------------------------------------- SoundTypes: dc.b $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90 dc.b $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $90, $80 dc.b $70, $70, $70, $70, $70, $70, $70, $70, $70, $68, $70, $70, $70, $60, $70, $70 dc.b $60, $70, $60, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $7F, $60 dc.b $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $70, $80 dc.b $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $80, $90 dc.b $90,$90,$90,$90, $90 ; $E0 ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| sub_71B4C: ; XREF: loc_B10; PalToCRAM move.w #$100,($A11100).l ; stop the Z80 nop nop nop loc_71B5A: btst #0,($A11100).l bne.s loc_71B5A btst #7,($A01FFD).l beq.s loc_71B82 move.w #0,($A11100).l ; start the Z80 nop nop nop nop nop bra.s sub_71B4C ; =========================================================================== Can someone help me out as to what I'm doing wrong? Note I have the spindash implemented and that seems to corrupt everything. A video demonstrating:
