Problem with defining variables

[pacgreg]

Ok so I cannot for the life of me define a variable, as simple as it is, i always get syntax errors. I just want to set d=1 and VbB is saying no.

[pacgreg]

oops accidentally posted this twice since the first one didn't show up.

[+Random Terrain]

Your error might be caused by something else. You might want to post your .bas file.

[pacgreg]

Ok, so I looked around a bit more and found out how to set variables, but once I put in everything, I get a black screen, could you or someone else take a quick look at this? I'm trying to keep a record of the angle to the enemy with _DIR, and put it on screen when it's between 1 and 160.

default.bas

[SeaGtGruff]

One problem I see is that you have an extra column in your playfield statement-- i.e., you're defining 33 pixels per row instead of 32. I'm not sure if that breaks anything, but I'd fix it if I were you.

 

Another thing, you end your check routine with

if joy0left  then goto _LEFT
if joy0right then goto _RIGHT

but then your _LEFT and _RIGHT routines both end with goto check. Won't that cause the program to keep looping and never jumping back to the beginning of mainloop as long as joystick 0 is being pushed left or right?

[bogax]

_dir is not dimmed as 16 bits, 8.8 or as 4.4 so you can't add 0.75

to it I don't think

 

variables are 8 bits so the max value is 255 (360, 358 wont work

DASM chokes on that for me)

 

what SeaGtGruff said

Edited August 18, 2013 by bogax

[+Random Terrain]

You're also trying to use numbers like 358 and 360. Except for working with the score, you can't go over 255.

 

pacgeg_2013y_08m_18d_0107t.bas

[pacgreg]

Thanks all, it now compiles, the new problem is now _DIR doesn't seem to be updating, or the score=_DIR or if statements checking _DIR aren't picking up anything.

pacgeg_2013y_08m_18d_0107t.bas

[+Random Terrain]

Thanks all, it now compiles, the new problem is now _DIR doesn't seem to be updating, or the score=_DIR or if statements checking _DIR aren't picking up anything.

 

I put this code into your program:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#testvariables

 

I put _DIR on the left side of the score and you can see by looking at the score that it is changing:

 

pacgeg_2013y_08m_18d_2216t.bas

 

What is _DIR supposed to be doing? What do you want it to do?

[pacgreg]

I'm trying to use _DIR to track the angle from the character to the enemy, sorta like the radars from battlezone, robot tank, and submarine commander. Any tips on how to make it work any better would also be very nice.

[SeaGtGruff]

I'm trying to use _DIR to track the angle from the character to the enemy, sorta like the radars from battlezone, robot tank, and submarine commander. Any tips on how to make it work any better would also be very nice.

Is _DIR supposed to be the angle measured in degrees? Is that why you were trying to use values like 358 and 360?

 

You mentioned Robot Tank and other games. In your game I take it you want the player to be able to rotate left or right and move forward or backward, such that the angle between where the player is facing and where the enemy is located is always changing, as well as the distance between the player and the enemy?

[pacgreg]

Exactly SeaGTGruff, right now I'm trying to get it to work in atleast horizontal scroll tracking in this test game before I go trying to add more to the main project. RT's code does fix the updating problem, will see if I can tinker with it until it functions as I wanted it to.

Edited August 21, 2013 by pacgreg

[SeaGtGruff]

Exactly SeaGTGruff,

I'm not sure what the best way to do that would be. And I haven't studied this problem before, so I'm stumbling through it, myself. But on a fancy computer (read: a machine that's faster and has more RAM than the 2600), you could (1) calculate the vector between the player and some point "on the horizon" where the observer is facing, such that this vector defines the "0 degrees" or "12 o'clock" angle. Then you could (2) calculate the vector between the player and the enemy, and from there (3) calculate the angle between the "0 degrees" vector and the vector to the enemy. Step 3 would involve a conversion from Cartesian coordinates to polar coordinates, assuming you're working with Cartesian coordinates to begin with.

 

Here's a rough example-- and remember, I'm stumbling through this, myself. I'm going to use six variables for the three sets of Cartesian coordinates:

 

