I checked Ken's page out of curiosity a few days ago, and tripped over Voxlib. Having played with the 2003 voxlap demo, I'm quite interested in trying to get this to work -- I've always liked voxels, and it would actually be a more fun engine for me to use for one of my projects than a polygon based engine.
Problem is, I'm getting some -weird- problems getting the thing to build.
I first admit that I'm primarily a Unix software developer, and I've spent as little times in Microsoft dev tools as possible over the years. I'm familiar with command prompt work, but the microsoft CLI tools are fairly unintuitive to me. So I'm probably missing something obvious.
I'm using Visual C++ 6, service pack 5, with the processor pack for VC6SP5. What's baking my noodle are these linker errors.. Here's the output from nmake:
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
link simple voxlap5 v5 kplib winmain ddraw.lib dinput.lib dsound.lib dxguid.lib user32.lib gdi32.lib /opt:nowin98
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
LIBC.lib(crt0dat.obj) : error LNK2005: _exit already defined in MSVCRT.lib(MSVCRT.dll)
LIBC.lib(crt0dat.obj) : error LNK2005: __exit already defined in MSVCRT.lib(MSVCRT.dll)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(strcat.obj) : error LNK2005: _strcpy already defined in MSVCRT.lib(MSVCRT.dll)
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
simple.obj : error LNK2001: unresolved external symbol "void __cdecl kzaddstack(char const *)" (?kzaddstack@@YAXPBD@Z)
simple.obj : error LNK2001: unresolved external symbol "void __cdecl kzuninit(void)" (?kzuninit@@YAXXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kzclose(void)" (?kzclose@@YAXXZ)
winmain.obj : error LNK2001: unresolved external symbol "void __cdecl kzclose(void)" (?kzclose@@YAXXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzgetc(void)" (?kzgetc@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kzseek(long,long)" (?kzseek@@YAXJJ@Z)
winmain.obj : error LNK2001: unresolved external symbol "void __cdecl kzseek(long,long)" (?kzseek@@YAXJJ@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzopen(char const *)" (?kzopen@@YAJPBD@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzopen(char const *)" (?kzopen@@YAJPBD@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzread(void *,long)" (?kzread@@YAJPAXJ@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzread(void *,long)" (?kzread@@YAJPAXJ@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kztell(void)" (?kztell@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzfilelength(void)" (?kzfilelength@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kpzload(char const *,long *,long *,long *,long *)" (?kpzload@@YAXPBDPAJ111@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzeof(void)" (?kzeof@@YAJXZ)
LIBC.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
simple.exe : fatal error LNK1120: 12 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
Is there something I need to be doing to my build environment? Also, those symbols don't show up in google, and 'kz' doesn't look like a prefix that Microsoft would be using, so I was wondering if they might be from voxlib. The conflicting definitions are also confusing.
Any suggestions would be welcome.
Awesoken at
I forgot to put KPLIB.C -> KPLIB.OBJ in my SIMPLE.C makefile. If you compile GAME.C first, it will generate KPLIB.OBJ - and then everything should be fine after that.
I'm glad to hear about your interest in Voxlap : ) I'm curious to know what kind of game you're working on. Do you have a website about your project?
Hikaru at
No, I won't put together a website until I get enough of the core together to make it worth seeing. :)
I plan to use voxlib for a graphical client for a semi-MMO game. I'm not exactly sure how scalable the server will be, but I hope to be able to accomodate a couple hundred or so simultaneous players in a persistent turn based tactical setting. At the least, I know from past projects that I can manage at least 50 players, depending on the server hardware.
I won't really be making use of the intrinsic advantages of voxels, really. But assuming I get this sorted out, I think I could have some fun with this.
As to your suggestion..
I actually get the exact same linking failures with nmake game.c... Oddly, I had to c&p the rule for the kplib.c target and run it manually, but after that, no problems.
I just spent the last few minutes messing around in game.c, and I'm amused at the orphan detection. I haven't had a chance to go through all your source yet.. Is the orphan detection in the library itself, or is that in one of the .C files you include?
Hikaru at
Got distracted playing with slab6 after stepping away from the source. whoops.
And now it's bedtime and I have to leave this alone until tomorrow. Sadness.
I'm so much more familiar with forth than c/c++, it's not even remotely funny.
The idea of integrating something like FICL is growing more appealing very rapidly. Irony: I'll have to get rather familiar with what I'd need to get things done in C to get the proper entry points set up for FICL.
Oh well. This is quite the adventure.
Awesoken at
...game.c, and I'm amused at the orphan detection ... Is the orphan detection in the library itself, or is that in one of the .C files you include?
I'm afraid I don't know what you mean by "orphan detection". I realize my code isn't exactly the cleanest. I use GAME.C mainly to test new functions in Voxlap as I create them. In many cases, it's the only example code I have.
Hikaru at
After I posted that, I actually spent a little longer looking at voxlib instead of sleeping. :)
What I'm calling 'orphan detection' you refer to as fall checking, and I see the calls for that now.
As for the code, that's not a big deal.. A lot of my proof-of-concept and 'quick, make it work before someone complains' code is similarly messy. =>
The bigger problem is my relative unfamiliarity with C, which compounds any style issues.
I'm noticing that the lighting accuracy on adding lightsources in game.c is not quite on par with voxed. Is there something in voxlib that game.c isn't accessing, or is there something that voxed itself is doing that game.c is not?
Awesoken at
I'm noticing that the lighting accuracy on adding lightsources in game.c is not quite on par with voxed. Is there something in voxlib that game.c isn't accessing, or is there something that voxed itself is doing that game.c is not?
There are many lighting modes. It could be that you're using the functions wrong, but it is more likely that you just haven't found the right functions. You'll need to be more specific on which functions you're using and what mode you're comparing it to in voxed.
Hikaru at
Awesoken said
There are many lighting modes. It could be that you're using the functions wrong, but it is more likely that you just haven't found the right functions. You'll need to be more specific on which functions you're using and what mode you're comparing it to in voxed.
At this point, I clearly need to research and study what's here further so I can ask more intelligent questions. :)
I've determined that integrating FICL as I'd originally hoped is going to vastly be more difficult than I'd expected. Due to how you have the main loop designed, I'd have to either do weird things to winmain.cpp, or implement some state tricks for FICL's VM, and neither is particularly appealing. Oh well.
Judging by what I'm seeing, voxlib doesn't currently have a mechanism for point-accurate collision checking between sprites or between a sprite and terrain.. At least, nothing exported. Is there any work that's gone into that, or are the documented collision detection functions all that's been tried?
I mostly ask because I can imagine some places where more accurate collision detection would be handy, and right now the only way I could see that with arbitrary shapes (such as from meltfall) would be some fun shape analysis and defining some collision spheres.
This doesn't directly affect what I'm working on, but I was curious. :)
Awesoken at
I've determined that integrating FICL ... is going to vastly be more difficult ...
It would do you some good to learn some C anyway : )
voxlib doesn't currently have a mechanism for point-accurate collision checking between sprites or between a sprite and terrain.
That's correct. In Tom's unreleased game (2002 screenshots), he implemented his own collision system for sprite<->sprite collision. I think he just used spheres and it worked well enough.
For point-accurate collisions between sprite and terrain, I had an interesting idea for it, but never got around to implementing it. The idea was: pick 16 or so random voxels on the surface of the sprite. Then transform and project these to VXL coordinates. Then see if any of these points are inside terrain by calling isvoxelsolid(). This algorithm is likely to miss picking up a collision for a few frames - but it would certainly work as an interesting approximation without much speed penalty.
Hikaru at
Awesoken said
It would do you some good to learn some C anyway : )
Heh. Well, it's less a matter of learning, and more a matter of getting use to the mindset. I've been working with stack based systems almost exclusively for the past five years with the exception being LISP-like parsers. (Agony, I tell you. Agony.) I understand C decently, but it's difficult for me to think in. That aside, your point is taken.
Awesoken said
For point-accurate collisions between sprite and terrain, I had an interesting idea for it, but never got around to implementing it. The idea was: pick 16 or so random voxels on the surface of the sprite. Then transform and project these to VXL coordinates. Then see if any of these points are inside terrain by calling isvoxelsolid(). This algorithm is likely to miss picking up a collision for a few frames - but it would certainly work as an interesting approximation without much speed penalty.
That would probably work very well for small sprites.. You'd probably need to increase the sample size as the volume grows, or the inaccuracy would get increasingly obvious.
Sebastian at
Re: Trouble with compiling Voxlib
Hikaru said
LIBC.lib(crt0dat.obj) : error LNK2005: _exit already defined in MSVCRT.lib(MSVCRT.dll)
LIBC.lib(crt0dat.obj) : error LNK2005: __exit already defined in MSVCRT.lib(MSVCRT.dll)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRT.lib(cinitexe.obj)
LIBC.lib(strcat.obj) : error LNK2005: _strcpy already defined in MSVCRT.lib(MSVCRT.dll)
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
simple.obj : error LNK2001: unresolved external symbol "void __cdecl kzaddstack(char const *)" (?kzaddstack@@YAXPBD@Z)
simple.obj : error LNK2001: unresolved external symbol "void __cdecl kzuninit(void)" (?kzuninit@@YAXXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kzclose(void)" (?kzclose@@YAXXZ)
winmain.obj : error LNK2001: unresolved external symbol "void __cdecl kzclose(void)" (?kzclose@@YAXXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzgetc(void)" (?kzgetc@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kzseek(long,long)" (?kzseek@@YAXJJ@Z)
winmain.obj : error LNK2001: unresolved external symbol "void __cdecl kzseek(long,long)" (?kzseek@@YAXJJ@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzopen(char const *)" (?kzopen@@YAJPBD@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzopen(char const *)" (?kzopen@@YAJPBD@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzread(void *,long)" (?kzread@@YAJPAXJ@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzread(void *,long)" (?kzread@@YAJPAXJ@Z)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kztell(void)" (?kztell@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "long __cdecl kzfilelength(void)" (?kzfilelength@@YAJXZ)
voxlap5.obj : error LNK2001: unresolved external symbol "void __cdecl kpzload(char const *,long *,long *,long *,long *)" (?kpzload@@YAXPBDPAJ111@Z)
winmain.obj : error LNK2001: unresolved external symbol "long __cdecl kzeof(void)" (?kzeof@@YAJXZ)
LIBC.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
simple.exe : fatal error LNK1120: 12 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
I get exactly the same output but cant fix it even when I compile kblib seperately. How did you fix it?
But I must say I use VC++ .NET (i.e. VC++ 7)
Awesoken at
Trouble with compiling Voxlib
Type "nmake game.c" first and then everything should be ok when you type "nmake simple.c". If you really want to compile KPLIB.C manually, then you must include at least these 3 options: /J, /TP, /MD or else Visual C will generate an incompatible object file. If you already ran "nmake simple.c" first, then it may be easiest to start from scratch by unzipping again.
Sebastian at
Awesoken said
Type "nmake game.c" first and then everything should be ok when you type "nmake simple.c". If you really want to compile KPLIB.C manually, then you must include at least these 3 options: /J, /TP, /MD or else Visual C will generate an incompatible object file. If you already ran "nmake simple.c" first, then it may be easiest to start from scratch by unzipping again.
thanks, it runs now! - I used exactly the switches and it worked. The first time I compiled it (without the switches) I got an error in the definition of kv6data:
typedef struct kv6data
{
long leng, xsiz, ysiz, zsiz;
float xpiv, ypiv, zpiv;
unsigned long numvoxs;
long namoff;
kv6data *lowermip;
kv6voxtype *vox; //numvoxs*sizeof(kv6voxtype)
unsigned long *xlen; //xsiz*sizeof(long)
unsigned short *ylen; //xsiz*ysiz*sizeof(short)
} kv6data;
a C2061 Error, I fixed it by adding a "struct" in front of the lowermip Declaration.