Apparently in 2005 someone named Sebastian made a Voxlap engine using OpenGL, I currently use OpenBSD and Ken's release is... Windows only :'(.
Sadly, Sebastian's link is long since dead.. And I have not been able to contact him, If anyone downloaded his source when he originally posted it and still has it, Could you please post it here? I'd like to try to get ken's concept working on a true Operating System.
Original Topic: http://jonof.edgenetwork.org/forum/index.php?topic=166.0
Awesoken at
Re: I'm looking for VoxlapGL..
Consider yourself very lucky. I don't normally release other people's stuff without specifically asking them for permission. However, in this case it seems pretty clear (according to the linked thread) that Sebastian's intention was to share his code with the community. I am putting a (modified) copy on my website for a limited time. Unfortunately, I don't have Sebastian's original distribution. My copy includes whatever hacks I did to get his code to compile. Here's the link:
[link removed]
Edited by Awesoken at
Brynet at
Thanks very much, I've successfully downloaded the source. (Thanks for temporarily hosting it.. You are a generous person!)
Brynet at
Ported!! I've got many of the basic features implemented.. Mainly I had to rewrite a few things that like to call various functions of the Windows API.
Pros: Yay, Basic Voxlap on BSD (And other systems in the future?).. Finally no more Microsoft requirements... ;D
Cons: Painfully slow without hardware acceleration... (Or even with? :-\) Missing a few things... Mainly KeyFunc() in VoxEngine.cpp due to GetAsyncKeyState() calls.. (Dummy function inserted until other bindings are found)..
Here is a screenshot to drool over (I did..).. If there is interest in the source I'll post it here if the interest is high enough :)
(Btw when signing up I checked hide my email.. but it's appearing on the side.. is it only visible to me? or is there a bug in the forum software?)
Edited by Brynet at
Awesoken at
Painfully slow without hardware acceleration... (Or even with? )
Yeah. Sebastian's renderer is ridiculously slow. You have wasted your time. A brute force renderer would probably run faster! If you want a faster Voxlap clone, you should take a look at Peter Houska's site: http://stud3.tuwien.ac.at/~e9907459/ It's still no Voxlap though.. I'm sorry you find my source code prohibitively complicated : /
Brynet at
Well, It's indeed slow.. Maybe it can be improved, but I'm no algorithmic genius..
http://stud3.tuwien.ac.at/~e9907459/ is of no use to me, It's closed source.. He only provides what looks like to be a linux or Windows binary.... :'(
As for your code.. It is extremely dependant on: Microsoft's Windows Operating system... DirectX... and Microsoft's Visual C++ Compiler...
(I can only take so much before it starts making me feel sick to the stomach.. :D)
But I'm a fan of your work and ideas none the less, One can only imagine how many innovations would of came from the great Ken Silverman if his original development platform was UNIX derived. ;)
Awesoken at
http://stud3.tuwien.ac.at/~e9907459/ is of no use to me, It's closed source..
You know, you could try asking Peter for the source code. I think there's a good chance he would be cooperative, and possibly even delighted to help.
As for your code.. It is extremely dependant on: Microsoft's Windows Operating system... DirectX... and Microsoft's Visual C++ Compiler...
I have tried my best to put all of my system dependent code into a separate module called WINMAIN.CPP. JonoF has written a Winmain replacement for SDL called SDLMAIN.C - if you ask him for the latest copy, that would speed up the porting process a lot. As for the Visual C compiler, the main depenencies are the blocks of in-line assembler. For most blocks, I have kept the original C code that it was based on. You can enable these by simply changing an #ifdef. I'm not saying that porting my code will be easy. I'm just saying it would probably not be as hard as you may think.
Brynet at
Thanks for the information, And your time :)
Jinroh at
Wow. So cool to see Ken's jawsome Voxlap Engine Expanding to other platforms.
Once I get some more experience with 3D Graphical Algorithms (and 3D Graphics in general) I'll have to play around with the code. I've been keeping my eye on it but lack of experience is the barrier against me. :'( If only this could be about game logic or AI then I might be up to speed, I'm a bit stronger in those areas. :D
What might the estimated system requirements be Ken? I'm curious because of some potential consoles maybe that it could be ported to. Only because console ports interest me for some reason or another.
Cool new avatar BTW Ken.
Awesoken at
Wow. So cool to see Ken's jawsome Voxlap Engine Expanding to other platforms.
Sorry to disappoint you, but you ought to read the thread more carefully. What Brynet has ported is a much much slower clone of Voxlap without any features.
What might the estimated system requirements be Ken?
Voxlap in its current form requires a CPU equivalent to a Pentium III, and 128MB of memory. I expect it could work on an Xbox just fine. To reduce the memory requirements, you would either have to compress the colors, and/or use smaller map dimensions.
Cool new avatar BTW Ken.
Hehe, it's tile 3445 of Duke Nukem Atomic Edition : )
Brynet at
Yeah sorry Jinroh.. Kens Voxlap uses DirectX etc, I ported the unusually slow OpenGL clone written by Sebastian Scholz (Who is unavailable for contact..)
@Ken, I could not find Peter Houska's email so I have not enquired about his Voxlap like project, I tried contacting Jonathon Fowler the other day for the SDLMAIN.C file with little success (But I'll keep checking my email..)
Also I attempted to look through your code Ken, It is generally well contained (Sorry for my previous comments) but I would have to port a large amount of Assembly to GCC's AT&T format (And generally make changes to various other calls you use..)
Once I get SDLMAIN.C I might be able to get an idea to float around in my head, but currently I'm at a loss.
It's quite shocked at the lack of interest there is for Voxlap, I found the demo game (With that house..) fairly neat a few years ago.. Destructible environment etc.. :D
(And yes.. Your avatar is nice lol..)
Jinroh at
Yeah sorry Jinroh.. Kens Voxlap uses DirectX etc, I ported the unusually slow OpenGL clone written by Sebastian Scholz (Who is unavailable for contact..)
Sorry to disappoint you, but you ought to read the thread more carefully. What Brynet has ported is a much much slower clone of Voxlap without any features.
No need to be sorry, it was my mistake, I was skimming it at work and should have either been A. Working Harder or B. Reading more carfully :P. But, no need to be sorry none-the-less, Micro$oft wasn't built in a day and all that. We'll get a cross platform Voxlap-like engine in good time.
I'm sorry to disappoint you guys though. I tried my hand at a Voxel Terrain like the ones Comanche last night and yeah...it would be acceptable for maybe an Atari 2600. Had correct projection though so I guess I'm getting better with that at least.
Voxlap in its current form requires a CPU equivalent to a Pentium III, and 128MB of memory. I expect it could work on an Xbox just fine. To reduce the memory requirements, you would either have to compress the colors, and/or use smaller map dimensions.
Ah, I see. That sounds about close to the Xbox, look like it has 64MB or RAM so yeah, reducing both the maps and switching to maybe 8-Bit color would let Voxlap clear the bar. But the Xbox does run DirectX so a port may be feasible.
Hehe, it's tile 3445 of Duke Nukem Atomic Edition : )
Hmm...I'm gonna have to dig around my Atomic Edition now. :D
Awesoken at
Ok, I put a download for SDLMAIN.C on my Voxlap source code page: http://advsys.net/ken/voxlap/voxlap05.htm I should not have suggested bothering JonoF about it. How silly of me : ) Also, I sent Peter Houska an email about this thread. Hopefully he will respond soon and offer his help.
Awesoken at
FYI: Peter Houska has updated his site with an E-mail address. He says he may do a Linux port himself, and that he's thinking about releasing the source code.
Brynet at
Thanks for the information Ken. :D
ChEeZeBaLL at
Awesoken said at
Hehe, it's tile 3445 of Duke Nukem Atomic Edition : )
Out of sheer curiosity, was that texture ever used in the game?
Awesoken at
Yes. Exactly once... and it's really hard to find! It's on the secret level, e1l7, which is not accessible by the in-game cheat keys. You must load it from the command prompt using 'duke3d /l7'. My face is on the lower level, on the side closest to the upper level (as viewed from the 2d map).
Ghostpilot at
Then, how about TRACY?
I accidently stumbeled upon this one, when searching for info about voxel rendering. TRACY realtime volume rendering engine Look like the "littlebrother" of voxlap.
Jinroh at
Re: I'm looking for VoxlapGL..
Ghostpilot said at
I accidently stumbeled upon this one, when searching for info about voxel rendering. TRACY realtime volume rendering engine Look like the "littlebrother" of voxlap.
Wow, with the OpenGL rendering it does look impressively smooth. Someday, my voxel rendering engine will work well without fighting with me too much. lol. Oh well. I just need to come back to it after clearing my head for a few more months.
But yeah, it looks like a Voxlap Lite maybe? Or whatever creative name you could insert there. :P
I'll be playing Duke Atomic later to find the elusive Ken :D
Edited by Jinroh at
husky at
Hello Voxelfans!
My VXL-viewer has been mentioned on this forum some time ago. I just released the source-code. It's in no way clearly structured - it just grew over the years, sorry... I added a minimalistic doxygen-documentiation, so I hope this helps!
(Ken adds: Link to Husky's site)
Edited by husky at
Brynet at
Peters Voxel viewer is just wild, I got some pretty decent fps rates on a OpenBSD system without any hardware acceleration!!
I'd like the thank him for releasing the work under a "BUILDLIC.txt" inspired licence :)..
I can navigate through kens infamous "untitled.vlx" map on a Open Source system :D w00t..
I got around 6fps when walking.. I'm guessing on a system with hardware acceleration it would be considerably faster ;D
Edited by Brynet at
husky at
Hello Brynet!
Nice screenshot and thanks for the positive feedback :) It's really cool to see my demo run on a third platform/OS (in addition to my own "tests" in Linux and Win32)!
Did you compare the framerates with Sebastian's VoxlapGL?
Btw., hardware acceleration won't improve the framerate - it's a pure SW-renderer (just like Ken's VOXLAP), so it doesn't take any advantages of a modern GPU :(
Brynet at
husky said at
Hello Brynet!
Nice screenshot and thanks for the positive feedback :) It's really cool to see my demo run on a third platform/OS (in addition to my own "tests" in Linux and Win32)!
Did you compare the framerates with Sebastian's VoxlapGL?
Btw., hardware acceleration won't improve the framerate - it's a pure SW-renderer (just like Ken's VOXLAP), so it doesn't take any advantages of a modern GPU :(
Well the thing is, OpenBSD only supports the 2d hardware operations of the 3d card.. but with that said, With Sebastian's render it took like a minute per move in any direction.. I get that with "every" OpenGL program simply because the OS has no hardware assisted graphics acceleration.. (Due to developers philosophical reasons for not using closed source drivers in OpenBSD.. And lack of security with DRI..)
The card in this OpenBSD system though is a Matrox G200 with 8mb of Video Memory (Pentium 2 @ 400mhz), In the past I had FreeBSD on this system with DRI and games like Duke3d worked brilliantly.
I do expect that the card is capable of using ph6dvxl at a higher framerate, But I'm currently limited by the low-level "software" rendering of "everything" which is not so great sadly.. :'( It might be faster on a system with more RAM and a faster CPU though.. :)
So in conclusion, My "comparison" on a system without hardware acceleration was that ph6dvxl is considerably faster, But I can't compare VoxlapGL with ph6dvxl on a system with hardware acceleration, But I myself would definitely be rooting for ph6dvxl ;)
Take care, And thanks again!
Edited by Brynet at
husky at
I see, things are a bit more complicated when it comes to hardware-acceleration on your system - I didn't know, sorry ;)
Now OpenBSD caught my attention - maybe I'll try it out, too :)
Sebastian at
Hi,
I've seen this thread qite lately, but... the source as well the demo is available at www.sebastianscholz.at
best regards sebastian
Dany at
I can visit peter someday(he lives only 20km from me ::)), and ask him ow did he do that, as Ken said, without HWACC it's S-L-O-W(remember system shock without it?). Not even like slow but you can't imagine how bugful(I belive that you're 13-20 years old gamer). The problem of thos codes is that, that it stays in the debug version(like in BadGamesMaker 1.0-7.0-future versions), so it looks like this:
myfunnygeometry: draw: do cube.a * cube.b...... x= 1*|zyx... do draw cube = [a=1,b=1,c=1,d=1...]
But final versions MUST look like this: //fasty-blasty cube that sucks(however) by Dany (C) 200000000800000 IH$TEmicros$ft cbdr: do cba * cbb * cbc * cbd..... x=cbcalc() cbcalc: blabla cb = [(a|b|c|d|aa|bb|cc|dd|z|x|y)=1] Like, do you see the change? first of all, learn this, it it really helpful, because if you got like 2GB of code THIS will mean ratio between old and new code 1:1000(2MB). And the compiled code makes EXACTLY the thing it has to do, not like if it will stay in debug version, this version is overusing RAM and crashes 1000 times per day. P.S.:Take it to your hearth, but not head, I'm pretty sucky weekend-programmer that still doesn't understand WHAT THE HELL is void!!!
jeffz at
Awesoken said at
FYI: Peter Houska has updated his site with an E-mail address. He says he may do a Linux port himself, and that he's thinking about releasing the source code.
Peter's programs (and Voxlap too) work perfectly under Wine if anyone else on GNU/Linux is interested