Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351330 views, last view: 12/09/2021 06:27

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

   Board Index   

#81: Re: Scripting

by pushplay on 04/17/2004 03:46, refers to #80

I'm 100% with you on the direct manipulation and visual feedback, but radiant has the invisible brushes and string arguments. Would that be something worth adding to Sauer, or is there another way to get the same power?

reply to this message

#82: Re: Scripting

by Aardappel on 04/17/2004 21:26, refers to #81

probably as sauerbraten gets more mature we can extend its GUI capabilities and add more traditional entity properties editing.

But this particular feature doesn't need that at all. Why use strings to connect entities, when you can just have the editor create a link for you at the press of a key?

reply to this message

#83: abuse

by Pxtl on 04/17/2004 22:20

http://www.the-underdogs.org/game.php?id=18

best in-engine map editor ever. Place triggers, events, logic, wire things together, etc, all graphical.

type

abuse -edit

to use it. Copying that would be good.

reply to this message

#84: Re: Scripting

by pushplay on 04/17/2004 23:47, refers to #82

Connecting triggers doesn't need strings at all, but what about dialog? This is an rpg after all. :)

reply to this message

#85: Re: Scripting

by macdonag on 04/18/2004 17:23, refers to #84

As far as I can see, if you want to script interactively, you need some sort of widget set. Combine that with some 3D tools to map paths, place things, point in directions, etc. and you'd have something useful (and tres cool)!

reply to this message

#86: subdivision

by Gilt on 04/18/2004 18:16

if(c->children==NULL)
{
if(!tsize) break;
c->children = newcubes(F_EMPTY);
uchar se[3][3][3]; //[dim][col][row] z to x

loop(d,3) // expand edges from 4 to 9
{ // set corners using c, avg of neighbours for rest
loopj(2) se[d][0][2*j] = c->edges[j+(d*4)];
loopj(2) se[d][2][2*j] = c->edges[j+2+(d*4)];
loopj(2) se[d][2*j][1] = ((se[d][2*j][0]>>1)&0x77) + ((se[d][2*j][2]>>1)&0x77);
loopj(2) se[d][1][2*j] = ((se[d][0][2*j]>>1)&0x77) + ((se[d][2][2*j]>>1)&0x77);
se[d][1][1] = ((se[d][0][2]>>1)&0x77) + ((se[d][2][0]>>1)&0x77);
// ((se[d][0][0]>>2)&0x33) + ((se[d][2][2]>>2)&0x33);
};
#define rb3(num) (((num<<1)+(num&4?1:0))&7)
#define pd(d,i) (i&(1<<(2-d)))
loopi(8)
{
loop(d,3) loop(col,2) loop(row,2)
{ // split edges into +ve/-ve per dim and assign
uchar *cce = &c->children[i].edges[(d*4)+(col*2)+row];
uchar sed = se[d][col+(pd(d,rb3(i))?1:0)][row+(pd(d,rb3(rb3(i)))?1:0)];
if (edgeget(sed,1) < 5) *cce = (pd(d,i) ? 0 : 2*sed);
else if(edgeget(sed,0) > 4) *cce = (pd(d,i) ? 2*sed - 0x88 : 0x88);
else *cce = (pd(d,i) ? (2*sed - 0x80)&0xF0 : (2*sed & 0x0F)+0x80);
};
loopj(3) if (!c->children[i].faces[j]) emptyfaces(c->children[i]);
loopj(3) c->children[i].colour[j] = c->colour[j];
loopj(6) c->children[i].texture[j] = c->texture[j];
};
};
--------------------------------------

That's my first version of working code for subdivision. It's pretty much exactly as how I explained it above, but it's fairly awful.

For one thing, it has a tendancy to 'peel and crack' when the slopes of the cube cross two or more children:
before:
http://server6.uploadit.org/files/hapoooo-screenshot_27232.JPG
after:
http://server6.uploadit.org/files/hapoooo-screenshot_35291.JPG
http://server6.uploadit.org/files/hapoooo-screenshot_43931.JPG


