fps


(bani) #41

the ET gamecode proper isnt really CPU intensive.

the ET client gamecode (cgame) typically uses < 10% of total CPU, most is spent in the engine.

although it might not look it, ET is a very graphically complex game – the maps are very complex overall and there are many huge outdoors areas in the stock maps. q3, jk2, etc might “look better” but graphically they tend to be much simpler. they ‘look better’ because they use brighter, more saturated colors and lots more contrast.

there are a number of things in the ET renderer that are not as optimized as they could be (and there are a bunch of bugs :D), but overall it is the complexity of the stock maps that tends to be the killer.

with careful mapping you can get very good performance out of ET.


(Domipheus) #42

Read ur own post I was responding to. Why did u say that bad performance is not matter of GFX when u say it is now? If it wouldn’t be a matter of GFX, then I should get the same framerate no matter if I look at the ground or forward. U’re opposing urself.

W.T.F - YOU go read it again, what i said is that, most people buy their new ‘omg radeon 9800’ and then end up getting shit fps in et because their cpu is bottlenecking them. Nothing else.

If it wouldn’t be a matter of GFX, then I should get the same framerate no matter if I look at the ground or forward. U’re opposing urself.

Again, :banghead:

I have my own box in frustum and rectangle in frustum functions for use within my engine, because unlike you, i know what im talking about.

Oh, very nice. Tell me, are u using it in ur code? Actually, frustum culling is already included in OpenGL (most GFX cards count it in GPU) and it’s very simple to enable it. It’ll save much of CPU time u’d otherwise give to frustum culling (if ur card supports it, otherwise, it’ll call it in CPU). BTW, that article is written for API that doesn’t include frustum culling itself.

Thats great squire, but! instead of putting ‘opengl frustum’ in google, and copying and pasting a function header right out of the fire match returned, why dont you sit and think for a minute.

GLAPI void APIENTRY glFrustum( GLdouble left, GLdouble right, GLdouble bottom, GLdouble top, GLdouble near_val, GLdouble far_val );

This function, only has once purpose. To set up a viewing frustum. It doesnt cull A THING. You will still get buildings/objects drawn behind you that do not exist, and, bascically, all it does is give you the correctly adjusted viewpoint for your selected fov and near/far plane.

I have my own functions as said before for handling this, as said before. I dont even use glFrustum for frustum culling, i use it in setting up the field of view required in my engine. If you knew anything more than how to look something up in google, you would see that your points are really quite void.

I think that problem is u know how to draw something at all costs but u hell don’t know how to draw something using only really necessary resources.

Unfortunately for you, and your unending wisom of resources (i.e. google ‘im feeling lucky’) your still talking shit. So why dont you just pack it in.


(Domipheus) #43

And thanks bani for clearning that up :slight_smile: tho, the engine does use cpu also (jsut say that so mongotitboy above doesnt think the engine is loaded into gpu ram or smuffin and executed on cookie dough)


(next_ghost) #44

Domi, ever heard of ‘display lists’? It’s a read-only set of commands and resources in video memory that was recorded in CPU and can be called from CPU using only identifier. If u’re not using them in large scenes with geometry that never or rarely changes (i.e. BSP solid world), u’re overloading either CPU or AGP bus. And using vertex arrays is also good. It’s like display list but it can be changed by resending data from CPU.
The question is: Why do I have 128MB of video RAM if I don’t load anything in it except few small buffers that’ll fit into 32MB card?

And about glFrustum:
Anything outside field of view is cut. If u draw a triangle with one vertex outside of screen, that vertex is cut and OpenGL counts two other vertexes in intersection of FOV plane and clipped vertices turning that triangle to trapezoid u can see.


(Domipheus) #45

Domi, ever heard of ‘display lists’? It’s a read-only set of commands and resources in video memory that was recorded in CPU and can be called from CPU using only identifier. If u’re not using them in large scenes with geometry that never or rarely changes (i.e. BSP solid world), u’re overloading either CPU or AGP bus. And using vertex arrays is also good. It’s like display list but it can be changed by resending data from CPU.

Thats idiocy showing its ugly head. Read up on q3BSP PVS, then u shall see that the BSP is not drawn as a solid world but is drawn according to data which is compiled into the BSP. Ever heard of Vis? Portals? Visability cluster, yeah. Thought not. You would be surprised how much changes.

Taken from The Display List manual:
Another disadvantage is the immutability of the contents of a display list. To optimize performance, an OpenGL display list can’t be changed and its contents can’t be read. If the application needs to maintain data separately from the display list (for example, for continued data processing), then a lot of additional memory may be required.

I rest my case, as bsp rendering requires continuous processing of nodes/clusters and the PVS that has to be drawn/visible for that cluster. Its a bit big also for use in a list tbh.

I use display lists for my in-game fonts however, heres a screenshot of them in action sir:
http://www.colsofthub.co.uk/console.jpg

now,
And using vertex arrays is also good. It’s like display list but it can be changed by resending data from CPU.

This is what I use, ive also got a Vertex Buffer set up but this is not implimented as yet. There is no need to resend data after the map load (on my engine anyway).

And about glFrustum:
Anything outside field of view is cut. If u draw a triangle with one vertex outside of screen, that vertex is cut and OpenGL counts two other vertexes in intersection of FOV plane and clipped vertices turning that triangle to trapezoid u can see.

Wrong. Try it for yourself. And, anyway, you seem to forget that if you were right, calls are still being made which ogl then instantly would refuse, which is obviously quite stupid efficiency wise, would you not aggree.

