Hey,
I'm looking at ways to proceed with a game idea I had a while ago and abandoned to pursue another game ... It needs there to be bitmap editing, much like Worms had, where earth can be 'eaten'. Now, of course this could be done using blocks of 10x10 or 40x40 pixels, but then the game is too rigid. I would like to be able to smoothly 'eat' the earth, but this introduces a few problems:
- Firstly, how to do it in the first place. Previously, I simply had a mask bitmap and a background bitmap, and would eat from the mask to show through the background.
- Collision detected - how do you know if ground has already been eaten ...
I guess one question would be - What is the most efficient way to store a mask of 'eaten ground'? A 2d-array of bools? A single array of Bools (storing x * y + y, or whatever the method is! Can't remember precisely!) or is there a more native way? Plus, whatever method is required then needs there to be edits to it - if it were a bitmap, for instance, you could just call a filled circle routine on it to wipe out ('eat') a circle of earth ... Maybe not the biggest hurdle to overcome but still important.
And naturally - this all has to be done in realtime as it's not a turn-based game but rather a bug that can eat through earth !
Thanks in advance
Editing Bitmaps A.K.A "Worms"-style ...
Could you perhaps use one pixel images in an array and then destroy the images when the ground is "eaten?" This would of course lend to a solid color very boring looking ground.... So maybe you could have a ground pattern and only use one (different) pixel of the image... or even just changethe SColor of one pixel. Then you could even have a random earth tone for each image resulting in a nice random patterned ground .... then take away the images when the ground is eaten...
This way you don't have to actually edit an image...
This way you don't have to actually edit an image...
Last edited by Dances on Sun May 06, 2007 10:33 pm, edited 1 time in total.
Theres no need when he can decide to draw the pixels or not.Dances wrote:Could you perhaps use one pixel images in an array and then destroy the images when the ground is "eaten?" This would of course lend to a solid color very boring looking ground....
Why not do it in 3D with terrain deformations?
Dances - Not sure if I understand you, actually... You mean hold a separate 1-pixel image for every single square (pixel) in the game?
BlindSide - the game's actually going to be 2D (Although I'm using and learning Irrlicht for a 3D game I'm working on) - so is that going to be overkill? Will it allow for pixel-precise edits? Or are you simply suggesting something that would be very cool but silly for something like this?! Cheers!
BlindSide - the game's actually going to be 2D (Although I'm using and learning Irrlicht for a 3D game I'm working on) - so is that going to be overkill? Will it allow for pixel-precise edits? Or are you simply suggesting something that would be very cool but silly for something like this?!
Cheers!Well what I mean is you would have a one pixel texture and load it. You would then draw that texture for every pixel in the screen. You could create different SColors with rand() so that your texture would variate. Then you would have to use if statements to prevent the dirt from drawing when it is destroyed.
This would probably require a retarded amount of bools (one for each pixel, to stop it from being drawn if it is alive) and you would have to test each one for collision.
Someone can probably come up with a better solution than I XD
If I knew enough to know what BlindSide is talking about I might shut up ^.^
This would probably require a retarded amount of bools (one for each pixel, to stop it from being drawn if it is alive) and you would have to test each one for collision.
Someone can probably come up with a better solution than I XD
If I knew enough to know what BlindSide is talking about I might shut up ^.^
@Dances:
Using that much seperate images is asking for trouble (out of memory errors, sounds familiar ?
).
In 2D you should just use one or two image masks and blend them with your images to get the result you want and to check for collision. By accessing the texture data, you can change the image depending on your masks. Look into how AND,OR and NOT operations can be used to manipulate your image with a mask.
Using that much seperate images is asking for trouble (out of memory errors, sounds familiar ?
).In 2D you should just use one or two image masks and blend them with your images to get the result you want and to check for collision. By accessing the texture data, you can change the image depending on your masks. Look into how AND,OR and NOT operations can be used to manipulate your image with a mask.
Dances - thank you for your help, I do appreciate it!
Robert - as this is what I've concluded also (although wondered if there was a better way) - what would be the most efficient bitmap storage method? It only needs to hold a single bit per pixel, and needs rapid read & writes. Plus, although I can make the game screen-based (tiling multiple screens worth of bitmaps) it would be even better if I could simply make the bitmaps big enough for larger levels. This brings a few other problems:
- If it's done within a graphics system, will I start having to play nicely with texture sizes on the graphics ram?
- Bitmap's are huge - even just a 1-bit bitmap. What's the realistic limits?!
Looking (again) at something like worms: The game ran smoothly on a 486 (or whatever it ran on) with no graphics card to speak of, so processor wise it's not that intensive. It was turn based, so real-time editing never occured, but it was always smooth enough that in todays PC's real-time should be fine. It's not a worms-clone I'm making by any means, just this is the closest to quality earth-eating I've seen.
Death Worm does something similar - but as it does no collision detecting on 'eaten ground' it doesn't help me beyond that. However - interestingly - it obviously stores the areas that have been eaten, or uses multiple bitmaps tiled, as if you 'eat' a lot of earth your tracks will start to disappear at the end. I've not looked deeply enough into this to find out if it's a gradual fade off or an entire page at once, but that's another game with something similar.
Thanks again!
Robert - as this is what I've concluded also (although wondered if there was a better way) - what would be the most efficient bitmap storage method? It only needs to hold a single bit per pixel, and needs rapid read & writes. Plus, although I can make the game screen-based (tiling multiple screens worth of bitmaps) it would be even better if I could simply make the bitmaps big enough for larger levels. This brings a few other problems:
- If it's done within a graphics system, will I start having to play nicely with texture sizes on the graphics ram?
- Bitmap's are huge - even just a 1-bit bitmap. What's the realistic limits?!
Looking (again) at something like worms: The game ran smoothly on a 486 (or whatever it ran on) with no graphics card to speak of, so processor wise it's not that intensive. It was turn based, so real-time editing never occured, but it was always smooth enough that in todays PC's real-time should be fine. It's not a worms-clone I'm making by any means, just this is the closest to quality earth-eating I've seen.
Death Worm does something similar - but as it does no collision detecting on 'eaten ground' it doesn't help me beyond that. However - interestingly - it obviously stores the areas that have been eaten, or uses multiple bitmaps tiled, as if you 'eat' a lot of earth your tracks will start to disappear at the end. I've not looked deeply enough into this to find out if it's a gradual fade off or an entire page at once, but that's another game with something similar.
Thanks again!
I would use a byte per pixel per mask. This way you don't have to do slower bitconversions and if you use values 0 and 255, you can AND it directly with your image pixel values. It takes 8 times more memory, but a few MB more or less nowadays isn't a problem anymore. If your levels are very big, you may have to store bitwise however. But this will slow you down.what would be the most efficient bitmap storage method? It only needs to hold a single bit per pixel, and needs rapid read & writes.
I wouldn't use the textures for this, as they are very limited in size, but for rendering you could copy the part of your bitmap to a texture.- If it's done within a graphics system, will I start having to play nicely with texture sizes on the graphics ram?
- Bitmap's are huge - even just a 1-bit bitmap. What's the realistic limits?!
About size: I don't know the game, so I don't know exactly what you're trying to do, but 3000x3000 pixels in 256 colors results in a 9 MB image and mask, so that wouldn't be a problem. In my software I most of the time try to limit the needed memory to somewhere between 64 and 128 MB.
Out of its context, that sounds weirdjust this is the closest to quality earth-eating I've seen
Robert,
You're right about the Space over Size issue. I guess I'm looking for an efficient way to do something that's not really a common requirement!
My current frustration, then, is with 2D rotation - I know how to go about it, but it's much harder than need be!
Hmmm --- would it be worth simply setting the Alpha value of a bitmap instead, or is this too slow (accessing bitmap memory and writing it)?
Cheers for the help!
You're right about the Space over Size issue. I guess I'm looking for an efficient way to do something that's not really a common requirement!
My current frustration, then, is with 2D rotation - I know how to go about it, but it's much harder than need be!
Hmmm --- would it be worth simply setting the Alpha value of a bitmap instead, or is this too slow (accessing bitmap memory and writing it)?
Cheers for the help!
2D rotation isn't that hard. For speed, don't do realtime math calculations, but use a lookup buffer instead for sin, cos etc. Or simply have a set of precalculated rotated sprites in memory, so you don't have to calculate anything in runtime.My current frustration, then, is with 2D rotation - I know how to go about it, but it's much harder than need be!
It's essentially the same, but to load a bitmap, you probably have to put it in a texture, so it becomes size limited.Hmmm --- would it be worth simply setting the Alpha value of a bitmap instead, or is this too slow (accessing bitmap memory and writing it)?
That's true, I forgot about the size limitations! Darn, surely there's a simple way to do software bitmaps, and then simply blit the part of the software texture (so completely graphics card independent) to the video card?
Yes, the lookup-table for COS/SIN/etc is definitely required. That being said, I've never been impressed by the routines - even the slow ones - for rotation that I've seen, and my math isn't good enough to write a better one than I've seen. Just artifacts like drift and slight alterations in size that (somehow!) the graphics card can do natively in 3D. Why the facilitiy isn't available in 2D I'll never know. Of course, there's texturing a quad and rotating that - but it doesn't 'feel right'! That's one of the drawbacks (IMO) of SDL - the rotation (rotoZoomSurface or whatever it's called!) suffers from those artifacts. Not to mention it's slow, but then you can cache the output ...
I'm working on two games at the moment - this one is a little back-of-mind-curiosity, the other is 'the project' I've been working on for years in various forms. I've just found a need for a piece of software that doesn't (appear to) exist in PHP, and no doubt my brain power - already limited - will now be stretched across another project!!
Thanks for the help!
Yes, the lookup-table for COS/SIN/etc is definitely required. That being said, I've never been impressed by the routines - even the slow ones - for rotation that I've seen, and my math isn't good enough to write a better one than I've seen. Just artifacts like drift and slight alterations in size that (somehow!) the graphics card can do natively in 3D. Why the facilitiy isn't available in 2D I'll never know. Of course, there's texturing a quad and rotating that - but it doesn't 'feel right'! That's one of the drawbacks (IMO) of SDL - the rotation (rotoZoomSurface or whatever it's called!) suffers from those artifacts. Not to mention it's slow, but then you can cache the output ...
I'm working on two games at the moment - this one is a little back-of-mind-curiosity, the other is 'the project' I've been working on for years in various forms. I've just found a need for a piece of software that doesn't (appear to) exist in PHP, and no doubt my brain power - already limited - will now be stretched across another project!!
Thanks for the help!
Maybe you could take a look at www.clonk.de (available in German and English). It's a shareware game (one or two versions are open source) using directx and some kind of "digging" that could be compared with that of worms. Maybe you could get some ideas there (they're NOT using irrlicht - pure DX).
I've never played Worms, so I'm not exactly sure what you're doing, but here's an idea.
When the ground gets eaten, place a bitmap at the location it was eaten and place the location of the eaten section in an array.
If the worm attempts to eat again, check through the array to see if there is already an area that has been eaten nearby. If there is, then don't place another bitmap there, if there hasn't, then just place one there.
I hope this makes sense. If not, I apologize lol.
When the ground gets eaten, place a bitmap at the location it was eaten and place the location of the eaten section in an array.
If the worm attempts to eat again, check through the array to see if there is already an area that has been eaten nearby. If there is, then don't place another bitmap there, if there hasn't, then just place one there.
I hope this makes sense. If not, I apologize lol.
Ico - thanks, that game looks interesting - just for playing purposes but also definitely along the lines of 'earth eating'!
Phant0m51 - You've NEVER played Worms?! It's a pivotal and classic way to waste, sorry - Spend - your time. Srsly!
OTOH - this is designed to have 'earth eating' done very frequently (need a better name than earth eating, lol! It's terrain modification...) as in at the game's FPS, as a player will (nearly) constantly be moving around, so collision detection on said eaten-ground and terrain removal of non-eaten ground...
Argh! Too many ideas and projects floating around. Honestly, I've just started working on my new PHP File Server and it's actually making progress, a word I haven't been able to use for quite a while recently (Game coding
)
Phant0m51 - You've NEVER played Worms?! It's a pivotal and classic way to waste, sorry - Spend - your time. Srsly!
OTOH - this is designed to have 'earth eating' done very frequently (need a better name than earth eating, lol! It's terrain modification...) as in at the game's FPS, as a player will (nearly) constantly be moving around, so collision detection on said eaten-ground and terrain removal of non-eaten ground...
Argh! Too many ideas and projects floating around. Honestly, I've just started working on my new PHP File Server and it's actually making progress, a word I haven't been able to use for quite a while recently (Game coding
)