Forum archive
Voxlap programming questions
- Hey, I just came across Ken's amazing source code... His binaries work fine but when I try to compile... I get this...
http://img207.imageshack.us/img207/1344/badtrip.jpg
Andy Warhol on a bad trip...
Note: I'm compiling under VS2010 Express... and the latest DX distribution doesn't inlude ddraw.lib or dinput.lib anymore so I copied those files from DX8 into my sdk directory...
Any ideas?
Anyway thanks to Ken for opening the source... I plan to implement networking and see where it goes from there. Re: Voxlap programming questions
After compiling with VS2010, VC Toolkit, linking ddraw dynamically instead of statically, scratching my head at the assembly language, giving up, coming back, etc... the solution was to change my desktop depth to 32bit. I just wonder why my binary misreads the desktop depth (I'm guessing).- It looks to me as though the pixel format the renderer is assuming does not match the actual format of the surface, like 32bit into a 16-bit surface for example. Given the way the title bar fades from dark to light blue I'm guessing you're using a 16-bit desktop depth in that picture?
Jonathon - Yeah my desktop was at 16bit color... and like I said Ken's original binaries work fine under 16bit, just I have to track down why mine don't. Maybe I'll just label the 16-bit color option in my game as 'acid trip m0de'
- Hi, I'm trying to write a simple boxclipmove function (as opposed to the fancy sphere clipping implemented) but I have a couple questions on the char* sptr in voxlap.cpp.
It is usually referenced by:
v=sptr[p->y*VSID+p->x]
First off, I understand why it is VSID*VSID because I believe it stores solid voxel information or each xy index, but why the 4/3 multiplication in the declaration?
Also I'd just like to know if what v[0] to v[3?] are.
I think v[0] is pointer to the next solid in the z array but does it point up or down (+z or -z)
Thanks and sorry if the questions seem ignorant, I haven't coded in a while but I'd like to get back into it. - 1. It's for mip-mapping. 1 + 1/4 + 1/16 + .. = ~4/3
2. Search for "vbuf format" in VOXLAP5.C. - thanks!
Simplified dorthorotate
Partly as a coding exercise, and partly because I dont need the view to rotate around the ifor vector, I'm trying to rewrite the dorthorotate function to be more like half-life, etc... (yaw rotates around z-axis). Here is my current code so far... it kind of works but left/right mouse movement moves the view around the ihei vector instead of the games z axis. Any ideas how to fix this?
void viewrotate (double ox, double oy, double oz, dpoint3d *ist, dpoint3d *ihe, dpoint3d *ifo)
{
double dx, dy, dz, rr0, rr1, rr2, rr3, rr4, rr5, rr6, rr7, rr8;
dcossin(oy,&oy,&dy);
dcossin(oz,&oz,&dz);
/*
yaw movement rotates around ihei in stead of x axis... help!
rr0 = oz; rr1 = 0; rr2 = dz;
rr3 = 0; rr4 = 1; rr5 = 0;
rr6 = -dz; rr7 = 0; rr8 = oz;
X
up/down movement works
rr0 = 1; rr1 = 0; rr2 = 0;
rr3 = 0; rr4 = oy; rr5 = -dy;
rr6 = 0; rr7 = dy; rr8 = oy;
*/
//pre-calculate rotation matrix (the two above matrices multiplied)
rr0 = oz;
rr1 = dz*dy;
rr2 = dz*oy;
rr3 = 0;
rr4 = oy;
rr5 = -dy;
rr6 = -dz;
rr7 = oz*dy;
rr8 = oz*oy;
ox = ist->x; oy = ihe->x; oz = ifo->x;
ist->x = ox*rr0 + oy*rr3 + oz*rr6;
ihe->x = ox*rr1 + oy*rr4 + oz*rr7;
ifo->x = ox*rr2 + oy*rr5 + oz*rr8;
ox = ist->y; oy = ihe->y; oz = ifo->y;
ist->y = ox*rr0 + oy*rr3 + oz*rr6;
ihe->y = ox*rr1 + oy*rr4 + oz*rr7;
ifo->y = ox*rr2 + oy*rr5 + oz*rr8;
ox = ist->z; oy = ihe->z; oz = ifo->z;
ist->z = ox*rr0 + oy*rr3 + oz*rr6;
ihe->z = ox*rr1 + oy*rr4 + oz*rr7;
ifo->z = ox*rr2 + oy*rr5 + oz*rr8;
}Re: Voxlap programming questions
You can use the 3rd angle (actually the first parameter passed to (d)orthorotate) for tilt/horizon correction. The idea is to keep the height component (z direction in Voxlap) of the player's right vector stay near 0. To accomplish this, you can plug in "irig.z*-.02" as your tilt angle to keep the horizon stabilized.- Thanks again... I expanded out my funtion to allow rotation in 3 dimensions but I looked at the result and it looked a lot like your orthorotate funtion (just some signs were negated). I looked up how to get the motion I want but it looks like I'd have to implement qauternions... oh well I've put some simple if statements to limit motion how I want anyway. Thanks for merging topics... I'll post future questions in here.
- I've run into a road block in development. It seems sprites are not z-buffered correctly from above or below.. doesn't matter how many world blocks are in between. In a multiplayer game where players are rendered as sprites... this is a big problem. I don't expect an engine update after this many years but could you tell me, Ken, where the problem might lay? My guess (hope) is kv6draw or is it the zbuffer in general?
http://img690.imageshack.us/img690/1449/zbuf.jpg
http://img252.imageshack.us/img252/5738/zbuf2.jpg
Thanks!
-Ben - Unfortunately, that's not a bug. During the raycasting pass, the depth (parallel to the floor) is stored along with each pixel color. During the 2nd pass (projecting the raycasted data to the screen), this depth is converted to a standard (screen parallel) Z-buffer depth. The problem with this method is there is a singularity near the zenith point when you are looking straight up or down. I decided it wasn't worth the speed decrease to fix this artifact. It should be noted that I hacked in the Z-buffer after I had already written the raycasting code in assembly. Obviously, a new engine written from scratch would not be designed this way.
- Ahh ok... looking at the code it seems fog is done on the xy plane only too. Maybe one day I'll develop fully 3D z buffer and fog but for now I think clever use of cansee() before rendering sprites should get me by.
-Ben