Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1691877 views, last view: 04/26/2024 03:21

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

   Board Index   

#985: Re: third person?

by enigma_0Z on 07/14/2005 23:57, refers to #984

Uhh (open mouth, insert foot)...

That is to say that it's not _only_ in source CVS. Chances are it's there too, but you don't need to get the source to get the thirdperson mode... Just download the latest EXE.

reply to this message

#986: Lua scripting patch

by Andrew Brault on 07/15/2005 01:46

I made a quick patch to integrate Lua scripting into Sauerbraten. I haven't tested it much but it "seems to work". The patch needs to be applied against the latest CVS sources.

http://unsignedint.com/sauerbraten.html

reply to this message

#987: gravity

by da5id on 07/15/2005 03:58

i think it would be great to have
gravity spherically based around a single point of influence rather being based on dimensional axis.

i had recently seen this used to
groovy effect in \\\"psychonauts\\\"

i\\\'m not sure how one would go about implementing this. i just wanted to throw it out there and see what people though.

thanks for listening to the peanut gallery.

i love the thirdperson camera

reply to this message

#988: ..

by madcrow on 07/15/2005 14:32

Wow, scripting. This brings Sauer one step closer to being an engine that other games can be built on.

reply to this message

#989: Re: Lua scripting patch

by Pxtl on 07/15/2005 15:13, refers to #988

imho, Sauer Lua script should be handled as data within a package. It improves the portability and orthogonality of the code - as a package can be thought of as an atomic "mod".

Still, I think the ideal approach would be to have downloaded content go directly into a cache using hashcodes for filenames, allowing you to have redundant and versioned data.

reply to this message

#990: performance

by makkE on 07/15/2005 16:21

I don´t agree that portals are "low priority"

from the wiki:

"...levels are relatively small, and the average graphics card nowadays seriously overpowers sauer's modest rendering requirements."

I own a pretty much average gfx card.(plus amd 3000 64 or something, guess that´s already on the "good" side) I feel like portals and other optimization are BADLY needed. I have to play 32bpp colour depth to get rid of the z-fighting. Thus performance is darn low. Everything above 50000 tris
starts getting really bad.
Since sauer has always claimed to aim for "huge" maps I wonder how that´s going to work without making real simple
architecture, using only 20% of what would be nice from the mapper´s perspective. Even sticking to Cube-ish architecture could already be too much there.

q3 for example works 250% better on my system, with everything at max. It´s almost 6 years old.(the game) I wouldn´t really call sauerbraten´s rendering requirements are "modest".

I don´t want to whine here.Sure sauer is already impressive. I´d just love to see portals and stuff being regarded as high priority. To me they are.

reply to this message

#991: ..

by makkE on 07/15/2005 16:52, refers to #990

Okay, that q3 example was stupid, kind of.
Nvm it.

reply to this message

#992: Lua scripting

by Andrew Brault on 07/15/2005 19:14

Glad the lua patch worked... it definitely needs some cleaning up and better integration. It might be nice to have a command like /luabind A myluafunc that would set key A to invoke myluafunc() in Lua. That way you could come up with a nice library of scripted mapping utilities.

I'd also like to come up with a better way of manipulating the selection; right now you have to use the relatively unintuitive setsel().

There's a lot of possibility here... in my opinion a major weakness of Sauerbraten is the difficulty to make complex-yet-systematic objects like arches/stairs/curvy objects and scripting could really help here, not to mention the possibility of algorithmic map design (like the excellent tmapgen).

reply to this message

#993: ..

by TOGoS_1u2kuhbui on 07/15/2005 23:19

What I did in tmapgen is treat the main executable as a lua interpreter with tmapgen functions built-in. So you'd start it like so:

bin/sauerbraten.exe scripts/test9.lua

Starting it without any aguments does the standard lua thing which is to give you an interactive interpreter. This main lua interpreter has access to everything - IO, keybindings, map loading. Level scripts (like something called when the user flips a switch) should be given a separate interpreter with fewer privileges.

reply to this message

#994: Re: ..

by Andrew Brault on 07/16/2005 01:39, refers to #993

I took a closer look at tmapgen and wow, it really does have nice bindings. Much better than my patch. How hard would it be to link that into a real Sauerbraten? Something like a combination of our two approaches maybe, so you can call tmapgen functions and see the results immediately.

reply to this message

#995: TMapGen lua bindings

by TOGoS_1u2kuhbui on 07/16/2005 04:32

