Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1691689 views, last view: 04/25/2024 11:58

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

   Board Index   

#1: right...

by Aardappel on 03/03/2004 05:28

finally everything is in CVS, the new enet, the linux fixes and some other stuff, so it is now ready to go.

Hardly anyone has commit access yet, so if you get started working seriously on Sauerbraten and feel you should have commit access, let me know

reply to this message

#2: ..

by hungerburg on 03/03/2004 15:12

the enet source defines in the Makefile HAS_SOCKLEN_T=1, when including ../enet/include/enet/unix.h from the cube src dir, this is not defined and gcc quits with an error (conflicting types for `typedef int; previous declaration in /usr/include/bits/socket.h).

this is with glibc-2.3.2; add -DHAS_SOCKLEN in the cube Makefile after CXX=g++ and there is no more error, but it takes away the autoconf advantage.

reply to this message

#3: Re: ..

by hungerburg on 03/03/2004 16:49, refers to #2

the best way probably was, if configuring enet wrote the defines into a file config.h instead of the Makefile. compiling the cube source then could include ../enet/config.h and the problem was set.

reply to this message

#4: Re: ..

by Aardappel on 03/03/2004 21:24, refers to #2

Yeah this isn't really a nice solution. Eihrul?

reply to this message

#5: Re: ..

by eihrul on 03/05/2004 00:37, refers to #2

The solution is simpler than you think... I just moved the definition of socklen_t to the only place it is actually used... unix.c.

Crisis averted!

reply to this message

#6: Modeling

by eddy on 03/05/2004 21:22

hey i would like to contribute to this new project, i can not program but i can make mods for the new game...
if your interested

reply to this message

#7: wait wait..

by Lethedethius on 03/07/2004 05:42

What is this!? :-X

reply to this message

#8: ok.

by Lethedethius on 03/08/2004 02:53

Now that I know what this is...

I believe the new cube should be atleast 20x better, both graphically & script wise.

Graphically it needs more weapons to choose from, if dcp could do this everyone would kiss his toes =-). Perhaps some totally new kinda weapons should be brought into play. *A sword ;)...*, Sauerbraten should have more modding capabilities. ie... keep the gameplay seperate from the engine; so it's easily editable. Maybe Sauerbraten should be equipped with it's own set of skin type (not quake format...) & unique types.

reply to this message

#9: Re: ok.

by pushplay on 03/08/2004 06:59, refers to #8

I think md3 is the most widely-supported, open format at this point.

reply to this message

#10: ..

by staffy02 on 03/08/2004 08:17

that is because so many games, mods, players and engines use it.

reply to this message

#11: rendering random tiled textures in pov-ray

by sinsky on 03/09/2004 14:43

To make this work you need Pov-Ray (my version is 3.5; povray.org) and the tile generator macro from Chris Colefax:

http://www.geocities.com/SiliconValley/Lakes/1434/tilegen.html

If anyone comes up with those things I'll write a small tutorial and answer questions if any. Other free programs that can help you further (you're on your own there but it shouldn't be too hard) are Wally, The Gimp (available for Windows, too), Virtual Dub (can load and view bmp and tga sequences; this app is originally used for avi file creation but I use it a lot for viewing as well). If such info has been posted here previously please disregard this.

I can help in the development with simple and textureless models (I don't have the experience for anything else for now, maybe I'll manage to do something more useful later). If you make anim8or support for your project I may be able to do more stuff (again, I'm only learning now, so don't expect great quality, at least from me)

reply to this message

#12: How would this be for terrain? err...and other thoughts

by Stampson on 03/10/2004 02:41, refers to #1

How good will the method in Sauerbraten be at terrain, as in ground? I'm wondering if a single, simple world such as this could work for a world that is a mixture of dense city areas and terrain. Or consider large buildings separated by terrain as in the tribe series. I'm also thinking of large city areas with rooftops which are traversable, which would be similar to terrain in view distance, but even more demanding in detail. What kind of view distance could be managed with open terrain?

I wonder if it would be worth having support for octree members which are not 6-dimensional, but only one or two. This could allow for more compact data storage, especially since significant portions of interior and exterior spaces would only need one or two dimensional heightfield support. The engine could simply replace a one or two dimension octree with a 6, if the member was edited such that it was needed. It would only save a few bytes each as its written now, but if you're after a significant terrain view distance, it sure adds up fast.

Also, could an axis-aligned bounding box tree work rather than an octree for even more compact storage? The grid system keeps suggesting it to me.

-stampson

reply to this message

#13: some idea's

by Lethedethius on 03/11/2004 00:43

Well hopefully this Cube2 will include some more support for varius things as... player limit to a server, html & graphics, Server names & MOD Names, so that your cube version can connect to that specific port...

Also Aard, it might not be a bad idea to make it so you download maps from the server... that way you'll always have the textures needed? no? :)

reply to this message

#14: question about representation

by stampson1 on 03/11/2004 20:17

Would this be two primitives or many more?

/######/ /######/
/######/ /######/
/######/ /######/
/######/ /######/

In case my ascii art does not work, I attempted to indicate two slanted cubes leaning in the same direction separated by a small gap, but part of one cube \\\'overhanging\\\' the other. Are the cubic primitives to be bounded by the octree member they are part of? If so it might cause the number of primitives to represent certain types of shapes to explode. Of course, that might simply mean one doesn\\\'t use those shapes =)

-stampson

reply to this message

#15: Re: How would this be for terrain? err...and other thoughts

by Aardappel on 03/11/2004 21:01, refers to #12

it will generally do well on mixed scale maps (i.e. a dense building area surrounded by large course grain terrain etc), that's what it was designed for.

There's no real reason to make special octree node types to save space. Sauerbraten derives its simplicity from having a single node type, others would complicate matters. And the current node type is already very compact.

Your figure would likely have to be at least 3 primitives. The rule is simple: if you can model a shape as a "deformable cube" that fits inside an octree node, you will have to use multiple nodes to model the shape.

reply to this message

#16: Re: How would this be for terrain? err...and other thoughts

by Aardappel on 03/11/2004 21:02, refers to #15

can -> can't

reply to this message

#17: As I understand it...

by Pxtl on 03/11/2004 21:04

The minimal representation would be 3 primitives - one for each cube, and one for the air volume in between. In Sauer, air volumes are cubes too. Now, the catch is that such a structure would also depend on the scale of the objects around it, as the system is based on a grid with deformable points - so if depending on the details around it, then the resolution of the surrounding octree could be higher such that one or more of these cubes would have to be rendered with extra cubes (probably 2 at most).

Think of it this way - imagine a Voxel system where the corners of each voxel can be moved around. Each voxel has 2 states - solid or empty. Now, heres how the octree thing comes in - a voxel can be split into 8 voxels. The base concept is that the level is a big voxel that you divide up repeatedly until you get the voxel resolution you need to construct your detail. This resolution can vary on the details of the region. So, for an empty parkinglot it can be very low, but for a bathroom it can be very high.

My description is very obfuscated - the true system is very simple, but hard to explain without a nice graphical animation.

reply to this message

#18: Maybe a lot more than three...

by Stampson on 03/12/2004 06:45, refers to #15

It would be much more than three..if you have a cube shape which overhangs another cube shape which is on the same level as the overhanging cube shape, it will result in a great many uninteresting subdivisions. For the 2d case alone it causes at least two deeper subdivisions of two or more octrees based on my napkin diagram. It would be worse for a 3-d case, if your shape overhangs on multiple sides. Depending on the angles involved it could be most inconvenient indeed.

I'm not arguing that the simplicity of the world should be sacrificed over this, basically I am just getting a feel for what kinds of geometry are going to be tough on the representation.

On the bright side, it does seem to me that the world representation is ideal for the sorts of shapes architecture is made from, and the situation I describe could likely be avoided without sacrificing level design goodness.

But, if the editor ever reaches a point where it is shaping elements automatically, rather than the player picking and manipulating every piece, it could be a bigger concern, because the player could create massive space wastage without realizing it. Maybe it's just an education issue for the map makers.

-stampson

reply to this message

#19: Re: Maybe a lot more than three...

by pushplay on 03/12/2004 07:06, refers to #18

The answer has to be 1, 8, or something times 8.

reply to this message

#20: Well, I was only considering

by Pxtl on 03/12/2004 19:20

I was only considering the cubes he mentioned - I didn't discuss the surrounding area. If it is air around this "archway" then each of those air cubes will need a cube. The point is that the archway will require at least three cubes itself, regardless of the floor underneath and its surroundings, and the detail level implied by this archway will also increase the resolution of the octets of which it is part, which may or may not be made use of.

Personally, I think that once we all get comfy with Sauer we'll find it disgustingly easy to work with. The way I figure we handle the problem you descibed is to allow mappers to design geometry with higher level tools, but the actual resolution of the geometry must be set in place before the modelling is placed. So if a mapper wants a circle/dome sort of deal thats fine, but they must set the octree density of the region they plan to place it in before they place the dome.

reply to this message

   Board Index