What are you working on? V5

[Eleventeen]

bool CVideoLayerOpenGL::run(void)
{
	if(art == 0) // No art?
		return true;
	
	#ifdef _JE3D_OS_WINDOWS_
		SwapBuffers(deviceContext);
	#endif
	
	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	glLoadIdentity();
	
	// - Bottleneck code start here.
	
	// Begin drawing the art.
	float x, y;
	x = -1;
	y = -1;
	
	glBindTexture(GL_TEXTURE_2D, art->getImage()->getTexture());
	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, art->getImage()->getWidth(), art->getImage()->getHeight(), 0, GL_RGBA, GL_UNSIGNED_BYTE, art->getImage()->getData());
	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
	
	glBegin(GL_QUADS);
	glTexCoord2f(0, 0);
	glVertex2f(x, y);
	glTexCoord2f(1, 0);
	glVertex2f(x + artWidth, y);
	glTexCoord2f(1, 1);
	glVertex2f(x + artWidth, y + artHeight);
	glTexCoord2f(0, 1);
	glVertex2f(x, y + artHeight);
	glEnd();
	// End drawing the art.
	
	// - Bottleneck end here.
	
	glFinish();
	glFlush();
	
	return false;
}

[Cathbadh]

[QUOTE=Zekian;18993686]To prevent the Z-fighting, could you not just disable the Z-Buffer while rendering shadows?[/QUOTE]
That Z-buffer is the entire reason I can create shadows on the scene. I don't draw any color when rendering shadow, I'm just basically recording how far the light travels from the sun before hitting an object in the scene. With every pixel I draw from the camera's point of view, I calculate where it would hit on that depth buffer from the light's point of view and compare it with the value recorded in the buffer.

[editline]04:11PM[/editline]

[QUOTE=Eleventeen;18993837]

bool CVideoLayerOpenGL::run(void)
{

...
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, art->getImage()->getWidth(), art->getImage()->getHeight(), 0, GL_RGBA, GL_UNSIGNED_BYTE, art->getImage()->getData());
...

}

[/QUOTE]
You're uploading the image of the art to texture memory [i]every time[/i] you draw the buffers? No wonder it's slow.

[s0ul0r]

Didn't think that coding a tower defense game in xna would take that much effort :D
Coding buttons, placement functions etc. etc. etc. enemy kills, removing them, adding gold, upgrades, pheew.
But I just used event handlers for the first time and it works great, whenever I create a new Button from my Button class, I have a custom function that handles the click :D (Yes it's great for me :D)
A little screenshot from my progress:
[IMG]http://img24.imageshack.us/img24/7052/mytd.png[/IMG]

[Cathbadh]

[QUOTE=nullsquared;18985913]
Or, if all your objects are closed, you can instead render their backfaces into the shadow map (instead of the front faces), and then you get automatic biasing without having to do anything.[/QUOTE]
That would work all the time if it weren't for normal mapping
[img]http://img691.imageshack.us/img691/1798/screenshotsm2.jpg[/img]
See where I've circled the face of the cube? Raised lettering on it in the normal mapping makes it behave as if it should be illuminated when in actuality, it should be in shadow (I'm not doing any depth biasing in this screenshot) I still get artifacts from this stuff and the way phong maps work out.

I guess one thing I might try would be to bias what gets drawn to the shadowbuffer. Don't draw faces where the dot product between the face and the light direction are merely positive, make sure that the product is like greater than 0.01 or something. This will discard the faces that are just barely in shadow.

[Eleventeen]

[QUOTE=Cathbadh;18993892]That Z-buffer is the entire reason I can create shadows on the scene. I don't draw any color when rendering shadow, I'm just basically recording how far the light travels from the sun before hitting an object in the scene. With every pixel I draw from the camera's point of view, I calculate where it would hit on that depth buffer from the light's point of view and compare it with the value recorded in the buffer.

[editline]04:11PM[/editline]

You're uploading the image of the art to texture memory [i]every time[/i] you draw the buffers? No wonder it's slow.[/QUOTE]

