Sauerbraten engine development |
by Aardappel
on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1699925 views, last view: 05/16/2024 20:13 |
|
This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.
|
|
Board Index
|
|
#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
|
|
#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
|
|
|
Board Index
|
|