Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1691837 views, last view: 04/25/2024 23:59

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#1552: linux debbugging enhancements

by rancor on 09/26/2006 00:47

After my sauer client crashed from the crash exploit that has caused a stir recently, it occurred to me that there was no good way of examining the sauerbraten client after a crash on linux. So, I wrote a patch that attaches GDB to the sauerbraten process on a fatal error. I would really like to see this get into the main distribution, since it makes it much easier to track down issues such as this. The patch is at the following URL: http://www.iit.edu/~lcooper4/patches/attach_on_signal.patch

reply to this message

#1553: cvs down?

by absinth on 10/03/2006 19:07

anyone else hat problems with cvs recently?

$ cvs update
sauerbraten.cvs.sourceforge.net: Connection refused
cvs [update aborted]: end of file from server (consult above messages if any)


strangely, a checkout works but i can't update

reply to this message

#1554: ..

by makkE on 10/04/2006 04:02

Sounds weird, but SF is known to behave weirdly at times.

reply to this message

#1555: ..

by absinth on 01/18/2007 19:12

i improved my score-hud patch:
http://homepage.mac.com/julianmayer/score-hud.png

is there any interest to get this commited?

reply to this message

#1556: R2T

by qwurty_ on 01/18/2007 19:30

I want to implement Render to Texture, but I really don\\\'t know how. I had render to texture semi working in a darkplaces for a while, but it was mostly copy and paste from the NVidia C++ \\\"Tutorial\\\" on render to texture (http://developer.nvidia.com/object/gdc_oglrtt.html), And I\\\'m lost on how to do it in Sauerbraten. Is this planned for implementation anytime soon or should I keep hacking away untill I find out how to do it? I have no 3D knowledge, though I do understand C/C++/VB, so if anyone could help with this it would be a great feature. Mirrors, security monitors, \\\"Fake\\\" Portals, the list goes on.

reply to this message

#1557: Re: score-HUD

by MeatROme on 01/18/2007 23:01, refers to #1555

interesting. Please give some more background on what your displaying there.
Like : what happens when your in the lead?
which frag-difference is displayed exactly? diff 2 leader or just to next in line?
maybe add display of the playername currently next in line (usually up but one down respectively if your in the lead)

reply to this message

#1558: Re: ..

by SanHolo on 01/18/2007 23:49, refers to #1555

Graphics could be improved, maybe just displaying 4 (-6) was enough (for rank 4 and 6 frags less than current leader), but I like the idea. Best implementation IMHO is in UT.

reply to this message

#1559: Re: score-HUD

by absinth on 01/18/2007 23:59, refers to #1557

it's an exact copy of the score HUD in quake 3 (minus the fraglimit display, because there is no fraglimit in sauerbraten)

