I've been playing around with using the Plot system to make sprites, and I figured I would rewrite Tanks to use the new system. I would also add some to capabilities into Tanks, thus, Tanks 2 is now an open project.

I'm still putting the game together, and I have a few questions.

1) Whats the best way to store 3D Location data, simple to render?

- The system in Tanks 1 stores enemy location along a 32-point list, wrapped around a theoretical circle with the player in the middle. this means that the player cannot move. I clearly would like a better way to store the field. However, if field creation and render is too complex, I will ditch it; Ill just use a 320-point list and work on this some other time.

- No, Tanks is not in 3D! I just would like variable distances from you to also be added, giving you the option to move around.
No longer necessary, I scratched something together. However, it will likely need to be optimized by someone who knows what they are doing.

2) about how long is an acceptable render time?

3) the current render system is slow because of sprite merging. Plots only accept three list pairs, so I must merge sprite lists . what is the fastest method for appending one list to the end of another?

4) How should I judge a tank's Armor? Some of the tanks I have selected have "classified" under their armor thickness, but I do have type. Should I consider Weight as part of your armor?
Ugh. Thats all I can say about my 'scratched-together' x/z graphical system. It takes over 3 minutes to render a single frame - so i ditched the render code, and decided to ask you all for help.

The easiest way I can think of this working is checking if points are greater than a specified binomial; if they are, they are displayed. Otherwise, they arent. I can rotate the turret 90 degrees this way by x*-1 to the x or z coord of all items on screen, and can have a fine-aim option for within those 90 degree quadrants.

~~~I have no idea how to test if a point is greater than a prescribed function.

Once rendering works, then ill start working on the rest of the game.
In that yellow-green text there, you touch on the idea of figuring out storing the field. As I think I briefly touched on at some point, Your best option is to just use the screen to figure out when a tank needs to fall or when a projectile has hit the ground. If you track the position of each on-screen object (which should be a small number of items), you just Pxl-Test( while a projectile is flying or an object is falling to determine when it should stop. Creating a list of (number of pixel columns) elements is definitely not a route you should take.
As i also talked to you about on the SAX, this is an x/z plane, not an x/y plane. Tanks have nothing No height stored to them.

The best way i can describe the camera system is like anarchy (this program, minus the up/down movement.

Naturally, the tanks also wont need to move as much, but that does allow the kind of veiw im trying to get.
Hmm, from those screenshots of Anarchy I didn't get a good sense of the game, and I'm afraid I didn't take the time to download and try it. So if tanks have no height stored in them, then it's a top-down view? I'm afraid I'm having trouble visualizing what you mean, unless it's a top-down/birds-eye-view, in which case it makes perfect sense. However, in that case, I'd assume the map was flat.
Neither. You veiw from the turret's position; imagine a 3d game using 2d sprites; i need to render where on the x_axis the tank would be. There is no y_axis here, since the land is flat (to simplify things), and the z_axis is reported to you via text. Maybe i can make a mockup of what im envisioning.

mode7 engines use a simulated x/z plane, if that helps. Sure, moving tank/rotating turret wont be rendered per frame (select where you want to go by entering coords, then the game rerenders the scene), but it would be [lightly] like that.
Well, i scrapped engine two (uses a matix for rough display of position, turned out even slower than previous edition), and have been brainstorming for engine Try #3. Im wondering if maybe i could cut frame render speed by using the window values somehow. Will experiment.
Given how long its been, I'm dropping the idea of using a garage type deal here. However, I've finally gotten tanks 2 working on the render side.

Important peices of math in 3d positional rendering:
(9/DEPTH)X = X position on screen (9x9 field)
DEPTH = sqrt( (X[object]-X[camera])^2 + (Z[object]-X[Camera])^2) ***distance formula, which is secretly the pythagorean theorem***

Right now the Y position on screen is just the horizon; i want it to be 'the greater the depth, the less distance between object and the horizon'. Still figuring this out.

Also, sprite sizes increase depending on depth.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum