Saturday, 24 February 2018

Reference for converting GLSL to HLSL - Unity 3d ShaderToy

  • Replace iGlobalTime shader input (“shader playback time in seconds”) with _Time.y
  • Replace iResolution.xy (“viewport resolution in pixels”) with _ScreenParams.xy
  • Replace vec2 types with float2mat2 with float2x2 etc.
  • Replace vec3(1) shortcut constructors in which all elements have same value with explicit float3(1,1,1)
  • Replace Texture2D with Tex2D
  • Replace atan(x,y) with atan2(y,x) <- Note parameter ordering!
  • Replace mix() with lerp()
  • Replace *= with mul()
  • Replace signed integer vector ive2, ivec3, ivec4 with int2, int3,int4
  • Replace iTime with _Time
  • Remove third (bias) parameter from Texture2D lookups
  • mainImage(out vec4 fragColor, in vec2 fragCoord) is the fragment shader function, equivalent to float4 mainImage(float2 fragCoord : SV_POSITION) : SV_Target
  • UV coordinates in GLSL have 0 at the top and increase downwards, in HLSL 0 is at the bottom and increases upwards, so you may need to use uv.y = 1 – uv.y at some point.
  • Replace fract with frac
  • Replace function dFdx with ddx
  • Replace function dfdy with ddy
  • fragCoord in GLSL
    Default Unity shader naming :

    HLSL - Shader Lab in Unity
struct v2f
float2 uv : TEXCOORD0;
float4 vertex : SV_POSITION;

In frag method:

fixed4 frag (v2f i) : SV_Target


   // GLSL - fragCoord, fragCoord.xy = i.vertex.xy



In GLSL we would have method:
void mainImage( out vec4 fragColor, in vec2 fragCoord )


  • Replace mod with fmod

I took some information from

Wednesday, 14 February 2018

Principles for fast and good game development

Above video is a John Romero's presentation in WeAreDevelopers 2017. Just in case you are not sure who is John Romero, he was one of the main creators behind FPS legends such as Doom, Wolfenstein 3D, Quake. 

I personally think is the easiest way to improve skills in any field is to listen the experts. I wasted too much time in the past trying to figure out too many things on my own. I summarize principles that John Romero's team was following. There is not a paradigm in those, however it is good to print them and place them on your office wall as a good reminder to your team.

  1. Polish game as you go
  2. Always maintain shippable code
  3. No prototypes for small game/team
  4. Game can always be run by your team
  5. Have defaults for your core methods, so when someone override it with faulty code other team members won't be blocked by it.
  6. Keep code super simple, refactor as you go
  7. Test properly your code before you commit it, so testers do not have to waste too much time creating bug reports etc.
  8. Write code specifically for the game you are working on, do not try to make your code ready for future games as in the future you will be writing better code as you become more experienced
  9. Run your code after writing few lines of code so you can quickly detect problem if occur 
  10. Write the code is it is very easy to understand by other developers

My personal favourite that is related to point 10

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.