Quickie Q on movement

[Sivak]

Ok. I'm doing the part involving moving the sprite around and wanted to know this:

If I want to just use one routine to move around, 1 pixel at a time, would having it so one variable = 1 or 255 be acceptable?

So you basically do this:

Code: Select all

LDA spriteXposition
CLC
ADC (either #$01 or #$FF)
STA spriteXposition

Or should I just have two routines, one for addition and subtraction?

[Bregalad]

Do it like you prefer. You could do something like that :

Code: Select all

ldy Direction
lda XPosition
clc
adc PosAddTbl,Y
sta XPosition
...

PosAddTbl
.db $01, $ff

But when doing a more complex game engine, you'll have to move 16-bit coordinates and do collision detection, etc... So you'll probably end up with different (but similar) routines for each direction.

[Celius]

I think you should have just one addition, but that's my opinion. Though in my scrolling routine, I do subtractions to scroll left and up, but this actually avoids complications in this case. Depending on what kind of game it's really a good idea to have the object handled with the same code no matter if it's facing left or right. If you have lots of objects, this will save you a lot of space in the long run.

But Bregalad is probably right about the 16-bit coords. You are probably going to want to deal with precision bits (Like .5 pixels) so you can move something at 1.5 pixels a frame, or to give something a parabolic effect for gravity and such. But you can still use the "addition for subtraction" method for 16-bit, all you have to do for the code Bregalad posted would be:

Code: Select all

ldy Direction
lda XPosition
clc
adc PosAddTbl,Y
sta XPosition
lda XPositionHigh
adc PosAddTbl,Y
sta XPositionHigh
...

PosAddTbl
.db $01, $ff
PosAddTblH:
.db $00,$ff

Though there are several things you can do to optimize this. I currently have to heavily optimize some of my AI code. If you were going to access that table a lot, you'd probably want to do something like this:

Code: Select all

ldy Direction
lda PosAddTbl,Y
sta ZTempVar1
lda PosAddTblH,Y
sta ZTempVar2

lda XPosition
clc
adc ZTempVar1
sta XPosition
lda XPositionHigh
adc ZTempVar2
sta XPositionHigh
...

PosAddTbl
.db $01, $ff
PosAddTblH:
.db $00,$ff

Where "ZTempVar" is a temporary variable in Zero Page. If you don't have any space reserved for TempVars in ZP, I highly highly advise reserving about 8 bytes for them.

[tepples]

I've been debugging Balloon Fight (JU) lately. As I strongly suspected, it uses 64 bits for each of 9 characters' position and velocity, 16 bits for each coordinate:
8 bits X displacement high
8 bits X displacement low
8 bits X velocity high
8 bits X velocity low
8 bits Y displacement high
8 bits Y displacement low
8 bits Y velocity high
8 bits Y velocity low

[smkd]

I'm using seperate routines for updating speed, split into X and Y which can each handle negative numbers but since some entities don't move in both X/Y it makes sense to seperate them.

I'm actually using the same speed format (for enemies) as SMW since I could just grab its routine at the same time.

1 bit sign
3 bits integer
4 bits fraction

So everything fits into one byte. For the player I needed more gradual movement so I added an extra byte for some more fraction bits (currently using a 12bit value).

[Celius]

Your idea actually sounds very practical, and something like it for my engine would be very great, actually. Currently, my game can only scroll at 8 pixels a frame at max, so I set myself a limit so that no enemy or object can move faster than 8 pixels. Also, this would be bad because a 4x4 pixel object if moving faster than 8 pixels a frame could fly through an object, which is bad if it needs to collide with it. Most objects that it'd need to collide with are at minimum 8 pixels wide, so this is good. The 3 bits integer would still allow me to keep the speed under 8 pixels a frame. Though I'm not going to use that exact format, it may give me some ideas to modify some things.