One option could be to just copy what Sonic 1 does for its Level Select. I did this for my own project, as it was the simplest solution that I could manage at the time. Honestly, I'm not that experienced myself (as I do not really have the time to devote to hacking in general), but I experimented and came across that as a solution even though I barely knew how to even go about making it. Now, I will say that I found it a bit limited/wonky then, because I found myself having to jump around some obstacles and issues to make it work the way I needed it to (though I will admit, due to my aforementioned inexperience, there are probably a lot of problems and inefficiencies I could have avoided). Concerning this thread (and others), I've personally had some questions go blatantly unanswered. Though I was at first annoyed by this, it drove me to heavily research, seek out, and really learn to do what I wanted to do. As a result, I also figured out a lot more things than I didn't even intended to learn, but became useful later on. Looking back at previous posts, it seems you've already ported the S2 Level Select to Sonic 1, so you should be familiar with how menus work, right? That's a very solid starting point, if anything.
This is only tangentially related to hacking, it's really a question of how the games work in a more general sense. I might have a few more questions like this too. So here goes. The SPG mentions the usage of sin and cos to get proper movement values for moving at diagonals. Do the games use a lookup table for this though? It seems like an excessively slow operation to be doing so often without a lookup table. I've got one other question right now too. How exactly do the games handle floating point numbers?
Yes, there is a lookup table (see CalcSine in the disassemblies), and floating point numbers are handled as fixed-point, for example, Sonic's speed values are stored as a word where the high byte is the whole and the low byte is the fraction, while coordinates are stored as a longword where the high word is the whole and the low word is the fraction.
So I managed to import my art into EHZ fairly successfully using SonLVL (thanks for the heads up MainMemory). However, after importing it and building the ROM, several sprites have been affected and look like this: Does anybody know what is going wrong here? I simply deleted a couple of chunks and imported one I'd just produced. I haven't messed with sprite behaviour.
Your new art tiles are overflowing into the area of VRAM used by object art. You will either have to move the objects' art to somewhere else in VRAM or more likely remove some of the tiles that you don't need from the level art.
I last posted in March? Jesus, it's been a while :v: At any rate. While I've been meaning to, I still haven't sat down to take a stab at properly learning ASM yet. Having said that, a few days ago I decided "eh, why the hell not" and set up an S1 disassembly again to reacquaint myself. So far, all of what I've done is really stuff I've done before - port Sonic's S2 sprites and animations over, add the spindash, create peel-out sprites and add the peelout, remove speed cap, etc. This time, I decided I'd go the entire way in copying Sonic's S2 animations over, and make the game use the multiple balancing animations on edges. And that's where I've run into a problem. I copied Sonic 2's equivalent routine over and modified it to work with Sonic 1, and the thing is, it won't build. I just get these errors: ... Repeated 4 times each. Lines 63, 67, 71, 75, 84, 87, 91, 94, 110, 116, 119, 125, 134, 140, 143, and 149. I've had Illegal value errors in the past and managed to fix them, but I can't figure out for the life of me what's wrong here. Here's a snippet of the code where these first four errors happen: All 16 lines that have this error are the same thing - a move.b of one of the balance animations to Sonic's current animation. I've checked the Sonic 2 code side-by-side with mine, and I can't see anything that I'd imagine would cause this. I've tried numerous workarounds - lea'ing the animation, then moving just the byte to obAnim (same error), clr'ing obAnim altogether then adding the animation as a longword (Sonic just plays a static walking frame on a ledge), moving the value as a longword (same as with adding), but no dice. How can I diagnose/fix whatever the problem is here? Is there some key difference in how Sonic's animations are handled between S1 and S2 that could cause this?
You're trying to move the addresses of the animation data itself into the animation ID byte, instead of moving the ID number of the animations. You'll either need to manually count out each animation's ID in the list, or add code to generate constants like both disassemblies have by default, but in different ways.
DP, but I'm not very good at this. As the name implies, this is a subroutine meant to allow the player to curl into a ball while in midair if they're not already jumping (e.g. bouncing off a spring, walking off a ledge). I've been struggling with this for quite a while now, because no matter what I do, I can't get it to work properly. I hooked up the HUD to show Sonic's status instead of sprites while debug mode is active, and from what I can ascertain, everything's working fine there - if Sonic is facing right and walks off a ledge, his status is set to 02, if facing left + walking off ledge, it's 03, etc. For whatever reason though, the code doesn't work. I've tried commenting out everything to do with controller input, and I've tried multiple ways of checking Sonic's status, but nothing seems to be working. For what it's worth, if the first branch is a BNE, like here, then simply put, nothing happens at all, while if it's a BEQ, the game constantly sets Sonic's status to spinning, making the game unplayable.
2 issues: you are checking for joypad control and not for Sonic's buttons. it is very important of checking Sonic's buttons specifically, as sometimes they are enforced or disabled. Another thing, that your joypad test in fact is inverted; when said button is NOT pressed, the code is ran. I like to use this cheatsheet when doing button tests.
Oooh, that looks useful, I'll be sure to bookmark it. Thanks. //forums.sonicretro.org/public/style_emoticons/default/smile.png As for my code... something like one of these? [68k]Sonic_FallCurl: btst #1,obStatus(a0) ; is sonic airborne? bne.s @return ; if not, branch cmpi.b #id_Roll,obAnim(a0) ; is Sonic already rolling? beq.s @return ; if yes, branch btst #1,(v_jpadhold2).w ; is down being held? bne.s @curl ; if yes, branch rts @curl: move.b #id_Roll,obAnim(a0) ; set sonic's animation to rolling bset #2,obStatus(a0) ; set sonic's status to jumping/rolling move.w #sfx_Roll,d0 ; load spin sound jsr (PlaySound_Special).l ; play it @return: rts ; return to routine ; End of subroutine Sonic_FallCurl Sonic_FallCurl: btst #1,obStatus(a0) ; is sonic airborne? bne.s @return ; if not, branch cmpi.b #id_Roll,obAnim(a0) ; is Sonic already rolling? beq.s @return ; if yes, branch move.b (v_jpadpress2).w,d0 ; move joypad data into d0 andi.b #$02,d0 ; logical AND the down button with d0 bne.s @curl ; if yes, branch rts @curl: move.b #id_Roll,obAnim(a0) ; set sonic's animation to rolling bset #2,obStatus(a0) ; set sonic's status to jumping/rolling move.w #sfx_Roll,d0 ; load spin sound jsr (PlaySound_Special).l ; play it @return: rts ; return to routine ; End of subroutine Sonic_FallCurl[/68k] With these, I'm getting the same results as before, except that holding down causes @curl to be executed... How does btst work, exactly? Something about checking Sonic's status seems to be the problem here now, and I have no idea what exactly is wrong.
btst checks a specified bit in a register or memory. This bit can be input as as immediate, or a register, and if latter, the register contents are andied with 7 or $1F, depending on whether the target is memory or a register Code (ASM): moveq #$73,d0 ; prepare $F3 in d0 btst d0,d1 ; this will check bit 3 of d1 The issue with btst, is that you can only check a single bit at a time, and if you want, say, check for A, B and C, this will not work. This is why we have and! And, unlike btst, allows you to have a bitmask, which allows you to clear all other bits you don't wish to test. Lets say you want to test for A, B or C. This is how you'd do it: Code (ASM): moveq #$FFFFFF9F,d0 ; prepare $9F in d0[/size][/size] [size="2"] and.b #%01110000,d0 ; check for A, B and C buttons. The nuber equates to $70 Now I want to note, unlike that tutorial I linked tells, you can use both btst and and for testing held and pressed buttons This pdf shows all the instructions for 68k, with fairly technical descriptions of their actions.
Hmm, okay. I'll be sure to bookmark that .pdf as well, that looks very useful. As for my code - I still feel really dumb, I've been looking through it and I just can't see what's wrong here at all. [68k]Sonic_FallCurl: lea (v_player).w,a0 ; load player data into a0 btst #1,obStatus(a0) ; is sonic airborne? beq.s @return ; if not, branch cmpi.b #id_Roll,obAnim(a0) ; is Sonic already rolling? beq.s @return ; if yes, branch btst #bitDn,(v_jpadpress2).w ; is down pressed? beq.s @curl ; if yes, branch rts ; otherwise, return @curl: addq.b #$4,obStatus(a0) ; set sonic's status to rolling move.b #$E,obHeight(a0) ; set sonic's height move.b #7,obWidth(a0) ; set sonic's width move.b #id_Roll,obAnim(a0) ; use "rolling" animation addq.w #5,obY(a0) ; add #5 to sonic's y position sfx sfx_Roll,0,0,0 ; play rolling sound @return: rts ; return to routine ; End of subroutine Sonic_FallCurl[/68k] I've made sure the routine's actually called for and included it properly, but it's still not functioning.
Hello all! I have been working on something and have come to quite a standstill and was hoping someone could help me! See, I had been looking for a certain problem with what map_sonic was, and while I did eventually did find the cause, I was wondering if I could maybe just go around it. From what I have read, every time I save a file as a .asm, I remove all these labels. Is there a way to either keep the labels, or atleast to make it so I don't have to relabel the code every time? I am not very adept at coding, so assume I have no idea what I am doing, because I definitely don't.
I'm assuming you're referring to altering Sonic's mappings with SonMapEd? I don't know of a way to have SME save the data with the original names, but what I usually do is save the mappings/DPLCs to a separate file, then open it alongside the original file in Notepad++, using find/replace to set all the labels back to their proper names before copying the new data over. It's a bit time consuming, but it works.
Thanks, man, you really helped me out! I was doing that, but manually, copying and pasting it will speed it up tenfold! Cheers!
I am back. So I was trying to hack Sonic 2 instead of 1 since it had all .bins, and using flex I got pretty far, until... Any suggestions on what I did so wrong? Any idea is a welcome idea!