XC = the X coordinate of the center (i.e., the point where the player is located, since everything is centered around the player's point of view).

YC = the Y coordinate of the center (or player).

 

XF = the X coordinate of some point the player is facing.

YF = the Y coordinate of some point the player is facing.

 

XE = the X coordinate of the enemy.

YE = the Y coordinate of the enemy.

 

Let's say the game is being played on a 15-by-15 grid, where the X axis ranges from -7 to +7 (left to right), and the Y axis also ranges from -7 to +7 (bottom to top), such that coordinate (0, 0) is at the center of the grid.

 

Let's say the player is always considered to be at coordinate (0, 0)-- i.e., whenever the player moves to a different coordinate, the new coordinate becomes (0, 0) and everything else shifts up or down or left or right accordingly.

 

Let's say the player is facing coordinate (4, 7), and the enemy is at coordinate (-3, 5):

 

 

So in this picture the red lines represent the vectors (direction being faced and direction to enemy), and the blue arc represents the angle you're looking for.

 

I'm going to have to do a little reading to get the right formulas, but they'll involve trig functions. So I assume that for a 2600 game it would be simplest to use polar coordinates from the get-go, meaning you aren't keeping track of the Cartesian coordinates per se but are maintaining the enemy's angle and distance from the player so that no conversions are needed.

[SeaGtGruff]

Okay, back to my example!

 

Converting from Cartesian coordinates to polar coordinates is easy with a computer or calculator.

 

Polar coordinates are expressed in terms of the distance and the angle.

 

To get the distance R, you use R^2 = X^2 + Y^2. Solving for R gives you R = SQRT(X^2 + Y^2). For my example, we don't care about the distance to the point we're facing, just the distance to the enemy, so that's as follows:

 

R = SQRT(X^2 + Y^2) = SQRT((-3)^2 + 5^2) = SQRT(9 + 25) = SQRT(34) ~= 5.83...

 

To get the angle A, you use TAN(A) = Y/X. Solving for A gives you A = ARCTAN(Y/X). For my example we need (1) to angle to the point we're facing and (2) the angle to the enemy. Then we can get the angle between them.

 

For the point we're facing, the angle is as follows:

 

AF = ARCTAN(YF/XF) = ARCTAN(7/4) = ARCTAN(1.75) ~= 60.255...

 

For the enemy, the angle is as follows:

 

AE = ARCTAN(5/(-3)) = ARCTAN(-1.6_6) = ~= 59.036...

 

Note, however, that both of these angles are measured with respect to the X axis (horizontal line at Y=0), and the quadrants are also important. In this case, to get the angle between the two vectors we can add the two angles and subtract their sum from 180:

 

A = 180 - (AF + AE) = 180 - (60.255 + 59.036) = 180 - 119.291 = 60.709

 

Of course, you'd also need to know that the enemy is to the left of the player, so that's about 60.709 degrees to the left of center, or roughly a "10 o'clock" position on the radar.

 

Now, I don't think it will be feasible to do these calculations on the 2600 during your game. However, if you're assuming that the game is being played on some kind of grid (as in my example), and that the grid has a finite size, you could compute the values ahead of time and store them in a ROM table, then look them up as needed. You need only two tables-- one for the angle, and one for the distance.

 

For a 16x16 grid, each table would be 256 bytes, which is a nice, convenient table size. Anything bigger than a 16x16 grid will make the tables harder to work with and require more ROM-- for example, a 32x32 grid would require 1024 bytes per table. And you might want to use a grid with odd numbers-- like 15x15, as in my example-- so there's an equal number of coordinates on all sides. That isn't necessary if you let the grid be bigger on some sides, like from -8 to +7 rather than from -7 to +7. But if it were me, I'd probably use 15x15 and have two 225-byte tables.

 

If you're assuming that the grid has a finite size, there's also the question of how you handle when the player moves around-- that is, does the grid move too? I think it would be simplest to pretend that the grid always moves with the player, such that the boundaries are always the same distance away. Then you can pretend that the enemy can never get too far from the player-- that is, if the enemy is at (-7,0) and the player moves toward (7,0) or directly away from the enemy, pretend that the enemy moves too, keeping up with the player. So the enemy can get closer to the player (or vice versa), but never gets farther away than a certain distance.

 

I think what you need to do for now is decide how you want the grid to work (if you're going to be using a grid)-- how big is it, etc.? Because that will determine how you proceed.

[pacgreg]

Wow, That's amazing., almost converting the 2600 into a scientific calculator and using ray casting to find the enemy. Sounds pretty complicated and I'd like to try it out later, but for now I worked out the kinks in the scrolling and have a pretty nice little horizontal turn loop that breaks down 360 degrees into 12 that go up every 30 cycles. If I get some time in the next few days I'll try making another test game like the one I was working on, but with your idea.

[pacgreg]

By the way, can batari or 2600 even have trig functions or square roots, or would you need to derive them into four functions?

[SeaGtGruff]

By the way, can batari or 2600 even have trig functions or square roots, or would you need to derive them into four functions?

As I said, the easiest thing to do would be to compute the values ahead of time for every point on the grid and store the values (angle and distance) in tables. It's easy enough to do all the calculations in a minute or two with a spreadsheet: