One thing is that the points graphics will have to be moved elsewhere. Here's a video, courtesy of Clownacy (relevant parts start at 19:28): EDIT: Quote block added; this message and the one this is a reply to were once their own thread.
It would actually be better to do this: Code (Text): lea LevSel_Ptrs(pc),a0 move.w (a0,d0.w),d0 It's a bit faster to do that, since the code is still closeby.
thanks but i've already given up on sonic 1 and trying my luck in sonic 3 (i also completely ditched the mania md idea lel)
Hmm... what exactly are you hoping to accomplish? Are you just experimenting for fun, or are you actually trying to make a hack? If it's the latter, surely you'll never get there by continuing to switch between disassemblies. All of them will come with some growing pains, but you have to stick with it if you're to get anywhere.
I might be asking this in the wrong thread, but does anybody have or know where to find Alberto Robert's model from Sonic 2006? I need it ASAP for a top secret project
For doing a simple *4 operation, which is faster? Code (Text): add.w d0,d0 add.w d0,d0 or this? Code (Text): lsl.w #2,d0 Asking because I was looking in the game's main object loop, and it uses two d0 adds instead of the bitshift operation that, in my mind, seems like it would be only a single binary instruction with less math, therefore, at least negligibly faster. Am I off the mark?
https://mrjester.hapisan.com/04_MC68/CycleTimes.htm According to this page by MarkeyJester, using two add.w is 2 CPU cycles faster than using lsl.w. Not really a huge boost in performance, but still worth it in my opinion.
Modern CPUs use barrel shifter circuitry to perform bit shifting any number of times for the same CPU time. The 68k does not, internally the instruction is performing one shift left in a loop, which is why the time decreases as the shift number increases. The add instruction is 4 cycles while the shift instruction itself is 6 cycles (with 0 shifting), each shift takes 2 cycles.
The sonic games code for scrolling the camera vertically calculate the distance from sonic y and the camera y. If sonic is rolling when jumping , it subtracts the difference of his rolling and standing height raidus (5px). instead, wouldnt you want to add 5 px to make sonic lower and now 5 pixels higher (by subtracting)? Why are they doing this? ; --------------------------------------------------------------------------- ; Subroutine to scroll the camera vertically ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| ; The upper 16 bits of Camera_Y_pos is the actual Y-pos, the lower ones seem ; unused, yet this code goes to a strange extent to manage them. ;sub_D77A: ScrollVerti: moveq #0,d1 move.w y_pos(a0),d0 sub.w (a1),d0 ; subtract camera Y pos cmpi.w #-$100,(Camera_Min_Y_pos).w ; does the level wrap vertically? bne.s .noWrap ; if not, branch andi.w #$7FF,d0 ; loc_D78E: .noWrap: btst #2,status(a0) ; is the player rolling? beq.s .notRolling ; if not, branch subq.w #5,d0 ; subtract difference between standing and rolling heights Other code adds 5 to sonics y , making him lower as seen below @roll: bset #status_jump_bit,ost_status(a0) move.b #$E,ost_height(a0) move.b #7,ost_width(a0) move.b #id_Roll,ost_anim(a0) ; use "rolling" animation addq.w #5,ost_y_pos(a0) My Image shows it sets the radius (w/h) for rolling and lowers sonic 5 pixel after addq.w #5,ost_y_pos(a0)ss
Sonic's physical Y position gets pushed down 5 pixels downwards once he enters his ball form to take into account the hitbox size change. The camera code then takes that into account by offsetting that when calculating the camera's Y position. Otherwise, the camera shifts downward as Sonic's position gets shifted when going into ball form, which looks jarring.
I'm misunderstanding something ? I don't see how it fixes the jarring. When sonic goes to ball firm 5 pixels are added to his y moving him down . Then the camera code subtracts 5 pixels just to undo that 5 pixels. The distance from the top of the screen to sonic ( sonic y - sonic y) is additionally subtracted 5 in camera code. So the distance is from sonic y to camera y as if he is standing but he us rolling?
If the camera did not subtract 5, it would shift down 5 pixels as Sonic's Y position is shifted, which looks weird. It's not obvious when you jump, but it's painfully so when you roll. The camera subtracting 5 offsets the shift and keeps the camera in place. The camera does not actually overwrite Sonic's Y position variable at all. Sonic rolling into a ball, however, is actually physically shifting him down 5 pixels to keep him aligned on the ground when his hitbox size changes. Here's what it looks like when the camera doesn't apply that offset: All in all, it's just simply the camera moving up a little when Sonic is shifted down, so that it doesn't look odd.
Let me see if i understand it . In case of rolling as you showed in video , the Sonic_Roll code adds 5 px to sonic y shifting him down . then the camera code , code needs to offset this back or otherwise the sonic y would be 5 pixels below ( greater) than the camera y pos bias, causing the camera to move by the difference from sonic y and the camera y pos bias calucated by cameraypos = (sonicplayfieldy-cameraplayfieldy) - camerybias + cameraplayfieldy Couple related questions When on the ground does the camera code strictly use the camera y bias to determine scrolling compared to when jumping it uses top bottom left right borders? Is the center for camera y pos bias (0x60 aka 96) not the screens true vertical center (112 PX) because 96 is divisble by tile/block After roll code and camera code is running sonic still physically appears standing . has it just not updated drawing and doesn't contradict offsetting sonic y 5 in roll code
The way the camera works vertically is as follows: First it gets Sonic's Y position. Which basically boils down to something like Code (Text): Sonic Y position - (Default hitbox height - Current hitbox height) which, like I said, is done to prevent the camera from jittering abruptly on hitbox size changes. Then it checks if Sonic is in the air or if he is on the ground: If Sonic is on the ground If the "bias" is not exactly 0x60, meaning that Sonic was looking up or down, scroll towards the shifting "bias" at a max speed of 2 px/frame. Otherwise Get the camera's vertical scroll speed cap in px/frames Set it to 6 if Sonic's ground speed/"inertia" is < 0x800 in either direction. Set it to 16 if Sonic's ground speed/"intertia" is >= 0x800 in either direction. Move the camera towards Sonic. If Sonic is in the air If Sonic is 32 px away from the "bias" in either direction, move the camera towards Sonic at a speed of 16 px/frame. Otherwise If the bottom level boundary is changing, move the camera right at Sonic's Y position (to be honest, probably a side effect due to the code always doing that whenever updating the camera to take into account boundary changes). Otherwise, don't move the camera vertically. Boundary checks and level wrapping take place at the end when the camera's Y position is updated. So, on the ground, it tries to stay centered at Sonic's Y position, but in the air, Sonic generally has to be 32 px away from that "bias" in order for it to scroll. EDIT: Also WOW are bullet points glitchy here.
I believe I understand it, give me a yes / no if this sounds about right, ( maybe I oversimplify some of it let me know please ) The image shown shows a red line representing the bias at 96. The transparent yellow box is his bounding box, the black dot with white around it is sonic center. and the cyan lines are the two height radius. Using Sonic 2 Disasm code, Assuming I pressed the button to roll sonic on the ground (like the video), but before Obj01_DoRoll is called... sonic y coordinate variable position is at the black dot of the left picture. After Obj01_DoRol moves his y 5 pixels down , sonic y coordinate position is as shown at the black dot of the right picture. Left picture has him at the camera y pos bias and the right picture has him 5 pixel below to align him with the floor as he goes in the ball. When ScrollVerti is called, since it sees sonic is rolling, it needs to subtract 5 to the temporary d0 register storing sonic local coordinate (sonicy - cameray), before ScrollVerti calcualtes how far sonic moved from bias . Otherwise if we didn't, it will think sonic moved 5 pixels, below the camera y bias,consquently moving the camera down to adjust. Am I understanding it correctly? Thanks for everything!
