Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 14 Feb 2007
Offline Last Active Today, 08:39 AM

#5053019 Hi .. how much get paid top 3D engine developper at major company?

Posted by Hodgman on 13 April 2013 - 09:58 PM

A veteran developer could probably aim for $80-$120k in normal circumstances. If you're going for an executive role (CTO, etc), then you'd be looking at the outrageously high salaries.

The numbers are always negotiable. As part of the interview process, they'll ask you how much you want to be earning, and they'll make you an offer. I've had one European company go from an advertised EU30k up to EU50k by asking them to. I've also seen Google go from an offer of AU80k to AU130k because the applicant said they wanted at least 100... I've personally also accepted a low salary, and then received a 20% raise in my first salary review.

Join some of the "jobs in games" type groups on LinkedIn, and you'll receive all the spam from recruiters about vacant positions, which often include salaries.

#5053008 Sorting draw calls when stages are executed multiple times

Posted by Hodgman on 13 April 2013 - 08:37 PM

I also use the multiple buckets approach. Sorting 5 lists is faster than sorting a single list that's 5 times bigger.
AFAIK, you can't use a single list (with a single stage identifier) for repeated stages like shadow mapping, because each light/shadow-stage will have different culling results. You also probably don't want to share items between the shadow list and the g-buffer/forward list, because objects that are 3-draw calls in the latter (3 materials) can be just one draw call in the former (z-only pass disregards material).

In that article, he's talking about what they happened to do on their PS2 games, not necessarily saying that one approach is PS2 era and one is PS3 era. Also, IIRC, GoW didn't use deferred shading, and made little use of shadow mapping - they merge many lights together into a single light for forward shading, which seems incompatible with having shadow maps per light.

#5052731 Shader Model 2.0 runs faster than 3.0 !

Posted by Hodgman on 13 April 2013 - 04:01 AM

I don't know how XNA compiles shaders, but when do it manually, you've got the option to have the compiler spit out the resulting assembly as text, which lets you look at exactly what instructions are being generated.
It's possible that because ps2 is so limited, it's actually using branch instructions, whereas ps3 isn't as instruction limited so the compiler is unrolling the loop and always doing 15 iterations... As well as [branch]/[flatten] statements on some platforms, there's also compiler flags that influence the use of branching vs unrolling.

#5051763 Texture filtering on normal and specular maps

Posted by Hodgman on 10 April 2013 - 03:16 AM

Yeah it looks simply like you're not using mipmapping, so when the texture is shrunk by more than 2x, bilinear filtering (which blends 4 texels) won't be able to stop it from shimmering.

#5051446 Luminance

Posted by Hodgman on 09 April 2013 - 04:23 AM

Your reflectance/pi formula is the Lambertian BRDF, which is off on a completely different tangent.

As above, luminance is a much more general concept -- if you've got some quality of colored (vector/spectral) light, how can we approximate how bright (1d/scalar/monochrome) it will be percieved to be. It's basically just "to greyscale", but with some carefully tuned weights.
You can calculate the luminosity of radiance, irradiance, or even a pixel from an uncalibrated JPEG.

#5051420 Scripting language use in game programming

Posted by Hodgman on 09 April 2013 - 12:39 AM

Keep in mind that 'scripting' just means programming, and scripting languages are just programming languages.
The distinction of which languages fall into the 'scripting language' category is completely arbitrary... Because of this, I like to call them "extension languages" - programming environments embedded into a system to allow that system to be easily and flexibly extended. This includes browsers, which are simple, but can be extended into any kind of "web app" through the use of their embedded JavaScript environment. Game engines are the same - they're a barren framework of idle systems (physics, 3d renderers, etc), that are useless until a game team comes along and uses the engine's programming environment to reshape those systems into a living game world.

In the last 3 console games I've worked on, Lua has been the primary programming language used by the game - almost the entire game is written in Lua.
The game-engine itself is written in C/C++, as are some small parts of the game, as required.

Lua is preferred over C++ because it's a more productive language. Problems require less lines of code to solve, the code is more malleable, and errors are easier to fix.
C++ is a dangerous language that you can only trust in the hands of veterans, and even then, it's all too easy for even your programming veterans to write brittle and buggy code. There's whole classes of bugs/errors that are all too easy to write in C, but are impossible to write in Lua (basically anything to do with memory accesses, lifetimes and corruption).
It's the same reason that C# is so popular in many fields - its often a more productive choice.

This doesn't mean that C++ is bad -- there are many situations where C++ is he most productive language choice, but general gameplay programming is not one of those situations.

#5051396 [Lua] Installing/compiling and usage of Lua in Windows

Posted by Hodgman on 08 April 2013 - 09:53 PM

You can also just include all of Lua's (or LuaJIT's) code directly into your game if you don't want a separate DLL.

Binding libraries are designed to make it easier to glue your C/C++ and Lua code together -- e.g. 1 line of code per function, instead of a dozen.
They also make everything act the same way -- e.g. With manual binding code, you could accidentally pop the wrong argument, or forget to push your return value, or forget some type-safety checks; a binding library ensures every bound function does all these actions in the exact same way.

