Archived

This topic is now archived and is closed to further replies.

2D Line Terrain

This topic is 5022 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently attempting to make a version of the following game: http://www.ebaumsworld.com/helicopter.shtml for MIDP 1.0. I've got my plane working with physics / animation / control etc.. and now I want to add the terrain, using just drawLine() similar to this... I want to randomly generate this terrain on the fly, so that the player can keep going until they crash (with their score then deicded by the timer). I will need to check for collision between the player sprite (a rectangle - im not too bothered about perfect collision atm). What's the best way to go about this? Do I create a terrain class that stores the points for each vertex in a vector and decrease each x co-ord by a fraction each frame? How would I go about checking for collision between a rectangular sprite and a line which may or may not be sloped? [edited by - LazyManc on April 15, 2004 7:35:42 PM]

Share this post


Link to post
Share on other sites
Well, you seem to have a plan for the terrain generation so give it a try (experiance is the best way to learn). Don''t worry about optimisations just yet, your game looks fairly straightforward at the moment.

As for collision detection, you could try modifying the Sutherland-Cohen clippling algorithm (where your plane''s collision rectangle is the ''screen'') or just use the y=mx+c formula to determine if any of the corners are above/below the roof/floor (not as good as it can miss peaks).

Skizz

Share this post


Link to post
Share on other sites
quote:

Do I create a terrain class that stores the points for each vertex in a vector and decrease each x co-ord by a fraction each frame?

Sounds like an idea. I don''t know about decreasing the x-coord each frame though. I would probably add a "world-position" to the plane object and offset the terrain according to that (keping the terrain object static).
quote:

How would I go about checking for collision between a rectangular sprite and a line which may or may not be sloped?


You can use line line intersection.

shmoove

Share this post


Link to post
Share on other sites
I would create a number of "slices" - images that contain pieces of the terrain. Create them at startup and reuse to avoid allocation / deallocation (when a slice falls off the LHS, reuse it on the RHS). using the Image API clear the new slices and draw lines for the floor / ceiling in the new slices, just before they appear on the RHS.

Keep track of where the floor and ceiling start / finish on a per-slice basis. Work out which slice(s) the plane is intersecting with, and do some kind of crude comparison (perhaps with linear interpolation to work out the actual floor / ceil height at that point). So if the bottom of the plane is below the ground, it''s crashed (and top also).

If you want to put obstacles in (like the flash game) you have to remember where they are too and factor in accordingly.

Mark

Share this post


Link to post
Share on other sites
Yay. This is offtopic. But I''m making (not far from done) a game that works just like that.



And here''s the new menu I really like how it turned out:



If you''re making it using lines you should probably just count the difference bettwen the first X (where the line start) and the X where the plane is. Then you need to figure out the Y at and by using a simple if (plane_y > line1_y_at_planes_place || plane_y < line1_y_at_planes_place) then Collide()

/MindWipe



Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There''s an old text game called "caves" where all you do is fall down a cave and try not to die.

It''s the same thing you''re doing except the "cave" is scrolling sideways instead of up.

Look at the source for that game and you should be able to figure out how to do it with graphics.

Share this post


Link to post
Share on other sites
Thanks for the help, it's starting to click now.

quote:
I would probably add a "world-position" to the plane object and offset the terrain according to that (keping the terrain object static).


The main reason I wanted to generate coords on the fly was because I don't want the player to ever run out of terrain. If the terrain object is static wouldn't I have to create all the points (and therefore a limited amount of them) before the game runs? If i'm incorrect blame it on my poor programming skills

I want to keep the x coordinates of the vertices alligned for top and bottom, so I should only have to store 1 x coord for both points, correct? I'll probably only need 3 or 4 points (in x) on screen at once, so can I use the following method to store them:

I was thinking of checking to see when the 1st point in the vector x position was < 0, and if it is, then it's off the left of the screen and I can remove it from the vector, and then generate a new set of points and append to the end of the vector? Is this an incredibly slow / poor way of doing it? What would be better?

quote:
I would create a number of "slices" - images that contain pieces of the terrain. Create them at startup and reuse to avoid allocation / deallocation (when a slice falls off the LHS, reuse it on the RHS). using the Image API clear the new slices and draw lines for the floor / ceiling in the new slices, just before they appear on the RHS.


I was considering doing it that way but it's my understanding that i'd then have to make sure all the slices started and ended at the same height so that they lined up, or at least create a series of them that joined up in various places, and then pick the correct ones? At the minute i'm just concentrating on getting it working, i'm not too bothered about how it looks, but thanks for the suggestion.




[edited by - LazyManc on April 16, 2004 2:29:07 PM]

Share this post


Link to post
Share on other sites
Hmm, i'm starting to confuse myself here. I've never used vectors in Java so bare with me for a minute or two...


import javax.microedition.lcdui.*;

public class Terrain
{

public class Vertex
{
private int x;
private int y1;
private int y2;
}

private Vector terrainVec = new Vector();

public Terrain()
{
// Create vector of 4 initial points

}


public moveTerrain(int speed)
{
// decrease x coord of each point by a fraction each frame
}


public void paint(Graphics g)
{
// paint terrain at new position
}
}



On the right track? Or completely the wrong way to do it?

The only thing that's confusing me at the minute is this; when i'm removing old vertices that have passed off the left of the screen, and I want to add a new vertex to the vector, can I just change the data in the old one and add it back to the end of the vector? Is this a stupid way of doing it?

[edited by - LazyManc on April 17, 2004 6:14:26 AM]

Share this post


Link to post
Share on other sites
It''s probably easier just to have a circular buffer using a fixed size array big enough to hold enough points to draw the screen and then some, and two indices: one for the left hand most vertex and one for the right hand most vertex.

Messing about with vectors could badly fragment your memory.

Skizz

Share this post


Link to post
Share on other sites
I second that opinion. If you know offhand the maximum number of vertex (is that the plural?) you''ll have, then using a Vector will just generate unnecessary overhead.

shmoove

Share this post


Link to post
Share on other sites
Well I managed to get it working, it's probably very poorly coded but the framerate seems pretty high on my T610. I ended up using a custom vector class someone lent me.

Terrain.class

I will probably go through and replace the vector bits with a fixed size array at some point but for now I just need to get the collision sorted.

Back to y = mx + b I think...

[edited by - LazyManc on April 18, 2004 11:37:25 AM]

Share this post


Link to post
Share on other sites