Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1693058 views, last view: 04/29/2024 12:42

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

   Board Index   

#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

#1007: Re: third person?

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

ok nevermind ive figured it out

But i still cant use sauer properly, it crashes whenever i load a map, change weapons etc etc (though if im lucky sometimes it doesnt) and i have checked my drivers (and cube still works properly)

help

reply to this message

#1008: Re: ..

by absinth on 07/17/2005 18:21, refers to #1003

>and you're the only one who understands how that works since as you said you've kept it all in your head instead of documenting it.

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

i don't think thats true at all

the codebase of sauerbraten is VERY comprehensible and mostly because of its small size

also many people here have already contributed big features (physics, rendering, ...) in a short time, which kind of proves that sauer is easy to understand and work with.

thanks to all those involved, especially aard

reply to this message

#1009: ..

by makkE on 07/17/2005 18:26

Morgaine, all Aard said recently was that he wants to do the separation of gameplay code from the engine before integrating any script-language first. (he also mentioned there wasn´t a final decision on Lua or something else yet).
You obviously haven´t noticed that.

And I can perfectly understand he wants to do it himself and I believe 95% of the people will be glad if he does it, because everyone here knows he will do it right.

I myself have 100% faith in Aard making the right and resonable decisions. And I think everyone here has no problem with Aard being the one leading the way things go in Sauerbraten.

I must say that I have no experience on programming and open source projects, etc.

But I have had the experience that in many social projects (like bands, political activity, Music events..clans, guilds etc...) you will only get to a satisfying result if one person leads the way, a person that preferably has a clear vision and the needed skills and knowledge to do the right decisions, and in the same time having an open ear to suggestions and letting people work out stuff independently(to assure ppl will have FUN doing it).
Of course the result will thereby heavily depend on the person that is in the lead, but it will assure that it´s "tight", not chaos or some undefineable something.

I agree with kurtis too. If Aard had allowed anything ever offered here to go into Sauerbraten, we´d by now have an engine that might look cool, but run 15fps on a high end machine (and probably me a big mess).

And I furthermore believe you are just taking this whole thing a little too serious. I believe most people including Aard here are working on Sauerbraten for the joy of creating something cool and unique, not to be "working on a collaborative engeneering project" a term that I must say startled me.
Is this some big buissness going on here ? definately not - so why bring up the term "professional" all the time?

reply to this message

#1010: might I add...

by Aardappel_ on 07/17/2005 20:38

That this whole "cathedral and bazaar" thing is the biggest myth ever propagated? (sorry Eric). Succesfull bazaar projects are few, successfull cathedral projects are the rule.

The linux kernel, is a cathedral project. We have pope Linus, who relies on his cardinals like Alan Cox. Then maybe there's a few bischops scurrying around, but as you go down the ranks, there's less power in decision making. Like any hierarchical organisational structure.

Similarly I am the sauerbraten pope. I have cardinals like eihrul and gilt. Those on here who have not contributed code nor media on this board, are not even priests, they are the religious masses. They generally don't tell the pope what to do. The pope listens to what the people feel, but generally he doesn't make things a popular vote.

I listen. But without trying to hurt too many feelings, many people's ideas are so far off base and so technically uninformed, that it is a waste of my typing time to even respond. Especially when I have clearly explained the issues surrounding it in other threads. The Lua thing is a clear example of this.

In the end, what me (and my cardinals) do, is a cross between what the masses want, and what we want. We are doing all the work, we might as well have it the way we like it. We try as best we can to unify what everyone wants, but is not always possible.

reply to this message

#1011: More immediate concern

by spentron on 07/17/2005 22:32, refers to #1004

When editing cubes in non-fullbright, the lighting is set to ambient on modified cubes. This results in the cubes almost disappearing on a bad monitor or low bright setting, which seems like a bug. Even with more brightness, it raises the question of does it really have to be like this. And fullbright editing doesn't look 3D enough.

reply to this message

#1012: Re: might I add...

by spentron on 07/17/2005 23:10, refers to #1010

It seems to me that how scripting is integrated is more important than getting an immediate "jump" on its progress. Then all the "we can do this" people can really contribute stuff of substance and importance. Maybe not going on a deciding on a language and sticking it in with little actual functionality is arbitrary, but it's still not that important.

reply to this message

#1013: ..

by madcrow on 07/17/2005 23:11

Lua's fine and being able to intergrate it with the actual game engine will make Sauer capable of powering games far more sophisticated than a simple deathmatch-based FPS. Of course, judging by the discussion, it's possible that we may never see scripting...

reply to this message

#1014: mapmodels...

by Aardappel_ on 07/18/2005 06:23

I changed them over to being rendered with VBO's, which causes 4x less verts being sent to the card for them, and generally being faster. This, coupled with eihrul's VFC of mapmodels should means significantly faster rendering on mapmodel heavy maps, which sofar is only "oasis" and kurts/niebs upcoming massive rpg maps.

reply to this message

#1015: Re: portals

by absinth on 07/19/2005 02:13, refers to #999

i thought using portals for occlusion culling (in sauer) was just an idea pushed by some, but after reading that page it seems like it is the definite plan:

http://strlen.com/wiki/?id=SauerPortals

can anyone tell me WHY this decicion was made?
they really seem to have many drawbacks compared to other mechanisms.

reply to this message

#1016: Re: portals

by HopFrog on 07/19/2005 03:40, refers to #1015

They can be used in conjunction with other methods, which makes them a win-win as far as features go.

reply to this message

#1017: Re: portals

by absinth on 07/19/2005 14:36, refers to #1016

>They can be used in conjunction with other methods, which makes them a win-win as far as features go.

sorry that is very vague.
what "features" are you talking about?

the only "additional feature" possible with portals that i know about is that they allow portals, connected to far away geometry, like a "looking glass". (that could still be done without portals, so it seems like a non-issue)

still, the need for manual placement of portals is a killer drawback in my opinion!

also since portals are only useful for indoor maps, which is not the kind of future envisioned for sauer (big outdoor RPG maps) they seem to make no sense at all!

(please correct me if i'm wrong)

can anyone tell me what is speaking against other static (PVS) or dynamic (Coherent Hierarchical Culling) solutions, which don't have the problems of portals?

about "used in conjunction with other methods", that seems like a big mistake. you inherit the drawbacks of portals (mandatory manual placement) without any visible benefit over a completely non-portal solution.

reply to this message

#1018: Re: portals

by HopFrog on 07/20/2005 01:20, refers to #1017

Your post actually triggered an idea on my part.

Firstly, you're about half-wrong. Portals CAN be used in many outdoor areas, however wide-open ones would not benefit from it very much.

However, it would be nice of MANY culling methods were supported, and able to be used at the mapper's discretion. Then, each map could have a flag in the config file stating which method of culling would be used. In an outdoor map, something more outdoor-friendly could be used. In an indoor/street map, portals might be a better bet.

Of course, I'm just batting the idea around. In any case, there is certainly a place for portals in the engine.

reply to this message

   Board Index