and just before i finish, what were you saying about tris and vert count? you do realise that tris (a triangle) = 3 verticies (corners)? so the tris count would obviously be ALWAYS lower than the vert count? Have you done primary math yet?

Putting it plainly, and i hope you now shut up…


(digibob) #46

Using display lists is a bit silly for any large amount of geomtry, nowadays i’d only use it for some simple quick text rendering, as you can convert characters directly to the specific display list index you want. Using it on large amounts of geometry will NOT use index/vertex arrays, so can end up being stupidly big and/or slow.

Using the openGL frustum culling can also be a bad idea, as if you can do it further up the pipeline in the engine, and on an entire surface for example, it can cut down on the need to send it to the card/openGL pipeline.


(SPo0n) #47

not an ATI thing, it’s an ET thing. same happens on my nvidia. all other games are fine


(SCDS_reyalP) #48

First of all, do your really think that carmack and the splash team are unaware of basic opengl functionality ? Somehow this seems rather unlikely :moo:

OTOH, COD gets away with significantly higher r_speeds than ET does, so it does seem that optimizing the engine for more modern hardware could have some merit. But apperently the splash team were rather busy with other things, so it is a moot point anyway.

As far as getting 100FPS when you look at the ground, and under 30 when you look level, /r_speeds 1 should give you the answer. Or r_showtris 2.

and BTW, ET can use almost all of your 128 megs of video ram for textures alone. /imagelist will show this to you.


(next_ghost) #49

Thats idiocy showing its ugly head. Read up on q3BSP PVS, then u shall see that the BSP is not drawn as a solid world but is drawn according to data which is compiled into the BSP. Ever heard of Vis? Portals? Visability cluster, yeah. Thought not. You would be surprised how much changes.

Nobody forces u to load the whole map as single array. Simply load one vis cluster after another to different arrays and then call these arrays depending on basic cluster visibility calculations. And about the changes: Well, tell me, what changes on the base mesh of map during game? Nothing. The mesh is the same from load to unload. The only thing that changes is what u actually draw in a frame.

And here comes another optimization:
If u don’t keep base mesh in CPU memory, u don’t need brushes broken for texturing by CSG and u can merge all coplanar polygons to save time in collision test.

And, anyway, you seem to forget that if you were right, calls are still being made which ogl then instantly would refuse, which is obviously quite stupid efficiency wise, would you not aggree.

Actually, clipping polygon to only visible part is one of the very first steps of drawing. Yes, if u draw the whole map, u’ll end up with idle GPU and overloaded bus/CPU. Well, if u don’t use VRAM instead of RAM. Then u’ll get idle bus/CPU and “overloaded” GPU.

you do realise that tris (a triangle) = 3 verticies (corners)? so the tris count would obviously be ALWAYS lower than the vert count?

Yes, one triangle has 3 vertices. But if there’s a closed scene, each triangle shares vertices with 3 other triangles. Sure that vert count can never be equal to tri count but at best, it should be as close to it as possible.

reyalP:
Quake3 engine is from pre-GPU era and I doubt they started rewriting it when GeForce256 came out. Carmack has other problems with Doom3 and it seems Splash damage focused on gameplay rather than rewriting whole renderer code. Anyway, IF they did it, first GPUs had little memory to use for keeping the whole scene in it.


(bani) #50

next_ghost: produce some code, show some opengl project you’ve coded, and maybe someone will take you seriously :slight_smile:


(ildon) #51

And here comes another optimization:
If u don’t keep base mesh in CPU memory, u don’t need brushes broken for texturing by CSG and u can merge all coplanar polygons to save time in collision test.

Q3map2 already does this. It’s called -meta. The renderer doesn’t (and shouldn’t have to) care. Not to mention that no one in their right mind uses CSG when mapping…


(Domipheus) #52

Nobody forces u to load the whole map as single array. Simply load one vis cluster after another to different arrays and then call these arrays depending on basic cluster visibility calculations. And about the changes: Well, tell me, what changes on the base mesh of map during game? Nothing. The mesh is the same from load to unload. The only thing that changes is what u actually draw in a frame.

Clusters can contain duplicate surfaces. So, Wheres your ‘memory’ optimisation for that pal, sounds like youve just increated memory requirements 2 fold.

And here comes another optimization:
If u don’t keep base mesh in CPU memory, u don’t need brushes broken for texturing by CSG and u can merge all coplanar polygons to save time in collision test.

In the q3bsp system, there are things called brushes that your collision detection algorithm uses. They are made on compile, and it has nout to do with the renderer. And, CSG, If u think SD dont know how to make a hole in a little wall then you are more stupid then i initially thought.

Im not even going to comment on your other waffle.

next_ghost: produce some code, show some opengl project you’ve coded, and maybe someone will take you seriously

Agreed.


(Domipheus) #53

aww, to think, i was expecting another laugh today :frowning:

hes prolly off coding doom 4 :slight_smile:


(next_ghost) #54

Not Doom 4 but when it comes out, it’ll be revolution :wink:


(Domipheus) #55

:wink:


(ETplayer) #56

:wink:


(Domipheus) #57

is that actually u i nthat pic btw ETplayer?


(Fusen) #58

lol for the whole time hes been here and you randomly ask now =P and i would be worried if he put some random teenager as his avatar o.0


DETROIT DIESEL V8 ENGINE


(Domipheus) #59

i know, always wondered as well :slight_smile: