+1 for cascaded shadow maps. There is an alternative called parallel split shadow maps (PSSM), but while they utilize the shadow map more efficiently, they lack couple of interesting properties of CSM - if you cache shadow maps in CSM, you can update them progressively, i.e. only update them every few frames to improve performance, or only render static objects to the map and update slices as the camera moves. Also unlike PSSM, you can snap them to shadow texels in world space to avoid shimmering artifacts. CSM has been used for quite long time in many shipped titles to cover large shadow range, so it's quite a safe way to go.

To me it sounds like you need to write what you have been doing in the past regarding software development (have some hobby projects? Participated in some game industry events? Relevant internships?) and why you are interested in pursuing a career as a software developer in the game industry? Do you have a specific field of interest (physics, graphics, gameplay/AI, etc)? What are you exited about in software engineering? What your vision is for the future development in the software development area you are planning to pursue? I think you need to convince them this is something you truly want and have somewhat realistic expectations instead of being merely a dreamer who hasn't bothered to do anything to reach those dreams.

Seems like I have now a side project to the data driven effect system: generic expression parser. As the result of some research on the topic it seems that the common way to implement this is to convert infix notation to more evaluation friendly Reverse Polish Notation using Shunting-yard algorithm.

In my spare time I'm currently working on a data driven effect system for Spin-X, where you can define effect templates in XML.These XML templates define effect parameters (textures, colors & other constants), render & sampler states, mapping of these parameters to shaders and which shaders are used in which render pass & for which vertex declaration. This is abit like FX files but more flexible. Currently all state setup for rendering is done in C++ in Spin-X, so the idea is to have flexible enough system that majority of this boilerplate code could be defined in XML instead and thus be technical artist accessible as well. This system is also potentially more efficient than the current C++ setup code as well since it can take advantage of continuous register usage due to its data driven nature. The effect system can then be used for defining materials, post effects, etc. The system is working otherwise, but I need to implement a simple expression evaluator to feed shader constant data from effect parameters (e.g. evaluate simple expressions like "color*brightness") and have support for some functions (e.g. "degamma(color)*brightness").

edit: Finally got it running \o/


Cheers, Jarkko

While ago I had an idea for DRM system where the code would be instrument by the developer with a simple DRM macro (in non-highly performance critical places). This macro would add some self-contained encrypted DRM check (i.e. no API or function calls cracker could circumvent) which essentially gets your CPUID and uses that to generate a unique check value for that DRM macro instance (e.g. by using __LINE__ as a key within the macro). Each instance of the DRM check code is decrypted in fly every time it's executed so there's no decrypted version of the game in memory that cracker could capture. The decryption code is very tiny so it's not easy to locate it in code and this code can also vary per DRM check instance. The decryption is also written in C++ so generated op codes for decryption can vary significantly per DRM check instance as it's embedded to the surrounding code. The DRM check code decryption and DRM check itself are also fast so it's not really a performance issue as long as you don't instrument std::vector::operator[] equivalent function or something like that. You could essentially do hundreds of DRM checks per frame if you wanted without notable performance impact, though these checks should be distributed more along the line of game progression and different branches of logic to make it more difficult to bump into them. They can also be non-deterministic (e.g. per CPUID) making it more difficult to find them all.

User would need to register the application with a DRM server only once which returns bunch of DRM check values (one for each instance of the DRM macro) for user's CPUID. These check values are then injected into the exe by the registration app and those values are used by the DRM macros. The DRM check values reside in static store, so cracker can't find the DRM code locations simply by checking where the codes were injected. The DRM code encryption further hides any op codes (e.g. CPUID) or memory addresses cracker could search in memory to find the check locations, so all the DRM checks would need to be removed individually by playing the game and hitting each one. These macros would make it very easy to litter the code with thousands of DRM checks all over the code base making the removal very taunting and time consuming task.

I did some prototyping long ago for the DRM code decrypting. This can be done completely in C++ and was pretty easy to do, so it doesn't require any magic asm tricks or anything like that. This DRM system essentially relies that you can't easily find the DRM checks in binary distributable/memory of the app and that CPUID read can't be circumvented.

You can register the game say 10 times with your password before having to contact support. So if you update your PC's CPU it should be ok. Of course you could register the app for your friend's PC, but the idea is just to prevent mass distribution of a pirated exe.

So what do you think? Any obvious loopholes? Since this is just client side DRM you would of course still need figure out how to make things secure in server side that someone doesn't steal the DRM check value generator.


Cheers, Jarkko