In this thread we discussed maths teachers, and it reminded me of my time doing 3D programming using matrices and algebra and having to back to school aged 21/22 to learn the maths I should have learned before.
It took me back to one of my favourite Eureka moments when programming. You know that feeling that olympic gold medalists get when you achieved something.
I think this one may be interesting enough for some of you. (or perhaps not
)
Back before there were 3D libraries to display 3D objects on screen and animate them for you. You had to draw each individual pixel,
Roughly speaking.
You would first build a pixel plotting routine where you drew to x,y on the screen and set the colour.
Then you would build a line drawing routine that would plot each pixel in a line between two points (x1, y1, x2, y2, colour)
Then you would draw a an enclosed surface, say a triangle or a square known as a polygon.
The bit I am getting so excited about, remember is that on those old computers the speed of the CPU was 7MHz, 3D was heavily mathematically intensive and those CPUs didn't do floating point math only integer.
So if you weren't smart and didn't optimize you would be lucky to draw more than a couple of cubes on screen and animate them.
So we had to do two things. Back face culling (Don't draw things facing away) and hidden surface removal (don't show stuff hidden by other stuff) so you didn't draw the same pixel twice.
Now it is the back face culling that triggered my memory and got me excited again.
A technique I learned back then, remember this was before the internet etc.
Using this cube as an example.
When laying out the coordinates of each point of each cubes face we would define them as 4 sets of coordinate which if facing towards us would be in clockwise order.
Once you have defined all 6 faces you could tell whether to draw it or not simply by using a bit of algebra to see if the face was clockwise or anti clockwise. If it was anti clockwise you would cull it from the draw list before it even got close to the screen drawing routines.
This is the algebraic formula.
As you can see, it just used subtraction and multiplication which on an integer only CPU was blisteringly fast.
The beauty of this formula is that although it only used 3 coordinate Xa, Ya -> Xc, Yc, it would work on any polygon from a triangle to something with 10+ sides providing the surface was flat and you didn't start it on a concave portion of the polygon.
I am not sure I was clear there so here is something to test it with.
Imagine you are looking at a square. You imagine the coordinates of each point, use a range of say 0 - 5 so 1st is top left (0,0) next is top right is (5,0) bottom right is (5,5) and bottom left is (0,5). If you then flip the square, imagine turning the paper over so you are looking at it from the back (yes we used tracing paper to test some things out) You will see now that if you go from 1st to 2nd to 3rd it is now anti clockwise from the front.
That was it. A very simple technique which in most games cut the number of surfaces you had to consider in half. Meaning the game ran almost twice as fast (not really but close for this example).
And each cull took about 12 lines of machine code/assembly.
Sorry I got excited and wanted to share a cool memory from back in the day of geeking out over maths due to programming.
* If you don't realise how slow 7MHz was. It is 0.007 GHz The current computer I am working on boost to 4.5GHz which is 4,500Mhz which is 642 times fast just in clock cycles. and that was a 16 bit vs my 64 bit, and my current cpu has pipelining, parallel operations multiple cores and on much better silicon. So things were slow and tight back then. which is why the challenge was much more fun back then than today.
It took me back to one of my favourite Eureka moments when programming. You know that feeling that olympic gold medalists get when you achieved something.
I think this one may be interesting enough for some of you. (or perhaps not
)Back before there were 3D libraries to display 3D objects on screen and animate them for you. You had to draw each individual pixel,
Roughly speaking.
You would first build a pixel plotting routine where you drew to x,y on the screen and set the colour.
Then you would build a line drawing routine that would plot each pixel in a line between two points (x1, y1, x2, y2, colour)
Then you would draw a an enclosed surface, say a triangle or a square known as a polygon.
The bit I am getting so excited about, remember is that on those old computers the speed of the CPU was 7MHz, 3D was heavily mathematically intensive and those CPUs didn't do floating point math only integer.
So if you weren't smart and didn't optimize you would be lucky to draw more than a couple of cubes on screen and animate them.
So we had to do two things. Back face culling (Don't draw things facing away) and hidden surface removal (don't show stuff hidden by other stuff) so you didn't draw the same pixel twice.
Now it is the back face culling that triggered my memory and got me excited again.
A technique I learned back then, remember this was before the internet etc.
Using this cube as an example.
When laying out the coordinates of each point of each cubes face we would define them as 4 sets of coordinate which if facing towards us would be in clockwise order.
Once you have defined all 6 faces you could tell whether to draw it or not simply by using a bit of algebra to see if the face was clockwise or anti clockwise. If it was anti clockwise you would cull it from the draw list before it even got close to the screen drawing routines.
This is the algebraic formula.
As you can see, it just used subtraction and multiplication which on an integer only CPU was blisteringly fast.
The beauty of this formula is that although it only used 3 coordinate Xa, Ya -> Xc, Yc, it would work on any polygon from a triangle to something with 10+ sides providing the surface was flat and you didn't start it on a concave portion of the polygon.
I am not sure I was clear there so here is something to test it with.
Imagine you are looking at a square. You imagine the coordinates of each point, use a range of say 0 - 5 so 1st is top left (0,0) next is top right is (5,0) bottom right is (5,5) and bottom left is (0,5). If you then flip the square, imagine turning the paper over so you are looking at it from the back (yes we used tracing paper to test some things out) You will see now that if you go from 1st to 2nd to 3rd it is now anti clockwise from the front.
That was it. A very simple technique which in most games cut the number of surfaces you had to consider in half. Meaning the game ran almost twice as fast (not really but close for this example).
And each cull took about 12 lines of machine code/assembly.
Sorry I got excited and wanted to share a cool memory from back in the day of geeking out over maths due to programming.
* If you don't realise how slow 7MHz was. It is 0.007 GHz The current computer I am working on boost to 4.5GHz which is 4,500Mhz which is 642 times fast just in clock cycles. and that was a 16 bit vs my 64 bit, and my current cpu has pipelining, parallel operations multiple cores and on much better silicon. So things were slow and tight back then. which is why the challenge was much more fun back then than today.
