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, 1771174 views, last view: 06/23/2024 05:58

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

#961: ..

by TOGoS_1u2kuhbui on 07/05/2005 01:11

Once in a while, goto comes in very handy. I tend to miss it when it's not there (or is restricted like in C# and can't jump 'into' blocks. Think elseif chains.)

Anyway, adjustable ambient light is a lot more useful (necessary, I'd say) than goto. Especially if I DON'T WANT AMBIENT LIGHT BUT IT'S STUCK AT 10%. Maybe you should remove the ability to carve out cubes because some people will make really stupid maps with it.

reply to this message

#962: Re: ambient lighting

by enigma_0Z on 07/05/2005 06:10, refers to #960

Well goto is pretty much useless if you structure your code right... I haven't needed it since my BASIC days.

but IMO this has no bearing on sauer's lighting... it is unrealistic to brighten up shadows with little dots of light when it's reasonable that ambient reflected from other surfaces adds light.

reply to this message

#963: Here's a thought....

by Pxtl on 07/08/2005 02:16

How about a global scaling of the lightmap available from script? That is, apply the lightmap at 10% or 50%? I only suggest this because I'm a big fan of the Darkmatch modes in UT (similar to the flashlight/weapons gameplay of Doom 3, but not as stupid) and it would be nice that, if post-map scripting for mutators/mods were possible, that a darkmatch mode would be possible for Sauer.

reply to this message

#964: Another idea...

by enigma_0Z on 07/08/2005 17:25

I had thought of this a long while ago, but your post, pxtl, reminded me of it.

Could we save multiple lightmaps with a level? Or at least partial lightmaps? If you could then add lightmap-switching and saving commands, you could have triggers that turn room lights on and off, as well as several other cool things. (Including Pxtl's "darkmatch" idea).

reply to this message

#965: ..

by Aardappel_ on 07/11/2005 10:12

there's a preliminary 3rd person perspective mode. switch it on using the "thirdperson" variable.

The evils of glReadPixels() have been removed from the code. That means no more people asking why rockets explode in their face.

reply to this message

#966: Re: ..

by enigma_0Z on 07/11/2005 18:19, refers to #965

Very cool... very cool!

If third person mode is going to become permanent, will we get vwep support so we can see the weapons our character and the other characters/monsters are holding?

reply to this message

#967: Re: ..

by tentus on 07/11/2005 21:32, refers to #966

i was just thinking on this a few days ago... so far the options for this a very limited.

1) Quake 2 style vweps, in which the gun models are custom made to mesh with a specific character model. This is messy and space/time consuming at best.
2) Use a set of bones which would align generic models and guns together. Without a good bit of time put into the bones, models, and system as a whole, this usually comes out with glaring visual glitches.
3) Allow for spot adjustments to the gun models, to mesh with the player model. this is very like the Q2 system, but it requires a lot less modelling effort.
4) don't bother meshing the character and gun, just have 'em roughly in place. I discover in CL that my hudguns look significantly better without an arm/hand attached to them, so i just let the weapons float around. Obviously, this is not a solution if you're looking for realism :)
5) don't use models for vweps- instead, use an icon or something that will overlap the player model, perhaps float over their head, which will clearly tell what you've got out. This is simple, has few glitches, and requires the least work.

There are a few others that i could mention, but i think this pretty well covers the basics. of the lot, i'd say that #5 is the most reasonable for the time being, while #2 would be the most professional looking but hardest to pull off (hence #3).

reply to this message

#968: third person?

by CC_machine2 on 07/11/2005 23:17

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

#969: ..

by enigma_0Z on 07/11/2005 23:55

Out of those, I think that I like 3, 4, & 5 the best, perhaps 5 as a temporary fix untill something better comes along.

reply to this message

#970: Re: ..

by tentus on 07/12/2005 02:21, refers to #970

hey, just because some of us aren't as pretty as you... lol

third person does increase the desire for custom player models, because all of a sudden your identity is being represented by something decidedly inhuman, instead of being left up to the imagination. it also creates a real problem in that the fist is so radically different in 3P than in 1P.

