Dark Bit Factory & Gravity
PROGRAMMING => C / C++ /C# => Topic started by: da_fatstuff on August 29, 2007
-
Hi again,
So far I've only used static views and moved everything in the scenes by various formula...now I'm thinking of something that needs specific predefined camera control around a 3D scene, and for the movement of the camera to be reasonably fluid...currently I'm thinking of some sort of array of movements, with a movement being presented with these properties:
fx, fy, fz = viewing from co-ords
tx, ty, tz = viewing to co-ords
ticks = duration to utilise these co-ords for
smoothing = number of ticks to use graduating from previous co-ords to current co-ords
As the camera movements definition will have to be a manual process in code I'm hoping the smoothing will enable a relatively small set of defined paths to look less cheap (removing the jerky movements from one to the next).
Anyone got any tips/routines to use predefined demo camera paths for use in OpenGL, or does the above seem ok to y'all?
Cheers!
-
I think you should look into bezier splines.
If you want exact contro to be sure that your camera path goes through control points, look into catmul rom splines.
There may even be a catmul example somewhere on this forum somewhere.
-
Cheers - that was quick!
I've found a forum link for a Freebasic implementation:
http://dbfinteractive.com/index.php?topic=2098.0
I hope it's ok if I also post this link that I found explained it (has the C code) for anyone else looking:
http://www.lighthouse3d.com/opengl/maths/index.php?catmullrom
Thanks again.
-
looking forward to what you come up with :)
-
One last thing to consider is to use d3dx (not d3d) for all its maths routines. It has catmull rom splines for "free". Plus a huge set of other stuff like a complete vector and maths lib, geometry subdivision, image loading etc. Its perfectly compatible with Opengl and I'm unsure why more people dont use it.
Chris
-
Cheers Chris - D3DX is definately worth me looking at as you say (the specific Catmull-Rom link below for anyone else looking):
http://msdn.microsoft.com/archive/en-us/directx9_c_Dec_2005/D3DXVec2CatmullRom.asp
I guess OpenGL users might have a portability consideration/intention that prevents them using this - but I don't so it's great, thanks!
-
To start with you might just want to slide the camera along a line.
If you have x0,y0,z0 and x1,y1,z1 as the start and end points and a value t between 0 and 1, then you can slide the camera along by
cx = x0 + (x1-x0)*t
cy = y0 + (y1-y0)*t
cz = z0 + (z1-z0)*t
The you can use look-at code to make the camera point where you want, there's a sample of that here
http://dbfinteractive.com/index.php?topic=1874.0 (http://dbfinteractive.com/index.php?topic=1874.0), and I think D3DX has functions for doing it too.
Once you've done a straight line, curves will be easier - they nearly always take a 't' parameter to position you along them.
Jim
-
I've knocked-up a quick VS2005 project using what's been discussed here to test it out - and it seems to work -I've attached it here for anyone's future reference - obviously the scene being viewed is just for testing's sake (so not pretty), and the camera movements are largely just random values.
Basically the misc.h contains CAMERA_PATTERNS to specify how many camera movements there are, and camera_moves has these movements defined as the array that I initially described. The Main.cpp's PositionCamera method then uses the described D3DX D3DXVec3CatmullRom spline method to transition from one camera position to the next...
...I think I've used this correctly anyway, with the 2nd/3rd vectors being the from-to transitions I'm interested in, and the 1st/4th being the historic/future transitions either side.
Note: original post I put here defined fromcam_pos twice instead of prevcam_pos then fromcam_pos, so corrected this here.
-
Hmm.. Not working here, do you have a safe version perhaps? I'd love to see it!
-
The debug exe should be in there too - did you try that one? Not sure why I included the release one actually :-\
PS It's nothing exciting to see (I haven't got that far) - just really to demonstrate how I intend to use camera's as guided by the above- I think the important bits of code are:
misc.h
struct CAMERA_POS {
float fx;
float fy;
float fz;
float tx;
float ty;
float tz;
unsigned int frames;
unsigned int smoothing;
};
const unsigned short CAMERA_PATTERNS = 8;
CAMERA_POS camera_moves[] = {
0.0f,-20.0f,0.0f,0.0f,-20.0f,-60.0f,450,300,
0.0f,0.0f,0.0f,0.0f,-20.0f,-55.0f,600,300,
-10.0f,-10.0f,-10.0f,0.0f,-15.0f,-55.0f,350,350,
10.0f,-10.0f,-10.0f,-20.0f,-10.0f,-50.0f,350,350,
-10.0f,-10.0f,-10.0f,20.0f,-10.0f,-30.0f,60,60,
-20.0f,-20.0f,-20.0f,0.0f,10.0f,-40.0f,45,45,
0.0f,-0.0f,0.0f,0.0f,-15.0f,-60.0f,900,45,
0.0f,-10.0f,-20.0f,0.0f,15.0f,-40.0f,120,45,
};
Main.cpp
#include <GL/gl.h>
#include <GL/glu.h>
#include <D3dx9math.h>
#include "misc.h"
static CAMERA_POS prevcam_pos;
static CAMERA_POS fromcam_pos;
static CAMERA_POS tocam_pos;
static CAMERA_POS nextcam_pos;
static float sstep = 1.0f;
static unsigned int frames = 0;
static unsigned short cam_index = -1;
static void PositionCamera() {
frames++;
if ((!&tocam_pos)||frames>tocam_pos.frames) {
// Increment camera view and store previous ones
cam_index++;
if (cam_index>=CAMERA_PATTERNS)
cam_index = 0;
tocam_pos = camera_moves[cam_index];
if (cam_index==1)
prevcam_pos = camera_moves[CAMERA_PATTERNS-1];
else if (cam_index==0)
prevcam_pos = camera_moves[CAMERA_PATTERNS-2];
else
prevcam_pos = camera_moves[cam_index-2];
if (cam_index==0)
fromcam_pos = camera_moves[CAMERA_PATTERNS-1];
else
fromcam_pos = camera_moves[cam_index-1];
if (cam_index==(CAMERA_PATTERNS-1))
nextcam_pos = camera_moves[0];
else
nextcam_pos = camera_moves[cam_index+1];
frames = 0;
lasts = 0.0f;
sstep = 1.0f/tocam_pos.smoothing;
}
// Default position to defined camera position
float sfx=tocam_pos.fx,sfy=tocam_pos.fy,sfz=tocam_pos.fz,stx=tocam_pos.tx,sty=tocam_pos.ty,stz=tocam_pos.tz;
// Movement smoothing achieved by Catmull-Rom splines,
// recommended by Shockwave & Chris highlighted the existing D3DX library functions
if ((&fromcam_pos)&&(tocam_pos.smoothing > frames)) {
// We're here so we're smoothing the movement to our required destination from a previous one
// lasts will be the 0-1 position along the smoothing spline
lasts += sstep;
// View-from smoothing
D3DXVECTOR3 fprev = D3DXVECTOR3(prevcam_pos.fx,prevcam_pos.fy,prevcam_pos.fz);
D3DXVECTOR3 ffrom = D3DXVECTOR3(fromcam_pos.fx,fromcam_pos.fy,fromcam_pos.fz);
D3DXVECTOR3 fto = D3DXVECTOR3(tocam_pos.fx,tocam_pos.fy,tocam_pos.fz);
D3DXVECTOR3 fnext = D3DXVECTOR3(nextcam_pos.fx,nextcam_pos.fy,nextcam_pos.fz);
D3DXVECTOR3 fsmoothed;
D3DXVec3CatmullRom(&fsmoothed,&fprev,&ffrom,&fto,&fnext,lasts);
// Overwrite default 'from' co-ords with smoothed ones
sfx = fsmoothed.x;
sfy = fsmoothed.y;
sfz = fsmoothed.z;
// View-to smoothing
D3DXVECTOR3 tprev = D3DXVECTOR3(prevcam_pos.tx,prevcam_pos.ty,prevcam_pos.tz);
D3DXVECTOR3 tfrom = D3DXVECTOR3(fromcam_pos.tx,fromcam_pos.ty,fromcam_pos.tz);
D3DXVECTOR3 tto = D3DXVECTOR3(tocam_pos.tx,tocam_pos.ty,tocam_pos.tz);
D3DXVECTOR3 tnext = D3DXVECTOR3(nextcam_pos.tx,nextcam_pos.ty,nextcam_pos.tz);
D3DXVECTOR3 tsmoothed;
D3DXVec3CatmullRom(&tsmoothed,&tprev,&tfrom,&tto,&tnext,lasts);
// Overwrite default 'to' co-ords with smoothed ones
stx = tsmoothed.x;
sty = tsmoothed.y;
stz = tsmoothed.z;
}
// Position camera
glMatrixMode(GL_MODELVIEW); // Select The Modelview Matrix
glLoadIdentity();
gluLookAt(sfx,sfy,sfz,stx,sty,stz,0.0,1.0,0.0);
}
Note: Edited this code as original had fromcam_pos assigned twice instead of prevcam_pos then fromcam_pos
-
->Shockwave, I see da_fatstuff is using August '07 DirectX SDK which means you should update your DirectX runtimes (yeah, yet again) or get a hold of d3dx9_35.dll from somewhere eg. http://www.m3fe.com/760/ (http://www.m3fe.com/760/), and stick it in the folder with the EXE. Looks like a side effect of the packing is you lose the warning from Windows about missing dlls.
Jim
-
Defo karma++.
-
Hey,
really nice to see your 4k stuff here, da_fatstuff ... pretty sure that you'll become a famous intro coder within the next few months ... and thanks again for sharing your stuff to the community - this is gladly seen here ... we need guys like you keeping up the things :)
Looking forward to see more stuff from you in the future ...
The only thing missing right now on your 4k prods is a decent softsynth :)
...
Cheers,
SLiPPY
P.S.: Have some K++ dude
-
Cheers, but I'm a loooooong way from that level - I need to get some proper 3D objects embedded and as you say some sounds going next - that'll take time to master...be a few years before I produce my Micropolis (http://pouet.net/prod.php?which=13017 (http://pouet.net/prod.php?which=13017)) ;)
Regarding the softsynth I did try Farbrausch's V2 (as they supply the code and it's a great synth) but I can't get it to work with Crinkler yet :( ...not sure how small it'll compact to if I do anyway...and I think MIDI is seen as cheating :)
-
well,
fr's softsynth is supposed for 64k prods only ... you won't fit the replay and track data within a few hundred bytes, though - unless the sound quality of kebby's synth is "kick-ass" IMHO :)
you have to do some low-level coding for that ... I got an example here for you ... it's not mine but I know the author quite good and it's a rather sophisticated tiny synth IMHO ^^
Just watch the filesize and you'll get the point of what it should be ... aherm nearly forgot to mention ... there's a really good article on sound programming for 4k intros by auld on in4k ... check this link here (http://in4k.untergrund.net/index.php?title=4k_synth)
Also a good starter would be the "Making-of" article of sprite-o-mat (http://www.pouet.net/prod.php?which=30222) in the Zine #12 magazine ... here's a direct link (http://www.bitfellas.org/e107_plugins/content/content.php?content.437) to the article ... the sources are available as well ...
Perhaps rbraz could give you some tipps or hints as well :whisper: ... anyway ... :)
Laters,
SLiPPY
-
Cheers SLiPPY, I'll study this lot - great links, and I'll inflict the forums with any progress I make!
Edit: The In4k site you sent also had this Pouet link to a basic sequencer and playback synth's VC++ source code, where the test song/playback EXE Crinkled down to around 2.54Kb without any code changes (it'll be a good reference for doing this I think):
http://www.pouet.net/prod.php?which=13016 (http://www.pouet.net/prod.php?which=13016)
-
Just thought I'd post an update (code etc included) to illustrate what I wanted to do with these cameras better than my initial example did - it's still very much work in progress, but now I've added a (very basic) 3D fractal landscape to demonstrate the camera movements better (and tarted a few other minor things).
It still needs the Dx3dX9_35.dll from the link Jim posted previously...if you do run this - run the debug version, the Release exe was just so I know I still have 1.5K left to tinker with...here's a piccy anyway:
(http://fatstuff.fireflyinternet.co.uk/images/4kFractaland.png)
-
@da_fatstuff: that's very good work, some really interesting stuff in there. :clap:
Are you turning this code into 4k intro ? If yes, I just can't wait to see the final release :)
-
:clap: Thats just plain amazing, nice work and welldone dude :clap:
-
Generate some textures, work on the colours and include a synth tune, then you have a top rated 4kb intro right there. Seriously, people will be impressed by it.
Really nice work. :clap:
K+
-
Awesome. Well done.
K++ for sharing code !!!
-
Thanks everyone - all very kind.
Textures - my next step is to generate the towers using cubes of a set size then pasting in-code generated (basic) window-like texture(s) on each block's sides (probably not in the next week though!)...I'll also probably try something similar with the grass, and make the top block a different shape - to make that slightly less blocky looking. Also got to have some better-looking "FATSTUFF" object too, but some kid of texture on that will help that too if I can't think of anything else ;)
Music - erm - I have absolutely no talent in composition but I think I'm going to do something simple based on the FuxPlux engine (Pouet link I posted earlier) but stripped down to ensure it goes in <4k with the other stuff...I might even make the music fractal to keep a theme going (really it'll be because the computer will do a much better job than me!)...have to see how many bytes are left once it's pretty to see my options really.
Anyway - thanks again for the feedback - really is appreciated!
-
Fractal music would indeed carry on the theme :)
What are your plans for this 4k? Are you just going to release it generally or do you want to see if you can get some money for it by enering it into a competition at a scene party?
Standards for 4KB's are pretty high but if you chose the right party and with some nice textures , objects , camera paths , lighting and storyboard you could have a serious chance of winning something.
Also if you wanted to keep the fractal theme going, there are certainly lots of options you could use to generate fractal objects to live in your 4kb world :)
You are certainly not all that far away from something like this;
http://www.intro-inferno.com/production.php?id=216 (http://www.intro-inferno.com/production.php?id=216)
Which you can achieve now with the right objects, colours, camera paths etc..
-
No intentions other than as a learning exercise for me, and that hopefully something in there might be useful/inspiring to someone else.
However, I do want to try and polish it as much as possible in 4K, and when/if I get it done I'll see what you guys think about needed improvements then see what's happening at the time - if there's an appropriate competition I might throw it in, but most likely I'll just showcase it :-\
-
Very impressive for a couple of kb. Nice work with the camera splines :)
BTW, correct place to get all these d3dx9_??.dll files is from
http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en)
It will automatically patch your DirectX install up to the latest version.
Jim
-
Hi again,
I haven't been able to spend much time on finishing this (usual real-life stuff getting in the way that we all endure ;) ) but I've added some bits:
- (very) basic textures on buildings/grass/water
- rooftops/mounds
- waves...well water movement, hardly realistic motions!
- erm...a scroller...always a scroller...but I've implemented it differently so it's staying in for now ;D
Anyway, the purpose of this prog for me was/is as a learning exercise, and there's been stacks of C++/OpenGL learning been done which is why it's taking so long...one such learning curve is that I OO'd it then eventually found that new/delete and memalloc/free link to the MSVCRT.DLL...so de-OO'd it and used GlobalAlloc/GlobalFree instead to avoid the __chkstk errors from my huge static arrays at the time (I haven't implemented my own new/delete routines yet)...which brings me to an issue I'm currently stuck on, and I'm really hoping someone here has some suggestions...
...when I enable the VC 2005 size optimizations, my textures go wrong (compare debug and release EXEs) - they look different...if I make the debug version use the size optimizations it also looks wrong, so I have tracked it to the optimizations specifically. The textures are created in the Shapes.cpp's InitTextures method and are stored using pointer arrays allocated using GlobalAlloc, extract here:
void InitTextures() {
GLubyte **textureStore = (GLubyte**)GlobalAlloc(GPTR,TEXTURES*sizeof(GLubyte*));
for (int t=0;t<TEXTURES;t++) {
textureStore[t] = (GLubyte*)GlobalAlloc(GPTR,TEXTURES*TEXTURE_SIZE*sizeof(GLubyte));
}
...
glGenTextures(TEXTURES, textureIDs);
for (int x=0;x<TEXTURES;x++) {
glBindTexture (GL_TEXTURE_2D, x);
// Texture repeats over both S & R axis so out of range co-ords still get textured
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, TEXTURE_WIDTH, TEXTURE_HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, &textureStore[x][0]);
}
// Free dynamic array
GlobalFree(textureStore);
}
I've tried giving textureStore broader scope by defining it out of the method, also removing the GlobalFree altogether (as in attached source) without any difference...mainly because I figure that if the optimization is affecting it then maybe my texture memory is being seen as available and something is stomping over it, but the corruption seems consistent which kind of shoots that theory really...maybe the optimizations use different data types under the hood yielding different values or something like that?
BTW this is regardless of whether I use Crinkler or not so it's not the compressor trashing data or anything like that.
Anyone come across stuff like this before? I'm away from my computer for a week (not sure how I'll cope) - but thanks in advance for any ideas if you have any!
Correct kind of view (without optimization):
(http://fatstuff.fireflyinternet.co.uk/images/TextureGood.png)
Wrong kind of view (with size optimization):
(http://fatstuff.fireflyinternet.co.uk/images/TextureCrap.png)
Apart from this issue the code itself seems to work fine, albeit quite hard going on the CPU/GPU, and I've put as many comments in as I can - in case anyone sees something they want to try and improve on in their own intros...I'm at the 4k limit, so I'll have to start making the code optimizations (i.e. will be unreadable) now to fit stuff in ::)
PS Shockwave - cheers for the mention in the gears intro - I was/am totally gobsmacked!
-
The problem is GlobalAlloc doesn't return a pointer to memory, it returns a handle.
To get a pointer you must do
HGLOBAL global = GlobalAlloc(flags, size);
char *ptr = (char *)GlobalLock(global);
...
GlobalUnlock(global);
GlobalFree(global);
I think you're been fortunate it hasn't bitten you in the debug version.
Jim
-
Jim, dafatstuff isnt the only one who has been fortunate. I must learn to RTFM. Thanks Jim. K++ , again!
-
Cheers - you're a star - I KNEW you'd know what the heck I was doing wrong!
I'll change it when I get back, so fingers crossed...might be just one of many bugs in there of course ;)
-
Yep, you were right, it is pretty intensive! The release version wouldn't run but I got the debug version to work, it's pretty cool actually :) And it's always my pleasure to mention the people I know in my greets when I can ;)
K+ (for once again uploading your whole project)
-
da_fatstuff: nice work, a bit slow when the view is far.
Btw, why didn't you use an array (buffer) for your textures ? I gues you can save some bytes instead allocating memory with "GlobalAlloc".
-
@da_fatstuff:
Amazing work !!! I really like it. Keep it up. (And thx for greeting).
K++ for sharing code !!!
-
Thanks all, I appreciate the responses!
RBRAZ - I originally used a static array buffer, but then I used 64*64 resolution textures and that caused a __chkstk link error because I'd exceeded the stack allowance with the static arrays (I think this is what you meant, but I'm not up on the C++ terms yet)...
...as I'm now using lower-res 16*16 resolution textures you're right in that the GlobalAlloc and dynamic arrays aren't essential...so I've reverted to static arrays, along with removing the OO code and other stuff that (I think) wasn't being used (project attached here with these changes)...and I still have the same texture problem, still only with the MS VC size-optimized builds...it's really odd, so I'll be spending a lot of time reading up on what this setting really changes (any knowledge anyone has about it is welcome!).
BTW I notice my GLU32.DLL has a dependency on MSVCRT.DLL, probably because it's installed with MS VC++, but is there a release that doesn't use MSVCRT? I tried to download it from OpenGL instead, but it seems to be just specs and 3rd-party libraries that I can see :'( I guess it's irrelevant to 4K anyway, because if GLU is accepted, whatever DLLs it uses are accepted too...maybe...
BTW2 I'll try to do something with the scroller so it's not so far away and set the view distance to something more sensible to speed it up...I might pre-render each 3D char with proper lighting etc and capture them as 2D images to use in ortho blended on top of the Fractaland as a standard scroller...depends how many bytes that change uses :-\ not an original concept, but all good fun to play with...far more interesting than the day job ;)
-
Hi there,
there are loads of ways to get this smaller...piece by piece, which will help you squeeze in a synth. I think you could get this down by 0.5k easily in time. The biggest one I can spot by eye is the camera_moves[]. At first glance it seems the entire array could be into a range of 0..255. This means it could be stored as a byte array. Also its unlikely you will visually see the difference between 5.1 and 5.3 (as an example) so approximating both to 5 wont hurt. I didnt believe this until I tried it with a city scape in 4k. 0..255 is more than enough for almost any stored data (models, camera paths, timings etc).
Chris
-
Hi Chris,
Thanks for the tip! The camera_moves are multiplied by WORLD_SCALE, so a position difference of .2 is actually .2*20...but you're absolutely right - those bytes saved (and others like that) are going to be needed for the synth and hopefully other things...all good learning for me (I'm a Java programmer who does non audio/visual stuff by day :) )
Thanks again!
[Edit] I just tried the camera_moves change, and that change alone saved 1020 bytes in the (uncompressed) debug version, and even 61 bytes in the (compressed) Crinkler release version - so I'll definitely be replacing floats with smaller types wherever possible, as they'll all add up. I'll also replace the unchanging calcs with constants once I've got the finished app in place - at the moment it's easiest to leave them in so I can change stuff easily.
-
glGenTextures(TEXTURES, textureIDs);
for (int x=0;x<TEXTURES;x++) {
glBindTexture (GL_TEXTURE_2D, x);
note that glGenTextures doesn't necesarily return 0->TEXTURES-1.
Should be:
glBindTexture (GL_TEXTURE_2D, textureIDs[x]);
Don't know if that fixes it, I'm in a bit of a rush :-\
Jim
-
I appreciate you looking at it Jim - all ideas are very welcome, as I'm running out of them :-\
I tried setting all glBindTexture to use the value from the textureIDs array, as well as the specific one you highlighted, but alas no difference in the output (I've kept these in though because you're still right)...
...I've been trying to find out why size-optimization (/O1 and/or /Os) specifically should cause this texture corruption, but no joy yet.
A version of the Intel compiler for CE had an optimization problem with local arrays >3.5KB and a size not divisible by 4, so I set the texture count to 16 in case VS2005 had a similar issue, but it made no difference...my gut feel is it's going to be something like this, just because it works ok without size optimization, but I'm aware of my inexperience as the most likely cause!
FYI I also found someone having a similar problem with OpenGL on a Mac, but alas a solution wasn't posted:
http://lists.apple.com/archives/mac-opengl/2006/Dec/msg00013.html (http://lists.apple.com/archives/mac-opengl/2006/Dec/msg00013.html)
I've tried it on AMD with NVidia FX5500 and Intel with ATI X600 and it displayed the same issue, so it's not CPU or driver-based issue...oh and I reinstalled/updated VS2005 out of desperation too :)
-
More than likely you've done something daft :o. Often when this happens it means that you've either crapped over the stack or you've not initiliased something - in the debug version the stack might contain all 0s, in the release it's been optimised into registers which might contain anything. The last time I found a bug in Microsoft's compiler was in 1998 and I was using VC6 without any service packs. Sorry, but right now I've not had a chance to look at your code in any great detail. I checked the texture array and you didn't seem to be overrunning that - you threw me to start by using y for the horizontal and x for the vertical in a loop somewhere though :D x*width+y just looks a bit too funky!
Jim
-
Well, if it's a choice between me or Microsoft doing something daft, then I KNOW it's me :D Although I think the Intel compiler error I mentioned was surprisingly from last year.
It does happen in Debug mode if I enable the size optimization, it's just the data in the arrays is hard to spot by eye when it changes...hopefully the Watch can watch for changes in it (will check this out) so I can see what's corrupting it.
BTW the x and y confusion is probably where I've been moving this code around to try different things and that stuck by mistake - I'll clean that one up ;)
[edit] I think that this was my 25th post so I can finally give you karma for the tons of help!
[edit] Damn...debugging is out of the question because the optimization screws the symbols...but one thing I can see is that the texture array is being populated with duff values when run under size optimization, rather than being corrupted afterwards...the 'colMap' array that the textures derived their values from is being populated with 0's when size-optimized for some reason, and the textures still look the same when I overwrite values in that array anyway...time to look at COD outputs :'(
-
BTW I notice my GLU32.DLL has a dependency on MSVCRT.DLL, probably because it's installed with MS VC++, but is there a release that doesn't use MSVCRT?
google freeglut or glut windows, first or second hit is what you need.
-
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!
-
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
//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
-
Wow!
Thank you! Thank you! Thank you! Thank you! Thank you! (and K++ of course)
That's an impressive find :clap: 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 (http://dbfinteractive.com/index.php?topic=2310.15) 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!
-
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:
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
-
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 ;D
-
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 (http://www.agner.org/optimize/calling_conventions.pdf).
Jim
-
Thanks again - and that site seems to have some interesting stuff on it...hope I can absorb some of it!