Comparison on ID Tech 5 VS Other Game Engines

Started by
9 comments, last by Necrolis 11 years, 10 months ago
This is just my perspective but perhaps you may agree or disagree. I noticed while playing Rage by ID Software that the game engine is very optimized. On the other hand, I am currently playing L.A. Noire by Rockstar Games and noticed a bit of lag but then runs smooth. If I just ponder on this for a moment, couldn't this be because ID Software uses better memory mangement than Rockstar Games? In Rage I noticed if you jerk the player very quickly the textures then get drawn starting out blurred. Perhaps if the player is facing towards the scene than the textures not on the screen go into the lowest mip-level. What are your thoughts about this? I noticed L.A Noire that while driving the objects are being drawn at a given distance from the player. As like the player is far away then the engine care less about drawing them on the spot - however, if the player is right up there then draw it. If you seen the Private Property Clitch I think this is the reason why. What are your thoughts about this?

I am currently doing alot of research into Code Optimization techniques and memory allocations and better memory management. By doing some reading in Frank Luna's book Introduction to DirectX 11 and other tutorials, I am wondering what if a mesh is drawn by first clearing out the memory for it then once it's drawn then clearing out that space of memory again for better memory management...?

Well, I'm still doing more intense research at the moment and so far loving this forum!
Game Engine's WIP Videos - http://www.youtube.com/sicgames88
SIC Games @ GitHub - https://github.com/SICGames?tab=repositories
Simple D2D1 Font Wrapper for D3D11 - https://github.com/SICGames/D2DFontX
Advertisement
Rage does use quite a few optimisation techniques. ID have a patent on some weird texture drawing technique and another on a method of drawing the terrain using 1 texture both of which are meant to boost framerate, the terrain drawing uses more disk space though with a slight overhead on asset loading.
ID have a patent on
Are you sure about that? It'd be suprising, seeing how vocal Carmack is in opposing software patents -- "The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.", "Getting a patent is uncorrelated to any positive attributes, and just serves to allow either money or wasted effort to be extorted from generally unsuspecting and innocent people or companies."

They call their texture streaming idea "MegaTexture", other research literature uses the name "SVT" for the same idea.
am wondering what if a mesh is drawn by first clearing out the memory for it then once it's drawn then clearing out that space of memory again for better memory management...?
I'm not sure what you mean by this idea, are you stalking about streaming geometry data to the GPU?
Hodgman, if streaming geometry data to the GPU would be a better way to optimize then I think that would be it. What's the difference between Streaming and gathering from file? I noticed that DX has for instance, get texture from file function and gettexturefromresource. So, can anyone clear up what streaming is for me? Is it from file or resource? Thanks
Game Engine's WIP Videos - http://www.youtube.com/sicgames88
SIC Games @ GitHub - https://github.com/SICGames?tab=repositories
Simple D2D1 Font Wrapper for D3D11 - https://github.com/SICGames/D2DFontX
Hodgman, if streaming geometry data to the GPU would be a better way to optimize then I think that would be it.
Better than what at optimising towards what goal?
What's the difference between Streaming and gathering from file? I noticed that DX has for instance, get texture from file function and gettexturefromresource. So, can anyone clear up what streaming is for me? Is it from file or resource? [/quote]Neither and both. It's the concept of only moving data to it's destination as it's required for processing, and only moving the sub-set that's needed at that time, not the whole data-set at once.
I was trying to ask what your original idea was though, instead of suggesting that you should stream your geometry...

Rage does use quite a few optimisation techniques. ID have a patent on some weird texture drawing technique and another on a method of drawing the terrain using 1 texture both of which are meant to boost framerate, the terrain drawing uses more disk space though with a slight overhead on asset loading.

Trust me that that technique has no patent as Square Enix was involved in blatently stealing that technology for their new engine and I was involved in that theft (I was actually against it from the start, but not due to feeling like a thief but from the fact that there are just better ways to go about managing your textures).

But as for anything boosting the framerate, nothing exists. Megatextures decrease the FPS and there is nothing else. Nothing to gain FPS somewhere else, nothing to make up for the loss of megatextures.
This is why I was originally opposed to megatextures from the beginning and still am (the results of Rage on Xbox 360 may have helped).

In a previous post I mentioned that their GPGPU particles could have had higher numbers. Megatextures is basically to blame for this.
This is one major advantage Unreal Engine 4 has over the Lunimous Studio engine.


Rage is not as optimized as you think. Only the iOS version is really considerably optimized, but you are not talking about that.

The terrain is not optimized at all, and is in fact twice (or so) as slow as it could have been. id Software has no patents on those techniques, and there is not a lot happening under the hood that you could not replicate yourself.
iOS was made possible by its flash storage, which is basically impervious to random reads and writes as long as the reads and writes are properly aligned.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid


[quote name='6677' timestamp='1341918714' post='4957576']ID have a patent on
Are you sure about that? It'd be suprising, seeing how vocal Carmack is in opposing software patents -- "The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.", "Getting a patent is uncorrelated to any positive attributes, and just serves to allow either money or wasted effort to be extorted from generally unsuspecting and innocent people or companies."
[/quote]

Since the US PTO grants patents on a first to file rather than a first to invent basis it wouldn't surpise me if carmack and alot of other people are filing patents on anything semi decent just to make sure noone else files first and drags them to court over it.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Streaming is really neither. The DX CreateTextureFrom* functions are quite high-level and will make calls into the lower-level API, as well as do a lot of I/O and format conversion - you wouldn't even think of using them for a real-time/run-time solution (in addition to that, creating a new resource is always going to be much more expensive than simply updating an already existing resource).

With streaming what happens is that you have a texture (for the purposes of this discussion) that has already been created, you have a chunk of data that comes from somewhere, and you replace the contents of that thexture with the new data. How you replace the contents is up to you - you can require that everything must be replaced before execution can continue (which may or may not run slow), you can do partial replacements, update a second copy on another thread (e.g. a PBO in GL or a STAGING texture in D3D) then copy across on the GPU, or whatever.

Regarding idTech5 specifically, one advantage of it that doesn't get often mentioned is that the fact that it uses a single large texture for everything allows it to do some quite agressive draw-call batching. In practice it won't use a single call for the entire scene as that will break frustum culling, but it can handle the entire scene in considerably fewer calls than other approaches.

Regarding patents, Carmack is the person who once said that if id ever brought up the topic again (after the first time) he was out the door.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.


Rage is not as optimized as you think.


Really? Cause its probably the best looking Xbox 360 game that runs at 60 FPS. It looks about as good as Halo or BF3 but those are 30 FPS. Yeah, having Id artists helps too, but the engine runs flawless 60 FPS on the 360 and very few games with that visual quality do.
I would be willing to believe that some parts of the engine aren't optimised-to-hell, but only on the basic optimisation tenet that you focus on the bottlenecks instead of needlessly complicating all code.

This topic is closed to new replies.

Advertisement