Defining/using Open-GL Camera paths

[da_fatstuff]

Hi Frea,

I'd assumed GLUT was a helper-system to use alongside OpenGL/GLU (e.g. I'm using GLU's gluLookAt command and I didn't think GLUT had an equivalent) - but I'll check it out as it has a handy static-lib build...

...thanks for the pointer!

[Jim]

OK, I reckon I've found the problem...

Your definitions in native.h for ftol and ftol2 are wrong.  I changed the code at the top of main.cpp to this

Code: [Select]

//extern "C" long _ftol( float fltSource ) { return ftol( fltSource ); }
//extern "C" long _ftol2( double dblSource ) { return ftol2( dblSource ); }

int glob;
extern "C" void _ftol(void)
{
__asm
{
fistp  [glob]
mov eax,[glob]
}
}

extern "C" void _ftol2(void)
{
__asm
{
fistp  [glob]
mov eax,[glob]
}
}
and that fixes the problem.
The difference between my code and yours is that mine removes the value on the fpu stack top.  Yours leaves it there and this is causing all kinds of fpu instability all over.

Let me know if that fixes it!  (incidentally, where did native.h come from? one of yours?)

Jim

[da_fatstuff]

Wow! 

Thank you! Thank you! Thank you! Thank you! Thank you!  (and K++ of course)

That's an impressive find if you hadn't have found it I might have had to give up on that in time, as I wouldn't have found that!

The native.h was in my previous scrolly Putrid 4K Scroller and it probably went unnoticed because of the nature of how they were used (I'll edit that thread to include the new one just in case anyone uses it!)...I think it was originally Slippy who gave me the header when he kindly optimised one stage of the code - but, of course, I added the two problem methods (from an Internet source somewhere - I sure as heck didn't write them from scratch - waaaay out of my depth!)

Now I can focus on ways to make it look better with less bytes!

Thanks again!

[Jim]

No problem   Actually, I think the reason I gave was wrong - if you were leaving an extra fpu entry every time you converted a double or float to int it would break far quicker.  I think what's really happening is in your code you require a spare fpu register (you do an fld), and under optimised code there's less likely to be a spare one.  Might want to rework the sin and cos for the same reason.
Did you know there's a fsincos instruction that gives you both sin and cos at the same time for much the same cpu cycles? I have this code in my CDI remake:

Code: [Select]

static void sincos(double a, double *s, double *c)
{
double zin,coz;

a *= 3.141592653589/180.0;
_asm
{
fld [a]
fsincos
fstp [coz]
fstp [zin]
}

*s = zin;
*c = coz;
}

Jim

[da_fatstuff]

Cool, and thanks again - I have a use for this in the texture creation section (and likely to be elsewhere too when I start polishing it) - could the 'fld' in your example code suffer from the same issues under size optimization that the ftol's did?  I think I need to read up on assembler over the next few months...if I ever complete this I'll know a stack more than when I started 

[Jim]

There won't be a problem with my sincos function because it's a proper C function.  In that case the caller has to assume that I will trash all the fpu registers.  When you replace the compiler built-in functions, such as ftol, you have to match exactly whatever Microsoft did in their run-time library - the normal C rules don't have to apply there.  I checked by stepping in to the runtime in the debugger and seeing the code.

Have a squiz at page 10 of this doc.  Registers marked as 'scratch' you don't need to push/pop.  Those marked as 'callee-saved' must be preserved in your function.
http://www.agner.org/optimize/calling_conventions.pdf.

Jim

[da_fatstuff]

Thanks again - and that site seems to have some interesting stuff on it...hope I can absorb some of it!