Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1699903 views, last view: 05/16/2024 17:31

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

   Board Index   

#1048: ..

by staffy_12 on 08/04/2005 08:20

If it is taking too much time to compute the lighting type:
shadows 0
lightprecision 128(or 256+ for a big map)
aalights 0

reply to this message

#1049: ..

by makkE on 08/04/2005 15:07

I think the current lightning system is pretty good. Of course it can´t do everything.

But I find it no problem to for example have a lamp on the ceiling use a rather small lightsource to have a nice corona (so to speak) and then add a slightly diffrent lightsource on the floor beneath, and wherever there might be some reflections from that source or even other nearby walls.

Lightning was already hard in cube, now in sauer it´s even harder. Just experiment.

The main challenge is to have enough light in a map to make it playable, withought losing contrast and those nice shadows.

reply to this message

#1050: buffersuch

by thepacz on 08/04/2005 16:53

Just a little thing about prebuffering (I think). I'm not a programmer, but there is one specific event I'd hate to see in Sauerbraten.

A while ago while playing GTA San Andreas, I was flying a plane around. I could see a bridge ahead that I wanted to fly under, so I started going toward it. But a tree suddenly rendered itself out of the fog in front of me and I had no time to dodge it. I don't know why the game decided to do that, but would it be possible to avoid in Sauerbraten?

I've always thought of Sauerbraten as THE perfect FPS (it's low cost helps a lot ;-) and I'm sure you guys will handle the prebuffering issue as excellently as everything else.

reply to this message

#1051: Re: buffersuch

by Pxtl on 08/04/2005 21:36, refers to #1051

And I want a trip to tahiti. Seriously, nobody wants these things, but the reason that they happen is 'cause it's really, really hard to avoid them, particularly when the content is user-generated (like in SL). SL really should've avoided teleportation at all because of their loading system. Want to know why it takes so long to move? Consider how much content is being downloaded - it's loading several maps worth of data on the fly after you teleport.

Now, in an engine like Cube where the whole map is in memory but the objects within are being rendered according to LOD, it's a little better (as opposed to the SL downloading-on-the-fly), but still problems can occur. Want to know the solution to the "tree from nowhere?" - buy a better computer so you don't need as much graphical LOD. Likely the same popping will happen in Sauer as maps get more detailed and LOD becomes more necessary.

reply to this message

#1052: Re: buffersuch

by thepacz on 08/06/2005 06:38

On second thought:
In Sauerbraten, I don't think the characters would be moving fast enough to run into so large a problem as hitting a tree you don't have time to avoid, though possible exceptions could include falling at high speeds, etc.

As for buying a better computer: the problem happened on a PS2, so that's out for this specific game. I guess my friend who let me play on his PS2 is out of luck =P and I'm fine on my PC.

In the specific event, I could see beyond the tree before the tree came up. The main problem was not the popping alone: it was that I could see more of the level in the distance, so I thought my way was clear.
In GTA it perhaps loaded the most important things (architecture and landscape) within a much greater radius than that within which it loaded the less important things (really annoying trees).
Would it be possible to keep it more continuous by loading both architecture and entities in the same radius, or is it far more complicated than that?

reply to this message

#1053: CVS in flux...

by Aardappel_ on 08/07/2005 10:10

for those with development CVS access, do not be suprised if thing don't compile right at the moment. I am refactoring the engine in major ways to seperate out the gameplay, and other general improvements, and it is likely I am breaking stuff on the *nix side. Please check with me online before making fixes to avoid conflicts. Thanks for your patience.

reply to this message

#1054: Re: CVS in flux...

by Aardappel_ on 08/07/2005 15:03, refers to #1053

ok, just checked in the VERY rough transitional version.. I have mostly just seperated out what is already there, much work to be done still.

Most importantly, all state is now owned by either game or engine, with no overlap. Both dynamic and static entities are split up between an engine base and a game derived class.

Things will be broken, I suspect eihrul will fix whatever is not working on *nix soon (the makefile, for starters :)

reply to this message

#1055: ..

by shahar2k on 08/11/2005 01:25

just a question but why cant sauer use a per-pixel type lighting solution, http://www.gamasutra.com/features/20050729/lacroix_pfv.htm i'm not a programmer but I think this could work pretty well (of course a simpler lighting model like vertex lighting for dynamic lights works across more hardware but I dont think that hardware capable of per pixel lighting is that uncommon today

reply to this message

#1056: ..

by >driAn<. on 08/11/2005 14:24