I fixed that, but it is still slow.

[Cathbadh]

[QUOTE=Eleventeen;18994387]I fixed that, but it is still slow.[/QUOTE]
The rest of the code isn't that bad. Consider putting those drawing commands in a display list or something? The fewer commands over the graphics bus the better. You also only need to specify texture parameters once per texture, so that's redundant.

[Eleventeen]

But I update the texture a lot.

[Cathbadh]

[QUOTE=Eleventeen;18994609]But I update the texture a lot.[/QUOTE]

Then you put it in shared video memory.

If you have to update your textures all the time, perhaps you're doing it wrong. The graphics pipeline should be doing most of the work.
Tell me what exactly is changing that you need to update the texture all the time?

[Eleventeen]

I have a texture of a bitmap that holds all the tiles on the screen.

[Ortzinator]

[QUOTE=Pirate Ninja;18988180]I actually think it's from gparent but im not sure.[/QUOTE]

Chandler was making a clone of it.

[Cathbadh]

[QUOTE=Eleventeen;18995704]I have a texture of a bitmap that holds all the tiles on the screen.[/QUOTE]
Tiles? What does that mean in this context?
Do the tiles change at all such that you need to reprocess them from disk all the time, or what? I'm still confused about exactly why you need to continually update this one single texture. Couldn't you just have opengl draw individual tiles and make each tile it's own texture?

[editline]05:44PM[/editline]

[QUOTE=Jallen;18985589]If you slapped cool effects on everything and ditched the crappy textures (e.g. the grass) it would look a lot more impressive with minimal effort.

Still, p. damn cool.[/QUOTE]
I'm only concerned with technical issues at this point. I'm better at coding than content creation.

[Eleventeen]

[QUOTE=Cathbadh;18996133]Couldn't you just have opengl draw individual tiles and make each tile it's own texture?[/QUOTE]

That'd complicate the process.

[Chandler]

[QUOTE=Ortzinator;18995997]Chandler was making a clone of it.[/QUOTE]

no? Gource is merely a visualization of a git repo. (Supports SVN now apparently). I was merely showing its existence :P

[Cathbadh]

[QUOTE=Eleventeen;18996439]That'd complicate the process.[/QUOTE]
I happen to think it is a lot simpler and much faster than trying to blit every tile onto a backbuffer and then uploading the backbuffer as a texture.

[Eleventeen]

[QUOTE=Cathbadh;18996963]I happen to think it is a lot simpler and much faster than trying to blit every tile onto a backbuffer and then uploading the backbuffer as a texture.[/QUOTE]

so theres no way in hell to do it this way

[ZomBuster]

Was messing around with some kind of randomised weapon system for a shmup
[media]http://www.youtube.com/watch?v=binOUmoEWU8[/media]
[media]http://www.youtube.com/watch?v=kS68VyzOvRU[/media]

[Cathbadh]

Eleventeen: do you see the text I have in the upper-left of my screenshots displaying the fps? That is done entirely on the GPU. The only thing that the CPU has to do is process the text as a string, and it uploads the string through the opengl api. The graphics pipeline reads this as an array of display list references, and each display list draws each character as a textured quad. Not only that, but it draws this text to an offscreen renderbuffer so that I can treat the whole thing as a text box. This was a decision made because text does not often change on screen, so the entire text box is seen as a single texture (actually a renderbuffer) that I need to only render into once per text update, and I can just tell opengl to blit the buffer right on top of my rendered scene. This is an incredibly fast and cheap operation.
What I am getting at is that the same technique can be applied to your tiles. They are each individual textures that can just be overlayed on top of the background graphics in the opengl pipeline. Way faster than using the CPU to blit things, ala SDL graphics.

[turby]

Wait... let me get this straight...

Is Eleventeen rendering the entire screen as an image before sending to the graphics card? whut

[nullsquared]

[QUOTE=Cathbadh;18994340]:words:[/QUOTE]

