Messages

1

Feature requests / sf::Color, making it union

« on: September 19, 2011, 05:14:16 pm »

Seriously, how much you'd gain? A thousand cycles in the whole run of the program? That's nothing on modern hardware.

True, it's not a significant gain. But it is fun to play around with things like this. Previous to this thread I had given little thought to data alignment, though I'm not saying I'll always do it in the future.

I think I'll read up on union behaviour a bit, I wont be returning to the thread anymore as I think there is little more to discuss. I appreciate all the feedback I've gotten and wish you all luck with your respective projekts.

Bye.

2

Feature requests / sf::Color, making it union

« on: September 19, 2011, 12:35:11 pm »

I concede that it's a possibility. But is it probable? Has it ever happened and if so with which compilers?

I mean even if it's possible doesn't mean it happens. I mean everyone uses unsigned char for allocating bytes of data, and there is no guarantee that  it's 1byte large. Still people use it since there isn't a compiler that implements it differently.

Glubyte is a typedef for unsigned char. And so is BYTE under windows and so is alot of other macros by other companies.

3

Feature requests / sf::Color, making it union

« on: September 19, 2011, 12:17:34 pm »

I read about that yesterday. And for this specific case it's not very dangerous since we will only ever use 32bits. No more, no less.

Are there any compilers out there that would make
struct Color{ byte r,g,b,a; };
sizeof(Color) == 16 bytes??? or even 8bytes
It's difficult finding data on this.

In other cases with more data involved it's obviously a bad thing to mess around with.

4

Feature requests / sf::Color, making it union

« on: September 19, 2011, 11:54:25 am »

In SFML 2 it's an array of UInt8.

Also, I have found no troubles with this method.
Please list them.

If the compiler decides to insert padding between the members you're screwed up.

But then so is SFML 1.6, and it has worked for countless people. So it doesn't seem to happen that often.

I guess I should look into alignment more, does anyone have any good sources?

5

Feature requests / sf::Color, making it union

« on: September 19, 2011, 11:27:52 am »

Indeed, the small speed gain is neither relevant in the big picture nor worth all the trouble it brings. Sometimes this is also called premature optimization.

I think myPixels is an std::vector<sf::Uint8>, i.e. an array of bytes, so there is no problem. As already stated, arrays guarantee subsequent element addresses, in contrast to separate members.

No it's not

mutable std::vector<Color> myPixels;

So it only guarantees no padding between Color elements not in between elements inside Color.

Also, I have found no troubles with this method.
Please list them.

6

Feature requests / sf::Color, making it union

« on: September 19, 2011, 09:22:19 am »

Also if having a set of 4 GLubytes instead of an array is undefined bahaviour this is also the case in sfml. Al you do in OpenGL is pass a Glubyte pointer to the beginning of the data and it is read in direct succession. So I can be as sure as Laurent that four GLubyte is contained within a 4byte integer. If it wasn't the case neither of our implementations would work.

SFML doesn't use vertex arrays (yet), the color is used in a call to glColor4ub(r, g, b, a).

what about GLCheck(glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, myWidth, myHeight, GL_RGBA, GL_UNSIGNED_BYTE, &myPixels[0]));
Doesn't glTexSubImage2D read 32 bits at a time?
This is SFML1.6. Do you do it differently in 2.0?

7

Feature requests / sf::Color, making it union

« on: September 19, 2011, 08:39:26 am »

On the other side, you don't really win anything with the union approach. You can easily cover the same functionality in a less "hacky" way, and avoid potential trouble by doing so.

Why is there no gain?

Why does

color.r = 255;
color.g = 255;
color.b = 0;
color.a = 255;

have the same operating speed as

color.data32 = 0xFF00FFFF;

It atleast to to me isn't obvious.

Also if having a set of 4 GLubytes instead of an array is undefined bahaviour this is also the case in sfml. Al you do in OpenGL is pass a Glubyte pointer to the beginning of the data and it is read in direct succession. So I can be as sure as Laurent that four GLubyte is contained within a 4byte integer. If it wasn't the case neither of our implementations would work. Infact, I mey even be more sure then Laurent since I use a POD type, which guarantees a magic free implementation.

Lastly, please write out the less hacky way. I have obviously not thought about it and would appreciate if you could write it out instead of just saying it exists.

