OpenArena Message Boards

OpenArena Contributions => Maps => Topic started by: pulchr on June 01, 2009, 06:20:27 PM



Title: pul1duel - five steps ahead - finished!
Post by: pulchr on June 01, 2009, 06:20:27 PM
update: finished openarena version of pul1duel - five steps ahead

i removed the old quake 3 images and updated this first post.

this is intended to be a duel map but plays well for small ffa matches (4-5 players) or very small team deathmatches (2on2). there are 12 spawns, but it will be quite messy in the middle with so many players. it might be quite heavy on slow computers since the r_speeds are a little too high for a level of this size. i found out that the sound from the blue fields wasn't played when the player couldn't see the target_speaker from their position. this made the blue fields a bit pointless so i turned some structural brushes into detail so the sound is played. of course this added to the high r_speeds - but i think that the sound cues are extremely important when playing duels - so it's my decision to leave it as that.

these game modes are supported: free for all, tournament, team deathmatch, elimination and last man standing.

the pk3 also includes a couple of new textures and some that was missing in openarena. these will be added to the svn commit thread along with the .map-file (done).

enough of the blah blah blah and on to the goodies. i made a youtube video of me playing the map (http://www.youtube.com/watch?v=MJLVECm7z-k). it's from the quake 3 version so the visuals and sound are of course not the same.

download the openarena version of pul1duel (http://www.pulchr.se/downloads/pul1duel-oa.zip)

have fun! =)

(http://www.pulchr.se/random/pul1duel-oa-01.jpg)
central area with red armour.

(http://www.pulchr.se/random/pul1duel-oa-02.jpg)
left: megahealth, right: lightning gun and teleporter to railgun.

(http://www.pulchr.se/random/pul1duel-oa-03.jpg)
left: see-throuh stairs near lightning gun. right: yellow armour.

(http://www.pulchr.se/random/pul1duel-oa-04.jpg)
left: rocket launcher and jumppad up from railgun. right: beneath the red armour.


Title: Re: pul1duel - five steps ahead
Post by: cosmo on June 02, 2009, 02:54:48 AM
Screenshots look bold and colourful. Very promising. Show us screenshots done with OA next time. ;)
You're doing fine new textures, pulchr.


Title: Re: pul1duel - five steps ahead
Post by: Cacatoes on June 02, 2009, 03:31:20 AM
Pulchosaur !!

Only one remark:
(http://www.pulchr.se/random/clang_floor_ow2.jpg)
In real they never have volume, so, it may be a bit counter-intuitive to see a deep hole like that.
Just my opinion ;)


Title: Re: pul1duel - five steps ahead
Post by: pulchr on June 02, 2009, 10:55:25 AM
cosmo: thanks! openarena screenshots will be posted soon.

cacatoes: i'll keep that in mind next time i create a blown up clang floor ;)


Title: Re: pul1duel - five steps ahead
Post by: bill----- on June 02, 2009, 09:36:40 PM
Very nice!

Looks really good.

Each area has its own look, but each fits the overall visual theme.

Good item and weapon placement, not overloaded.   Big items placed
to be fought over.   'Traditionally' the PG is supplied to offset the
RG, but on this map, the way the RG will be used, the PG might
not be all that useful, and so its omission makes sense.

Jumps that present themselves are makable with some effort.

Did about a 25 minute walk-through.  Found that I could see something,
wonder why it was like that and then find a reason why.   There's plenty
of stuff like that to see!  For example, it took me a bit to understand the
utility of the lowest TP for attacking the RA platform, but it makes sense.

The noweapclip/playerclip see through brushes on the RA platform and
stairs near the LG are *very* interesting.  A lot of thought has gone into
supplying many mid-to-long range 'peekaboo' RG shots.  Five steps ahead
indeed.  :-)

In spite of that, there's lots of cover, and areas where RL/LG will be the
weapons of choice.   I can see how 2vs2 TDM would work
well here.  The 2SG and 2RL weapon load as a base, and LG and RG as
weapons to fight over along with the RA and MH.

The spawn points near the RG and MH made me wonder for a bit too, but
the spawn points overall supply a *dynamic* balance rather than attempting an
equal outcome for any spawn.

Once again, a lot of good thought has gone into this one. 


The grate texture under the RG has shadows but as a 2d texture has no depth and
so looks flat when you look at it while walking on it.  But you knew that. :-)


On the performance side, there more to it than the long sight lines.  There
are a *lot* of brushes!  Don't think I've ever seen as many volumetric lights.
And the stairs!   r_showtris was amazing! :-) 

Not that I think this is bad.  It really looks good.
I generally find myself checking out the skybox right away.  I didn't even look
up for the first 10-15 minutes.

I suspect there are opportunities to use hint brushes to reduce the rendered tri counts.
There isn't much to read about concerning them, but there is a certain
tutorial in which the author says that the hint brushes in the sample
maps that come with Radiant don't make sense to him.  Value that tutorial
accordingly.  Better just to understand how the Potentially Visible Set of volumes
is generated for a player at a viewpoint, why that PVS can contain brush faces that
aren't visible to the player, how a hint brush affects and ends that generation
of volumes, and therefore the rendering of the faces of brushes beyond.  Add
a bunch of screwing around with hint brushes and you may find performance
improving.

Do hinting last though.  Decompiled Cardigan's Estatica one time and the thing
was stuffed with hint brushes.  There was no way to clear them all away in
Radiant to even see what was going on.  Ended up writing an awk script to
delete all of the brushes with hint textured faces out of the .map.   So, unless
you do something special, working on a map after adding hint brushes will
be much more difficult. 

Maybe put them in a big prefab with their own function group, and use a copy of the .map
file with a different name to do the testing compiles.





Title: Re: pul1duel - five steps ahead
Post by: pulchr on June 03, 2009, 03:47:45 AM
thanks bill, for your thorough play testing!

i didn't include the plasma gun in the first version of the map and never really thought of including it. but i'm tempted to do a version and see how it would affect the gameplay. i'm not a big fan of the plasma since it often results in lots of spam. but in a duel it might work out differently.

it's true that i'm not all that happy with some of the spawns, being too close to some items and teleporters. but since i know that many server admins allow more players than the maps are designed for i added a couple of spawns to avoid people "invading other players' personal space" as the output reads :P

yes, the grate indeed looks a bit odd - but at least the texture is better in openarena than in quake 3 arena...

in regards to the light beams i will reduce the amount of them. it looks silly and will only be annoying after a while. i will keep some of them but most of them will have to go. the stairs are a bit overkill as well. most of them will probably be replaced with a simpler style. some goes for some walls that are too messy and look weird.

once i've reduced some of the stupid details (walls and stairs) i will have another go at the hint brushes. i've read cardigan's and other tutorials regaring hint brushes and vis-portalling and as much as i gather it's the open way beneath the door that ruins performance the most. both r_showtris and r_lockpvs imply that this is the case. one thing's for sure - the next map will have a structure that use hint brushes more effectively and that are planned from the beginning.

edit: small edits.

edit 2: yes i know i said that there would be screenies from within openarena in a day or two... but i've done some heavy edits so there will be some more time until those shots get here :)


Title: Re: pul1duel - five steps ahead
Post by: pulchr on June 25, 2009, 04:50:40 PM
i've run into problems with the sound effects. i made a new sound that triggers when a player steps on the blue see-through fields - but the triggered sound effect is only played in certain parts of the map. it turns out that the target_speaker entity only play sound effects to the game clients that are in an VIS portal connected to the trigger_speaker. it can be avoided by using a looping effect instead - but then i can't control when the sound is played. and therefore not an option. it can also play a global sound, but then you can't hear from where the sound comes or how far away you are.

i'm currently testing to see what happens if i open up the VIS so that the sound is played in the nearby areas. this will increase the r_speeds, but i'm on the verge of not caring anymore. a duel map where you can't hear if the enemy is close or far away is kinda crappy :P

i've been googling and it appears that a NO_PVS flag can be set in gtkradiant when you're mapping for wolfenstein or later games. but it's not available in the quake 3 version.


Title: Re: pul1duel - five steps ahead - finished!
Post by: pulchr on June 28, 2009, 11:04:27 AM
finished: see first post.


Title: Re: pul1duel - five steps ahead - finished!
Post by: Cacatoes on June 28, 2009, 12:33:29 PM
Congrats, come kick my ass on it some day ;)


