Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1700788 views, last view: 05/18/2024 16:18

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

   Board Index   

#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

#21: VC++ 6 project file progress

by stampson1 on 03/12/2004 21:03

Well, I have created a vc6 project for Sauerbraten, and it seems to me to work, however I have encountered the following issue.

From tools.h:

#define loop(v,m) for(int v = 0; v<(m); v++)
#define loopi(m) loop(i,m)
#define loopj(m) loop(j,m)
#define loopk(m) loop(k,m)
#define loopl(m) loop(l,m)

When the loop macros are used, the second time the compiler encounters one it errors and complains about the redeclaration of the index variable used int the loop.

I can certainly imagine many ways to fix this for myself, however in terms of the project, should changes to suit vc6 be rolled back into the source, or should people using vc6 just roll their own?

Of course it's possible I'm so rusty I am just missing something =)

Here is a link to the project file, if it is of use or interest: http://www.westga.edu/~phall/vcpp.zip

reply to this message

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

by Aardappel on 03/12/2004 23:59, refers to #18

Yup, sauerbraten allows a rich set of geometrical shapes, but there are worst cases. Editing for Sauerbraten means having fun piecing things together taking into account the cubes you work with, not trying to squeeze every potential shape in there.

There certainly never should be a generic mesh->sauerbraten importer, it would be senseless. The other way around however can be useful and is absolutely trivial (the data is already available in the engine as mesh).

reply to this message

#23: Re: VC++ 6 project file progress

by Bingo! on 03/17/2004 19:25, refers to #21

Not sure how this would be changed in the project. I think the problem is down to MSVC6.0 not adhering to standards ;-)

The scope of variable definitions in loops should be local to the loop but in MSVC6.0 they are local to the enclosing block!

You can fix these errors by simply wrapping the offending items in curly braces to force a block to contain the scope. Not sure if this is the best way though! Anyone have a better way?

reply to this message

#24: Sauerbraten Mac OS X Port

by absinth on 03/18/2004 00:53

hello
i've ported sauerbraten to macosx.
you can get a diff at http://homepage.mac.com/julianmayer/osx.diff

project files for macosx can be downloaded from http://homepage.mac.com/julianmayer/osx.tgz
(the folder should be put inside the sauerbraten folder)

i had to disable the GL_NV_vertex_array_range stuff for macosx, but if someone would modify the code to also work with the GL_APPLE_vertex_array_range extension, it would be better ;)

regards, julian

reply to this message

#25: Re: VC++ 6 project file progress

by Bingo! on 03/18/2004 12:34, refers to #21

Sorry I should probably have posted this before. You can download a working MSVC++ 6.0 project from the Sauerbraten page on my website...

http://www.linux-games.co.uk/

Should compile fine and there's a read me with changes listed.

reply to this message

#26: Re: Sauerbraten Mac OS X Port

by hungerburg on 03/18/2004 12:51, refers to #24

this looks cheap:) and does it run too? or just compile...

BTW: the last two hunks (in renderparticles) should not need a #ifdef apple - they might be due to the gcc apple ships; sth. similar happened with building the initial source on linux systems.

then it seems wrong to me, that you three times set v.x, but not v.y and v.z... but I dont know c++, only c, and dont understand the declaration of struct vec in cube.h...

