Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (636)
Games in Android Showcase (178)
games submitted by our members
Games in WIP (688)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Pocket Tanks ground  (Read 6175 times)
0 Members and 1 Guest are viewing this topic.
Offline bert

Junior Devvie

Miles of road and miles of code

« Posted 2006-06-09 17:19:19 »

I put this in the Game Logic area because it didn't really fit anywhere else. I'm trying to make a program that uses features similar to those in Pocket Tanks where the ground can be eroded or blasted away. I'm having problems figuring out how to keep track of where the ground is and where it isn't. I've tried vectors for the ground's surface, which is a nightmare to keep track of if a hole is blasted far underground, and I don't think a double-subscripted array would be the best because it would fill the memory with 800x600=480000 numbers to just hold the ground data. Another reason why I don't think the vectors would work is because you can see the layers of the earth moving and surface vectors would not be able to reproduce this accurately. With the double-subscripted array you can use an
array to represent each type of terrain. (Or you can use an object, but that would get messy real quick. (In my science class we're having a Pocket Tanks tournament because it's the end of the year. This frustrated me to no end when I could not replicate the ground moving around on my computer at home. I will find out on Monday if I've won the tournament.)

w00t, i'm winning
Offline Malohkan

Senior Devvie

while (true) System.out.println("WOO!!!!");

« Reply #1 - Posted 2006-06-09 19:14:21 »

int[][] data = new int[800][600];  should work fine.  It's really not that big Smiley  You have to store that much info for an image that size anyway and that's no serious drain.  Just have each int represent a color and play with that.  Use a 0 or 255 alpha to know if something is there or not.  That way you can still use gravity and such to pull down pixels that don't have anything below them.

Admin and Game Developer at
Play Rimscape!    |    Play Conquer!
Online CommanderKeith
« Reply #2 - Posted 2006-06-10 03:56:58 »

A harder method would be to let the ground be a polygon & blast chumks out of it using constructive area geometry (see Area & Shape classes).  This could be better since then you could have projectiles ricochet off the ground & also slide down the hill etc since you can work out gradients & angles.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bert

Junior Devvie

Miles of road and miles of code

« Reply #3 - Posted 2006-06-11 23:50:50 »

All right, Malohkan, you've convinced me. It'll work. The storing of the numbers wouldn't be too too bad, but drawing them to the screen would be a pixel-by-pixel ordeal. I've been trying an "optimizing" drawing method that only updates the pixels that have changed. Of course, I might just be afraid to do anything at all graphics intensive because my computer is a slug. (I filled it all up with free downloads and demos... I'll never do that again!) I could probably get away with total update on a better computer but I'm still going to only update the pixels that need it.
Oh, and CommanderKeith, to cause the projectiles to ricochet or roll, to find the slope you just have to use trig on the x and y coordinates of the topmost pixels to either side of the ground pixel where the projectile has hit.
Also, one last thing, I'm also creating a copy of this software in PocketC ( and running it on a Palm Pilot will take a lot of optimizing and stretching my luck. My company website is not up yet but when it is you'll be able to download either version. (I'm not selling this... it's just a little pet project of mine.)

w00t, i'm winning
Offline JAW

Senior Devvie

Medals: 2

« Reply #4 - Posted 2006-06-24 18:27:12 »

I was interested in a WORMS clone and did some experiments. I used a BufferedImage and WriteableRaster to access the alpha date of an ARGB BufferedImage. You can easily set Pixels to visible or hidden. Then you just draw the BufferedImage to the screen. If pixels move, eg if they fall down, you can change the color values of a pixel at a certain position. Collisions are made on the Alpha information of the BufferedImage. If Alpha > 0 it is ground, so the worm stands, the rocket hits, etc.

As long as you have a limited Image size, like one screen, it would work. I am interested in a long jump and run like level, this is far too much for a single BufferedImage, I will need to make some Image loading on the fly.

Message is, try BufferedImage and you dont need per Pixel painting. You can access the Image Data as Array with the WriteableRaster. You get Image data as one dim Array, but convert it into a two dim array using the Image width to divide the data into lines of pixels.

Online CommanderKeith
« Reply #5 - Posted 2006-06-26 14:52:13 »

Oh, and CommanderKeith, to cause the projectiles to ricochet or roll, to find the slope you just have to use trig on the x and y coordinates of the topmost pixels to either side of the ground pixel where the projectile has hit.

But the pixels surrounding the one hit can only be left, right, above or below.... so there's only 4 angles possible, all multiples of 90 degrees.  Maybe worms gets over this by using the 2 nearest pixels to make an angle, giving more possible angles.  Using a path that has floating point coordinates solves this, but for a worms style game - that pixel-based design you have in mind sounds solid. 

I'm just wondering whether it is practical from a Java2D perspective since accessing pixels in an image breaks hardware acceleration so the rendering may be slow...

Offline BloodRain

Junior Devvie

« Reply #6 - Posted 2006-07-31 21:09:45 »

Using rectangles or circles would be easy , but unfortunatelly the fun part of the game is the perfect collision . The main problem is that I don't know yet to get the color of a particular pixel, but I will learn that. I think I will use polygon(with lots of points) collision . Is it faster ? My idea is to create a secondary program that is very slow (but it just doesn't matter because it will be used only in the developing of the game) that makes a polygon from a sprite.I mean some kind of bounding polygon. I'm not sure if I can do this but I will try. 10x again.
Offline Kova

Senior Devvie

« Reply #7 - Posted 2006-08-01 17:46:59 »

about modifying pixels in bufferedimage:
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Dwinin (73 views)
2015-11-07 13:29:08

Rems19 (81 views)
2015-10-31 01:36:56

Rems19 (78 views)
2015-10-31 01:32:37

williamwoles (107 views)
2015-10-23 10:42:59

williamwoles (93 views)
2015-10-23 10:42:45

Jervac_ (111 views)
2015-10-18 23:29:12

DarkCart (135 views)
2015-10-16 00:58:11

KaiHH (118 views)
2015-10-11 14:10:14

KaiHH (157 views)
2015-10-11 13:26:18

BurntPizza (172 views)
2015-10-08 03:11:46
Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48

Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!