Also, Lua is *not* an object oriented language (it does not have classes as a built in feature), but it is so flexible that it's very simple to implement OO features like classes and class-inheritance yourself, in Lua code.
Often a binding system will do this for you (implement classes) so that your C++ OO code can be sensibly translated into Lua.

The guys behind the BitSquid engine do actually recommend *not* using a binding library, and instead doing all your binding work manually using the Lua C API. Their reaoning is that these binding systems are often very inefficient, and that they hide a lot of important details, such as big differences between C/C++ and Lua. They say that by doing the binding work yourself, your Engine's Lua API will be much more Lua-oriented, rather than a C++-oriented API that's been shoehorned into Lua.

Personally, I found the existing binding libraries that I surveyed to be way too bloated and inefficient for my tastes, so I wrote an extremely simple one for use in my engine, where most of the time I can bind things to Lua with one line of code, but sometimes need a few more in complex cases - a kind of middle ground between the raw Lua API, and something like luabind..

#5050847 Abstraction layer between Direct3D9 and OpenGL 2.1

Posted by Hodgman on 07 April 2013 - 06:57 AM

I'd recommend not supporting fixed-function pipeline at all, and instead requiring pixel and vertex shaders.
In D3D9, this means that you'd be using vertex declarations instead of FVFs.
Both D3D and GL allow you to store arrays of individual attributes or strided structures of attributes. The optimal memory layout depends on the GPU.
I've not heard of 'D3D compatability mode' in GL...
Both APIs let you have 4-byte vertex attributes (e.g. For colors).

#5050738 Advanced Particle Engine

Posted by Hodgman on 06 April 2013 - 08:11 PM

Usually it will be mostly billboards, with animated rotations, scaling, opacity, tex-coords (to use a different part of an atlas overtrime), etc...
When I worked as an effects programmer, we had a particle editor GUI tool where you could do all his work, rather than hard-coding things. E.g ranges for initial parameters (size, velocity, opacity, etc), curves describing how parameters change over time, what textures to use and atlas layouts, how often different emitters spawn particles (e.g. Smoke and fire would be two different sub-emitters), how particles should be sorted, the shaders to use, the geometry rendering mode (billboards, constrained billboards, ribbons, 3D meshes, etc), external force generators (cylinders/boxes of wind, gravity, etc), and so on. All this would be saved into a 'particle system' file, which the programmers could load/trigger. These files could also be reloaded at runtime to iterate on an effect.

For this kind of effect, yes, I'd just use (soft) billboards. Probably af least 2 different emitters - one with black smoke obscuring the background, and one with orange flames being added over the background. You could also experiment with pre-multiplied alpha blending, which lets you put both additive and alpha blended images into the one texture.
Youd probably have more than 2, so that some particles shoot outwards quickly, while others rise slowly, or mushroom out, etc..

#5050568 the cost of loop in glsl

Posted by Hodgman on 06 April 2013 - 06:37 AM

You don't need a loop to implement vertex skinning - usually you just process your maximum bones per vertex, e.g. 4.
The cost of a loop depends greatly on the GPU itself, rather than GL. Older GPUs will have very high overheads for any kind of branching, while newer ones will be a bit more forgiving. Also, generally if many different items being shaded at once (pixels/verts/etc) all take different paths (if vs else, different number of loop iterations) then those branches will be more expensive than if every item too the same path.

#5050561 Animation blendweight/bone compression

Posted by Hodgman on 06 April 2013 - 05:35 AM

I've seen tricks like this used before -- you can use floor and frac to get the integer and fractional parts of a float.
However, in all the recent skinning implementations I've used, the vertex data has been an integer byte4 of IDs and a fractional/normalized byte4 of weights, which is still half the size of a single float4.

#5050560 Help me with which engine/development tools I could use to make this: (FPS)

Posted by Hodgman on 06 April 2013 - 05:30 AM

I'd suggest the UDK, or making it as a mod for any other FPS game out there - Unreal, Half-Life/Source, FarCry, Quake/Doom, COD, Halo, Battlefield, etc... Then the whole "FPS game" part is already done and you can just focus on your rule set.

#5050489 Textbook question about OOD with odd answer

Posted by Hodgman on 05 April 2013 - 09:21 PM

I'd answer that as 'all of the above'...
"is a" and "has a" are both instances of "knows about", as are "operates on"/"passed as argument"/"makes use of" etc...
All of these are dependencies, which in my eyes is synonymous with 'knowing about'.

#5050455 arbitrary sort function

Posted by Hodgman on 05 April 2013 - 06:23 PM

Std::sort is designed for this - the 3rd parameter is the ordering/comparison function to use.

**sorry no example, I'm posting from my phone, google should have some ;)**

#5049908 Deferred Ambient Light via CubeMap, Edge Artefacts

Posted by Hodgman on 04 April 2013 - 06:45 AM

To be doubly sure, you could use texCUBElod, with a w coordinate of 0.