Scrolling land and collision detection...Opinions?
BlitzMax Forums/BlitzMax Beginners Area/Scrolling land and collision detection...Opinions?
| ||
| Hold on a sec... |
| ||
| .... |
| ||
| (Had to preview first) Anyway... My goal is to create terrain for an entity to "walk" across and collide with. If you were to do this, would you create a giant sprite out of the terrain(Like, 800x600) and use perPixel collision detection? Or would it be quicker to have an invisible 800x600 binary mask that matches my terrain to determine passable and non-passable areas? In Basic, with it's indexed colour, I could just draw the land to the screen and then when I wanted collision detection, I just sampled the colour of the pixels around my movable character. This won't work without indexed colour, huh. ___________________________________________ If you're curious to see what my last terrain generator looked like, here's a link: http://soldiers.250free.com/OldBASIC_MapRoutine.exe It was done entirely in Qbasic 4.5 five years ago with no libraries installed. The game that used this generator and the source for it is long, long gone. Looks good for using only under 150 (!) indexed colours and only ONE video layer, eh? |
| ||
| This won't work in realtime no mather what kind color. But the pixel perfect collision does something like that |
| ||
| This won't work in realtime no mather what kind color. But the pixel perfect collision does something like that |
| ||
| This won't work in realtime no mather what kind color. But the pixel perfect collision does something like that |
| ||
| I would make my map from tiles, that way you can calculate which tile the player is standing on and only have to do your collision detect with that single tile rather than the whole screen. For example, if the ground was something like this  and was made up from tiles, thus http://www.olpin.net/temp/ground+grid.png for collision purposes, you are only really testing against a few basic shapes: http://www.olpin.net/temp/ground+solid.png As you can see this only actually uses half a dozen different collision shapes.  I've drawn them for illustration purposes, but in application these are regular shapes so you could do the 'collision' with simple maths. Just figure out which tile your player's feet is on then calculate accordingly. For example: 45º slope up /, y=x 45º slope down \, y=32-x first half of a 22.5º slope up, y=x/2 2nd half of a 22.5º slope up, y=(x/2)+16 etc. Assumes a tile size of 32x32, and that x/y are pixel offsets within the tile. |
| ||
| Reckon the easiest way is to have an 800 by 600 image, and just use images collide. Should run plenty fast. Faster than that would be the binary mask you mention, but it will require more programming, and fastest of all would be riks method that only requires a few calculations. |
| ||
| For something like this, Rik's solution is ideal. In fact, just make your landscape out of the shapes Rik suggests, this would allow a huge landscape which takes up minimal memory. Takes me back to the good old days of 8 bit programming...but I digress ;) |
| ||
| Yeah use my method, especially after I went to all the trouble of drawing those pics eh ;) |
| ||
| Wow that terrain generator is awesome I made a game similar to that for the One button competition. http://www.coorrae.com/artillery/artillery.zip I just used ReadPixel for collisions. What you can do instead of having a binary mask for collision, is you can have the foreground be a seperate image from the background, and test if there is a pixel on the foreground's imagebuffer. Using tiles would be ideal if the terrain weren't destructable or if you wanted a larger level though. |
| ||
| I like Riks method, and I use it every now and then. But... for this particular game, like the last version of this game, there will be destructible terrain via explosions and drills and other usable tools. So PerPixel collision is essential. I thought about it last night, and I actually like the idea of using a giant Matrix @ 800x600 for collision. I then have complete control and very fast access. Memory be damned, I have a Gig of ram. (Blitz CAN theoretically access that whole gig, right?) |
| ||
| Why would you need a gig? Even a 32-bit image isn't going to be much more than a couple of megabyte of data. |
| ||
| When I said "Memory be damned, I have a Gig of ram" I wasn't trying to say that one array would fill the whole thing. That would be crazy. I was just saying that memory wasnt an issue for me. And an 800x600 Integer (that's 32 bits, right?) array takes up 14 megs of memory. |
| ||
| You better would learn how to calculate ;-) its 1'920'000 Bytes = ~2mb (800 * 600 * 4 Bytes) |
| ||
| You are both right about the calculations, but why does the program take up 14 megs when I run it then? If you hit ctrl alt delete (in windows 98 or xp, etc) you can actually see how much memory is being used. Mine says 13-14 megabytes. I don't understand why. |
| ||
| Because Blitz uses more memory than just that data you allocated. BMax itself, plus the underlying OGL/D3D, and whatever else is humming beneath the hood. :P |
| ||
| Yeah, that's what I thought. I'm still learning, I guess. |
| ||
| Hiya, Couldn't you simply have a type with heights in. This would be a look up table for where your character can stand. This would be easy to implement, fast to look up, and minimise memory useage. This could almost be as big as you want too. IPete2. |
| ||
| I'm not sure what you mean by a "type with heights", sorry. Is it similar to the matrix I had mentioned? In other news: I, like always, am biting off more than I can chew with the design of this little game. I've never completed a game in my life, because I can't settle for just "getting it done". I'm trying to create a dynamic animation system for my character where he actually walks over uneven terrain with bending knees and properly planted footsteps. It's unbelievably hard. We'll see how it goes. I'm also implementing a fully-customizable weapons-design system (for use while in-game)that would give you complete control over the behaviour of a shell and allow you to make amazing shots and set clever traps for enemies. It's very in-depth and complicated, so I'll likely never finish, but it's so much fun to dream about it and plan it on paper. And these are the reasons I am a hobbyist programmer and not a proffessional one. |
   |