LWJGL Forum

Programming => General Java Game Development => Topic started by: lorcán on November 13, 2008, 20:40:05

Title: Deformable/destructible terrains used as texture
Post by: lorcán on November 13, 2008, 20:40:05
Hi all

I'm making a kind of lemmings game remake using LWJGL. For those who don't know the original game, you can ckeck a description there : http://en.wikipedia.org/wiki/Lemmings_(computer_game) (http://en.wikipedia.org/wiki/Lemmings_(computer_game))

I'm facing a big problem in rendering a level, since it's using derformable/destructive terrains.

A level "scenery" is made of several layers, in the following order :

1 - animated objects (sprites) in the background : moving water, bubbling lava, marshes... These elements are not destructible (whew!  :P)
2 - a big image (BufferedImage) which represents the overall scene (terrain). This main image is drawn using many .PNG's and rendered once (in level initialization) as a single BufferedImage. This large image actually show the destructible/deformable terrain.
3 - others animated sprites in the "foreground", not destructible

On top of this scene, there are the lemmings creatures walking, climbing, ... (individual sprites)

A lemming can dig tunnels in the soil. in carvern walls and so on... You can guess it : soil, walls, etc, are parts of the large BufferedImage (the second layer). This BufferedImage is converted into a texture bound to a quad. Digging in the terrain means that it affects this image making corresponding pixels transparent (we should see the back sprite objects behind = layer #1). As the texture used for the quad is cached, it won't take note of the image changes.  :(

In addition to digging in the ground, a Lemming can also build stairs... Stairs are also destructibe (another lemming can dig in it like in the terrain). This means I should draw stairs in the BufferedImage (replacing pixels). Same problem here.  :(

What do you think about all this?

Are there methods to manipulate specific pixel in a texture currently being used? Is there any way to alter the buffer instead of clearing the cache and reloading the whole picture into it?

I thought about dividing this big pictures into smaller tiles (several quads instead of just on) and reload only concerned tiles when needed.

Any ideas are welcome  :)

Thanks in advance  ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 14, 2008, 01:21:48
Have you thought about using FBO's?

You can just continually minipulate the Image, and then store the changes. Depending on how a projectile will erase the scene you may want to create textures to handle this, draw them to the depth buffer, and redraw the scene(Main Texture) with depth testing on. As for stairs, They would work the other way, draw the scene first then the stairs.

As for collision detection. Thats probably gonna be a head ache. You may need to store a 2 dimesion boolean array to store weather or not a pixel exists.
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 14, 2008, 01:22:34
Here is a very good tutorial on how to implement FBO's

http://www.gamedev.net/reference/programming/features/fbo1/ (http://www.gamedev.net/reference/programming/features/fbo1/)
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 14, 2008, 09:18:42
Thanks for your fast answer, bobjob.

Quote
Have you thought about using FBO's?
No, I didn't thought about FBO's. I even didn't/don't know what they really are :-X I'm going to have a look at the tutorial for further information and details. Do FBO's also apply to 2D games? (Lemmings is 2D)

Quote
As for stairs, They would work the other way, draw the scene first then the stairs.
As stairs are also erasable like the scene (partially, only where they are dug/broken), don't you think stairs should become parts of the main scene? Or should I handle them separately?

In the picture attached to this post, you can see : 1) stairs destroyed by a lemming (a lemming has just dug into these stairs) 2) and 3) lemmings digging in the ground. Note that stairs are built by the lemmings as well, they are not present at the initialization of the level.

Quote
As for collision detection. Thats probably gonna be a head ache. You may need to store a 2 dimesion boolean array to store weather or not a pixel exists.
This is exactly what I intend to do ;) Well, more exactly, I intend to store the state/type of each pixels in an int[][] array. I think this the easiest and most "universal" way to handle a level map, even without having to care about graphics rendering.

Thanks again
Title: Re: Deformable/destructible terrains used as texture
Post by: Ciardhubh on November 14, 2008, 11:40:57
How about that:

This would require something that keeps alpha values and does not replace/blend them with the background colour, so you can later draw it over the background and read alpha values. This is just an idea that might be worth looking into if it works. No guarantuee it will work :)
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 14, 2008, 21:08:40
No, I didn't thought about FBO's. I even didn't/don't know what they really are :-X I'm going to have a look at the tutorial for further information and details. Do FBO's also apply to 2D games? (Lemmings is 2D)
Ok the reason i recommended FBO's, because basically you can render to a texture instead of the screen. You can get the same results using PixelBufferObjects but I figured FBO's are easyer to use, as I dont know how much experience you have had.

