Collision data: 8 or 16 bit?

[DoNotWant]

Part of the problem is that neither the C Standard nor POSIX nor the Windows ABI specifies a 24-bit integer type.

So a good Pascal compiler targeting the 6502? Subrange Types could perhaps be a solution to this.

[zkip]

Suppose I wanted to make it that way; 8bit. 4 bits of pixel and 4 of subpixel. Before I try this and possibly screw myself over, is that plausible for 1 screen? Something like using bit math to separate the two nybbles into temp zero page RAM then add them as if they were 16bit? Would I then catch the overflow from the carry and then add it to the lower nybble? But how would the carry even get set because it wouldn't go over $ff. Would it be considered "hackish" if I just check if the lower nybble is larger than $0F and manually set the carry flag?

In my calculations which are probably wrong, this would make $48 essentially be 4.5?

[Joe]

4 bits of pixel

You'll be able to move a total of 16 pixels. You'll probably need more bits than that for a game.

But how would the carry even get set because it wouldn't go over $ff. Would it be considered "hackish" if I just check if it's larger than $0F and manually set the carry flag?

Why do you need the carry flag?

[zkip]

You'll probably need more bits than that for a game.

This is for the acceleration of the player, not the actual coordinates. I'm pretty sure I won't need more.

[tepples]

4 bits of pixel

You'll be able to move a total of 16 pixels. You'll probably need more bits than that for a game.

For Sonic, maybe. But is there anything in, say, Super Mario Bros. 3 that moves more than +/- 8 px/frame, crossing the screen in a half second? The fastest thing I remember from that game is the large cannonball from the tank levels in World 8 "Dark Land". I've read its scrolling engine goes haywire if Mario exceeds 4 px/frame.

[zkip]

I'm still struggling with this. Just getting around to trying the method described earlier and I'm back in the same boat. Granted, the player has more smooth gravity, but the jump is still the same. It's sort of a "snap" jump. Adding the constant as you described in the code as START_JUMP still makes this same problem. I adjusted the values to fit this scenario, but it's still that same "snap" jump as I had to begin with. I think it's because rather than decreasing its setting it to a certain value? Rather than jumping it just snaps to whatever value that constant is relative to its position. I'm so confused with this.

[GradualGames]

Make sure that if you're using two bytes for Y, that you're using the higher of the two bytes for your world (and screen, for a single screen game) Y coordinate. Make sure when you set the velocity to a negative value that you only do it once, at the start of a jump. This requires that you detect an off-to-on transition in the controller, and if the button continues to be pressed you'll only see on-to-on transitions, and you won't reset the velocity again. Finally make sure you're adding a constant positive acceleration to the velocity on each frame, as well as adding velocity to your Y coordinate each frame. Again, using only the high byte of the Y for your actual world/screen coordinate (just pull out y_coordinate+1 when deciding where to draw the sprite). Not sure if that helps, maybe post your asm file again to inspect. It's probably something small.

It might even be worthwhile to practice sub pixel movement in isolation before going all the way to a jump (like, no other logic, just accelerate, or decelerate, moving in one direction on X or Y perhaps). Though you did say you've got smoother movement, now. If the jump is then too fast, as you describe, the only guess I have is that when you set the initial velocity it is much too high and maybe you're setting the high byte of the velocity when you want to be setting the low byte to some negative value, and the high byte to $ff (you need to sign extend...). Note in my original example, lda #>START_JUMP should be setting the hi byte to $ff (because START_JUMP is negative, the assembler should sign extend for you when you use > ). you'd use lda #high and lda #low instead of #> and #< in nesasm.

[tokumaru]

Also important: if positions are 16.8 bits, and speeds are 8.8 bits, you have to sign-extend the speeds when adding them to the positions. If the speed is positive, you have to add $00 to the high byte of the position, otherwise you have to add $ff. I normally handle this by branching based on the N flag after loading the speed for adding:

Code: Select all

	clc
	lda SpeedFraction
	adc PositionFraction
	sta PositionFraction
	lda Speed
	bmi AddNegativeSpeed
AddPositiveSpeed:
	adc Position+0
	sta Position+0
	lda #$00
	beq Finish
AddNegativeSpeed:
	adc Position+0
	sta Position+0
	lda #$ff
Finish:
	adc Position+1
	sta Position+1

[zkip]

I'm going to set down and study this and like you mentioned try it separately from everything else. If that doesn't work I'll go read up and try to see if I can do it in a higher level language for practice, then come back to the NES with it. Thank you both for being so helpful.