Problem getting angles and rise/run working

[scotthuggins]

I say a small issue, but it's actually a complete pain in the arse! LOL.

In my case depending on how far away an enemy is from my player ship, the BIOS routine: Rise_Run_Angle
returns #14, but the documentation (http://playvectrex.com/designit/chrissalo/rise_run_angle.htm) says in order to convert to Vectrex angle, you must subtract #$10 (90 degrees) in order to use it to in your programs. When I do that it becomes -2 for the angle.

When I then turn around and compute the rise and run values (how much to add to the enemy's X coordinate and how much to add to the enemy's Y coordinate) using Rise_Run_Y ($F601) in bios the numbers seem backwards. Like, instead of +2 for the value to add to Y for enemy, it brings back -2.

This only happens when the player ship is a long ways from the enemy (as far as y,x coordinates are concerned).

Pretty easy to duplicate. Here's the code to gather the angle of the enemy that I point him to in order to chase the player ship. I think it's something with this code. I have tried for several hours to no avail. Any ideas, as always, is much much appreciated.


Code:
; **** THIS SECTION COMPUTES THE ANGLE ALIEN SHIP NEEDS TO EMBARK ON IN ORDER TO CATCH PLAYER SHIP
jsr      dptoc8
lda      ShipYX      ; y,x coordinate of player ship (each are stored in consecutive bytes, y followed by x)
suba   enemyy    ; subtract the enemy's Y coordinate value from the player's Y coordinate
ldb      $c931       ; x coordinate of player ship
subb    enemyx   ; subtract the enemy's X value from player's x value

jsr      $f593       ; get angle where player ship is at
subb   #$10       ; subtract 16 from the angle - this converts to a vectrex angle
stb     ThaAngle  ; store the angle to be used in next lines of code

; NOW THAT WE HAVE "ThaAngle", LETS GET RISE / RUN TO GET THE ENEMY SHIP MOVING
; move enemy #1 towards player ship

lda     #$02                ; a-reg = the scalar velocity value
ldb     ThaAngle           ; b-reg = angle
jsr      $f601               ; calc rise/run <-- this bios function is returning 255 in A reg when player and enemy are far apart from each other or -1 when used as a signed integer
adda   enemyy           ;a-reg = the rise value - add this to enemy's y position
sta     enemyy
addb   enemyx           ;b-reg = the run value - add this to enemy's x position
stb     enemyx

[mountaingoat]

I would recommend that you check that you actually get the right values for he coordinate subtraction.

If you are doing it on 8 bits (which it looks like - suba and subb) then you may get the difference "backwards" right there and then the angle calculated will be also "backwards".

Basically any time the difference is > 127 you will overflow the 8 bit register.

I had the same thing with Sub Wars - you can see that the torpedo may actually turn to go after you going through the edge of the screen. In my case it was desired since that was the shortest distance.

You could try using 16 bit operations (addd and subd) and convert those results back before the run/rise calculations.

[scotthuggins]

Thanks for the reply! Interesting you had the same issue in "Sub Wars" - but that it turned out to be a good thing. I will definitely do the 16-bit route. I'll bet that gets it. It's the angle that is the problem - you are right - once I get that right - the rise/run stuff will be good.

Thanks again.

[christophertumber]

FWIW, IMO, BIOS routines are poo.

[scotthuggins]

Christopher-

Really? You have abandoned them? Would love to hear why. Buggy? Too many cycles or inefficient? Heck, I use them only because they are there.

[christophertumber]

Dec 22, 2015 10:18:16 GMT -5 scotthuggins said:

Too many cycles or inefficient?

This.

Most of the BIOS routines are generalist routines which include a lot of extra overhead for flexibility. They also tend to prioritize code size over speed - unrolling loops from drawing routines, for example, will save you a lot of cycles.

When dealing with 8-bit systems with no built in floats and a slow MUL you're generally way, way better off using pre-calculated tables and pre-rendered sprites than relying on the BIOS to handle anything along those lines (rotation, direction).

Also, a lot of Chris S's innovations (more efficient use of drawing hardware, running code during wait states) require the use of custom routines.

You can also learn a lot by figuring out what the BIOS routines are doing (either at the hardware level or software) and then doing it better.

Hell, just the cycles you save from eliminating a bunch of JSR/RTS calls (IIRC 13 cycles each) add up.

The only BIOS routines I'm currently using are the joystick and button I/O and it's on my todo list to replace them as well. (Only called once per frame so while they're slow (maybe unavoidably), they're not as urgent as drawing or rotating routines which get called dozens of times per frame).

You're not wrong for using BIOS routines and in a lot of cases, especially beginner level projects, they're very useful (easy). But when you get to the point where you really want to push the hardware (Protector, Vector Pilot, Tsunami, my more recent WIPs) you'll be ditching the BIOS routines.

(I've made similar posts on this subject in this forum, if you're interested it may be worth looking back over my posting history for additional details or items I didn't think to include this time - Hmm, maybe I should put together an anti-BIOS FAQ )

[christophertumber]

There's a ton of value in just getting sh*t finished especially when it comes to large projects like a game. Getting anything out that's playable is a huge accomplishment. If using BIOS routines prevents you from getting too bogged down and abandoning a project, stick with the BIOS routines.

In fact, I'd suggest avoiding going down the custom road until you find you need to -> When you're having a problem sustaining the framerate. They're good enough for most of the original games so I'd let your game design drive these technical decisions rather than the other way around.

FWIW, the original Omega Chase (IIRC) uses the BIOS routines (except probably not rotation). So I'm approaching this as someone who's already been there and done that and my ambition is to try to put out both the best and most technically impressive game the console has seen. I'm pretty biased in favour of hardcore optimization over ease of coding.

[scotthuggins]

Great thoughts! I think I wanna go the route you said on this:

>They're good enough for most of the original games so I'd let your game design drive these technical decisions >rather than the other way around.

I've gotten lucky so far to keep a stable framerate.

[kokovec]

This is why I started to experiment with off-board FPU's and 3D engines.
They are soooooo much faster and a 32-bit ARM processor can burn through complex calculations.
One of my 3D rotation routines uses quaternions. I also implemented LERP functions and collision detection used matrices.
Of course the 8-bit purists shudder at the thought of using acceleration hardware but as you probably guessed I'm not such a beast.
I remember while writing Koko's Retiribution I stumbled my way through the Rise/Run routine. It's terribly inefficient but I ended up using it anyway. The "guardian" uses it to find Koko.
Keep at it, you'll eventually be writing your own routines to get around the pokey ones found in the BIOS.

[scotthuggins]

>Of course the 8-bit purists shudder at the thought of using acceleration hardware but as you probably guessed >I'm not such a beast.

I don't fault you at all for that....however, I agree with Christopher - why not push the 'existing' hardware to see what you can do with it? I have a strong feeling the sense of gratification would be much more. But, maybe that's just me.

I hope everyone has a great holiday season.