In addition to the lua bindings, I did quite a refactoring of the portion of the Sauerbraten code that TMapGen uses - making the world and cubes and octrees more OOish, putting a 'parent' pointer on each cube, etc. So you'd have to either rewrite the tmapgen lua bindings to interface with the old Sauer code, or update the Sauer code to look like TMapGen. I happen to think that my refactor job made things a lot better, but I'm not sure that Aard and the gang appreciate the new code style/layout.

That said, being able to merge the tmapgen/sauer source would save a lot of work. There was a discussion about this earlier in (I think) this same thread.

reply to this message

#996: ..

by staffy2005 on 07/16/2005 09:28

I have been working on a little sauer "town". http://img302.imageshack.us/img302/7554/blah8ts.jpg
(It needs a lot more work before it is finished)

reply to this message

#997: Re: ..

by Pxtl on 07/16/2005 17:54, refers to #996

Heheh, looks like a roman garrison camp from Asterix to me. Still nice.

reply to this message

#998: Lua

by Aardappel_ on 07/16/2005 22:37

Just binding Lua to the console commands gives you exactly 0 more power to anything than you have now. It is cute but just linking a scripting engine doesn't do anything.

Once we transition to using a scripting language, the main challenge is not adding it, but how it integrates with all the engine functionality, and rewriting the gamecode in it (which before that, will first need to seperated out from the engine code, something I will do before then).

Also, the choice for Lua or something else has not been finalized yet. It will happen when the time comes to integrate it.

reply to this message

#999: portals

by Aardappel_ on 07/16/2005 22:42

it is low priority because it is a LOT of work for potentially little gain. As I explained in another post, occlusion is HARD to make optimal on current hardware. Just because something is occluded, doesn't mean you can make it render faster easily.

LOD will happen first, because it likely will give us bigger gains, easier.

"modest" compared to the latest engines. Quake3 has completely been architected to rendering the minimum amount of polies... it is WAY more efficient in doing so than sauer. Sauer has its current structure just because it is targeting more modern hw than quake 3.

What video card do you have? If you have severe fps issues with sauer you must have a really old card... not talking about oasis.

reply to this message

#1000: ..

by makkE on 07/17/2005 02:26

Yep, the q3 example was not appropriate. I have a gf5600xt. The problem is I have to use 32bit colour depth to get the zbuffer work in 24bit on that card. A roughly I get only 80fps in aard3.. and it only has 17k tris or so.

reply to this message

#1001: Re: Lua

by Andrew Brault on 07/17/2005 03:33, refers to #998

Actually I find the lua bindings pretty handy for making geometry. Obviously pulling out all "game logic" (AI for nasties, physics etc) into Lua is more involved but for geometry manipulation Lua is really nice.

And lua itself fits very well into the cube philosophy, it's small and tightly coded like cube/sauer.

reply to this message

#1002: Re: Lua

by Aardappel_ on 07/17/2005 07:06, refers to #1001

I am holding the community back? I am sorry, but I am afraid you have no idea what is involved in extending sauerbraten in the right way. The only reason sauerbraten exist and is cool is because someone has the overview and a central vision. If you would just add features randomly, you'd end up like every other useless project out there.

If you don't have faith in my design skills, I suggest you find another project to patronize.

reply to this message

#1003: ..

by TOGoS_1u2kuhbui on 07/17/2005 08:38

Wooh00! Flame time!

Nobody's attacking anyone's design skills, It's just that everyone has a different vision for what they want Sauerbraten to be. Some of those visions might be a bit overblown - Sauer wasn't originally intended to be the end of game engines and it shows - Aard's idea of keeping the engine simple is to make the code such a mess that nobody can figure out how to add features ;)

That's not to say that there aren't a lot of good ideas here and in Sauer already that couldn't be applied elsewhere, but trying to slap them all into an engine that can bearly make a decent curve (and IMO isn't especially easy to map for, after all), might be misguided effort. I say if Aard feels so stronly about it, let Sauer be what it is.

/me stops talking out of butt

reply to this message

#1004: Re: Lua

by kurtis84 on 07/17/2005 14:37, refers to #1004

Opinions are like assholes....we all have one. If we all use them, things start smelling like shit.

Think of the mess that sauerbraten would be if Aard allowed ANY idea to be implemented. Someone has to decide what goes into the code, and what doesn't, and IMHO, I don't think anyone on this forum aside from Aard should be doing that. I also think if someone doesn't agree with Aards decision, thats just tough shit...move on. Sure other people have contribulted, but most of the work on sauerbraten was done by Aard, and thats probably the only reason it's a good engine. Why not focus on whats good about Sauerbraten, instead of whats not there yet?

reply to this message

   Board Index