123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|428|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Optimization!
Sun, 28 Sep 2008, 12:23
Phoenix
 		I'm working in C, and I have a piece of code which I don't really like.



It loops through all of the pixels (three bytes each) in a specific area and sets their values to the same color, similar to Blitz's Cls() command. This means that if I have an area of 800x600 it loops almost half a million times, which isn't really desirable.

plSetPixel basically just sets the value of each color byte to the correct value, but I think it would be much more handy to do something like this instead of the above code:



Although, it only sets the first byte of each color value since buffer->data has the type unsigned char*. Is it possible to make memset treat every pixel as a three byte value? Or is there a better way of doing it? Am I being unclear?
Sun, 28 Sep 2008, 12:28
Afr0
 		Uhm... I'm not really well versed in C at all, but from looking at the Sim City source, it seems they're using pointers as arrays.
Maybe you could do the same?

I.E

int *Ptr;
Ptr[0] = 1;
Ptr[1] = 2;
Ptr[2] = 3;

-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Sun, 28 Sep 2008, 13:13
Phoenix
 		That's what plSetPixel does, but that means that I have to loop through all of the pixels. I imagine that memset has some internal optimizations.

Actually, now that I think about it, I perhaps should represent pixels as integers instead of individual bytes.

|edit| Argh, when I tell OpenGL to treat pixels as integers it treats every color component as an integer as opposed to the whole color. So that approach doesn't really work. |edit|
Sun, 28 Sep 2008, 14:30
Phoenix
 		No, unfourtunately not. I am trying to clear a texture's pixels, not an entire scene. Perhaps there is no way to do it effectively?
Sun, 28 Sep 2008, 14:48
Jayenkai
 		No way to draw anything other than pixels? No "Big chunky rectangle over all o' this" function or something?

-=-=-
''Load, Next List!''
Sun, 28 Sep 2008, 14:49
flying_cucco
 		Can you replace the texture with a blank one? or use a single pixel/small texture? I don't really know enough to be more help.
Sun, 28 Sep 2008, 14:54
Phoenix
No way to draw anything other than pixels? No "Big chunky rectangle over all o' this" function or something?


Well the problem is that I'm trying to make a "Big chunky rectangle over all o' this"-function.

Can you replace the texture with a blank one? or use a single pixel/small texture?


Hmm... Perhaps I could have a small block of pixels by the side and then just copy its data several times. I'll give it a try.
Mon, 29 Sep 2008, 08:37
mike_g
 		Theres no way around it; you will have to iterate over each pixel, or use some kind of SIMD instructions. GPUs are very good at this kind of stuff, but if youre doing software rendering you can still use the MMX/3dnow resisters to crunch 4 pixels at a time, the downside is that you will have to write a little ASM for it. Mutithreading is another option if you have a multi core CPU, but for anyone running you prog on a single core this will create extra overhead.

Algorithimcaly I think you can optimise it a little using pointer arithmetic. In pseudo code:

In that you would basically cut out the overhead of calling plSetPixel and you would not need to convert 2D co-ords to 1D (requiring multiplication and addition)
Mon, 29 Sep 2008, 09:36
Phoenix
 		The pointer traversal seems to be working nicely If anyone is wondering what I'm up to I'm mixing software with hardware rendering, trying to get the good stuff from both worlds... again. There's probably lots of optimizations that can be done, much like this one, but I'll leave them alone for the moment.