3d GameStudio vs Doom, Quake, etc engines

To all:
Thanks for the feedback, I appriciate it.

To Clay:
I am thinking to build a 3d shooter like Battlefield 1942. But different scenario offcourse

I guess this could be done with 3DGS.

Thanks,

Wildcard

First/3rd person Games are very easy to do in 3DGS.
One thing to keep in mind is, 3DGS does use BSP for level building.
This makes indoor areas ideal, such as Quake/Doom/UT type settings veru easy.
Large outside areas can be done, but involves a bit more work as you need to focus on LOD of models, clip range, collision detection, etc...

However, Octave is in the works, so I assume you would be able to choose Octave vs. BSP on a level by level basis?

Octave is much easier for outdoor levels, but I am not saying it cant be done quite effectively now by using some planning.

Peace out, Clay...

Thanks GFX for the corrections.
And yes, easy is relative...

yes but the fps is already low with really >small< test levels, and doom has really big levels, so i guess thats a thing that conitec has to work on, because why do you have normal mapping for l. geometry if you can only use it in one room

Fixing the texture size will likely double the FPS (if not more) for most users in the test level. The other issue is in the shader code itself. Doom 3's shaders are well written and highly optimized, however the one in the example level is not so much so.

There are other issues that can be fixed from within the engine itself (an initial rendering pass without textures to remove faces that will not be visible - and thus reduce the overall calculations needed once a shader is applied), but those are really pretty minor when compared to the shader itself and the textures being used.

well like i already said , with 3DGS you can produce great things ,
it ony depends on your artist talent and good coding,
look at metroid 2 on gamecube , no bump mapping , simple textures , but very great,
with 3DGS this studio would use tricks to bypass limitations and
they could bring metroid2 to 3DGS like in gamecube version and same quality,
with bump mapping for characetrs creatures and some parts of the level.

And 3DGS is the most fast and easy of use of all 3D engines in the same
order of price for us , and you can quicly produce something playable like a prototype or a real game than any other 3D engine.
For example an Arkanoid game or simple FPS could be done in one hour of programming/testing in C-script ; after that it will take more time to bring it to a good level with better design, 3D models ,textures, etc..

actualy, everything done in any engine is a 'trick'.

It's not a matter of the process, its only a matter of the result that counts.

Personaly i think the gs engine is way more sexy then doom3.

I think fun and a good level architecture is the most important thing for a game. This is much more important than 5 fps more.

lets not delude ourself people... any comparison of the Doom3 engine and A6 is purely incidental... or should i say, coincidental...

but there is hope and progress on the A6 end... as far as the graphics are concerned, take a look at this


and visit the Universal Shader Thread thread...

so, i guess in the hands of a talented developer or two... i think that A6 can be used to make a game that can come verrrry close...


--Mike

Nothing in particular is wrong per se with how the shader is written, there are almost always optimizations to be found though. About those:

- Generally speaking ASM is faster than HLSL. Although I haven't looked at Doom 3's shaders I would bet that a good portion of them are written using ASM. You can also use ASM within HLSL to optimize costly portions of the shaders by enclosing the ASM portion with a {};

- When using a lot of shaders (and this would qualify as a lot since it is used on the majority of surfaces) it is important to eliminate anything that is not a Programmable Shader. When the GPU processes the scene it is very costly in terms of GPU cycles to purge the FFP commands and load up the Programmable Shader commands. Some tests in my own engine have shown as much as 10-15% difference in the frame rate. This is something that might need to be fixed from within the engine itself since I am not sure if the engine will still issue built in FFP commands even if you manage to eliminate objects which use them from the scene.

- Co-issue commands. I only did a quick glance through the shader itself, but I didn't notice any such optimizations. If you leave this up to the GPU you may or may not recieve the benefits of this technique. However if you manually apply the proper masks you will recieve the performance boost.

- Optimize the number of passes. I am pretty sure you should be able to get that down to a 2 pass shader - although I will admit that most my shader programming has not been with 3DGS so there may be a limit that I am missing out on that causes you to render in this method. Use the first pass for culling to prevent overdraw and the second to actually render the lighting effects.

- Doom uses several rendering systems. Each major chipset has its own highly optimized rendering system including shaders which are optimized for that chipset. You can include similiar features in 3DGS with a bit of work too. An example of this are optimizing texture fetches and ALU instructions for ATI cards. Each clock cycle the GPU for the last generation of ATI cards (9500,9700, 9800...) could process one of each. By tweaking the techniques used you can optimize the shader to make full use of the available processing power of the GPU. NVidia has their own tricks and traps as well which is why using a shader specific to each chipset is important when looking at making the most out of shaders.



Other issues can really only be addressed with proper analysis of the scene. You may find that using so many normal maps and what not is leading to a bottleneck in texture calls. If this is the case you can look into using alternative methods of storing that data. Some of the issues need to be addressed by Conitec within the engine itself - others are more a factor of the end user of your shader (Nadester using normal maps which were way too large) but the biggest difference between a game like Doom and a tech demo done with 3DGS is the time spent tweaking it.

Writing the switches needed to identify end user hardware and even testing shaders on that hardware is very time consuming - but without doing that 3DGS will look like it is holding a candle in the wind when compared to Doom 3 or Half Life 2.

Usually it is done using something along the lines of the texdepth command in a Pixel shader. I have heard of some success using vertex shaders though and that should be a bit more efficient too. I'll poke around tonight and see what I can dig up on the depth test technique in terms of online documentation. I think I first learned of it in ShaderX though. Needs PS 1.4 to work - and it is pretty efficient too (solves the nasty z-buffer sorting error as well). The culled data when using texdepth (or more correctly data that is not culled) gets passed to the r5(have to double check?) registry and can be passed on to additional shaders and passes as needed.

The lights were my bad. I went back and took a look at the technique I am using and it is one ASM pass per light. According to my notes the ASM versus HLSL freed up about 15 FPS. Also using the initial pass to set the z-buffer made it so that I do not need to deal with a lot of extra pixels which will not be seen anyway (exact numbers will vary depending on scene complexity but it appears to have been almost a 25-35% improvement).

Like I said though I will look for the documentation on that culling technique tonight. I have too much junk covering my desk now to find it quickly and my bookmarks have become almost worthless (too many damned sites bookmarked). It will likely need some tweaking to work with 3DGS, but it is a pretty simple shader to set up (might even solve Orange Brat's depth problem for prerendered back grounds...at least it should be able to in theory).

thnx a lot for your help and knowledge.. i look forward to hearing more i will also do some research into this.

Just got done emptying half my desk o' junk and haven't found it yet. However when I was looking through the documentation of two of the engines we are evaluating for use at work I decided to poke at the shaders section...

Right now both are recomending using a seperate pass per light using a 2.0 with a 1.4 fall back shader for optimum results on DX9 hardware for per-pixel lighting. Seems as though that might be something to investigate for 3DGS as well.

Ugh - back to the stacks...
________________________________

Did some more looking today - I must have my notes at work right now. However there are a couple articles that quickly glaze over the issue on Gamasutra and GameDev.net. Also when looking online use the keywords "depth test."

As far as chip specific techniques I have been implementing an optimized path for ATI chips the past few days. It uses the HyperZ technology which is ATI only. The premise is similiar, but the ATI cards can process larger chunks at a time than other manufacturers and writing a pipeline for that specific chipset comes in quite handy.

For anyone who is doing a lot of shader programming consider working in fragments as opposed to complete shaders. NVidia and Microsoft both have handy fragment tools which will allow you to assemble predefined shader fragments into complete shaders which aids in the process of developing multiple paths (you will still need to implement switches in C-script...but that is pretty simple).