Elysian Shadows

Ah, good man.

As for the operator, no unfortunately not. There must be an explicit lvalue and rvalue. So operator+ would have to be defined for point and vector both.

As that is a binary operator you also have the choice of taking the definition outside of the class.

I vehemently disagree. We actually had a fairly lengthy discussion about this in another post. There was a post that I'd made a long time ago where I discussed that you CAN VIEW......a point as a vector offset from "some origin" ....wherever that is. Apparently some light bulbs ticked on a...

So what's the OTHER several hundred pages of that book filled with? Creme-filling?

Some concepts are timeless.

Maybe your algorithm book needs a watch :D

I've seen your code, I *KNOW* you didn't read "A practical introduction to Data Structures and Algorithm Analysis"

I like how your textbooks serve their highest purpose as a prop for your plywood table.

....fkn redneck.

....and after a weekend of paint and Ikea.

Heh... Consider what happens. If no appropriate copy constructor is supplied, the runtime will supply one for you. Your linked list contains a pointer to a type. When you call the insertion operator (makes a copy) it will use the default method. This method simply copies the VALUE of the pointer (eg...

You didn't supply a copy constructor for the linked list did you?

No, you had it right. "uniform" variables in GLSL are indeed read-only (constant). They are passed to constant registers on the logic unit (You can define them at compile time (in the shader) or link time (from the caller). "varying" parameters in GLSL are passed by "registe...

There's a TON of application there where it comes to encryption, run time encoding, file compression, texture compression, network compression, your mom compression. The important thing is to not view data types so much as concrete types that have ONE application, but rather just as a bitfield of an...

You might define something like so: struct RGBA8_PIX { char r, g, b, a; // 32 bpp in RGBA (DirectX style) ordering }; struct RGB8_PIX { char r, g, b; // 24 bpp in RGB (DirectX style) ordering }; template <class T> static void swap_pix(T& l, T& r) { T tmp = l; l = r; t = tmp; } // Might check...

The API (whichever you're using...SDL, LibPNG or what have you) should be able to retrieve all that information for you. Either way, if you load an image you MUST know those things. If the memory lock maps to a void* or char* then you can just cast it to a BGRA8_PIX type or what have you and you'd b...

Now yer thinkin. Absolutely you can. Just like a regular array, you can offset by width and height. The only difference in an image is that you have to offset by the bytes per pixel as well. So when you map the tilesheet from memory, you can read in pixel by pixel with whatever looping structure you...