home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM

Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1771326 views, last view: 06/23/2024 07:24

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

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

#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

#1005: It's not a bazaar or a cathedral....

by HopFrog on 07/17/2005 15:09

but instead, a republic.

Listen, it's fun to come on here with all sorts of ideas and toss them against the proverbial velcro wall and see what sticks, but you're not trying to contribute to the project. You're trying to hijack it, and I think I speak for quite a few people when I say "please stop."

I was going to write a lot more, most of it not very nice. I'm going to leave it at this though.

Show some respect, especially to people who know a hell of a lot more than you.

reply to this message

#1006: Re: third person?

by CC_machine2 on 07/17/2005 17:17, refers to #985

and how do you use a *.82 file? do you have to recompile sauer?

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

Unvalidated accounts can only reply to the 'Permanent Threads' section!

content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
55161991 visitors requested 73014317 pages
page created in 0.068 seconds using 10 queries
hosted by Boost Digital