While the board has probably borked the spacing, one should be able to just c'n'p that into the relavant section of lookupcube for a laugh. I don't think it should get commited right now-- overall, it reminds me too much of 'carving' tools in quake mapping. So while it's been a worthwhile exercise in getting familiar with the engine, I'm going to start focusing on the stuff that will give mappers more direct control instead of trying to fix it.

Also, here's some pics of my updated understanding of the world structure:
http://server6.uploadit.org/files/hapoooo-experimentaledge.JPG
http://server6.uploadit.org/files/hapoooo-experimentalcube.JPG

I'll probably be busy for the next week or two, so won't be doing a whole lot of work on sauer until then.

reply to this message

#87: Texture Code

by macdonag on 04/18/2004 19:20

Are there any specific plans for the texture code? Having looked thru the code a bit more (I've got VAR and texture combine stuff working nicely on my mac...), I'm seeing that the texture stuff has been gutted.

I'm thinking of playing around with it, getting a texture system going, so I can flip thru textures for cubes and play with auto-generated textures (I just saw the kkreiger demo and want to do better:-))... Also thought dragging and dropping textures from a web page, file browser or whatever might be cool...

reply to this message

#88: Re: Scripting

by Aardappel on 04/19/2004 00:32, refers to #84

I assumed dialog would be in script, especially since you need to specify consequences of dialog options, and that can easily get complicated in a gui. But hey, if we do a nice gui system, who knows.

reply to this message

#89: Re: subdivision

by Aardappel on 04/19/2004 00:35, refers to #86

good effort Gilt.. for the situations that go wrong I think it is acceptable to just detect them and default to a standard cube instead... you can't cover all possible splits, this routine should just do the best possible.

It is good to see someone is getting the hang of things. If you create documentation like the coordinate system stuff you can also check that in to SF, for the benefits of others.

reply to this message

#90: Re: Texture Code

by Aardappel on 04/19/2004 00:38, refers to #87

dragging and dropping textures doesn't sound like it keeps with the philosophy of "keeping things simple" :)

One change that should happen is to change the texture system such that the 256 texture slots are the textures actually in use rather than the entire texture list (this way it can be bigger than 256 entries). And of course the texture script should support rotate/flip and a bunch of shader related options.

reply to this message

#91: Re: Texture Code

by macdonag on 04/19/2004 01:15, refers to #90

Yeah, but it seemed like a neat idea:-)

I've started playing around with textures, and only just realised the vector template being used isn't an STL vector... Out of interest, why did you write your own vector/hashmap implementation? Any reason other than knowing exactly what's going on?

As for the editing with a GUI, it would be complex for anything but the most simple case, again would be neat, but a lot of work.

reply to this message

#92: Re: Texture Code

by Aardappel on 04/19/2004 23:14, refers to #91

no, no good reason not to use the STL nowadays. Back when it was made, it is using a custom allocation scheme and STL implementations were a bit too diverse to serve as a solid foundation.

reply to this message

#93: Great work guys

by An0maly33 on 04/21/2004 21:53

I hope I'm not intruding by posting here but I keep seeing hints at Sauer becoming an RPG. I was actually looking into using Cube as a base engine for a simple RPG I want to try building. It's been a while since I checked the site and I was pretty excited to see that Sauer was in the works. At first glance, the biggest thing I felt was a limitation was not being able to have stacked world space (for lack of better term). For example the Doom/Duke3d engines would freak out if you had overlap in the level even if they didn't actually collide. Duke3d was better as long as you couldn't SEE the other space but I digress...It seems Sauer would have no problem with this. One of the things I would really like to see is some way of scripting events for quests, npc's etc. I get the impression that some of these features are already on the table, just wanted to put in my $.02(US). I'm definitely interested in learning more about the engine and seeing how it progresses. Keep up the good work guys. Very impressive stuff.