http://www.opengl.org/ <-- headline news
http://www.heise.de/newsticker/meldung/62708

>:
Damn, that could hurt sauerbraten...

reply to this message

#1057: Re: ..

by Aardappel_ on 08/11/2005 20:09, refers to #1056

No it won't... it will just mean that you will need an ICD to run sauerbraten, like you do right now, and that while it is running, windows looks very 2d, like it does now :)

Still a dumb decision technically, but nothing shocking.

reply to this message

#1058: Re: ..

by >driAn<. on 08/11/2005 21:32, refers to #1057

Well ok, its not that bad for Sauerbraten. But other OpenGL apps that run windowed are hurt, because Windows' Aeroglass stops working if they use an ICD. This fact will stop win developers from using OpenGL, they will switch to D3D. ID Software will switch too, btw.

reply to this message

#1059: sound

by spentron on 08/12/2005 12:39

OK my own weapons sound moves around when I turn. Latest version (1st I've tried since the last packaged release). Not right.

reply to this message

#1060: Re: sound

by eihrul on 08/12/2005 22:52, refers to #1060

Your code doesn't make sense... or rather, the "if(yaw)" thing. Why should the angle of the sound being 0 suddenly have anything to do with the player's yaw being considered? The player's yaw should always be considered.

Please explain what you intended to do with that line, since it is neither obvious nor commented as such.

reply to this message

#1061: Re: sound

by eihrul on 08/12/2005 23:56, refers to #1061

I don't believe in paragraphs and paragraphs of commenting. It is just a huge distraction for me as well, when I have to read the actual code hidden among the comments. Good code is self-explanatory.

The code presented here was not self-explanatory, and in such cases, a token line or two of commenting is helpful to explain the intent.

Comments can be used judiciously, but using them correctly is almost as much an art as writing good code itself. As I said above, I hate when people write novels and hide a few lines of code inside, and bad code without a good comment or two can be hard to understand.

And, anecdotally, I know of very few people who write good code and good comments. I somehow doubt Aard is opposed to comments in the code, just opposed to bad usage of them.

Then again, the Sauerbraten developers (Aard, me, etc.) write the code for ourselves, more than we write it for you, so the burden for you to get code included, if you are not a developer, is to have us understand the code you want us to incorporate for you. Tough.

reply to this message

#1062: Re: sound

by eihrul on 08/13/2005 04:35, refers to #1062

I just committed a newer and better fix for this. I believe Aard put it in, and I attempted a fix for it later when I saw a bug in the code. Sometimes fixes are buggy too.

But, you prove my point about good comments being as hard as good code, man. You gave me six lines of code, with comments, that did not at all explain why it was doing what I saw was an obvious bug on multiple counts.

Even then, do comments like "simple stereo attenuation" say much? Might have been better to say, "find the relative angle of the sound along the X-Y plane". For some people, that comment still might be too cryptic. Good comments are not easy.

But, saving a number of clock cycles which is certainly more than 0, but less than 10, just to introduce a latent bug in the code confused me.

Now, also, the CVS tree carries no guarentee of reliability. Aard, gilt, and I often leave a ton of broken stuff in there while we're working. A development tree is going to be unstable.

reply to this message

#1063: openbsd

by orobo on 08/13/2005 15:01

I could compile and run sauerbauten engine on openbsd(3.7) with almost no mod.

reply to this message

#1064: Re: openbsd

by -Rick- on 08/13/2005 18:42, refers to #1063

Yea works OK on FreeBSD too :)
Just had to add an extra include and library dir to the Makefile(-I/usr/X11R6/include and -L/usr/X11R6/lib)

reply to this message

#1065: ..

by TOGoS_1u2kuhbui on 08/13/2005 22:09

Eww! autoconf!

reply to this message

#1066: Re: bool local in weapon.cpp (projectiles)

by -Rick- on 08/13/2005 23:18, refers to #1066

Its indeed for the local player. The projectile is created in shootv. shootv for non-local players is called in clients2c at the SV_SHOT message. The argument 'local' is ommited in this case, but the default is 'false'(check the decleration in protos.h).

newdynent():
Nope. Its used for monsters and players. Monsters can't be used over the network so that leaves players. If a client sees an unknown player it will call this function to make a new dynent structure for this player locally.

reply to this message

#1067: Re: ..

by pushplay on 08/15/2005 03:03, refers to #1065

If the organization of files in linux wasn't such a mess we wouldn't need scripts to run tools which create scripts that call other tools for information so they can finally run the compiler.

reply to this message

   Board Index