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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.