I'd probably say locking the controls from the moment the final hit has landed and playing out that entire section with pre-recorded movement would be the best way of doing it. An instant control lock would also prevent people from being able to overfow the boss hit counter back to 255.
I did THIS... for Sonic 1. Wasn't all that hard, more time consuming than anything else, what with all of the separated .asm's and all. (One of the few drawbacks to this layout) Follow these steps to do the same: 1. GET A FREE UNIVERSAL SST - You can do this a couple of ways... I chose to do this. (Based on RHS' SST guide) obActWid: Switch from $19 to $14. obPriority: Switch from $24 to $18. obInertia: Switch from $14 to $20. - This is the same SST as obColType, but we don't need to worry about this. Only one object in the game uses both. 2. Perform Steps 2-10. If you applied my change to remove the functions that freeze objects when Sonic dies, you won't need to apply step 10. You can find it here, as well as a second step here. 3. Caterkiller's collision flags bit is overwritten by the inertia variable... meaning that Sonic cannot interact with it. Let's quickly fix this: In 78 Caterkiller.asm, replace EVERY instance of obInertia with $1E. This is anim_frame_duration (I forget the S1 name for this variable... since I converted all of my equates to the S2 nomenclature) If you want, you can even give $1E a new local equate for use with this object. below "Cat_Index", place this line: Code (Text): cat_gvel: = $1E ; ground speed. (To replace the normal g_vel SST, as it is used for collision purposes) Other than Caterkiller, I found ZERO bugs. I haven't had ANY time to do wiki work... just barely had time to squeeze in some changes to RHS' Sonic 2 Recreation page... but I'll get this up in due time.
Congratulations on porting the system over, it's nice to see non-techies trying these things out for themselves and making good progress, well done!
I also used your code for the fades, and got my own white in and white out effect, similar to yours. I'm looking into re-working all of it to appear similar to this effect, but in the original 21 frames instead of the new 7. I'll post that here too.
I'm re-bumping this thread again, to give you all a tutorial on a powerup I just finished for my new hack in progress: Sonic 1: Freehand (The Sketchhog hack) This powerup is called Ring Time. For those who don't know what this is... it turns your enemies into rings when in proximity. So, the first thing you will want to do, before anything else... is create a new frame for this monitor... using your art editor of choice (*cough* Insert shameless Sonic Triad plug here *cough*) If you can't be arsed to do art, just have it use the normal ring art, which is what I did when I first put this together. Now, go into _incObj/2E Monitor Content Power-Up.asm and scroll down to the end of the powerup checks. Replace "Pow_ChkRings" with the following: Code (Text): ; =========================================================================== Pow_ChkRings: cmpi.b #5,d0 ; does monitor contain 10 rings? bne.s Pow_ChkRingTime ; <---- ADD NEW CHECK HERE addi.w #10,(v_rings).w ; add 10 rings to the number of rings you have ori.b #1,(f_ringcount).w ; update the ring counter cmpi.w #100,(v_rings).w ; check if you have 100 rings bcs.s Pow_RingSound bset #1,(v_lifecount).w beq.w ExtraLife cmpi.w #200,(v_rings).w ; check if you have 200 rings bcs.s Pow_RingSound bset #2,(v_lifecount).w beq.w ExtraLife Pow_RingSound: music sfx_Ring,1 ; play ring sound ; =========================================================================== Pow_ChkRingTime: cmpi.b #6,d0 ; does monitor contain 'Ring Time'? bne.s Pow_ChkGoggles move.b #1,(v_ringtime).w ; make Sonic able to turn enemies into rings move.w #$4B0,(v_player+$2A).w ; time limit for the power-up music sfx_Ring,1 ; play ring sound ; =========================================================================== Don't mind the check for Goggles, you can change that to Pow_ChkEnd if you don't want more powerups. Notice v_ringtime and v_player+$2A. The first one... just make an equate for it in Variables.asm whereever you want to. I'd do it somewhere near v_shoes. For the second one, $2A and $2B are unused SST's for Sonic, so they are now our RingTime powerup SST's. When we get the powerup, these will be set to a value, and they will ultimately tick down to 0, much like Speed Shoes and Invincibility do... Now, to make this expire after a limited time, go to _incObj/Sonic Display.asm. Below @chkshoes, add this block of code: Code (Text): @chkringtime: tst.b (v_ringtime).w ; does Sonic have the powerup? beq.s @chkgoggles ; if not, branch tst.w ringtime(a0) ; check time remaining beq.s @chkgoggles subq.w #1,ringtime(a0) ; decrement timer bne.s @chkgoggles move.b #0,(v_ringtime).w ; cancel powerup Replace @chkgoggles with @exit if you have no other timed powerups intended. Now if you are familiar with the above @chkshoes code, you already know what this does. It decrements the ring time timer, and disables the powerup. Now finally, to the piece de res.... ok I'll shut up. Here is how the powerup bears fruit. Go to _incObj/sub ReactToItem.asm. Replace "@proximity" with this (I attempted to comment stuff to help understand the code. My apologies if my comments aren't 100% accurate. I tried.) Code (Text): @proximity: andi.w #$3F,d0 add.w d0,d0 lea @sizes-2(pc,d0.w),a2 ; a2=other object's collision box size. moveq #0,d1 move.b (a2)+,d1 ; d1=a1's collision width. move.w obX(a1),d0 ; d0=a1's x-position sub.w d1,d0 ; d0=a1's x-position-minus its collision width. (Co-ordinate of its left side bounding box) sub.w d2,d0 ; d0=a1's left bounding box co-ordinate-(Sonic's position-8) bcc.s @outsidex ; branch if not touching (positive value or 0) add.w d1,d1 ; d1=a1's collision width*2 - a1's RIGHT bounding box co-ordinate add.w d1,d0 ; d0=(a1's left bounding box co-ordinate-(Sonic's position-8))+ d1, to check the right side. bcs.s @withinx ; branch if touching (negative value) bra.w @next ; =========================================================================== @outsidex: tst.b (v_ringtime).w ; is Ring Time active? beq.s @skipx ; if not, branch cmp.w #$50,d0 ; is the enemy within range, x-wise? bcc.s @skipx ; if not, branch move.b obColType(a1),d1 ; load collision type andi.b #$C0,d1 ; is object an enemy? bne.s @skipx ; if no, branch tst.b obColProp(a1) ; is enemy a badnik? beq.w RingTime_Enemy ; if yes, branch So basically, this checks if an object is colliding with Sonic's sides. If it is NOT, then it checks to see if the object is in proximity. ($50 pixels). If it is, it then checks if the object is a badnik, by first checking obColType(a1) o see if it is an enemy, then checking obColProp(a1) to see if it is a boss. if every thing checks out... then we proceed. We can replace @outsidey with essentially the same code, as you can see below: Code (Text): @outsidey: tst.b (v_ringtime).w ; is Ring Time active? beq.s @skipy ; if not, branch cmp.w #$50,d0 ; is the enemy within range, y-wise? bcc.s @skipy ; if not, branch move.b obColType(a1),d1 ; load collision type andi.b #$C0,d1 ; is object an enemy? bne.w @skipy ; if no, branch tst.b obColProp(a1) ; is enemy a badnik? beq.s RingTime_Enemy ; if yes, branch Now, finally let's get to RingTime_Enemy: Code (Text): RingTime_Enemy: move.b #id_RingBounce,0(a1) ; change object to bouncing ring move.b #0,obRoutine(a1) rts Essentially turns the badnik into rings. Now I used a new ring object for this... partly because using the standard lost rings will be a headache... IMO, THAT and you cannot collect lost rings in Sonic Freehand. If you do use RingLoss object for this... you'll have to do a little tweaking... as it is the RingLoss object that also reduces your rings to zero as it spawns the other rings. So... yep, that's what I've got. It works fine considering the circumstances of my hack, but perhaps it isn't perfect for the standard Sonic 1 hack YET. If I did something wrong, or if something could be improved, please help me to make this better. I haven't tested this in stock Sonic 1, and the conditions of that game are far different than my hack... so it may work fine for me, while it could cause bugs for you. I hope that someone experienced enough can help us perfect this. Hope this can be of use to anyone. -KoH
Ah yes... I should've put that in. I'd say that I thought that would come naturally to anyone looking to implement this... but I know I'd be surprised at how wrong I am. XD
Took this from Mercury's ReadySonic. I've had so much use for this mod... and it's already on a public forum with ReadySonic, so there's no reason why it isn't in the SCHG already. Added the page just now. It's not my best writing, I apologize. http://info.sonicretro.org/SCHG_How-to:Dynamic_Special_Stage_Walls_system I also made a small note about the fix Cinossu made for smoother rotation at the end of this guide.
One simple hack I thaught about -originally for S3 but could apply to all MegaDrive titles as well- is to escape the 60 frames per second in the collissions engine. Let me explain: The MegaDrive outputs 60 images per second, but the whole game physiscs are based on that clock. My idea was to initially test how the engine changes, but not aletering the physics. This could be done processing twice for object collisions per frame, but moving objects by half every step. This way, sonic would be moved twice per frame, but at half speed, checking for collissions evey time. Why mod this? Remember high speed glitches that don't happen at lower speeds? Maybe this could be a way to go around that limitation, because the collissions engine would be moving objects at half speed. Also, this mod would also allow to go for higher speeds in the game, exceeding those 16 pixels per frame < maybe this is a little too much (even unneeded), but it'd be easy to achieve. Yes, physics would be altered, but would be almost unnoticiable - this according to some simple simulations I've done. Taking this concept further, the clock rate could be made variable and switch to this supposed higher precision only at higher speeds, and keep the lower speed sections with their former physics. Maybe some of you experts out there could tell if this is possible, or if this could help achieve more continuity in the fastest sections of some levels -especially in S3.
I'm no expert, but considering how the game sometimes lags just trying to run at 60fps, there's pretty much no way you'd be able to double the amount of processing it does per frame.
As someone that has taken extreme measures in my hack to reduce the lag caused by an additional character, I can attest to what MainMemory is saying -- adding an extra character is nowhere near the same in terms of processing requirements as doubling all the updates for all objects, and it is bordering the limits of what the poor 68k can handle. Doubling all the game logic would basically make the game unplayable: you would end up with something like 60fps in physics updates displaying at maybe 30fps.
Ok, I accept that. But since the character is moving half the distance, the only processing that should be done is character repositioning. I mean, this would only double character repositioning when colliding with tiles. All other processing should remain the same, and once per frame. To get a bit more technical, instead of doing this: X[n+1] = X[n] + V[n] check for tile collision <continue to check other things and move objects> do this: X[n+1/2] = X[n] + V[n]/2 check for tile collision X[n+1] = X[n+1/2] + V[n]/2 check for tile collision <continue to check other things and move objects> As far as I suppose, this would similar to having 2 characters on screen. If so, this shouldn't need much more processing power
Would there be any interest in a S2 Ring Manager in Sonic 1 guide? I had some time today... for once... and managed it. If so I'll try to find time to whip one up.
Okay, most hackers here have likely caught onto this bug ages ago, but since there's no tutorial or anything of it, here's one for beginners. The Roller badnik suffers from a slight graphics glitch due to it's VRAM clashing with leftover Caterkiller tiles, leading to this: The inclusion of Caterkiller's data in Spring Yard Zone seems to be an error as it isn't used anywhere, thus we can take it out of here fine. Simply go to inc/pattern load cues.asm and find the SYZ data. Code (ASM): ; --------------------------------------------------------------------------- ; Pattern load cues - Spring Yard ; --------------------------------------------------------------------------- PLC_SYZ: dc.w 4 dc.l Nem_SYZ ; SYZ main patterns dc.w 0 dc.l Nem_Crabmeat ; crabmeat enemy dc.w $8000 dc.l Nem_Buzz ; buzz bomber enemy dc.w $8880 dc.l Nem_Yadrin ; yadrin enemy dc.w $8F60 dc.l Nem_Roller ; roller enemy dc.w $9700 PLC_SYZ2: dc.w 7 dc.l Nem_Bumper ; bumper dc.w $7000 dc.l Nem_SyzSpike1 ; large spikeball dc.w $72C0 dc.l Nem_SyzSpike2 ; small spikeball dc.w $7740 dc.l Nem_Cater ; caterkiller enemy dc.w $9FE0 dc.l Nem_LzSwitch ; switch dc.w $A1E0 dc.l Nem_Spikes ; spikes dc.w $A360 dc.l Nem_HSpring ; horizontal spring dc.w $A460 dc.l Nem_VSpring ; vertical spring dc.w $A660 Now edit out Caterkiller and change the object number accordingly like so: Code (ASM): ; --------------------------------------------------------------------------- ; Pattern load cues - Spring Yard ; --------------------------------------------------------------------------- PLC_SYZ: dc.w 4 dc.l Nem_SYZ ; SYZ main patterns dc.w 0 dc.l Nem_Crabmeat ; crabmeat enemy dc.w $8000 dc.l Nem_Buzz ; buzz bomber enemy dc.w $8880 dc.l Nem_Yadrin ; yadrin enemy dc.w $8F60 dc.l Nem_Roller ; roller enemy dc.w $9700 PLC_SYZ2: dc.w 6 dc.l Nem_Bumper ; bumper dc.w $7000 dc.l Nem_SyzSpike1 ; large spikeball dc.w $72C0 dc.l Nem_SyzSpike2 ; small spikeball dc.w $7740 dc.l Nem_LzSwitch ; switch dc.w $A1E0 dc.l Nem_Spikes ; spikes dc.w $A360 dc.l Nem_HSpring ; horizontal spring dc.w $A460 dc.l Nem_VSpring ; vertical spring dc.w $A660 Voila. Roller's graphics should be fixed. I've one query that's puzzled me since I was a kid, I've noticed the debug mode causes some VERY odd occurrences in Special Zone. It doesn't implement objects properly or even display most of them and exiting out of the maze can float you into these strange random areas with limited collision and numerous beta objects (solid emeralds can also be collected there). What would this be classified as exactly? Glitch? Unfinished programming? Necessary garbage data? What the heck is going on in this zone? I also noticed the HUD objects are in the VRAM for this level as well, leaving me wondering whether it was supposed to be used in there (has anyone tried lasting ten minutes in there?).
Actually :P Still, I believe this actually is the first time that the fix is detailed in a proper form, so nice work for that. It's one of those little things which pop up from time to time and everyone thinks "it's already known", so it's good to have it posted in a proper topic.
Exiting out of the maze can make you go on areas which read incorrect RAM for layout data, which so happens to be garbage. The actual layouts are loaded on RAM and displayed as you move, while you go out of bounds you find random broken things. The stage does not have any actual objects, aside from Sonic, so they will follow the stage position, and not the stage graphics, so it seems all wonky. The HUD is likely something unimplemented on the stage, I don't know why its there, but likely for no purpose, just leftover. I am not sure if being on the stage for 10 minutes will kill you, its something to look into.
This is the same reason you find garbage tiles underneath Sonic 3's maps - it's doing exactly the same thing.
The HUD art appears in VRAM as its not overwritten during the transition from zone to SS. Unless I'm mistaken... You won't find it in VRAM going there from Level Select immediately upon booting the game. Secondly there is no time over in the Special Stage, that is... Unless you hack it in.
