Ah, that might be the thing. I'm using the Xenowhirl disassembly though, and it listed no such command (and when I try to it makes an error). (Ah, wait, think I have something, it's $FFFFF7CF, right?)
I'm porting over the Homing Attack (don't judge) from Sonic 1 Legends into Hivebrain ASM68K, and there's a couple of lines that say something like 'move.w #$FFFFFF93,d0' and when I go to build it, it's telling me there's some sort of overflow. I don't know what this means and how to fix it, and I know I'm on this thread a lot, but that's because I'm the stupidest human being to ever walk the earth. Any reply on the former matter would be appreciated.
You're trying to move something that's too big for the specified instruction size. That .w means that you should be moving only two bytes (a word) and you're trying to move 4 (a longword). Hence why you're getting an overflow error. But, if I'm right, the overflow isn't the actual problem. I suspect that this line is actually meant to be moving something from memory, so you need to get rid of that # to fix it. Of course, without being able to see the line in context, there's no way for me to know that for certain. And not having an actual example of the error doesn't really help either. More than any of this, you NEED to go back and start with some basics instead of trying to port over other peoples' flashy exciting features. Do the boring stuff already and then come back when you've earned your spurs. You're clearly not able to understand the code that you want to port over and you may as well be slamming your head into a brickwall unless you level up. You won't ingratiate yourself to us with self-deprecation. If you know that you're asking a lot of questions, go away and actually do some learning.
I've mostly cleaned up the control lock attack, there just seems to be one leftover bug. If the player uses the move on something that forces them into rolling mode they are stuck in control lock until they are forced into the air. I'm guessing I have to implement a clr control_lock note somewhere but it doesn't seem to recognise it anywhere in Md_Roll.
I had a similar problem when I implemented the drop dash (not with control lock specifically, but similar). I believe I fixed it by having the non-player-object setting the state on the player object. You could try that.
Alright, alright, fine. I'll drill some knowledge into my skull. I have found some documentation, so that'll help, but don't expect you've seen the last of me here. Anyway, removing the # seemed to do the trick. The air dash works fine, but when I lock on to an enemy, the game crashes. I'll work that one out myself though, sorry for being so arrogant. Edit: K, so I've learned a few move commands. I wrote a practice function which basically clears some data in certain registers and replaces the data. Is this correct? Practice: clr.l d0 ; clear data reg 0 move.l $#123456 ; move hex into reg 0 clr.b d1 ; clear a byte of reg 1 move.b d0,d1 ; copy byte to reg 1
Not exactly... Firstly, your "move.l" will trigger an error for two reasons. Firstly, there's no destination operand, you wanna move 123456, but you haven't specified where, I think you might have forgotten to put ",d0" on the end. Secondly, the $ and # symbols are the wrong way around. The # will always come first. Code (Text): move.l #$123456,d0 One final thing... The "clr.l" you had on d0 before is not necessary. The reason being, you are moving a long-word number into d0, so the entire register will be replaced anyway, if you were just moving a word or a byte, then maybe the upper parts of the register you might want or need clearing, but any long-word moves will overwrite everything, so clearing isn't necessary. I think this'll help you: http://mrjester.hapisan.com/04_MC68/ =3
Thanks. I've realised just how needy I've been sounding, and your tutorials are really helpful, they explain a lot more that the documentation I was looking at. Edit: Here's the polished and corrected version: Practice: move.l #$123456 d0 ; move data into d0 clr.b d1 ; clear a byte from d1 move.b d0,d1 ; copy a byte from d0 to 1 I've added a destination operand to move.l and removed clr.l like you suggested, and good news: it works!
I didn't notice before, but your second clr isn't necessary either. At any rate, I'm glad you're trying, well done~
@AppleSauce Great to see you getting stuck in. Remember, you can always build a ROM with your code in it to check your syntax.
Thanks. I think my problem was I was being too arrogant and taking your advice the wrong way, thinking it was negative in a way. Really? I always thought there were values already loaded into the registers, but alas I wrong :|
There are, but if you're moving a value to the register anyway, you don't have to clear it first, unless you're moving a word and you want to be able to read it as a longword, or you're moving a byte and want to read it as a word/longword, then you'd use clr.l/clr.w before move.
Okay this one isn't urgent and more a little theoretical if anyone wants to join in, so lower priority than the other people on here. Is it possible to make the dynamic background in HTZ just be a still image? I've been dabbling in trying to make HTZ splitscreen compatible recently and I've made odd steps to making the dynamic background look right, however obviously the scrolling causes issues shared between two screens. Also does anyone know what might be the cause for the moving scenery from the earthquakes being invisible in splitscreen? Is there a certain routine it needs to go through for its art to load on there?
You want to have a look at SwScrl_EHZ, SwScrl_EHZ_2P and SwScrl_HTZ. That's GitHub naming, it might be loc_C57C, C6C4 and C964 elsewhere. I don't think HTZ has any animation besides scrolling in the background. I suspect that's also where you'll find the source of the issue with the invisible scenery. There's a SwScrl_HTZ_2P routine that is normally unused in-game, but you'll probably be tripping into it. Now, if you ever manage to get the SLZ/CPZ foreground pillars working properly in splitscreen, let me know In fact, do you mind me asking what your plans are for splitscreen? I've already got a hack out that fixes some problems with versus play. DM me, if you prefer.
So, I added in the Super Peelout to Sonic 1, recently. And, I'm having trouble making the sprites load. Any help?
What exactly do you mean by that? Like is the actual charging up animation not showing up, or the fact the peelout sprites don't show up when going super fast?