From what I know the Egg Prison should always work as an end of level trigger in Sonic 2, and the proof is that you can place them in any level with debug mode and they will always work. Of course they will have garbled graphics if you don't dynamically load the proper tiles while you're approaching the Egg Prison, even though this could give a spoiler to the player meaning he's on the right way. I don't know why your level doesn't work though. If a signpost is required by the engine just put one at a ridiculous location such as FFFF:FFFF so the player will never hit it. I don't think this is it but then again I am not familiar with Sonic 2 hacking so you should wait for other replies for a more precise opinion.
A quick question, what's the maximum size you can put on a sprite for Sonic before it starts fucking things up? (I would imagine a sprite too big would fuck up with something else)
Sprites can be at most 32x32 on the Genesis, so you're probably talking about a sprite mapping (or frame). There are many limits to consider. The VDP can only display 80 sprites (SonMapEd calls them 'pieces') at once, 20 sprites per line, etc. The limits are described on this page. Additionally, you have to consider how much VRAM is needed for the patterns that make up the image. Larger images need more VRAM, unless you reuse the same patterns. In the Sonic games, the VRAM is pretty full in most zones, so it can be difficult to find enough VRAM for new art without having to remove other things.
Thanks for the quick answer, I guess I'll just have to hope for the best with this. And one more thing I had forgotten. So, I've been working on this Sonic 2 hack and I'm switching Sonic's animations and adding new ones (this has nothing to do with the previous question), so, I added a falling animation when Sonic uses a spring, along with a SCD-like spring animation (HOW ORIGINAL :v , and they work fine, well, the SCD one does. The falling animation however has this... quirk... whenever Sonic falls from a spring into a wooden bridge, like those in EHZ, instead of reverting to the running animation he keeps using the falling animation until either he runs out of the momentum from the spring or I press either direction in the D-Pad. Code (Text): dc.w SonAni_Fall - SonicAniData ; 34; $22 SonAni_Spring: dc.b 4,$D8,$D9,$DA,$DB,$DC,$D8,$D9,$DA,$DB,$DC,$FD,$22 SonAni_Fall: dc.b 1,$D6,$D7,$FF So, I added SonAni_Fall just below SonAni_LieDown, I modified the spring animation to account for the new animations and linked it to the new falling animation. I'm sure I must be doing something wrong here, but honestly, I don't know what the fuck that is, some help would be appreciated.
Have you edited the code for the title screen (or removed a strange-looking frame from the sprite mappings)? Because the title screen uses sprite masking to clip the bottom part of the sprite, faking the 'hidden behind the emblem' thing. This masking is done by having a sprite with X coordinate 0 (when in the sprite attribute table in VRAM; search for "Sprite masking, mode 1" in this document for more information).
All I did was check the box that turned on the Press Start Text in ESE2 I'm just wondering if there is some way to fix the y position of the wing logo even using a hex editor. (ESE2 has one built in)
This probably happens because you've changed Sonic's start position in GHZ1. Restore at least his Y-coordinate to the original, so title screen's BG and FG will be at their places.
Sonic's start position in GHS affects the winglogo? Weird. Well lets see if that works. Edit: It worked. But why is the wing logo tied to Sonic's starting position in GHZ1?
I don't know exactly, I have a theory though. Title screen uses layout engine like all normal levels do, it calls a subroutine that loads level stuff for GHZ1, including Sonic's start pos etc. It also calls level deformation subroutines to scroll BG with deformation like in normal level. Those routines work with camera, which is affected by Sonic's coordinates, that's why camera is a bit bottomer than it supposed to be, so deformation routines scroll BG and FG upper. But sprites on the title screen have on-screen coordinates system, I.e. their coordinates are not depending on camera positions, so they stay at their places.
So I was wondering what the shortest way to check if Sonic is within the range of a certain object is. I'm always doing it like this: Code (ASM): move.w ($FFFFD008).w,d0 ; get Sonic's X-pos sub.w $8(a0),d0 ; substract the X-pos from the current object from it bpl.s ResultPositive ; if result is positive, branch neg.w d0 ; otherwise make it positive ResultPositive: cmpi.w #$10,d0 ; is Sonic within $10 pixels of that object? bgt.s TooFarAway ; if not, branch But this makes 6 commands just for the X-position, which is VERY annoying. Is there any way to check the distance with less lines?
I'm looking for information about data formats in Sonic 2: the bumpers in CNZ, and collision. And also all of the level data in Sonic 1. The wiki doesn't have anything on these.
I hope I got this right: Code (ASM): move.w ($FFFFD008).w,d0 ; get Sonic's X-pos sub.w $8(a0),d0 ; substract the X-pos from the current object from it addi.w #$10,d0 cmpi.w #$20,d0 ; is Sonic within $10 pixels of that object? bhi.s TooFarAway ; if not, branch I know, math is hard. What's happening here is that I add $10 to d0, then check if d0 is greater than $20 (2 * $10) with an unsigned comparison (bhi instead of bgt). This means that if the value is negative, it will still be higher than $20 (e.g. -1 yields $FFFF). This only saves one instruction, but I don't think you can do much better than that (plus, it saves 2 lines because you don't need that extra label).
Hey, two lines is better than nothing, so thanks for that. =) Just one thing I'm wondering about: Why would I need to write that add line? Why don't I just check for $10 in the cmp?
Incase it's a negative result (10 pixels left), by adding, you increase it into positive, if it's too far left, it'll be negative, if it's too far right, it'll be higher than 20.
I forget, how do I make an object (or in my case part of an object sprite) use a different pallete line to the one it's using in Sonic 1? Also, my old lamp problem still persists
The VDP has a "V-Ram setting" which is a word is size, this very same word format can be found used for map planes and sprites, the format is: XYZZ For Sonic 1 with sprites, there are two places it can be used. The first way is: Code (ASM): move.w #$XYZZ,$02(a?) This is the "main" V-Ram control, it controls all sprites of the object's mappings, so if I wanted to set it to use the second palette line, I set "CC" (as explained above) to 01, this makes "XYZZ" "2000", so by moving "2000" you set the object and it's sprites to use the second palette line. The second way is: Code (ASM): dc.b $03 dc.b $YY,$SS,$VV,$VV,$XX dc.b $YY,$SS,$VV,$VV,$XX dc.b $YY,$SS,$VV,$VV,$XX These are mappings, each line being a "sprite" piece, the "VV" "VV" are together as a word ("VVVV"), this is the same format as "XYZZ", so you can set say the first sprite piece to use palette line 2 (CC = 01 | XYZZ = 2000) and start from the second tile in V-Ram (+0002), the second sprite piece to use palette line 4 and to be flipped upside-down (CC = 11 and F = 1 | XYZZ = 7000) and start from the 56th tile in V-Ram (+0056), and the third sprite piece to use the first palette line, in high plane and mirrored (P = 1 and CC = 00 and M = 1 | XYZZ = 8800) and start from the 780th tile in V-Ram (+0780): Code (ASM): dc.b $03 dc.b $YY,$SS,$20,$02,$XX dc.b $YY,$SS,$70,$56,$XX dc.b $YY,$SS,$8F,$80,$XX Be warned, the XYZZ settings stored in the "main" V-Ram control (I.e. $02(a?)) will ADD to all the sprite's XYZZ's in sprite mappings. So if $02(a?) was 2010, then the first sprite would be $40,$12, the second sprite would be $10,$66, and the third sprite would be $AF,$90.
So, in what way would this apply to Obj79? (Lamppost) Which uses a the stage's first line for the main body rather than Sonic's? Where abouts do I look in terms of that object?
Assuming you mean the third line, consider trying "Obj79_Main:" from "move.w #$7A0,2(a0)" to "move.w #$47A0,2(a0)", this will increase the lamppost (except the red hit ball) to the 3rd line. Of course, if you wanna be more specific with the pieces, then it's suggested looking in "_maps\obj79.asm": Code (ASM): byte_17100: dc.b 6 ; ""untouched lamppost"" dc.b $E4, 1, 0, 0, $F8 ; half bottom body (left) dc.b $E4, 1, 8, 0, 0 ; half bottom body (right) dc.b $F4, 3, $20, 2, $F8 ; half top body (left) dc.b $F4, 3, $28, 2, 0 ; half top body (right) dc.b $D4, 1, 0, 6, $F8 ; half blue ball (left) dc.b $D4, 1, 8, 6, 0 ; half blue ball (right) byte_1711F: dc.b 4 ; ""Body (only) of lamppost when ball spins"" dc.b $E4, 1, 0, 0, $F8 ; half bottom body (left) dc.b $E4, 1, 8, 0, 0 ; half bottom body (right) dc.b $F4, 3, $20, 2, $F8 ; half top body (left) dc.b $F4, 3, $28, 2, 0 ; half top body (right) byte_17134: dc.b 2 ; ""Ball (only) that spins"" dc.b $F8, 1, 0, 8, $F8 ; half red ball (left) dc.b $F8, 1, 8, 8, 0 ; half red ball (right) byte_1713F: dc.b 6 ; ""touched lamppost"" dc.b $E4, 1, 0, 0, $F8 ; half bottom body (left) dc.b $E4, 1, 8, 0, 0 ; half bottom body (right) dc.b $F4, 3, $20, 2, $F8 ; half top body (left) dc.b $F4, 3, $28, 2, 0 ; half top body (right) dc.b $D4, 1, 0, 8, $F8 ; half red ball (left) dc.b $D4, 1, 8, 8, 0 ; half red ball (right) I've labeled what each piece is, though I suspect you might use SonMapEd (if you do, then it's suggested you read it's instructions about palette changing pieces), the middel byte of each piece, if it's +00, it's the first line, if it's +20, it's the second line, if it's +40, it's the third line, if it's +60, it's the fourth line (Again, make sure there's a $ sign to represent it as a hex value).
