next »

[Bad Sector]

Well i know about that but its just the whole "i know better than you what you like in formatting" attitude of Emacs :-). If i just could *completely disable* that and leave source code highlighting alone and the rest behaves much like most other editors out there (yes i know Emacs is older but no i dont care), then the experience would be very improved for me. Although i've already replaced Emacs with JOE when it comes to Linux console editing. In Windows and X i use jEdit anyway.

[dmoonfire]

cc-mode has the hooks not to format lines.  You don't bind the c-electric- functions and map TAB back to insert tab. They have instructions on that somewhere on the website. Then, as long as you don't use format-buffer, it won't ever format it for you. I could figure out how to turn off format-buffer (M-q), but that would need a few minutes in front of my editor.

Of course, there at a lot of options in cc-mode (and csharp-mode because of it) simply because no one agrees on formatting style. But, turning it off is actually pretty easy.

http://cc-mode.sourceforge.net/html-manual/Indentation-Engine-Basics.html#Indentation-Engine-Basics

The above link tells you how to turn off most of the indenting features (by turning off the syntax processing).

http://cc-mode.sourceforge.net/html-manual/Indentation-Commands.html#Indentation-Commands

This gives a lot of options for the tab control (assuming you don't just rebind it). Moot point if you don't use it, of course, but still use Emacs. Of course, I've been programming in VS2008 a lot more, which is annoying since it is now the only two reasons I use Windows (other being World of Goo recently).

[Decipher]

I hate how 5 minutes before a deadline someone walks in and says "We have a new bug".

I also hate how noise() is not implemented on nVidia and ATI drivers just because of marketing reasons. In fact they have a very valid reason. So, this boils down to the fact that I hate the current GLSL specification because it doesn't specify how noise() should be implemented.

Eventhough I am 18 years old, I am still grumpy!

[Zaphos]

You can dude... (though if you do it in a .h file C++ makes all of the methods inline I think).

C++ doesn't treat .h files specially; it'll make the methods inline if you do it in a .cpp file that way as well.  Unless you set a compiler flag to make it stop (gcc has one).

[increpare]

You can dude... (though if you do it in a .h file C++ makes all of the methods inline I think).

C++ doesn't treat .h files specially; it'll make the methods inline if you do it in a .cpp file that way as well.  Unless you set a compiler flag to make it stop (gcc has one).

Oh yep, sure.  My bad.

[mjau]

I also hate how noise() is not implemented on nVidia and ATI drivers just because of marketing reasons.

Oh, it's implemented.  They just chose the most efficient solution, that's all.  According to GLSL, the functions have to be continuous, generate values between -1 and 1, have an overall average of 0, be repeatable with the same seed, be statistically invariant, etc.  What solution to this problem could be better, more elegant, than simply always returning 0?  Sure, it's completely useless, but the efficiency is through the roof!

[Hinchy]

back in my day my actionscript was scattered all over the place on different movie clips and buttons and was frustratingly difficult to debug, and we LIKED IT that way!

[Decipher]

I also hate how noise() is not implemented on nVidia and ATI drivers just because of marketing reasons.

Oh, it's implemented.  They just chose the most efficient solution, that's all.  According to GLSL, the functions have to be continuous, generate values between -1 and 1, have an overall average of 0, be repeatable with the same seed, be statistically invariant, etc.  What solution to this problem could be better, more elegant, than simply always returning 0?  Sure, it's completely useless, but the efficiency is through the roof!

That's the funny thing about it. And this is being done as such because an implementation that is 1 millisecond per frame slower than the rival's one might make the company lose a huge market share (well, this is most likely relevant to the high-end market). On the other hand, GLSL (nor HLSL) specification doesn't really help either. It should state the exact type of noise function that should be implemented. It should also state the dimension and quality (such as equidistribution) of the noise generated (it can be anything, from Blum-Blum Shub to Mersenne Twister or to any stream cipher [who knows maybe someone might write a cryptography application that runs on the GPU]).

Argh, I hate this so much! So, frigging, much!

[jcromartie]

bitmask fail:

0x1
0x2
0x4
0x8
0x16

[mildmojo]

I'm sick of all the OpenGL tutorials and examples that expect you to implicitly understand the GL state machine.  Where are the detailed pseudocode or block diagram overviews?

It took me a good 6 or 8 hours to figure out that if you're feeding the GPU vertex and texcoord arrays, you need to have separate arrays for each time you want to switch textures because you still have to glBindTexture() in between calls to glDraw*().

Gah.  If they're going to have an array for coloring vertices, why not have an array that specifies texture IDs for each vertex, too?

[muku]

Gah.  If they're going to have an array for coloring vertices, why not have an array that specifies texture IDs for each vertex, too?

Because switching texture is a pretty heavy state change. You definitely don't want to do that from one primitive to the next unless you can help it.

[mildmojo]

Because switching texture is a pretty heavy state change. You definitely don't want to do that from one primitive to the next unless you can help it.

I expected to find a way to load texture switches into an array that would accompany my vertices and texcoords so I could say, "draw these 8 triangles with this texture, then draw the next 50 triangles with this texture, then draw these two with this texture..."

I happen to be working in 2D, so in the worst case I'm switching textures every 6 vertices (each pair of triangles, textured rectangular sprites), making vertex arrays sort of useless.  But I expected to find a way to load an entire mesh into a vertex array, then specify which parts of the mesh use which texture.

There's a good chance I lack some basic understanding of the texturing process, though, which goes back to my first point.

[muku]

Because switching texture is a pretty heavy state change. You definitely don't want to do that from one primitive to the next unless you can help it.

I expected to find a way to load texture switches into an array that would accompany my vertices and texcoords so I could say, "draw these 8 triangles with this texture, then draw the next 50 triangles with this texture, then draw these two with this texture..."

You can still do that with glDrawElements (which you can pass a list of vertex indices to). Or simply set up a display list.

I happen to be working in 2D, so in the worst case I'm switching textures every 6 vertices (each pair of triangles, textured rectangular sprites), making vertex arrays sort of useless.  But I expected to find a way to load an entire mesh into a vertex array, then specify which parts of the mesh use which texture.

It's of course hard to give any recommendations without knowing in more detail what you are trying to do. How many sprites and how many different textures are we talking about? In general, you should try to group your render calls by texture.

[mildmojo]

You can still do that with glDrawElements (which you can pass a list of vertex indices to). Or simply set up a display list.

Yeah, there's that approach.  I'm using display lists with immediate mode calls, but I thought maybe I'd try out vertex arrays on my way to vertex buffer objects.

It's of course hard to give any recommendations without knowing in more detail what you are trying to do. How many sprites and how many different textures are we talking about? In general, you should try to group your render calls by texture.

Not too many, I think.  At the moment, my sprites are all objects with their own draw() methods which make their own GL calls.  I'm working on a panel sprite class that can be packed with overlaid text and images.  I've got a vertex array for the triangles that make up the borders and the center area.  When I pack an image into the panel, it creates a two-triangle quad, and I was thinking of packing those vertices into the panel array.  Those triangles need to be textured separately from the panel, though, which means either saving offset lists for glDrawElements() or creating separate vertex arrays for each image.  There might be a dozen of these on screen at a time.  Textures will rarely be shared among drawn elements, I think.

[muku]

If there are only a dozen of those quads on the screen, frankly, I don't see why you'd use vertex arrays or even VBOs. Performance is hardly a concern with so little geometry?

By the way, you could use quads instead of triangles so you only need to specify 4 vertices instead of 6. It's quite possible that the driver internally converts it to triangles anyway, so it might not really change performance, but it's at least convenient.

[mildmojo]

If there are only a dozen of those quads on the screen, frankly, I don't see why you'd use vertex arrays or even VBOs. Performance is hardly a concern with so little geometry?

By the way, you could use quads instead of triangles so you only need to specify 4 vertices instead of 6. It's quite possible that the driver internally converts it to triangles anyway, so it might not really change performance, but it's at least convenient.

I have a hidden agenda: I'm trying to keep my GL stuff compatible with OpenGL ES 1.1, which supports neither immediate mode nor quads.  As I understand it, you have to use vertex arrays (or VBOs) filled with triangles.

I'd also like to learn how to use the arrays and buffer objects properly.

[muku]

Ah, I didn't know that about OpenGL ES 1.1. That's certainly an argument. By the way, it seems that this API supports multitexturing, so if you really want to use multiple textures in one render call, that would be a way to do it.

[increpare]

AAAAAAAAAAAAAAAAAAAAAAAAAH

GLfloat length(GLfloat x1, GLfloat y1, GLfloat x2=0, GLfloat y2=0)
{
 GLfloat x=x1-x2;
 GLfloat y=y1-y2;
 return sqrt(x*x+y*y);
}

is nice.  in some cases, to speed things up, I didn't need to take the root

GLfloat lengthsq(GLfloat x1, GLfloat y1, GLfloat x2=0, GLfloat y2=0)
{
 GLfloat x=x1-x2;
 GLfloat y=y1-y2;
 return(x*x+y*y);
}

ONLY THIS FUNCTION DOESN'T SEEM TO WORK,

however

GLfloat lengthsq(GLfloat x1, GLfloat y1, GLfloat x2=0, GLfloat y2=0)
{
 return length(x1,y1,x2,y2)*length(x1,y1,x2,y2);
}

does

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH

[Cagey]

The first lengthsq needs to be absolute value.

Those are the sort of programming errors you can never notice yourself

[muku]

GLfloat lengthsq(GLfloat x1, GLfloat y1, GLfloat x2=0, GLfloat y2=0)
{
 GLfloat x=x1-x2;
 GLfloat y=y1-y2;
 return(x*x+y*y);
}

ONLY THIS FUNCTION DOESN'T SEEM TO WORK,

What do you mean, it doesn't... work?

Cagey, why absolute value?