Quote
As stairs are also erasable like the scene (partially, only where they are dug/broken), don't you think stairs should become parts of the main scene? Or should I handle them separately?

The reason i said draw stairs after the scene, I ment in regards to minipulating the scene, stuff like bombs would be drawn first to the Depth buffer (hopefully you know about depth testing, if not say so its very easy to explain) then the Texture of the scene would be drawn and tested against the bomb texture. If the scene is, say, behind the bomb texture then it wont draw (thus it would have a hole in the texture).
But with stairs it would work the other way, draw the scene first, then just draw the stairs straight on top. Then lastly save the drawn scene to the scene Texture. After that is done you can draw the characters and such, and also test them against the new scene Texture.

If you weren't going to update the bomb/stair effects to the current scene Texture, you would have to store every explosion throughout the whole game and test alot of them against the characters, and it would be alot of processing for nothing. So its best to just update the scene Image, and that is best achieved through: FBO's, PixelBufferObjects, glTexSubImage2D
EDIT: oops you already know that  :P

tell me which you decide I should be able to give you a basic example updating a texture (except PixelBufferObjects havnt ever worked with them). I think your game idea is cool, and shouldnt be too hard to implement. So Im more than happy to help.

Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 15, 2008, 11:27:43
Quote
Ok the reason i recommended FBO's, because basically you can render to a texture instead of the screen. You can get the same results using PixelBufferObjects but I figured FBO's are easyer to use, as I dont know how much experience you have had.

I must admit I must learn what FBO's really are, how they work, how to handle them... I don't know anything about them however what you say seems much interesting. The only things I can do with LWJGL so far is just convert a BufferedImage into a ByteBuffer, use this for a Texture and apply it to a quad.

I've just read articles and source about GL11.glTexSubImage2D. This seems helpful and is rather "easy" to understand... However I still don't know If I can use transparent pixels in the "SubImage" in order to make pixels transparent in the "main" scene Texture (initilally made with glTexImage2D).

Could you teach me more about FBO's (tutorial, demo, code, or so)? Thanks in advance!

Quote
The reason i said draw stairs after the scene, I ment in regards to minipulating the scene, stuff like bombs would be drawn first to the Depth buffer (hopefully you know about depth testing, if not say so its very easy to explain) then the Texture of the scene would be drawn and tested against the bomb texture. If the scene is, say, behind the bomb texture then it wont draw (thus it would have a hole in the texture).

No indeed, I don't know about depth testing I'd appreciate your explanations :)
What you are stating is fairly easy to understand however it's rather more difficult to convert this in opengl.

Quote
But with stairs it would work the other way, draw the scene first, then just draw the stairs straight on top. Then lastly save the drawn scene to the scene Texture. After that is done you can draw the characters and such, and also test them against the new scene Texture.

Same opinion :)

Quote
If you weren't going to update the bomb/stair effects to the current scene Texture, you would have to store every explosion throughout the whole game and test alot of them against the characters, and it would be alot of processing for nothing. So its best to just update the scene Image, and that is best achieved through: FBO's, PixelBufferObjects, glTexSubImage2D

Yes, this is what I intend to do :)
glTexSubImage2D seems rather easy, but as I've just told you, I don't know if can use this to create transparent pixels yet.

Could you give a comparison between FBO's and glTexSubImage2D? Maybe FBO also uses glTexSubImage2D? Don't know, I have to go into FBO's more deeply...

Quote
tell me which you decide I should be able to give you a basic example updating a texture (except PixelBufferObjects havnt ever worked with them). I think your game idea is cool, and shouldnt be too hard to implement. So Im more than happy to help.

Thank you very much for your support... I really appreciate it :)

Also thanks for your advice, Ciardhubh ;)

Note : I'm absent this weekend (I'm abroad) ... ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: wolf_m on November 15, 2008, 11:32:34
Since this is a 2D game, I'd use a special monochrome bitmap for destruction.

Initially, that bitmap is black where the background is supposed to show through (alpha test result).

Destruction alters the destruction map exclusively; it acts on the non-black parts.

You then use the destruction map as an alpha map for making the background shine through at the right spots (black = opacity 0%).