EDIT:
I guess memcpy would be a less "hacky" solution. and you could use it in an overloaded = operator function.

8

Feature requests / sf::Color, making it union

« on: September 19, 2011, 12:29:13 am »

Correct me if I am wrong, but alignment could be an problem here:
The CPU can access single members faster, if their address is aligned (for example every address%4=0)
In this case &g - &r would be 4, so changing data32 would have no effect on g, b or a

I don't know whether there are compiler activating alignment without asking or whether the C++standart forbids  alignment within unions.

why is &g - &r? they are both one byte large. the size of 4 GLubyte is 4 bytes and the size of GLuint is also 4bytes. Why would the program pad each of the four bytes with three empty bytes? I have tried reading up a bit on alignment (good sources are scarce) and couldn't make sense of anything. Some testing shows that it works perfectly fine as it is. Though, the data is sort of scrambled. Dont know how it will fare on other platforms though.

0xAABBGGRR - the data is organized like this when writing to it like an int
Perhaps you know why? I'm a bit tired now and cant really think straight.

Also, Laurent. Perhaps you could share a bit more about why you think it's ugly. It seems like you have some kind of insight I don't and I think it will benefit me if I knew what it is that makes this idea so bad.

9

Feature requests / sf::Color, making it union

« on: September 18, 2011, 08:32:35 pm »

I found a cleaner way of doing it just now.

union Color
{
   struct
   { GLubyte r,g,b,a; };
   GLuint data32;
};

Isn't this a bit less ugly?
It's alot cleaner to work with then my previous version atleast.

10

Feature requests / sf::Color, making it union

« on: September 18, 2011, 07:55:15 pm »

Well it is faster to.

Honestly, who cares?

Well it is fun to optimize. It makes you ask questions and you learn lots by doing it.

Lastly I would like to ask. Isn't making it a class excessive?

Excessive in what? There's no extra overhead.

Making it a class creates a v_table for it doesn't it?

Nop, only classes with vritual functions have a v-table.

Read up on classes and how they implement member functions more closely. Everything makes more sense now, i just assumed that member functions were always handled with function pointers. Which is kinda stupid if I think about it. All of it should be resolvable at compile time.

Does this mean that a POD type can have member functions as long as it doesn't have any base class, constructor, destructor or virtual functions?
EDIT: It does mean that.

11

Feature requests / sf::Color, making it union

« on: September 18, 2011, 04:50:35 pm »

Well it is faster to.

color1.int_data =color2.int_data;

is faster or atleast as fast as

color1.r = color2.r;
color1.g = color2.g;
color1.b = color2.b;
color1.b = color2.a;

depending if the compiler spots the optimization it can do.
Not a very big optimization, granted, but an optimization non the less.

Or am i mistaken?

Also, the interface for the class would be identical would it not?
Everything is already hidden behind operator overloading and constructors. Only the rare cases when you want to access  the data itself would it be "ugly" to use.

Lastly I would like to ask. Isn't making it a class excessive? I mean wouldn't a POD struct/union be enough. And then maybe use a function to create colors. like

CreateColor(GLUbyte r, GLUbyte r, GLUbyte r, GLUbyte a=255);

Making it a class creates a v_table for it doesn't it? Seems a bit unnecessary for something so simple as a color.

I hope I haven't come across as rude, I realy like your work. Just a few questions for my own personal education.

12

Feature requests / sf::Color, making it union

« on: September 18, 2011, 04:21:18 pm »

Hi, a short while ago I was discussing my own color struct with a friend and my friend is a very meticulus person and thought my four GLUBytes were inefficient. He wanted me to use an int. Instead of doing what he said a did both

union Color{
   struct ByteData{
      GLUByte r, g, b, a;
   }byte_data;
   GLUint int_data;
}

this way when assigning one color to another I simply use
color1.int_data = color2.inte_data;
simple and effiecient.
I even overloaded the operators for it to make it more streamlined.

The reason I'm writing it here is because I'm still very much new to OpenGL and for the AI cource Im currently taking I'm using SFML.
I wanted to create an image with random pixels in it, and instead of calling random once for every byte in every color it would be nice if I could write

color = rand();

instead. I guess I could write

(*reinterpret_cast<int*>(&color)) = rand();

But thats so ugly.

Thoughts are welcome.