Title: Re: pul1duel - five steps ahead - finished!
Post by: sago007 on June 28, 2009, 12:54:45 PM
Looks stunning and plays extremely well.


Title: Re: pul1duel - five steps ahead - finished!
Post by: kit89 on June 29, 2009, 03:26:20 AM
The detail in this map is impressively amazing! :)


Title: Re: pul1duel - five steps ahead - finished!
Post by: schlorri on June 29, 2009, 03:39:12 AM
This map looks so nice and the gameplay is really good. But my fps-counter is low using r_vertexlight 0 (0.5*fps of r_vertexlight 1). What can i do?


Title: Re: pul1duel - five steps ahead - finished!
Post by: pulchr on June 29, 2009, 09:15:13 AM
caca, sago & kit: thanks! :D

schlorri: that's the main issue with this map - too much geometry drawn. the layout is not ideal at all for hiding the rest of the map from view. i had that problem on my last map (pul1ctf) and said that it wouldn't happen again... guess what? ;) i'm not a shader wiz either and i'm sure that there are unnecessary texture passes are drawn in these. looking through surfaces also slows down - like in the blue fields i used.

i built and tested the map in quake 3 and there the r_speeds were quite high (11-13k). but if you open the map in openarena the r_speeds are even higher in the same spots. not good at all. there's not much to do about it without changing the layout of the map or dumb down the shaders. there are no real obvious places to use hint brushes. of course i could remove all the light beams, edges on floors, turn steps into ramps and so on but i'm not that keen on doing that.