Collision detection also is solved via the destruction map. That way, you already have your array (a monochrome 2D bitmap is in principle a boolean[][]). No duplicates.

That way, the background remains unchanged and everything is really cheap.

Edit: I see that Ciardhubh's solution is rather similar.
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 18, 2008, 16:41:38
Thank you very much for your kind help.

Here's is what I'm doing :
1) I first draw the scene to a BufferedImage and fill a 2-dimensional int array. I draw each pixel of the scene coming from a large number of PNG's. This operation is done using AWT's setRGB(...) method while reading each pixel of each PNG. I also store each pixel state/behaviour in the 2-dimensional int array for further collision detection and game mechanics. These 2 operations are admittedly but are executed only once (level initialization).
2) I load the BufferedImage into a texture. Note this BufferedImage contains transparent areas.

Rendering the whole game level to the screen uses these "layers" (from the rear to the front) :
1) animated indestructible background sprites (water, lava, ...) = textured quads
2) main scene = the big scene quad textured with the BufferedImage created earlier
3) animated indestructible foreground sprites (doors, ...) = textured quads
4) the lemmings sprites = textured quads

Since the scene BufferedImage won't be changed after its creation, I can keep it as a backup copy (maybe useful if the player would like to restart the level).

When a lemming destroys the scene or builds stairs, I update the corresponding pixels directly in the texture using glTexSubImage2D(...). I have to process each altered pixels separately since stairs and holes are not always rectangles. I mean there can be transparent pixels around the object in the original image so I have to bypass these transparent pixels otherwise it would erase pixels in the main scene.

To do this, I use such the following method after binding :
Code: [Select]
private void setPixel (int x, int y, int red, int green, int blue, int alpha) {
    byte[] temp = new byte[]{(byte)red, (byte)green, (byte)blue, (byte)alpha};
    ByteBuffer subImageBuffer = (ByteBuffer) BufferUtils.createByteBuffer(temp.length).put(temp).flip();
    GL11.glTexSubImage2D(GL11.GL_TEXTURE_2D, 0, x, y, 1, 1, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, subImageBuffer);
}

I can use such a method to draw new pixels as much as to erase existing ones (drawing stairs and destroying terrain).

What do you think about this?

> wolf_m : could explain me how to create and handle such a destruction (alpha) map? Since my scene texture already has transparent pixels (where there is no terrain), does this alpha map only handles terrain "destruction"? Could you tell and explain me the opengl methodsused for this?

> Ciardhubh :
Quote
Removing destroyed terrain could be done with Alpha Testing (e.g. glAlphaFunc with GL_GREATER = 0.5) and a texture that is transparent in the area of the explosion (disable blending, write over background)
Do you mean using an additional texture with only "holes" over the current scene texture? Could you also tell me and explain me the opengl syntax to use in your example?

> bobjob : could you go further with your ideas and explanations? (how you handle destruction in the depth buffer, how you draw steps, how to update e texture using FBO's...).

Thank you very much ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 18, 2008, 19:05:50
Before I give you an FBO example, here is a depth testing example, notice how openGL can do the "hard part" of removing an image with alpha values.
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 18, 2008, 19:28:19
this uses Devil, and lwjgl 1.4... so you should use your own texture code, as well as change the import statement from

import org.lwjgl.opengl.glu.GLU;

to

import org.lwjgl.util.glu.GLU;

main things to notice in the code:
the 'z' value of the scene is different from the effect image.
you would draw stairs in the same way as the stencil style image, except you wouldnt change the GL11.glColorMask values (leave them all true).
when drawings are tested against each other which ever pixel is closer to the viewer will pass.


keys:
G: turn on depth testing
H: turn off depth testing

S: explotion mode
H: "stairs" mode


So Basically make sure Depth Testing is always on. draw the objects you would like to add imprints/stairs then draw the scene. And the variable that changes which you are drawing is the colorMask. You should be able to notice this with the key presses
Title: Re: Deformable/destructible terrains used as texture
Post by: wolf_m on November 18, 2008, 21:42:48
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 19, 2008, 18:28:56
> bobjob : Thank you very much for your explanation and demo sample.

So Basically, if I understand correctly, I should use 3 quads (all fitting the level dimensions)? 2 quads in the rear for destruction/stairs (glColorMask values set to true for the stairs quad, false for the destruction quad). These 2 quads are put at, let say as an example, z -1 and 0. And the third quad in the front for the global scene texture. This third quad (z = 1?) would remain unchanched (as well as it texture) and I should edit the 2 other textures (using GL11.glTexSubImage2D? on both of them). Is this what you expect me to do? Or would I handle destruction and stairs in another way? I understand what your code sample actually does rather clearly but I don't figure out what's at the back of your mind :P Maybe in the next chapter ;)