PS: the eu dont make law, but "directives", these are made into law by member countries (cf: http://wiki.ael.be/index.php/EUCD-Status)

reply to this message

#27: Re: VC++ 6 project file progress

by Aardappel on 03/18/2004 20:37, refers to #25

that's cool... I guess you could add things like that to CVS

reply to this message

#28: ..

by shahar2k on 03/19/2004 05:52

I just played with Sauerbraten for a bit, and I have to say this kicks ass, I was wondering about the earlier comment about using 3ds max to make Saurbraten maps... wouldnt you be able to do something like a marching cubes algorithm and take ANY 3D object and devide it into the appropriate 3D volumes? it seems very similar to the way metaballs are created from pure equations... at the same time it seems like you could even write a converter for wings maps though they would become a bit less efficient under the new engine (since elongated shapes require multiple cubes instead of just one column) though I dont claim to know much about the internals of the engine.

About the RPG Idea, originally unreal had a cool Idea where in any particular server, you could have doors and portals which would lead to other servers and players would be able to go between servers like a kind of HTML for a 3D world.

you could perhaps create a kind of distributed system, where by running the client, you have your own home \"map\" which anyone can visit, and you can visit anyone else running the client

just a few out-there ideas, hope this inspires.

reply to this message

#29: Re: ..

by Aardappel on 03/19/2004 07:06, refers to #28

again, yes its technically possible, but it would completely defy the point of sauerbraten. If you want to use max to create game architecture, you are better off with other engines.

Linking up servers is a fun idea, but it needs a bit more serious infrastructure to be really fun. You could have a mini-mmorpg this way if players could carry their stats & items over to new servers, and worlds persisted as well.

reply to this message

#30: Re: ..

by D.plomat on 03/19/2004 10:55, refers to #28

linking servers... sounds interesting, but it probably would be better to link multiple games hosted on the same server, as -like now for Cube- servers aren't always running the latest version(or it'd need some version checking system), and worst of all, if a link makes 6 ppl go from a server with good bandwidth to one with bad bandwidth that can be annoying.

reply to this message

#31: Re: Sauerbraten Mac OS X Port

by absinth on 03/19/2004 13:40, refers to #26

>this looks cheap:) and does it run too? or just compile...

yeah it runs just fine ;) even my scrollwheel works for editing

>BTW: the last two hunks (in renderparticles) should not need a #ifdef apple - they might be due to the gcc apple ships; sth. similar happened with building the initial source on linux systems.

yeah the compiler barfed at it, even though it is a modified gcc 3.3 which should be the same as on linux.

>then it seems wrong to me, that you three times set v.x, but not v.y and v.z... but I dont know c++, only c, and dont understand the declaration of struct vec in cube.h...

you are right it should not be three times x, didn't seem to matter though ;) i've updated the diff to be correct.

>PS: the eu dont make law, but "directives", these are made into law by member countries (cf: http://wiki.ael.be/index.php/EUCD-Status)

yeah i know but a law based on the EUCD directive is already passed in austria...


any chance some changes might be integrated or the project files might be added?

regards, julian

reply to this message

#32: Map editor

by PigeonRat on 03/20/2004 23:48

I downloaded Sauerbraten last night, and I must say, it's already looking quite nice. If I get some time I might be able to do a bit of work on it.

One thing, with the map editor, is that I was only able to push cubes down, not up. Say I have a flat ground, I can't select a cube and then scroll up to have it above the ground. Is that a bug, just not implemented yet, something I'm doing wrong or is the engine just not designed for this?

Hope that made sense.

reply to this message

#33: ..

by PigeonRat on 03/20/2004 23:49

BTW, if a cube hasn't been push the whole way down, I can still bring it back up. ie if I've only scrolled it down 7/8's of the way, I can still bring it back up.

reply to this message

#34: Re: Map editor

by pushplay on 03/21/2004 03:50, refers to #32

Right click to deselect, hold f and use the scroll wheel.

reply to this message

#35: ..

by PigeonRat on 03/21/2004 04:33

Thanks :)

reply to this message

#36: ..

by shahar2k on 03/22/2004 00:04

just wondering, but how feasable is it to add dynamically modifyable geometry to this? you could create something like in "scorched earth" with something like a "dirt missile" would create a sphere of junk in the world, or you could dig through the world using generated negative meshes. just an Idea, but I think it would kick ass to have this kind of stuff in a multiplayer game (somone's chasing you, you can dig your own tunnels, then fill them up)

reply to this message

#37: shahar2k

by Pxtl on 03/22/2004 03:55

Look up an indie game called Tread Marks. High-speed tank combat and racing game with fully mutable terrain.

reply to this message

   Board Index