Forum archive
VOXLIB queries
- Hello!
Im one of many (?) people playing with your amazing VOXAP code. At the moment Im building on simple.c to learn the functionality for myself. Im afraid its not a professional project!!! Reading your forum I can tell this is a tad annoying for you. Well maybe having chaps like me work on it will build interest?
Any how. Heres some questions that I hope you can answer for me.
Is it possible to change the distance for vx5.fogcol?
How can I clear the buffer the keyread() uses?
Also the code you have for reading input into "typemessage" (and processing it) really confuses me... All my experiments with this bit of code tend to break the system! Is this some how threaded? I can't see how, all the stuff in winmain is pretty sytandard for keyread().
Can you explain the Editing backup/restore methods?
Im _SLOWLY_ working towards making my own editor. Not that I think
yours is rubbish. It's just that I REALLY want some more VXLs to fly around (cavegen helped) and a user friendly editor might help the community... Plus its a good way to keep focussed on a project over summer ;)
You don't call genmipvxl() in your game code. Is this because .VXL saved from your editor have this information stored within them?
What are those "metaballs" you mention in VOXLIB.txt for setblobs?
Cheers - These are all excellent questions. I can tell you've done your homework and I admire that.
Yes, you can change fog distance. Use vx5.maxscandist.
To clear the keyread buffer, use this code:
while (keyread()); //flush keyboard buffer
The internal keyread() fifo is written to between doframe() calls. If you have any "wait for keypress" type loops inside doframe(), you must be call breath(); inside your loop to keep things running. The only place where I mess around with threads is in my sound system (in WINMAIN.CPP).
Someday, I'll release the source code to VOXED.C. Until then, here's some example code which should give you an idea of how it works:voxbackup(x0,y0,x1,y1,SETSPH);
setsphere(...);
...
voxrestore(); or voxdontrestore();/*use to deallocate memory on 64MB buffer*/
2 things to keep in mind:
1. You must write special code for each tool to calculate the x-y extents.
2. Usually you don't want to call voxrestore() until the next action is taken - which could be many frames later. In other words, you want to call voxrestore() before the next keystroke.
genmipvxl() is called internally inside updatevxl(). updatevxl() manages dirty rectangles for 3 things: lighting, mip-mapping, float-checking. You are free to call genmipvxl() explicitly, but it is not necessary if you use updatevxl(). VXL files only include the highest detail level. Mip-maps are always calculated on the fly at run-time.
setblobs() is just an interesting effect that I never got around to finishing. See METABALL.KC in Evaldraw for a visual demo of it. - Smashing! Just what the doctor ordered. Shortly after posting this question I worked out the keyread... Seems blinding;ly obvious now, the problem has just been my over complicating the situation by making eleborate assumptions.
Programming lesson #1. Simplicity is always best!
As for your backup/restore. Very interesting. In theory it would be possible to just backup the entire board and restore. Possibly stoopid but for todays fast computers maybe not such a bad idea... I think I will play with that for a while.
The general idea I was having for my editor was to have a list of additions and subtractions. Each containning details of dimensions, pos, col func etc (Thats my C++ thinking). This way it would be *easier* for a user to make alterations and tweak, much in the same way some one would work with qradiant to make a Q1,2,3 map.
Any how the long and short of it is another VERY big THANK YOU!!!
-Rik
p.s. where are the other bedroom coders? - Using backup/restore on the entire board is not only going to be too slow, but it will also put you at much higher risk of running out of memory. I allocate a static 64MB buffer for all VXL world data. This memory includes any duplicated parts on the backup & restore system. So if you backup the entire world, you would be limiting your maximum VXL map size to no more than 32MB. Actually, it's a little less than that if you take into account the memory fragmentation that occurs after a while.
The general idea I was having for my editor was to have a list of additions and subtractions.
That's a good idea. Tom and I were thinking about writing something like this a few years ago, but we never got around to it. The main problem is it takes too long to re-render everything from scratch. Here are some optimizations that might help:
1. Voxbackup/voxrestore can still be used to undo the last change
2. You could re-render a subset of the whole world - just the objects in the neighborhood of your changes. - Me again.
Few more questions...
what does the tag value stand for in voxbackup(...)? At the moment Im just setting to 0 or 1... It seems that in that mini example you had a constant SETSPH...
At the moment Im assuming that you call
voxbackup : on the area you will set some voxels to
set whatevere voxels
then decide
A : Im happy with where this voxel is set and call "voxdontrestore();" and make a permanant change to the map
B : Id like to change the settings, whatever (next keystroke as you say ;) ), "voxrestore()" return the map to what it was before calling "set..."
I've had a play and at the moment all I seem able to do is add shapes but not return to the old state of the map.
Can you release the VoxEd code? Just having the colouring functions would be fun! - Here's what the tag in voxbackup does:
(tag&0x30000) == 0 means don't back up
(tag&0x10000) != 0 means back up all geometry
(tag&0x20000) != 0 means back up intensity only (faster but only useful if no solid<->air changed)
I plan to release the Voxed source along with the rest of the engine code - "when it's done".