What do you think about my ideas expressed in the previous post (editing pixels in the main scene texture)?

Thanks again!
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 19, 2008, 21:03:32
basically the way i was thinkn would work like this (with FBO extensions)

This would all be drawn not on screen, but on the FBO texture ->

1. Load all Main textures, keep a copy of them all unchanged.

2. generate 2 FBO's with a new texture wrapped to each one, ill attach another example, but i think its best to understand the tutorial as well as go through the lwjgl version of it (the link from before).

3.
before starting draw the main scene texture onto both of the FBOs (as thiese are the textures that will be minipulated during runtime).

4. When minipulating the scene (again this wont make much sence till you go through the tutorial):
you would bind the first FBO.
a. "Cut out" Images would be drawn before the main scene, at a z = 1 (therefore closer to the viewer) with the color mask set to false.
b. the second FBO texture (copy of the scene) would be drawn at z = 0.
c. "stairs" would be drawn after the scene but still with a z = 1 (same 'z' as "cut out" images).

then you would draw the first FBO onto the second. (this is done because if you draw the scene onto the new scene, Im guessing there will be errors, its good to have the "temp" copy refering to step (b)).

Note: The way the stairs are drawn can be different, you could disable depthTesting, and not worry about its z value, but it might be confusing tryn to track weather on not depth testing is currently enabled, so I suggest just do it the way i explained for starters, you can always tweek the code later.

Once you have drawn to the texture the way you would like it using the FBO extension, you can then just draw the new scene as it will be stored into its own texture (either of the FBO wrapped textures, as the should look the same at this step).

Ill attach an FBO example but i still think in order to get a grasp you should go through the tutorial.

As for collision detection, Im guessing that will be per pixel, so you would need to get the value of each indivual pixel you want to test at a time, and check if its alpha value is = 0, or if you want you could make it if alpha < 0.25f (as that should be close enough). The 0.25f would also look cool, cuz you could have them going through semi-transperant tunnels and not getting blocked :D
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 19, 2008, 21:32:31
You have actually tempted me to make my own online turn bassed Worms game, as a side project.
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 20, 2008, 09:29:15
Waaaaaw! Thank you very much, bobjob. I really appreciate your kind help and explanations!

I've just gone through your FBO demo and I understand what happens, thank you.

Quote
1. Load all Main textures, keep a copy of them all unchanged.

Which textures precisely? The main scene and/or ... ?

Quote
2. generate 2 FBO's with a new texture wrapped to each one, ill attach another example, but i think its best to understand the tutorial as well as go through the lwjgl version of it (the link from before).

Do you mean empty texture when saying new texture?

Quote
3. before starting draw the main scene texture onto both of the FBOs (as these are the textures that will be manipulated during runtime).

We'll "edit" only one of the 2 FBOs, right?

Quote
4. When manipulating the scene (again this wont make much sence till you go through the tutorial):
you would bind the first FBO.
a. "Cut out" Images would be drawn before the main scene, at a z = 1 (therefore closer to the viewer) with the color mask set to false.
b. the second FBO texture (copy of the scene) would be drawn at z = 0.
c. "stairs" would be drawn after the scene but still with a z = 1 (same 'z' as "cut out" images).

a. Do you mean :
#1 : drawing on a single QUAD (altering a single texture during runtime)
or
#2 : using several QUADS with different textures for each imprint/impact (added one after the other)

I'd prefer method #1 since method #2 requires a lot of processing for almost nothing (storing every imprint...), doesn't it? What would you advise me to do?

Same remarks and questions go for point (b)
#1 : drawing on a single QUAD (altering a single texture during runtime)
or
#2 : using several QUADS with different textures for step of the stears (added one after the other)

Quote
then you would draw the first FBO onto the second. (this is done because if you draw the scene onto the new scene, Im guessing there will be errors, its good to have the "temp" copy refering to step (b)).