reply to this message

#94: Re: Great work guys

by jcdpc on 04/22/2004 23:53, refers to #93

I think an rpg engine that worked/looked like cube would be awesome, i've wanted to make an rpg for a long time, but most rpg engines are incomplete or have bad graphics or are impossible to use. also I read that sauer might have shaders so I am eternally gratefull to those who implemented them (i'm guessing aard). however, i want to say that you shouldn't abandon cube while you're working on sauer. I would hate to see a game a great as cube to turn into another incomplete game engine. (because there are so many other ones out there) anyway if theres anyway I can help with sauer, (I'm still learning C, but i can do a little modeling, sound, and mapping.)

reply to this message

#95: Re: subdivision

by Gilt on 04/23/2004 18:44, refers to #89

sorry for the late reply-I'm still going to be busy until tuesday. Anyway for those who are trying it out, the above code has a mistake in how it maps edges back in the Y dimension, which I've since fixed.

aard> "for the situations that go wrong I think it is acceptable to just detect them and default to a standard cube instead"

Well the bad situations lead to less-then-perfect, rather then invalid children -- or at least from my simple testing so far. 'Peeling' for example, can usually be fixed by just pushing one edge- figuring out which one though, is a problem. either way, it's probably best to just create a general cube validation proc that consists of stuff like optiface().

It's not perfect- I'll clean it up a tad and maybe add something to fix the peeling, but let mappers deal with the cracking, so can you set me up with commit access? I recently got an SF account with login: gilt. Is there any other info you need? anyway, I don't want to spend too much more time on subdivision-- it's kind of neat from a programmers pov, but rather non-essential to mappers, and completly invisible to end-users.


Also did you or anyone else have any thoughts on how the orientations should be fixed. currently, orient is derived from the player's pitch and yaw. I suppose the correct way would involve figuring out which face the cursor is on, on a cube.. probably from using that line-plane intersect proc in geom.c against the three facing faces of the selected cube.. I'm still struggling to try to remember my linear algebra and geometry from school... Also, I dislike having the selector cursor get soley derived from glproject() or whatever. It makes it very hard/impossible to select edges in certain circumstances... anyway, just a bunch of rambling thoughts for people to poop on...

reply to this message

#96: new builds

by shahar2k on 04/24/2004 20:54

any chance we'll see new builds sometimes soon? (since cube seems to be getting a new one) or is development on sauerbraten still slower than cube (I know, you're not fixing the engine your'e still creating it, but still I think this could be uber-cool)

also, what's the chance that sauerbraten can read cube levels too? (or convert them)

reply to this message

#97: Re: subdivision

by Aardappel on 04/27/2004 04:43, refers to #95

I just put you in SF as a sauerbraten developer, so commit to your hearts content.

Yes, if the face selection wasn't in my document it should have been, one of things that needs to be changed (selection based on face you point at rather than camera orientation).

glUnproject(), sure if you want to, but replacing it is a lot of work for little return. I suggest keeping that for later.

reply to this message

#98: Re: new builds

by Aardappel on 04/27/2004 04:45, refers to #96

I think once the edit tools have become a bit more solid we could do another release so that mappers can start playing with it more.

reading Cube maps... that would have the advantage of making a lot of cool maps available quickly, but rely defies the point of sauerbraten. Once mappers get to grips with sauerbraten I think they will quickly forget about their Cube maps anyway ;)

reply to this message

#99: Re: new builds

by Thalion on 04/27/2004 11:52, refers to #98

... and we can always write an external converter, if demand will be high. So don't bother, there are more interesting things to waste time on =)

reply to this message

#100: Re: new builds

by spentron-postcrash2 on 04/27/2004 17:31, refers to #98

"reading Cube maps" ... if Cube was a disk-eating monster like these other games, I'd see a point.

reply to this message

   Board Index