Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1692191 views, last view: 04/27/2024 02:32

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

   Board Index   

#981: Re: 3rd person..

by Aardappel_ on 07/13/2005 02:07, refers to #980

Well, more than just the planes, other things must be going wrong. Like I said, in aard3 (relatively simple geometry), I can get down to 5fps in debug mode when standing on the grass, but sometimes on the grass I get the usual 200 fps. Then around the grass I get guaranteed 200fps. Then at YA I get 5fps again. I don't think this is just the planes, it sounds like something really is buggy.

But yes, a physics cache would help.

struct cacheitem
{
float planes[N];
cacheitem *next;
cacheitem **backptr;
int age;
};


make an array of M elements of these (M can be tweaked, lets say 1000 for now). Link them up much like the current particle system.

Every time you compute some planes, grab one of the above from the freelist, and make the cube point to it. Make backptr point to the pointer inside the cube, that way we can clear it if this structure gets reused. set age to current milliseconds.

If you add them in order, and if at some point you need a new cacheitem and the free list is empty, you can simply find the tailend of the list and move the last items to the freelist (the oldest items). Ideally items that are referred to are moved back to the head of the queue. So maybe a doubly linked list would work better.

One thing to be careful of is deallocation: if a cube gets deallocated, you must remove its physics cache item as well.. subtle bugs could result.

reply to this message

#982: Re: 3rd person..

by Aardappel_ on 07/13/2005 06:42, refers to #982

first of, all the FPS display slowly gravitates towards the real fps, this is to make the figure more "readable".

Second, yes, at slow fps the physics will run more often, so basically it will always take a certain amount of time no matter what the fps. This means if there is something REALLY inefficient in the physics it can clog the fps more than on other games.

This is in an attempt to make the physics behave the same on all systems... it is rather hard to write physics which works the same on 5 and 200 fps if you use variable time steps.

reply to this message

#983: third person?

by CC_machine2 on 07/14/2005 22:36

ok, so i start the newest version of sauer and try this new third person thing and it doesnt work. Ive tried:

/thirdperson - says 'unknown command'
/thirdperson 1 - just does absolutely nothing

am i typing the wrong command or is my computer f***ed up?

reply to this message

#984: Re: third person?

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

Yeah, it's not in source CVS, but you need to download the latest EXE. There's a link at the top of the thread titled "Sauerbraten - Bug Reports".

reply to this message

#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

   Board Index