I can't understand yet why it's necessary drawing the 1st FBO on the second FBO (=unchanged scene texture). Maybe I'll realize later what would happen without using the 2nd FBO. Maybe you mean making FBO#2 an exact copy of FBO#1. I'm not sure I understand what you really mean here.

Quote
Note: The way the stairs are drawn can be different, you could disable depthTesting, and not worry about its z value, but it might be confusing tryn to track weather on not depth testing is currently enabled, so I suggest just do it the way i explained for starters, you can always tweek the code later.

OK

Quote
As for collision detection, Im guessing that will be per pixel, so you would need to get the value of each indivual pixel you want to test at a time, and check if its alpha value is = 0, or if you want you could make it if alpha < 0.25f (as that should be close enough). The 0.25f would also look cool, cuz you could have them going through semi-transperant tunnels and not getting blocked :D

For collision detection and so on, I think I should use a 2-dimensions array as told earlier because each pixel has several properties (not only transparent or not, but also destructible or not, maybe destructible in only one direction (left to right, right to left, from top to bottom, and so on) maybe a terrain area on which lemmings drop through, ....). Handling collision using alpha values is not enough, so I have to handle collision in a separate array, regardless of graphics. However using alpha values like 0.25f for tunnels is a great idea, thank you! ;)

Quote
You have actually tempted me to make my own online turn bassed Worms game, as a side project.

Great!!! :D

I do think the use of FBO is a really good idea since it would also allow me to upscale/downscale a level depending on display resolution without having to worry about resolution when drawing the scene with lemmings, handling collision detection and so on. To do this I'd also have to draw the other sprites into the FBO? What do you think about this feature?

Thank you very much Bobjob. You're an excellent teacher ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 20, 2008, 09:49:05
dude do yo use MSN?
maybe just add me on that and I can clear up the points in order.

with non destructable pixels, you could probably seperate this and make it a whole different texture.
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 20, 2008, 10:07:10
ok.

I also (rather) use gtalk (google talk). And you?

I have to leave now (going to work)

Thanks!
Title: Re: Deformable/destructible terrains used as texture
Post by: wolf_m on November 20, 2008, 11:57:23
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on November 20, 2008, 20:37:04
If you dont have msn maybe just go on the IRC channel
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 21, 2008, 08:12:12
> bobjob: I've just created a new msn account and you're added to my contact list :)

> wolf_m: thank you for your contribution :) I take good note of your advice and I'll try it out. It's not sure yet of every method I'll use in the game. I must perform lots of tests, comparing stuff, ... and learn quite a lot of things! ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on November 28, 2008, 06:38:30
> bobjob : certainly due to the time difference (gmt+1 here) it appears not to be easy to talk to each other using MSN  :P When are you usually connected? (using your local time, I think gmt+11). You can also use the address used by my MSN account in order to send me emails (lorcan....[at]gmail.com)
Title: Re: Deformable/destructible terrains used as texture
Post by: Ciardhubh on December 01, 2008, 15:44:36
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on December 04, 2008, 14:12:34
Title: Re: Deformable/destructible terrains used as texture
Post by: Ciardhubh on December 04, 2008, 22:00:36
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on December 05, 2008, 06:48:49
iv been helping him. Here is a copy of what i emailed him.

The problem with lemmings is, there are conditional pixels, like only remove if lemming is coming from the left/right.

So i sent him a layered example.

It changes each layer, and then adds all layer images to a single depth on the scene image.

its possible to do alpha checks, or depth checks at this point on the entire scene in 1 pass.

Keys:
1,2,3 remove from layer
q,w,e add to layer
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on April 30, 2009, 13:06:10
Hi there.

Sorry for this so late answer. I've been busy lately. Well I'm always busy and I try to find some little time for my numerous hobbies :-p but I often come here and read your posts ;)

After much hesitation, research, ... I realized that I can't use a FBO to handle the whole scene and its dynamic changes due to its large size :(. As you certainly know FBOs, like textures, have a maximum size depending on the current graphics device (usually 4096x4096). For compatibility reasons (with the old games) I intend to use 6400x640 pixels fixed scene... This is more than the usual max texture size... So I'm thinking about splitting this 6400x640px deformable scene into 50 x 5 sub textures (128x128px each) and I would update only the textures corresponding to the altered areas (holes and steps), in real time using glTexSubImage2D.

For performance reasons I might use temp copies of these areas as Image's instead of reading pixels from textures (since reading pixels inormation from textures takes lots of time). I don't know yet...