it always displays your scores (blue background), and the score of the nextbest (if you are leading) or the best player (if you aren't leading)

the order depends on you leading or not

reply to this message

#1560: ..

by absinth on 01/19/2007 00:07

>exact copy
well, excact copy is a lie, in quake3 your score is displayed with red background when you aren't leading, i thought it would be better to always have a blue background for your own score (and red for enemy score) not to fuel the confusion about the red/blue teams in teammode. blue is always "me/us"

reply to this message

#1561: Re: score-HUD

by SanHolo on 01/19/2007 11:27, refers to #1559

I think a plus-sign (if you are first) or a minus-sign (if you're not the leader) before the frag-difference would help to identify which number means what.

reply to this message

#1562: score--HUD

by absinth on 01/29/2007 21:52

i've updated the score-HUD patch to support the team modes (capture, tdm)

here is a patch:
http://pastebin.ca/332235

and here is an updates items.png you need:
http://stud4.tuwien.ac.at/~e0126505/items.png

reply to this message

#1563: Re: score-HUD

by Pxtl on 01/29/2007 22:11, refers to #1561

Wait, so my score is -1+? huh?

Seriously, I think the best approach is mentioned above: your-score | leader-score, with leader-score teamcoloured. Thus, if the leader-score is blue, you're winning.

reply to this message

#1564: sparse voxel octree

by absinth_grrr on 03/13/2008 17:45

http://www.pcper.com/article.php?aid=532&type=overview


so is this sparse voxel octree that carmack talks about essentially similar to the octree saurbraten?

both seem to offer far better filesizes per geometry amount than traditional mesh storing...

reply to this message

#1565: Re: sparse voxel octree

by Heyho on 03/14/2008 00:06, refers to #1564

No.

An octree in sauer is composed by vertexes making triangles, with textures.

A voxel is a volumetric pixel, with his own color.

The little filsize of sauerbraten\\\\\\\\\\\\\\\'s map is due to a simple geometry. The most little angle value is Pi/24, textures are fixed, etc...

reply to this message

#1566: Re: sparse voxel octree

by rancor on 03/14/2008 01:11, refers to #1565

The answer isn't really no, but sort of. An octree is just a way of storing hierarchical partitions of space, it's not really dependent on what those partitions are.

The filesize does actually have a good deal to do with how well the octree structure compresses, many of the limitations you mention are in fact a result of the octree structure, rather then filesize optimizations.

reply to this message

#1567: ..

by absinth_grrr on 03/14/2008 01:40

>An octree is just a way of storing hierarchical partitions of space,
> it's not really dependent on what those partitions are.

i know what an octree is, in fact i wrote an octree "compiler" just a few weeks ago. the thing is sauerbraten doesn't use the octree to divide the geometry (like everybody else does), but instead the octree IS the geometry.

reply to this message

#1568: Re: ..

by rancor on 03/14/2008 08:30, refers to #1567

Yeah, I know you do, but the post I replied to didn't seem to.

The main point I was making was that anything using an octree structure is more similar to Sauerbraten then something using BSP.

This actually does seem more similar to the Sauerbraten structure, in that the voxels are the world, though not sure as to the exact format, as the article didn't go into enough detail.

reply to this message

#1569: Re: sparse voxel octree

by 9382938475 on 03/14/2008 14:33, refers to #1565

the cube structure isn't really defined by verts or triangles. its just that's what today's video cards understand so that's what it gets transformed into...

the octree implicitly stores the size and positions of everything, and the cubes just used to tweak things a little bit. that's why map sizes on disk are small - most of the info is being derived at runtime.

probably if sauerbraten just used really really tiny cubes, it'd be quite similar. but that's not practical today, so it allows for larger cubes that can be tweaked.

"The most little angle value is Pi/24, textures are fixed, etc..."

technically voxels are even worse. The 'smallest angle' is 90 degrees and 'textures' are only a single colour. You're kind of comparing trees with forests. Theres a difference between the properties of the primitives themselves, and the emergent properties of having a group of primitives placed together.

the thing to remember is that while the 'sparse voxel octree' doesn't even attempt to run decently on today's hardware, the genius of sauerbraten is that in compromises just enough to allow it do so.

reply to this message

#1570: Re: sparse voxel octree

by 9382938475 on 03/14/2008 15:27, refers to #1569

actually, what I think would be really interesting, is if the editing took more of a voxel editing approach. So you'd use small cubes of uniform grid size to carve up the world in various ways. This would just be at the cube level; not modifying the edges at all at this point. And then you could select an area and remip up to higher gridsizes in a way that smoothly uses the edges and whatnot.

and one could even work the other way around as well, subdividing cubes using something similar to a catmull-clark thing that works within the constaints of cubes. this'd work nicely for organic geometry at least. the nice thing about this is that you can work with cubes at a uniform gridsize and have the engine do the work of scaling detail up and down.

the heightmap stuff kind of attempts this, but this is a tough problem with multiple issues. In a sense it tries to do too much at the same time, yet still being useful for only very specific situations.

Really you need to split editing into two:
1) raw solid cube editing (no edge modifications, uniform gridsize), then
2) powerful filters that can be applied to groups of cubes to do stuff like smoothing, scaling gridsize up or down, and that sort of thing. Ideally one would let the engine manage edges and gridsizes itself, as much as possible.

There's a lot of research still there on how the filtering should be done though. The height map stuff does some cool things with paired-cube groupings, which makes transitions much smoother. But this needs to be moved from '2D heightmaps', to full 3D maps. There's a lot more cases to deal with when doing that though.

reply to this message

#1571: ..

by IllvilJa on 03/14/2008 18:53

Hm... regarding the above post on tools for creating objects in the saurebraten octree world: it could be useful not only to have powerful filters in the editor, but also to be able to write LUA/Python/Perl/Javascript/whatever scripts that process the world. Another stab at the latter is to create LUA/Python/Perl/whatever libraries that allows external programs to autogenerate or modify .ogz files. This can both be used to carry out some of the work with the .ogz maps, or to create a complete .ogz map from scratch. With a cleverly use of pseudo random number generators and seed values, one can have a script which creates the same fully playable pseudorandom map each time given the same random seed. This in turn can be used to implement random terrain in sauerbraten or mods (just like games like Freeciv and others have random maps), a seed value is generated randomly and distributed to all clients. Then all clients start generating the related pseudorandom map and once that is done, the clients enter said map.

Could bring the joy of exploration into the game. Ok, perhaps more suitable for a more BF2-like mod, but still.

reply to this message

   Board Index