Even if what you say is correct (which i doubt imo), you seem to think a thing needs to be ‘complex’ for it to take alot of cpu time - which it doesnt.
fps
I never stated that ET is ‘not complex’ or ‘CPU intensive’ - just explaining how battle sense is awarded - which is quita a simple algorythm
I never stated that ET is ‘not complex’ or ‘CPU intensive’ - just explaining how battle sense is awarded - which is quita a simple algorythm
not talking to u
XP system:
- It’s server-side and client gets only notification and new values to draw
- BS is timer-based, everything else is tied to some sort of action (building something, killing somebody, stealing uniform…)
Objectives:
Objective is just a scripted trigger that must get fired to do something (ie. win/lose map, move something etc.) and draws in objective list. Anyway, both games have hundreds of triggers like that. Some just don’t periodically start a client sound or write a text. But that doesn’t mean they don’t exist.
Constructable object is just a set of few triggers that make something appear and disappear. Hell I can do a constructable object for Half-Life DM if I want to!
Paths:
How many has ET? 2 or 3 per map? Bah, Half-Life has many more that work the same and just having something in the map doesn’t mean it takes performance all the time. Path is just a set of points connected together in line and something moves from one point to another. Anyway, do we have any paths in Wurzburg radar? No. So why is it the slowest map to play?
Command map:
It’s nothing more than a texture with some icons blended over it. It ain’t taking more than a few CPU cycles to request drawing of a texture and blend over the icons.
Sophisticated sound system:
Ummm, what do u mean? Calling “construct tank barrier”, “construt the command post” etc.? Nothing more than just a few timed triggers that periodically fire themselves until they’re turned off. Possible since Doom 1.
Stats and loging:
Actually Jedi Academy logs every single saber attack and tells u how many times u cut someone’s hand, body, leg etc. It’s just a few variables that are kept in memory and sometimes increase/decrease. Nothing that could take much of performance.
The problem is that the world drawing is highly inoptimized so GFX is what we have to talk about. If I look on ground, I get over 100fps. If I look forward, I get only 25. Do u still think the problem is in game code and not in GFX?
The problem is that the world drawing is highly inoptimized so GFX is what we have to talk about. If I look on ground, I get over 100fps. If I look forward, I get only 25. Do u still think the problem is in game code and not in GFX?
Im not even going to dignify that with a responce, you obviously knwo jack shit.
I can say that you prolly have a CPU/mem bottleneck and that’s why changing res & detail doesn’t help much but still you should get more.
Your celeron is a housemother’s cpu tbh
Indeed :moo:
ET is barely playable for me either, with a 9800pro. It’s a hell of a lot slower than the overclocked GF3ti200.
Dont bother with the “try new drivers”, “delete the old ones properly” etc stuff ta, been there done that. Except the 3.7’s, might try them.
what a load of utter crap. It is pretty funny that of you to say someone doesn’t have any clue what they are talking about, when you are obviously equally clueless…
multiple objectives ? How would that cause a big CPU impact ? (never mind that RTCW had multiple objectives too. )
Constructables ? It is pretty much a func_static with a trigger around it.
Command map ? Its a blended texture (which is off most of the time). Player locations are tracked in games like q3 and RTCW too.
The XP system is rather simple… a few conditional on things that were already tracked in RTCW…
Spline movers ? Doubtful, especially the fact that even maps which don’t include them perform like crap would argue against it…
Sound system ? Oh yeah, that wav playback must be the problem.
The simple fact is the official ET maps are quite a bit more complex than those of earlier games. (30k+ r_speeds compared to 10k-15k for RTCW). The Q3 engine, even as modified by SD doesn’t really handle this very well, and a large part of the hit is on CPU and memory bandwidth. And that is even before you included the stuff like foliage and atmospheric effects…
On RTCW maps, ET performs quite similarly to RTCW (except for the not correctly compiled beach conversion that is floating around).
I’m sure the new ET features add some cost, but the bottom line is the complexity of the maps. It sure as hell isn’t the fact that you get ‘XP’ instead of ‘points’ for killing someone.
well your all wrong :poke: it doesnt matter what cpu or gfx card you have its all about your case I mean if you have a mini atx case then ofcourse you’ll get low fps but if you have a monster modded case with a blue cathode light and a big ass window then you could be getting 500+ fps… pffff thinking you know all about it
Domi wrote:
[quote]
do those games have an experience system that understands good skill in getting to objectives, sneaking by players.
do those games have multiple objectives
do those games have constructable objects
do those games have complex spline paths for movable objectx
do those games have command maps
do those games have a sophisticated sound system for updating the player on whats going ong
do those games log every single bullet fired, log where it lands, accuracy, and compile in-game stats on who is performing best.I think u will find ET is a hell of a lot more complex.
When i mean CPU intiensive, i dont mean gfx…
what a load of utter crap. It is pretty funny that of you to say someone doesn’t have any clue what they are talking about, when you are obviously equally clueless…
multiple objectives ? How would that cause a big CPU impact ? (never mind that RTCW had multiple objectives too. )
Constructables ? It is pretty much a func_static with a trigger around it.
Command map ? Its a blended texture (which is off most of the time). Player locations are tracked in games like q3 and RTCW too.
The XP system is rather simple… a few conditional on things that were already tracked in RTCW…
Spline movers ? Doubtful, especially the fact that even maps which don’t include them perform like crap would argue against it…
Sound system ? Oh yeah, that wav playback must be the problem.
The simple fact is the official ET maps are quite a bit more complex than those of earlier games. (30k+ r_speeds compared to 10k-15k for RTCW). The Q3 engine, even as modified by SD doesn’t really handle this very well, and a large part of the hit is on CPU and memory bandwidth. And that is even before you included the stuff like foliage and atmospheric effects…
On RTCW maps, ET performs quite similarly to RTCW (except for the not correctly compiled beach conversion that is floating around).
I’m sure the new ET features add some cost, but the bottom line is the complexity of the maps. It sure as hell isn’t the fact that you get ‘XP’ instead of ‘points’ for killing someone.
[/quote]
What I dont understand is the inability to read over peoples own words. Read what you have just said again. Finished? Good.
First of all, we are comparing this not with RTCW, but with the other games mensioned above. So all references of RTCW in your post are null and void, so stop using that as an excuse when its obviously going to be a simple get out of jail free card.
Secondly, the command map/compass that everybody seems to think is a little blended texture. Unfortunate most people think this, too. Take 30 seconds of your time to have a gander at it in game. Looks very nice doesnt it. Now, walk about. So some Vsays - ooh! looksie! a medic icon has appeared on it. Hey, whats that train going past it, Ahh - yes, its tracking my objective. Aint that nice of it to do that for me. Hey, seems theres lots of people coming my way, its nice how it can display all this info for me as its a real help. Just a blended texture, pfft…
I encourage you to make a constructable object in a q3 mod. Se how much code it takes up to impliment this func_static and keep the player informed about its status. Then have a coffee and celebrate what you have achived.
The sound system consists of alot more samples than (in your comparison, rtcw) and uses it alot more in maps. More streams for crappy sound cards = more cpu cycles.
Why people dont get that ET is a CPU intensive game is beyond me, of course it is, graphically its pushing the GFX side of things to the limit as you have said. I overclocked my CPU by only 200mhz, and gained 30 fps. If i was to upgrade my gfx card by such a small amount I dont think I would get that much of a gain from it.
I know u like your maps SCDS_reyalP, but you cant blame them all the time.
well your all wrong it doesnt matter what cpu or gfx card you have its all about your case I mean if you have a mini atx case then ofcourse you’ll get low fps but if you have a monster modded case with a blue cathode light and a big ass window then you could be getting 500+ fps… pffff thinking you know all about it
Indeed.
DG: 
Ways to improve performance:
- Use video memory as much as possible in game code
- Optimize drawing and computing algorithms using Assembler language
- Use better compiler than standard VC++6/VC.NET (GNU or Intel for example)
- Optimize maps by removing unnecessary brushes (like those that are created when carving or hollowing). Most maps can get about 10 to 25% performance boost by doing this
Secondly, the command map/compass that everybody seems to think is a little blended texture. Unfortunate most people think this, too. Take 30 seconds of your time to have a gander at it in game. Looks very nice doesnt it. Now, walk about. So some Vsays - ooh! looksie! a medic icon has appeared on it. Hey, whats that train going past it, Ahh - yes, its tracking my objective. Aint that nice of it to do that for me. Hey, seems theres lots of people coming my way, its nice how it can display all this info for me as its a real help. Just a blended texture, pfft…
And what else do u think it is? If the map is open, all u have to do is just blending the background (map) and then icons representing players, objectives etc. in a loop! U have to do exactly the same to draw the world but u’re just using polygon models insted of icons and a texture. If it’s not open, u do NOTHING! THE CODE JUMPS ELSEWHERE!
I encourage you to make a constructable object in a q3 mod. Se how much code it takes up to impliment this func_static and keep the player informed about its status. Then have a coffee and celebrate what you have achived.
I don’t need to write a single line of code to make a map with constructible object in Half-Life (I’m not familiar with radiant but it’s exactly the same). Use these entities:
<any trigger that can be held for longer time> - when player press USE, the construction begins, when he releases it, the construction is slowly disappearing
func_train - simulating a progress bar and a little exploit of system for timing
env_beam 4 times - our exploit’s main part, they’ll fire tirggers when progress bar releases them
<any trigger that can take damage and lock itself> 5 times - 4 triggers used to show/hide visible parts, one for destroying object
func_illusionary - transparent non-solid copy of object
func_wall_toggle - solid object to be constructed
trigger_relay 5 times - just for securing that trigger supposed to create something doesn’t destroy it or create something it should destroy
The sound system consists of alot more samples than (in your comparison, rtcw) and uses it alot more in maps. More streams for crappy sound cards = more cpu cycles.
Great, but what does the CPU do with sound card when not playing any sound? Answer: NOTHING. Keeping something in memory doesn’t mean it’s used by CPU all the time. Playing a single sound takes about 0.00132% of CPU load on my machine (found out using FMOD library). And the highest count of sounds I counted in single frame is 6. Not something that could do ANY harm to performance.
m8, your knowledge of how some of these things work is very lacking. IF you dont think they have done lots of this, fine. But stop talking bull.
And, if you think i dont know what im talking about, how about you have a look at my own 3D engine, which you can find a screenshot to here:
Oh, u’re so great master of programming! A trained monkey can make an engine with 3D scene! And what’s the framerate in the upper right corner? 13.11 when drawing 10 407 tris? I think u should practice using some cool optimizing features of OpenGL or what u used to draw that. Create a demo with scripts and sounds I can look at and watch how it runs. A single picture says nothing. Anyway, if u’d do it right, the vert count of closed scene should be about equal to tri count. Otherwise, u’re drawing each vert two times more than u need.
Oh, u’re so great master of programming! A trained monkey can make an engine with 3D scene! And what’s the framerate in the upper right corner? 13.11 when drawing 10 407 tris? I think u should practice using some cool optimizing features of OpenGL or what u used to draw that. Create a demo with scripts and sounds I can look at and watch how it runs. A single picture says nothing. Anyway, if u’d do it right, the vert count of closed scene should be about equal to tri count. Otherwise, u’re drawing each vert two times more than u need.
That tris count does not take into account curves, which adds about another 15k to that scene Id also like to point out that is best quality, high res, and i only have an FX5200 which underperforms a decent GF3. I should also point out that ‘3d scene’ you point out has beizer curves, frustum culling, full PVS occlusion (for q3 bsps) and Collision Detection. But, All of that shit aside, Im going to point out how you know jack shit.
You posted:
The problem is that the world drawing is highly inoptimized so GFX is what we have to talk about. If I look on ground, I get over 100fps. If I look forward, I get only 25. Do u still think the problem is in game code and not in GFX?
I ask you to go and read up on frustum culling, PVS occlusion and basic line of sight picking/tracing. Once you have, you should then realise why your above statement makes me laugh so much. You go on about how OpenGL has so many optimization capabilities. Mate, Look at what you have said. its just so damn funny i cannot contain myself.
‘When i look at the ground, I get over 100fps’
Good for you mate, id expect so too, considering its drawing, um, a bit of ground with maybe a little shrub or rock on it. :blah:
‘If i look forward, I get only 25’
Whoa, who would of thought. Not only am i drawing the ground, some shrubs, a few rocks, walls, buildings, players - but my fps is worse off than jsut drawing the ground. Shucks. :bored:
The only problem here is your lack of understanding with respect to how 3D geometry is sorted,selected and drawn within a 3d scene. Go read up on it, for pitys sake boy. :banghead:
Frustrum Culling: http://www.flipcode.com/articles/article_frustumculling.shtml btw, nice tut there.
The fact is that ET and RTCW perform about the same on similar maps, while the ET maps perform 75% to 150% worse than typical RTCW maps. Coincidently, they also have 75-150% higher r_speeds. But somehow, you claim that doesn’t matter, and it is the game code that is causing the CPU hit ?
By your argument tc_base in ET should perform much worse than mp_base in RTCW. But it doesn’t. Now please explain how that fits into the “it’s all the gamecode” theory.
note, I’m using RTCW as an example, because it is a game I know quite well, is quite similar to ET, and yet still shows a large performance differnce. Also, comparison is easy because a number of maps have been directly ported from RTCW to ET.
I ask you to go and read up on frustum culling, PVS occlusion and basic line of sight picking/tracing. Once you have, you should then realise why your above statement makes me laugh so much. You go on about how OpenGL has so many optimization capabilities. Mate, Look at what you have said. its just so damn funny i cannot contain myself.
‘When i look at the ground, I get over 100fps’
Good for you mate, id expect so too, considering its drawing, um, a bit of ground with maybe a little shrub or rock on it.‘If i look forward, I get only 25’
Whoa, who would of thought. Not only am i drawing the ground, some shrubs, a few rocks, walls, buildings, players - but my fps is worse off than jsut drawing the ground. Shucks.The only problem here is your lack of understanding with respect to how 3D geometry is sorted,selected and drawn within a 3d scene. Go read up on it, for pitys sake boy.
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.
Frustrum Culling: http://www.flipcode.com/articles/article_frustumculling.shtml btw, nice tut there.
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.
GLAPI void APIENTRY glFrustum( GLdouble left, GLdouble right, GLdouble bottom, GLdouble top, GLdouble near_val, GLdouble far_val );
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.