What do you think about this?

Thanks ;)
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on May 01, 2009, 02:16:36
http://www.mojang.com/notch/j4k2k6/miners4k/ (http://www.mojang.com/notch/j4k2k6/miners4k/)

Here is a 4k game that is very similar to the original lemmings, will need to be improved alot to be what you'd like.
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on May 01, 2009, 07:45:33
http://www.mojang.com/notch/j4k2k6/miners4k/ (http://www.mojang.com/notch/j4k2k6/miners4k/)

Here is a 4k game that is very similar to the original lemmings, will need to be improved alot to be what you'd like.

Yep I remember this mini game. You told me about this 4k "remake" in one of our emails ;)

Well I know all the main (technical) mechanics of the original lemmings so this is not a problem. If I had to do my remake in Java2D it might be finished yet but due to some of the Java2D limitations and constraints (less flowing movements, FSEM not always compatible, speed issues,...) I wanted to do it using LWJGL. The real problem is my lack of knowledge of OpenGL. For instance I didn't know that FBOs have the size restrictions like textures even if it's quite logical :)

What do you think about my idea of splitting the main game deformable scene into "tiles"? Each tiles would be a single texture I'll update on the fly when needed (without displaying those out from the screen)... Thinking of this, I wonder if will meet another problem like a max number of textures? Knowing that the deformable scene would be split into 250 textures (5x50 textures measuring 128x128 px), considering the number of textures used for the lemmings sprites animations (the number of lemmings is not a proble since the same textures are used for identical lemmings) and for the objects sprites animations (traps, doors,...) + the GUI elements, do you think I could store all these textures (even if they're small)?

What do you think about these ideas? :P
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on May 01, 2009, 12:05:18
yeah, your idea is a good approach. If you break the map into tiles, its also may be a good at rendering to the scene as you wont need to draw all tiles (only the visible part).

So theres probably 2 approaches you could take.
1. Manually draw changed pixels, 1 at a time on-screen then grab the new image. Also means you will have to draw offscreen objects to the screen in order to edit them - can be buggy as copying pixels off the screen back buffer is controlled by the OS and when the program looses focus, all hell can break loose, (can be fixed with FBO's).
2. Manually edit a byteBuffer, then generate new textures each render, for the visible map.

I would recommend the second approach as you dont know much about openGL. Also maybe spend some time looking through source code for texture loading. Like 1 important note is that there are 3 bytes for each pixel if the texture is going to be RGB. which means for each pixel you will need to minipulate all 3 bytes.
Title: Re: Deformable/destructible terrains used as texture
Post by: lorcán on May 02, 2009, 08:50:56
Quote
So theres probably 2 approaches you could take.
1. Manually draw changed pixels, 1 at a time on-screen then grab the new image. Also means you will have to draw offscreen objects to the screen in order to edit them - can be buggy as copying pixels off the screen back buffer is controlled by the OS and when the program looses focus, all hell can break loose, (can be fixed with FBO's).
2. Manually edit a byteBuffer, then generate new textures each render, for the visible map.

I thought something similar to #2 : initially, generate all the textures from a BufferedImage containing the scenery (BufferedImage -> ByteBuffer -> glTexImage2D), then update rectangular (smaller) areas in the textures which are concerned using glTexSubImage2D (BufferedImage updates -> ByteBuffer -> glTexSubImage2D). Generating new textures is said to consume more time than updating already existing textures.  I also think about keeping the BufferedImage in main RAM (maybe split into 5*50 BufferedImage's like the corresponding textures, rather than a big single one) for easier (offscreen) operations and access. The updated areas are easy to delimit since we know the size of the mask picture used for the alteration and where this change occurs. From this we can esily define 1, 2 or 4 rectangular "subImage"s to update.

Quote
I would recommend the second approach as you dont know much about openGL. Also maybe spend some time looking through source code for texture loading. Like 1 important note is that there are 3 bytes for each pixel if the texture is going to be RGB. which means for each pixel you will need to minipulate all 3 bytes.

In my situation I'll use RGBA textures this means also a 4th byte for the alpha channel... I need a RGBA scenery because animated objects (sprites) will be moving in front and behind this scenery and these sprites must be visible through "holes" in the scenery.
Title: Re: Deformable/destructible terrains used as texture
Post by: bobjob on May 02, 2009, 12:32:00