the highest r_speed i've found is 17k standing at the top of the jumppad near the megahealth.
may i ask what your lowest frame rate is in the map, and where?


Title: Re: pul1duel - five steps ahead - finished!
Post by: davidd on June 29, 2009, 06:40:13 PM
http://www.youtube.com/watch?v=BQKT6Vujjuc (http://www.youtube.com/watch?v=BQKT6Vujjuc)

Me exploring this map on my promode server
/connect lood.zvdk.nl
It is running this map right now.

http://dpmaster.deathmask.net/?game=openarena&server=lood.zvdk.nl:27960 (http://dpmaster.deathmask.net/?game=openarena&server=lood.zvdk.nl:27960)


Title: Re: pul1duel - five steps ahead - finished!
Post by: schlorri on July 15, 2009, 04:22:24 PM
caca, sago & kit: thanks! :D

schlorri: that's the main issue with this map - too much geometry drawn. the layout is not ideal at all for hiding the rest of the map from view. i had that problem on my last map (pul1ctf) and said that it wouldn't happen again... guess what? ;) i'm not a shader wiz either and i'm sure that there are unnecessary texture passes are drawn in these. looking through surfaces also slows down - like in the blue fields i used.

i built and tested the map in quake 3 and there the r_speeds were quite high (11-13k). but if you open the map in openarena the r_speeds are even higher in the same spots. not good at all. there's not much to do about it without changing the layout of the map or dumb down the shaders. there are no real obvious places to use hint brushes. of course i could remove all the light beams, edges on floors, turn steps into ramps and so on but i'm not that keen on doing that.

the highest r_speed i've found is 17k standing at the top of the jumppad near the megahealth.
may i ask what your lowest frame rate is in the map, and where?

Ah sorry... I'm late :(
I made screenshots of lowfps locations... i wonder why resolution does not effect fps? Last screenshot is taken using 640x480 and framerate is low .

EDIT: but i have to say it again; it looks awesome!!!


Title: Re: pul1duel - five steps ahead - finished!
Post by: pulchr on July 15, 2009, 05:27:19 PM
i'm not an expert by any means - but i've heard that quake 3 relies much on the cpu to calculate what the gpu should render. so the cpu bottlenecks even a crafty gpu. i'm not sure how much of this is true. in many (most?) games the resolution is important for the frame rate and 1920x1080 / 640x480 is quite a difference :P

thanks for your screenies, it's always interesting to see what the map looks like on different computers.


Title: Re: pul1duel - five steps ahead - finished!
Post by: kit89 on July 15, 2009, 05:32:09 PM
Ah sorry... I'm late :(
I made screenshots of lowfps locations... i wonder why resolution does not effect fps? Last screenshot is taken using 640x480 and framerate is low .

EDIT: but i have to say it again; it looks awesome!!!

It's because the Geometry & textures coordinates are CPU bound.
While the resolution is GPU bound.

Modern games like Gears Of War, Xreal, etc... Their Geometry & texture coordinates are bound to the the GPU, allowing them to have millions of vertices on screen at once.
Here's an article that describes it pretty well: http://xreal-project.net/?p=266


Title: Re: pul1duel - five steps ahead - finished!
Post by: Falkland on July 15, 2009, 06:36:57 PM
Xreal "miracle" is possible because the engine implements VBO - Vertex Buffer Object - and the game itself support it too ... there was a thread also on ioquake3 forum about the opportunity to introduce the VBO support also in ioquake3 - http://ioquake.org/forums/viewtopic.php?f=2&t=125&start=0

There's also an experimental ioquake3 based engine for Tremulous ( tremfusion ) that has a VBO support - which has introduced also explicit SSE , SSE2 support via cvars , fully SMP support and recently also multithreading support .

I don't really know the possible impact of VBO support : I've tried myself compiling an experimental UrT engine branch with VBO support but it didn't work for me simply because VBO is a part of OpenGL 1.5 spec , while the MESA lib running on my platform support only OpenGL 1.3.

EDIT : another interesting reading  -> http://lists.ioquake.org/htdig.cgi/ioquake3-ioquake.org/2008-June/002979.html


Title: Re: pul1duel - five steps ahead - finished!
Post by: kit89 on July 16, 2009, 06:29:18 AM
Quote
There's also an experimental ioquake3 based engine for Tremulous ( tremfusion ) that has a VBO support - which has introduced also explicit SSE , SSE2 support via cvars , fully SMP support and recently also multithreading support .

That modified ioquake3 engine is actually Xreal. Downloading Xreals SVN shows there is a separate area for Tremulous.

Quote
I don't really know the possible impact of VBO support :

There are a lot of advantages to using VBO's. One is the amount of performance gain. Allowing for more complex geometry, effects & detail in a map. The downside is however, that you require the appropriate GPU & drivers to take advantage of it. Anything that can't support VBO is effectively an outcast.


Title: Re: pul1duel - five steps ahead - finished!
Post by: Falkland on July 16, 2009, 08:30:59 AM
Quote
There's also an experimental ioquake3 based engine for Tremulous ( tremfusion ) that has a VBO support - which has introduced also explicit SSE , SSE2 support via cvars , fully SMP support and recently also multithreading support .

That modified ioquake3 engine is actually Xreal. Downloading Xreals SVN shows there is a separate area for Tremulous.

I don't think so ... I know there's tremulous support in XreaL ... but the project I was writing about is tremfusion : http://www.tremfusion.net/hg/tremfusion/summary


There are a lot of advantages to using VBO's. One is the amount of performance gain. Allowing for more complex geometry, effects & detail in a map. The downside is however, that you require the appropriate GPU & drivers to take advantage of it. Anything that can't support VBO is effectively an outcast.

It seems to me to understand that ALL the GPU till GeForce2 series are able to support VBO : the problem is that VBO are part of the OpenGL 1.5 specs and I don't really know which linux GL ( OSS or proprietary ) drivers actually support GL 1.5 spec .... That's what I wanted to mean .... I can't actually test VBO because MESA lib installed on my system supports only GL 1.3 specs.


Title: Re: pul1duel - five steps ahead - finished!
Post by: Falkland on July 21, 2009, 02:52:17 PM
It seems to me to understand that ALL the GPU till GeForce2 series are able to support VBO : the problem is that VBO are part of the OpenGL 1.5 specs and I don't really know which linux GL ( OSS or proprietary ) drivers actually support GL 1.5 spec .... That's what I wanted to mean .... I can't actually test VBO because MESA lib installed on my system supports only GL 1.3 specs.

http://openarena.ws/board/index.php?topic=3235.0 ... a guy is having problem with Ubuntu 9.04 and a r300 chip ... well I don't know how to solve but the guy has attached a link with a pastebin of the output of the game ...

Ubuntu 9.04 uses Mesa 7.4 but the supported GL version for ATI/Radeon driver is _STILL_ 1.3 ... noway to see how this f**cking VBO works ... and I don't think that the latest Mesa 7.5 supports a significant higher GL version.

Anyway for whom is still interested , the latest NVIDIA drivers for linux (169 series and forth , and maybe also back) support GL 2.x while the latest legacy drivers support only GL 1.4 version ...