*bleh* talk about opening a Pandora's Box, Aard :) Of course, this cements into fact that someday (in the distant future, most likely), i will have to make a Sauerbraten Legends. That's really hard to pronounce though, so I'd better stick to the Cube Legends name.

reply to this message

#971: Re: ..

by enigma_0Z on 07/12/2005 05:01, refers to #970


Speaking of pronouncations...

how do you pronounce "sauerbraten"? I've been pronouncing it: SOUR-bray-ten ... is that correct? Sour like taste, bray like in braid, and ten like the number ten.



With 3p mode, platforming adventures become alot easier to do with sauer... I'm getting all excited!

reply to this message

#972: Re: ..

by jerrybean on 07/12/2005 06:50, refers to #971

I was going to say how I (incorrectly) pronounced sauerbraten, but I looked it up and it's actually a word.



Anyway, I'm looking to make some changes: A better vertex array (VA) division algorithm and hardware occlusion culling. Is anyone doing work in this area?

I took a look the current VA divisions by drawing bounding boxes, and they are a mess (my fault) and not well suited for occlusion culling, let alone view frustrum culling. I have an idea that should break down maps more evenly as well as go faster (during VA construction) due to less redundant work.

reply to this message

#973: Re: ..

by jerrybean on 07/12/2005 07:24, refers to #972

Apologies. updateva has changed a bit more than I thought. These VA bounding boxes don't make sense anymore.

reply to this message

#974: Re: ..

by Wolf on 07/12/2005 08:02, refers to #973

i believe there is currently only one verex array. not 100% sure tho only looked though some of the code

reply to this message

#975: 3rd person..

by Aardappel_ on 07/12/2005 08:19

is here to stay yes. It has always bugged me that games prescribe 1st or 3rd person, and I think the user should have to option to play any game in either. So it will stay in as an engine feature, where game modes can set the "default", and users can override it if they are not happy.

having seemless zoom from 3rd person is an interesting idea. I think if the camera is too close to the model for whatever reason, the model should go seamlessly from 1.0 alpha to 0.0 alpha.

Yup, the vweapon is an issue. Dunno what I want to do here yet, especially since you do not see much of it at the moment. I may want to mount the camera bit over the players head, that would be easier for aim. Also, with a character on screen all the time it will be time for better animations and animation blending someday.

Dunno what the bug is you are getting. I noticed heavy physics performance issues in debug mode, which the 3rd person mode pronounces. Haven't found out what happens yet... Gilt or eihrul, feel free to have a go at it.

reply to this message

#976: oh and..

by Aardappel_ on 07/12/2005 08:23

I added png alpha support, for models. Some people are making some nice trees with this. For making some larger scale RPGish maps. For... but that is just hearsay ;)

reply to this message

#977: ..

by staffy2005 on 07/12/2005 12:28

when in 3rd person mode you don't look like you are running when you shoot + run.

reply to this message

#978: yum 3p views

by madcrow on 07/12/2005 15:07

This would actually make Sauerbraten much more flexible. 3rd person would make things like action-adventure games/levels quite doable.

reply to this message

#979: ..

by staffy2005 on 07/12/2005 23:26

I made a rpgish map. (a copy and paste job) http://img326.imageshack.us/img326/5476/screenshot661002zg.jpg

reply to this message

#980: Re: 3rd person..

by Gilt on 07/13/2005 00:32, refers to #975

when it comes to physics, well we are still generating planes each time we check a collision with a cube. so on average we are generating planes at 5cubes*20moves(+1perMob)*50hz... (and 5 cubes is probably very optimistic for the way many maps are made..) .. so it adds up very fast. we really should be doing some sort of caching of the planes before looking at tweaking anything else I think... unless you can think of a really fast way to generate the planes...

also todo is the fact that plane generation is being done two different ways, for physics collision and ray collision. this should be refactored into one. it'd probably be better to stick with the physics version since I'm guessing it's overall faster, though I haven't checked it yet

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
55159279 visitors requested 73011568 pages
page created in 0.070 seconds using 10 queries
hosted by Boost Digital