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, 1679902 views, last view: 03/29/2024 09:17

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

#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

#1019: Re: portals

by pushplay on 07/20/2005 06:59, refers to #1018

Usually I'm a huge fan of choice. But. When it comes to occulsion culling, giving the mapper more power is bad. Understanding the pros and cons of a bunch of options is a lot of work. Making mappers understand a single method and use it properly is bad enough. I think all of it runs contrary to the reason mapping for Cube was popular.

reply to this message

#1020: Re: portals

by spentron on 07/20/2005 12:33, refers to #1019

Portals are weird, defining what you can't see by what you can. I tried using them in Unreal, and except for the looking-glass type which is different, took most of them out as they caused visual glitches and poor performance stats (and then went on to tax the engine 10 times as much as well).

What would be good is some kind of plain occlusion, even if limited. For example if you have a huge outdoor area with big windowless buildings with 32 gridsize walls, you should be able to put lots of details and models inside without issues.

reply to this message

#1021: Re: portals

by HopFrog on 07/20/2005 13:32, refers to #1019

Good points. :)

reply to this message

#1022: ..

by madcrow on 07/20/2005 14:54

How do the commercial engines like Quake 3 and Unreal do their default culling? Maybe we should try things like that.

reply to this message

#1023: Re: ..

by Pxtl on 07/20/2005 15:30, refers to #1022

Unreal uses portals, and they're a pain, because mappers have to manually define areas as being a portal. Now, if Cube mappers often don't know to use the fill commmand, can we expect Sauer mappers to use the Portal command?

reply to this message

#1024: Re: ..

by spentron on 07/22/2005 03:03, refers to #1023

Unreal and Quake 3 use BSP, which is a complicated visibility precalculation method that must be compiled as part of the mapping process. Portals are supposed to help the compiler in Unreal but in my experience you're better off letting it do it automatically 2/3 of the time. Probably helps more when you need it less.

reply to this message

#1025: Re: ..

by kurtis84 on 07/23/2005 15:27, refers to #1024

I don't see portals as an option, unless you want to require map compiling of some sort. I cannot think of an engine that used protals, and didn't require a long compile to do so ( in quake engines, it VIS compiling )

Surely theres a better way.

reply to this message

#1026: ..

by TOGoS_1u2kuhbui on 07/23/2005 20:37

The whole point of using portals is to avoid having to compile. Think of Descent, not Quake, which also used BSP.

reply to this message

#1027: ..

by TOGoS_1u2kuhbui on 07/24/2005 05:14

I wonder why it is necessary for the mapper to manually place portals. Why not let the mapper mark cubes as belonging to a certain visarea, and let the engine place portals between visareas whereever there are adjacent empty cubes? This would have the added advantage of working well with my map linking model :) (looking into a different map is not much different than looking into another visarea - visareas in different maps would simply have pointers to a different world structure)

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
53419584 visitors requested 71179512 pages
page created in 0.050 seconds using 10 queries
hosted by Boost Digital