I think you're making things way more complicated than they need to be. Just render front faces with a tiny bias (like depth + 0.01 /* adjust this */) and do plain old shadow map comparison and make a screenshot.

[Cathbadh]

Results I am much happier with. Notice that the raised lettering on the face in shadow no longer is lit.
[img]http://img35.imageshack.us/img35/7906/screenshotsm3.jpg[/img]
Doing stacked shadowmaps seems like a good idea. You can see aliasing going on in the shadows in the background, and keeping the texture-lookup always using the min filter seems like a good idea to make sure shadows are soft.

[editline]06:35PM[/editline]

[QUOTE=nullsquared;18997501]I think you're making things way more complicated than they need to be. Just render front faces with a tiny bias (like depth + 0.01 /* adjust this */) and do plain old shadow map comparison and make a screenshot.[/QUOTE]
That was like the first thing I did, but it looked like garbage. What you see above discards the very incidental faces from the shadowbuffer, and it effectively got rid of the shadow banding effect from before.

[Shanethe13]

[QUOTE=ZomBuster;18997179]Was messing around with some kind of randomised weapon system for a shmup
[/QUOTE]

That looks awesome, especially if you vary the actual mechanics of each weapon, instead of making them all shoot straight with small changes in accuracy.

[ZomBuster]

[QUOTE=Shanethe13;18998559]That looks awesome, especially if you vary the actual mechanics of each weapon, instead of making them all shoot straight with small changes in accuracy.[/QUOTE]

Yeh good idea, was thinking about that. Like a homing factor which ranges from slighty tilting towards enemies to just going straight at them, spiralling, drunken movement etc.

[Chandler]

[QUOTE=ZomBuster;18998742]good idea... drunken movement...[/QUOTE]

So you're giving the weapons kung fu powers? :colbert:

[Eleventeen]

[QUOTE=Cathbadh;18997321]Eleventeen: do you see the text I have in the upper-left of my screenshots displaying the fps? That is done entirely on the GPU. The only thing that the CPU has to do is process the text as a string, and it uploads the string through the opengl api. The graphics pipeline reads this as an array of display list references, and each display list draws each character as a textured quad. Not only that, but it draws this text to an offscreen renderbuffer so that I can treat the whole thing as a text box. This was a decision made because text does not often change on screen, so the entire text box is seen as a single texture (actually a renderbuffer) that I need to only render into once per text update, and I can just tell opengl to blit the buffer right on top of my rendered scene. This is an incredibly fast and cheap operation.
What I am getting at is that the same technique can be applied to your tiles. They are each individual textures that can just be overlayed on top of the background graphics in the opengl pipeline. Way faster than using the CPU to blit things, ala SDL graphics.[/QUOTE]

What?

[efeX]

good 'ol cath essay response

[andersonmat]

[QUOTE=Eleventeen;19000402]What?[/QUOTE]

Do you need someone to break it down for you? :downs:

[Cathbadh]

[QUOTE=Eleventeen;19000402]What?[/QUOTE]
It's called off-screen rendering. Instead of rendering to the framebuffer, I render to another buffer in video memory. You can do this too with your system and will offload work from the data bus to pretty much your GPU exclusively.

[Eleventeen]

[QUOTE=Cathbadh;19000768]It's called off-screen rendering. Instead of rendering to the framebuffer, I render to another buffer in video memory. You can do this too with your system and will offload work from the data bus to pretty much your GPU exclusively.[/QUOTE]

Is there some kind of simple.wikipedia.org entry for that?

[Cathbadh]

I highly encourage you to read the opengl specification manual.
Read the core version first: [url]http://www.opengl.org/registry/doc/glspec32.core.20091207.pdf[/url]
Then move on to the compatibility version: [url]http://www.opengl.org/registry/doc/glspec32.compatibility.20091207.pdf[/url]
Most of the old 1.1 stuff you have been doing is legacy api stuff and found in the compatibility profile of OpenGL

[Eleventeen]

I can't wait to read these walls of text! Woo!

wheres my scotch