next »

[mcc]

Sometimes I think I should use a graphics library where it does not take a substantial amount of time to write the code to draw a gray rectangle.

Heresy! (What do you use now, and which language?)

OpenGL ES in C++.

So I go "oh-- I need to draw a single semitransparent rectangle over the screen at a certain point in my display code." So I scratch my head, and I copy and paste, and I tweak some stuff, and this turns out to be the simplest I can do.

Code:

	if (board_obscured) {
		States(false, false);
		quadpile scratch2;
		scratch2.push(-1/aspect,-1,1/aspect,1, false);
		scratch2.megaIndexEnsure(6);
		jcColor4f(0,0,0,0.8);
		int stride = VERT_STRIDE;
		jcVertexPointer(2, GL_FLOAT, stride*sizeof(float), &scratch2[0]);
		glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, &quadpile::megaIndex[0]);	
	}

Aside from just being incredibly unreadable... actually hold on, I'll comment it

Code:

	if (board_obscured) { // If the screen must be dimmed:
		States(false, false);  // Turn off color and texture arrays
		quadpile scratch2;  // Build a vertex array containing one quad made of two triangles
		scratch2.push(-1/aspect,-1,1/aspect,1, false); // that covers the entire screen:
		scratch2.megaIndexEnsure(6); // Build an index array
		jcColor4f(0,0,0,0.8); // Set color-- black, semitransparent
		int stride = VERT_STRIDE;
		jcVertexPointer(2, GL_FLOAT, stride*sizeof(float), &scratch2[0]); // Set vertex array
		glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_SHORT, &quadpile::megaIndex[0]);	// Draw
	}

...and I'm just sort of horrified, really, is this the simplest I can make things? It doesn't seem so bad when I set things up just so and then I'm drawing entire scenes in a single draw call, but then I keep getting into "... oh wait, one more thing" situations and then I find myself having to do something horribly convoluted like this.

[Eraser]

I've gotten around to playing with some object orientation in PHP, but I'm abstracting things way too much I think... finding it difficult to decide when to stop!

[Glaiel-Gamer]

So I go "oh-- I need to draw a single semitransparent rectangle over the screen at a certain point in my display code." So I scratch my head, and I copy and paste, and I tweak some stuff, and this turns out to be the simplest I can do.

This is why you should never just write raw opengl code like that. Wrap all the opengl stuff you have in a wrapper that you're comfortable using.


For instance, I have a "fillScreen" function which does exactly what you just said, draws a screen-sized rectangle. So if I wanted to draw an untextured transparent rectangle, I'd just do

Code:

Texture::unbind();
Blend::alpha.enable();
fillBuffer(0, 0, 0, .8);

OpenGL's not meant to be a graphics engine, it's just the bare bones you need to get shit displayed on the screen and access GPU functions.


for the record, my graphics layer for closure consists of the following core classes:
Texture
FBO (frame buffer object, i.e. render-to-texture)
VBO (vertex buffer object)
Shader
Blend
MatrixStack
ColorMatrixStack
Graphics (handles init, windowing, resolution, swapping buffers, etc)



that's it. All draw calls go through the vertex buffer class, and one shader and one blend mode and one frame buffer can be enabled at a given time, everything else is built on top of these.

if you write a good vertex buffer class all your problems will go away, suddenly all you got to do is populate the vertex buffer with the vertex data you need, then its just one call to render it whenever you want.

I have a few static "preset" vertex buffers like ScreenSizeQuad and Square1x1

[Sean A.]

I need to keep chipping away at my game but I can't bring myself to do it, I haven't been in the coding mood for a week 

[_Tommo_]

-cut-

This would fit much better in "Bad Coding Habits" 

[Nix]

This is why you should never just write raw opengl code like that. Wrap all the opengl stuff you have in a wrapper that you're comfortable using.

This is the best advice for anyone trying to figure out how OpenGL would work with the rest of their code.

When building my engine, I spend maybe the first five days with OpenGL getting the graphics functions I wanted sorted out. Now I don't touch the stuff because it's all nicely contained within a few classes such as SpriteDrawer and ShapeDrawer.

[mcc]

Well... that's the direction I've been generally trying to move in, but the problem I keep running into is that when I make an attempt to wrap, there's always some special case that my wrapper isn't expressive enough to cover. And then it's whelp, back to filling out vertex arrays.

(I realize this means that my wrappers aren't very good at the moment, but knowing that doesn't necessarily fix the problem...)

[Glaiel-Gamer]

*cough* write a wrapper for your vertex arrays (i.e. vertex buffers)

[Triplefox]

Either make a really high level and limited abstraction or a really stupid low level one that gives you almost nothing more than raw GL or DX would. The middle ground is the worst, but the low and high level options are usually surprisingly profitable.

[Glaiel-Gamer]

I have both, I have a low level API (the stuff I showed above) then a higher level API above that which does animations, sprites, fonts, effects, splines, curves, resource management, etc. The higher level API is written on top of the lower level one so if I need a one-off I can use the low level API (vertex buffer object class).

Its more than sufficient for a 2D game. For GGE 3.0 [glaiel game engine 3] I'm definitely adding in some scenegraph and quad/octtree stuff though. Rendering shit in closure ("engine" nicknamed GGE 1.0) is super easy but I really really wish I put a layer of abstraction in there that could like sort by texture and whatnot rather than just rendering in an extremely linear fashion. My new thought is objects should have both a depth and a layer (renders lowest layer to topmost layer, uses z-buffering for depth, and within a layer objects can be arbitrarily sorted by the renderer to reduce texture swapping / whatever). Of course none of that really depends on low level access so it can be completely 100% separate from the low level API.

[Nix]

I think I have like 4 graphics layers, and I find myself using them all at different occasions. There's the raw OpenGL, then some simple wrappers to simplify drawing sprites, then the interface I have for my Lua component system for accessing those wrappers, and then the pure Lua code for higher level graphics things like animations.

[PTibz]

Looking for C/C++/C# internships is a serious pain in the ass due to their availability. Now learning PHP because there are a ton of open jobs, but I can't stand PHP so far. 

[J. Kyle Pittman]

Fun thing I learned today: Vista will try to request elevated access for any executable with "patch" in the file name. If you want to circumvent that, you have to mess around with the manifest. Or just rename the file.

[TobiasW]

Looking for C/C++/C# internships is a serious pain in the ass due to their availability. Now learning PHP because there are a ton of open jobs, but I can't stand PHP so far. 

Maybe you're already doing this, though I thought I'd mention it: If you like C#, you could try looking for Unity internships too.

[MeshGearFox]

All programming jobs around here are Java; I hate Java. fml.

[Average Software]

My networking code works great on Linux, great on the Mac, but Windows has to be an asshole.

[oahda]

My networking code works great on Linux, great on the Mac, but Windows has to be an asshole.

Are you surprised?

[Player 3]

I can't decide on a programming language to use! Should I go C++ and SDL? What about Processing? Scala? AS3 won't have any easy way on Linux. Could you guys suggest the one I should stick with?

[RetroX]

I can't decide on a programming language to use! Should I go C++ and SDL? What about Processing? Scala? AS3 won't have any easy way on Linux. Could you guys suggest the one I should stick with?

I don't really like SDL; it's too complicated for what it is, imo.

Try SFML; it's simple, object-oriented, and pretty fast.  It has Python and C# bindings if you want to get into those, but I much prefer C++.

I would recommend C++ (the elite language) over all others, but I'm clearly the least helpful person to talk to; I'm extremely biased about it (C++ is the best, though).

[Player 3]

I can't decide on a programming language to use! Should I go C++ and SDL? What about Processing? Scala? AS3 won't have any easy way on Linux. Could you guys suggest the one I should stick with?

I don't really like SDL; it's too complicated for what it is, imo.

Try SFML; it's simple, object-oriented, and pretty fast.  It has Python and C# bindings if you want to get into those, but I much prefer C++.

I would recommend C++ (the elite language) over all others, but I'm clearly the least helpful person to talk to; I'm extremely biased about it (C++ is the best, though).

It's the licences I don't like about SFML, in case I decide to work on a commercial product.