diff --git a/cmuratori/hero/cinera__hero.css b/cmuratori/hero/cinera__hero.css index d56033d..c53e8bd 100644 --- a/cmuratori/hero/cinera__hero.css +++ b/cmuratori/hero/cinera__hero.css @@ -19,12 +19,14 @@ #cineraIndex.hero dt, .cineraMenus.hero, -.cineraMenus.hero > .menu .refs, -.cineraMenus.hero > .menu .filter_container, +.cineraMenus.hero > .menu > .refs, +.cineraMenus.hero > .menu > .filter_container, .cineraMenus.hero > .menu > .refs .ref, .cineraMenus.hero > .menu > .filter_container .filter_mode, .cineraMenus.hero > .menu > .credits_container, .cineraMenus.hero > .menu > .credits_container .credit, +.cineraMenus.hero > .menu > .view, +.cineraMenus.hero > .menu > .views_container .view, .cineraPlayerContainer .markers_container.hero, .cineraPlayerContainer .markers_container.hero > .marker { background-color: #161616; @@ -43,12 +45,13 @@ #cineraResults .markerList.hero > .marker, .cineraMenus.hero, -.cineraMenus.hero > .menu .refs, -.cineraMenus.hero > .menu .filter_container, +.cineraMenus.hero > .menu > .refs, +.cineraMenus.hero > .menu > .filter_container, .cineraMenus.hero > .menu > .refs .ref, .cineraMenus.hero > .menu > .filter_container .filter_mode, .cineraMenus.hero > .menu > .credits_container, .cineraMenus.hero > .menu > .credits_container .credit, +.cineraMenus.hero > .menu > .views_container, .cineraPlayerContainer .markers_container.hero, .cineraPlayerContainer .markers_container.hero > .marker { border-color: rgba(255, 255, 255, 0.1); @@ -100,6 +103,8 @@ .cineraMenus.hero > .menu > .filter_container .filter_mode:hover, .cineraMenus.hero > .menu > .filter_container .filter_content.focused, .cineraMenus.hero > .menu > .credits_container .credit *.focused, +.cineraMenus.hero > .menu > .view:hover, +.cineraMenus.hero > .menu > .views_container .view:hover, .cineraPlayerContainer .markers_container.hero > .marker:hover > .cineraContent { background-color: #222; } diff --git a/cmuratori/hero/code/code001_template.html b/cmuratori/hero/code/code001_template.html index c378b78..d7cf17b 100644 --- a/cmuratori/hero/code/code001_template.html +++ b/cmuratori/hero/code/code001_template.html @@ -3,15 +3,15 @@ -
+
- -
+ +
+

+

Handmade Hero Day 001 - Setting Up the Windows Build - by Emmanuel Vaccaro

+
diff --git a/cmuratori/hero/code/code002_template.html b/cmuratori/hero/code/code002_template.html index 679cf5f..12f9a4d 100644 --- a/cmuratori/hero/code/code002_template.html +++ b/cmuratori/hero/code/code002_template.html @@ -3,15 +3,15 @@ -
+
- -
+ + diff --git a/cmuratori/hero/code/code003_template.html b/cmuratori/hero/code/code003_template.html index de9cd40..65c5602 100644 --- a/cmuratori/hero/code/code003_template.html +++ b/cmuratori/hero/code/code003_template.html @@ -3,15 +3,15 @@ -
+
- -
+ + diff --git a/cmuratori/hero/code/code006_template.html b/cmuratori/hero/code/code006_template.html index 743baa8..a40ddd4 100644 --- a/cmuratori/hero/code/code006_template.html +++ b/cmuratori/hero/code/code006_template.html @@ -3,87 +3,87 @@ -
+
- -
-

-

So what's with all that "#define" and "typedef" mumbo-jumbo there?

-

You may have found yourself confused when looking at this code:

- 
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
-    typedef X_INPUT_GET_STATE(x_input_get_state);
-    X_INPUT_GET_STATE(XInputGetStateStub)
-    {
-            return(0);
-    }
-    global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
-    #define XInputGetState XInputGetState_
-

What on God's green earth is happening here? Well, don't despair. It's really quite simple, we just need to unwrap a few things and break it down line by line.

- 
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
-

In C (as well as C++ and Objective C), the first step of the compilation process is a code transformation pass by the preprocessor. As we have covered previously in the series, any command which begins with a "#" is what is known as a preprocessor directive. This is just a command which will tell the preprocessor to do something, such as #include a file. In this case, "#define" is a directive which creates a macro. A macro can be thought of as a code substitution, anytime the processor finds the macro used in your code, it will swap it out for whatever you defined.

-

The two types of macros

-

There are two types of macros, the first type is very simple and defines a constant value:

- 
#define PI 3.14159265359
-

This macro will cause the preprocessor to convert any instances of "PI" in the code directly into "3.14159265359". If we break it down a bit, on the left hand side we have what is called the identifier ("PI"), and on the right hand side we have what is known as the token string ("3.14159265359"). The preprocessor searches the code for the identifier, and replaces it with the token string. This means that the literal text "PI" will no longer appear in our code, having been replaced with "3.14159265359". This can be useful for constant values that we may want to use repeatedly, but not type in full all the time. Note that the preprocessor will not convert PI if it appears in a comment or as part of a longer identifier such as "PieceOfPI".

-

So let's go back to the macro we were looking at earlier.

- 
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
-

It is somewhat more complex and appears to have a function definition on the right for a function called "name". This is the second type of macro, which uses a token string as part of it's definition. - As a simpler, but somewhat different example:

- 
#define ADD(argument1, argument2) argument1 + argument2
-

Looking at this, we can see that it can be broken down into two parts just the same as the previous macro. First, on the left side we have the identifier "ADD(argument1, argument2)". This works similarly to the first kind of macro, but because we have written it like a function, the preprocessor will save whatever it finds in place of "argument1" and "argument2", and then plug those in for where they were found in the token string.

-

For example, if later on in the code we were to type:

- 
int c = ADD(a,b);
-

Our macro would expand this out to:

- 
int c = a + b;
-

So, again we will go back to our original macro, but this time we are going to pair it with its first use:

- 
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
-    typedef X_INPUT_GET_STATE(x_input_get_state);
-

Based on what we learned earlier we can see that the second line will expand out into the following:

- 
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
-

What's a typedef?

-

So that's easy enough to see, but what does 'typedef' mean?

-

In C, typedef declares a different name for a type. This can almost be thought of as similar to #define, but it is limited to type names only and is performed by the compiler instead of the preprocessor.

-

As a basic example, if we were to look at the following code:

- 
typedef char CHARACTER;
-    CHARACTER x;
-

The compiler will treat the type of x as though it were 'char.' Why would we want to do this? Well, because declaring our own types allows us to make use of the compilers strict type checking. This means that if we were to declare a function which took a CHARACTER as the type of one of it's arguments then we would not be able to pass it a char without the compiler warning us about it, even though a CHARACTER was defined as a char and they are both signed one byte values.

- 
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
-

But in the Handmade Hero code, we are using typedef with a function declaration. This declares a function signature as a type. It is important to understand that although we can use that type to declare a function like this:

- 
x_input_get_state _XInputGetState()
-

Due to the rules of C, we are not allowed to then go on to define the function as follows:

- 
//INVALID C CODE FOLLOWS
-    x_input_get_state _XInputGetState()
-    {
-        //Do some things.
-    }
-

We can define a function using our typedef and also declare the same function by using the original function type information, however, this makes the typedef itself unnecessary.

-

Using typedef for function pointers

-

So why are we using a typedef with a function declaration here? Because we are planning on using it to create a function pointer. A function pointer is just what it sounds like, a pointer to a function. The main benefit of function pointers is that they can be treated like variables, that is, they can be reassigned or passed as arguments.

-

So this is how we would use our "x_input_get_state" typedef to declare a function pointer:

- 
x_input_get_state *PointerToXInputGetStateFunction;
-

We can then assign that pointer to any function which matches the signature of x_input_get_state:

- 
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
-    DWORD XInputGetStateStub(DWORD dwUserIndex, XINPUT_STATE *pState);
-    XInputGetStateStub
-    {
-            return(0);
-    }
-    global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
-

Which if we were to unwrap our macros from the original code, is almost exactly what we would have:

- 
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
-    typedef X_INPUT_GET_STATE(x_input_get_state);
-    X_INPUT_GET_STATE(XInputGetStateStub)
-    {
-            return(0);
-    }
-    global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
-

Now all we have left is the last line:

- 
#define XInputGetState XInputGetState_
-

This is another simple macro which will substitute "XInputGetState_" for "XInputGetState" any time we use it in the code. We do this because XInputGetState is a function that has already been declared in xinput.h, and C does not allow us to declare functions multiple times. However, by using the preprocessor, we can type out our code as though we were just using XInputGetState we are actually using a function pointer which will either point to 'XInputGetStateStub' in the case that we are unable to dynamically load in the XInput library, or will point to the correct 'XInputGetState' function as defined by Microsoft in the case that we can load it.

-

Hope that's helped clear some things up for you. Happy Heroing!

-
+ +
+

+

So what's with all that "#define" and "typedef" mumbo-jumbo there?

+

You may have found yourself confused when looking at this code:

+
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
+typedef X_INPUT_GET_STATE(x_input_get_state);
+X_INPUT_GET_STATE(XInputGetStateStub)
+{
+        return(0);
+}
+global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
+#define XInputGetState XInputGetState_
+

What on God's green earth is happening here? Well, don't despair. It's really quite simple, we just need to unwrap a few things and break it down line by line.

+
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
+

In C (as well as C++ and Objective C), the first step of the compilation process is a code transformation pass by the preprocessor. As we have covered previously in the series, any command which begins with a "#" is what is known as a preprocessor directive. This is just a command which will tell the preprocessor to do something, such as #include a file. In this case, "#define" is a directive which creates a macro. A macro can be thought of as a code substitution, anytime the processor finds the macro used in your code, it will swap it out for whatever you defined.

+

The two types of macros

+

There are two types of macros, the first type is very simple and defines a constant value:

+
#define PI 3.14159265359
+

This macro will cause the preprocessor to convert any instances of "PI" in the code directly into "3.14159265359". If we break it down a bit, on the left hand side we have what is called the identifier ("PI"), and on the right hand side we have what is known as the token string ("3.14159265359"). The preprocessor searches the code for the identifier, and replaces it with the token string. This means that the literal text "PI" will no longer appear in our code, having been replaced with "3.14159265359". This can be useful for constant values that we may want to use repeatedly, but not type in full all the time. Note that the preprocessor will not convert PI if it appears in a comment or as part of a longer identifier such as "PieceOfPI".

+

So let's go back to the macro we were looking at earlier.

+
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
+

It is somewhat more complex and appears to have a function definition on the right for a function called "name". This is the second type of macro, which uses a token string as part of it's definition. +As a simpler, but somewhat different example:

+
#define ADD(argument1, argument2) argument1 + argument2
+

Looking at this, we can see that it can be broken down into two parts just the same as the previous macro. First, on the left side we have the identifier "ADD(argument1, argument2)". This works similarly to the first kind of macro, but because we have written it like a function, the preprocessor will save whatever it finds in place of "argument1" and "argument2", and then plug those in for where they were found in the token string.

+

For example, if later on in the code we were to type:

+
int c = ADD(a,b);
+

Our macro would expand this out to:

+
int c = a + b;
+

So, again we will go back to our original macro, but this time we are going to pair it with its first use:

+
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
+typedef X_INPUT_GET_STATE(x_input_get_state);
+

Based on what we learned earlier we can see that the second line will expand out into the following:

+
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
+

What's a typedef?

+

So that's easy enough to see, but what does 'typedef' mean?

+

In C, typedef declares a different name for a type. This can almost be thought of as similar to #define, but it is limited to type names only and is performed by the compiler instead of the preprocessor.

+

As a basic example, if we were to look at the following code:

+
typedef char CHARACTER;
+CHARACTER x;
+

The compiler will treat the type of x as though it were 'char.' Why would we want to do this? Well, because declaring our own types allows us to make use of the compilers strict type checking. This means that if we were to declare a function which took a CHARACTER as the type of one of it's arguments then we would not be able to pass it a char without the compiler warning us about it, even though a CHARACTER was defined as a char and they are both signed one byte values.

+
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
+

But in the Handmade Hero code, we are using typedef with a function declaration. This declares a function signature as a type. It is important to understand that although we can use that type to declare a function like this:

+
x_input_get_state _XInputGetState()
+

Due to the rules of C, we are not allowed to then go on to define the function as follows:

+
//INVALID C CODE FOLLOWS
+x_input_get_state _XInputGetState()
+{
+    //Do some things.
+}
+

We can define a function using our typedef and also declare the same function by using the original function type information, however, this makes the typedef itself unnecessary.

+

Using typedef for function pointers

+

So why are we using a typedef with a function declaration here? Because we are planning on using it to create a function pointer. A function pointer is just what it sounds like, a pointer to a function. The main benefit of function pointers is that they can be treated like variables, that is, they can be reassigned or passed as arguments.

+

So this is how we would use our "x_input_get_state" typedef to declare a function pointer:

+
x_input_get_state *PointerToXInputGetStateFunction;
+

We can then assign that pointer to any function which matches the signature of x_input_get_state:

+
typedef DWORD WINAPI x_input_get_state(DWORD dwUserIndex, XINPUT_STATE *pState);
+DWORD XInputGetStateStub(DWORD dwUserIndex, XINPUT_STATE *pState);
+XInputGetStateStub
+{
+        return(0);
+}
+global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
+

Which if we were to unwrap our macros from the original code, is almost exactly what we would have:

+
#define X_INPUT_GET_STATE(name) DWORD WINAPI name(DWORD dwUserIndex, XINPUT_STATE *pState)
+typedef X_INPUT_GET_STATE(x_input_get_state);
+X_INPUT_GET_STATE(XInputGetStateStub)
+{
+        return(0);
+}
+global_variable x_input_get_state *XInputGetState_ = XInputGetStateStub;
+

Now all we have left is the last line:

+
#define XInputGetState XInputGetState_
+

This is another simple macro which will substitute "XInputGetState_" for "XInputGetState" any time we use it in the code. We do this because XInputGetState is a function that has already been declared in xinput.h, and C does not allow us to declare functions multiple times. However, by using the preprocessor, we can type out our code as though we were just using XInputGetState we are actually using a function pointer which will either point to 'XInputGetStateStub' in the case that we are unable to dynamically load in the XInput library, or will point to the correct 'XInputGetState' function as defined by Microsoft in the case that we can load it.

+

Hope that's helped clear some things up for you. Happy Heroing!

+
diff --git a/cmuratori/hero/code/code007_template.html b/cmuratori/hero/code/code007_template.html index ff22f79..8e6bddb 100644 --- a/cmuratori/hero/code/code007_template.html +++ b/cmuratori/hero/code/code007_template.html @@ -3,41 +3,41 @@ -
+
- -
-

-

Input Cleanup and Fixes

-

This episode starts with some cleanup and fixes to the input handling code from yesterday.

-
    -
  • Windows API often uses a 0 return value to indicate success. Our stubs probably shouldn't return 0.
    • -
  • Windows 8 ships with xinput1_4.dll only. So we need to try each version in turn
    • -
  • When you handle WM_SYSKEY* messages, you lose built in Alt-F4 functionality, and have to reimplement it.
    • -
-

Sound Programming for Games

-

Casey starts with a high level overview of sound programing for games. The key ideas here are that we are allocating - a circular buffer for sound, and the system will play it continually - on a loop. If you haven't worked with circular buffers (or ring buffers) before, much of this code will be confusing. - It's worth taking some time to familiarize yourself with them.

-

Resources:

- -

Working with DirectSound

-

The basic process for initializing DirectSound is as follows:

-
    -
  1. Load the Library - LoadLibrary("dsound.dll")
    2. -
  2. Create a DirectSound object - DirectSoundCreate()
    3. -
  3. Set the Cooperative Level - IDirectSound8::SetCooperativeLevel()
    4. -
  4. "Create" a primary buffer - IDirectSound8::CreateSoundBuffer()
    5. -
  5. Create a secondary buffer
    6. -
  6. Tell DirectSound to start playing the secondary buffer - IDirectSoundBuffer8::Play()
    7. -
-

In the next episode we will look closely at how to fill this buffer and implement it in the game loop.

-
+ +
+

+

Input Cleanup and Fixes

+

This episode starts with some cleanup and fixes to the input handling code from yesterday.

+
    +
  • Windows API often uses a 0 return value to indicate success. Our stubs probably shouldn't return 0.
    • +
  • Windows 8 ships with xinput1_4.dll only. So we need to try each version in turn
    • +
  • When you handle WM_SYSKEY* messages, you lose built in Alt-F4 functionality, and have to reimplement it.
    • +
+

Sound Programming for Games

+

Casey starts with a high level overview of sound programing for games. The key ideas here are that we are allocating + a circular buffer for sound, and the system will play it continually + on a loop. If you haven't worked with circular buffers (or ring buffers) before, much of this code will be confusing. + It's worth taking some time to familiarize yourself with them.

+

Resources:

+ +

Working with DirectSound

+

The basic process for initializing DirectSound is as follows:

+
    +
  1. Load the Library - LoadLibrary("dsound.dll")
    2. +
  2. Create a DirectSound object - DirectSoundCreate()
    3. +
  3. Set the Cooperative Level - IDirectSound8::SetCooperativeLevel()
    4. +
  4. "Create" a primary buffer - IDirectSound8::CreateSoundBuffer()
    5. +
  5. Create a secondary buffer
    6. +
  6. Tell DirectSound to start playing the secondary buffer - IDirectSoundBuffer8::Play()
    7. +
+

In the next episode we will look closely at how to fill this buffer and implement it in the game loop.

+
diff --git a/cmuratori/hero/code/code008_template.html b/cmuratori/hero/code/code008_template.html index 213b368..e77dc93 100644 --- a/cmuratori/hero/code/code008_template.html +++ b/cmuratori/hero/code/code008_template.html @@ -3,57 +3,57 @@ -
+
- -
-

-

DirectSound is Object Oriented

-

DirectSound in an object-oriented API. What does that mean? Casey starts this episode with a discussion of "method" - dispatch through vtables, and why c++ virtual calls are costly.

-

Reviewing DirectSound Inititalization

-

The basic process for initializing DirectSound is as follows:

-
    -
  1. Load the Library - LoadLibrary("dsound.dll")
    2. -
  2. Create a DirectSound object - DirectSoundCreate()
    3. -
  3. Set the Cooperative Level - IDirectSound8::SetCooperativeLevel()
    4. -
  4. "Create" a primary buffer - IDirectSound8::CreateSoundBuffer()
    5. -
  5. Create a secondary buffer
    6. -
  6. Tell DirectSound to start playing the secondary buffer - IDirectSoundBuffer8::Play()
    7. -
-

Playing sounds

-

Audio is a complicated topic, and we start with a discussion of audio "waveforms" and how PCM audio data is encoded in - memory.

-
    -
  • A square wave oscillates between "full-positive" to "full-negative" every half period
    • -
  • A Stereo (2-channel) 16-bit PCM audio buffer is arranged as an array of signed int16 values in (left channel value, - right channel value) pairs
    • -
  • A "sample" sometimes refers to the values for all channels in a sampling period, and sometimes a value for a single - channel. Be careful.
    • -
-

The procedure for writing sound data into a buffer is as follows

-
    -
  1. Figure out where in the buffer you want to start writing, and how much data you want to write - -
    2. -
  2. Acquire a lock on the buffer - IDirectSoundBuffer8::Lock() -
      -
    • Because we are working with a circular buffer, this call will return 1 or 2 writable regions
      • -
    -
    3. -
  3. Write the samples to the buffer
    4. -
  4. Unlock the regions - IDirectSoundBuffer8::Unlock()
    5. -
-

A note on audio latency

-

Audio latency is determined not by the size of the buffer, but by how far ahead of the PlayCursor you write. The optimal - amount of latency is the amount that will cause this frame's audio to coincide with the display of this frame's image. - On most platforms, it is very difficult to ascertain the proper amount of latency. It's an unsolved problem, and games - with need precise AV sync (like Guitar Hero) go to some lengths to achieve it.

-
+ +
+

+

DirectSound is Object Oriented

+

DirectSound in an object-oriented API. What does that mean? Casey starts this episode with a discussion of "method" + dispatch through vtables, and why c++ virtual calls are costly.

+

Reviewing DirectSound Inititalization

+

The basic process for initializing DirectSound is as follows:

+
    +
  1. Load the Library - LoadLibrary("dsound.dll")
    2. +
  2. Create a DirectSound object - DirectSoundCreate()
    3. +
  3. Set the Cooperative Level - IDirectSound8::SetCooperativeLevel()
    4. +
  4. "Create" a primary buffer - IDirectSound8::CreateSoundBuffer()
    5. +
  5. Create a secondary buffer
    6. +
  6. Tell DirectSound to start playing the secondary buffer - IDirectSoundBuffer8::Play()
    7. +
+

Playing sounds

+

Audio is a complicated topic, and we start with a discussion of audio "waveforms" and how PCM audio data is encoded in + memory.

+
    +
  • A square wave oscillates between "full-positive" to "full-negative" every half period
    • +
  • A Stereo (2-channel) 16-bit PCM audio buffer is arranged as an array of signed int16 values in (left channel value, + right channel value) pairs
    • +
  • A "sample" sometimes refers to the values for all channels in a sampling period, and sometimes a value for a single + channel. Be careful.
    • +
+

The procedure for writing sound data into a buffer is as follows

+
    +
  1. Figure out where in the buffer you want to start writing, and how much data you want to write + +
    2. +
  2. Acquire a lock on the buffer - IDirectSoundBuffer8::Lock() +
      +
    • Because we are working with a circular buffer, this call will return 1 or 2 writable regions
      • +
    +
    3. +
  3. Write the samples to the buffer
    4. +
  4. Unlock the regions - IDirectSoundBuffer8::Unlock()
    5. +
+

A note on audio latency

+

Audio latency is determined not by the size of the buffer, but by how far ahead of the PlayCursor you write. The optimal + amount of latency is the amount that will cause this frame's audio to coincide with the display of this frame's image. + On most platforms, it is very difficult to ascertain the proper amount of latency. It's an unsolved problem, and games + with need precise AV sync (like Guitar Hero) go to some lengths to achieve it.

+
diff --git a/cmuratori/hero/code/code009_template.html b/cmuratori/hero/code/code009_template.html index 7a03362..a795420 100644 --- a/cmuratori/hero/code/code009_template.html +++ b/cmuratori/hero/code/code009_template.html @@ -3,67 +3,67 @@ -
+
- -
-

-

The parable of the Game Jam

-

Don't let this happen to you, kids. You need good audio hardware to debug audio code.

-

Debugging the audio code

-

Square vs Sine Waves

-

Because square waves are already pretty harsh, they prevent our ability to diagnose some audio bugs. A Sine wave is a - "purer" tone, and will enhance our ear's ability to pick up on weirdness. The sin function, however, is defined to - return a value between -1 and 1, so we need to talk how to represent fractional numbers on a computer.

-

Fixed-point arithmetic

-

Fixed point is just integer math. We define some number of bits at the low end of our integer to represent the - fractional part of the number, and the remaining bits represent the whole part. Normal addition, subtraction, - multiplication, and division work fine, although we need to be aware of the rounding characteristics of fixed-point - when doing any numeric computation.

-

Fixed-point math was used more widely before computers commonly had floating point hardware. Today every computer, GPU, - and phone has very strong floating point capabilities, and so it is the defacto way to do numerics on a modern computer.

-

Floating-point representation

-

Floating-point is a more complicated (although very rigorously defined) way to represent fractional values. It - approaches the problem by dividing the available bits into:

-
    -
  • Sign bit
    • -
  • Exponent
    • -
  • Mantissa
    • -
-

Such that the value represented is given by (sign)(mantissa * 2^exponent). This allows us to preserve a consistent - number of bits of precision (like "significant figures" from your physics class), given by the size of the mantissa, - regardless of the scale of our numbers, given by the exponent. This means that values representable by floating point - will be more densely packed near zero, and more sparse near the limits.

-

Floating Point values come in a few different precisions: float (single-precision, 32-bit), double - (double-precision, 64-bit), and long double (128-bit). We will rely on single-precision floats almost exclusively, - because they are good enough, and often we can operate on them twice as quickly as doubles.

-

Generating a sine-wave test tone

-

For the test code, we use the c standard sinf function. It's defined in math.h. Its defined to accept a float - "angle" and return a float in the range [-1.0f, 1.0f]. The angle is a function of:

-
    -
  • How many samples we have written in total. Call it RunningSampleIndex.
    • -
  • The sampling frequency
    • -
  • The frequency of the tone we want to play (200-500 Hz is a good range for testing).
    • -
-

When we set the tone frequency, we calculate its period in samples, and call it WavePeriod.

-

The "angle" is then given by 2.0f*PI*((float)RunningSampleIndex / (float)WavePeriod).

-

The SampleValue is given by the sinf(angle) * Volume.

-

Smoothing the waveform on frequency change

-

When you change the frequency with the current code, you'll end up with an artifact. To combat this, you need to track - an additional value in your synth, basically your progress through the period of the wave, here called tSine. - Incrementally accumulate it per sample written:

- 
tSine += 2.0f*Pi32*1.0f/(float)WavePeriod // tSine = 2*Pi*how many "WavePeriods" we've played since we started
-

Then just use it as the angle for the SampleValue calculation.

- 
SampleValue = sinf(tSine) * ToneVolume;
-

Additional Fixes

-
    -
  • There is yet another XInput version that may be the only one available on some Windows 8 installs. xinput9_1_0.dll. - Add it to the chain when loading libs.
    • -
  • Bitshifting to divide will give you unexpected results for negative numbers. Use actual divide instead.
    • -
-
+ +
+

+

The parable of the Game Jam

+

Don't let this happen to you, kids. You need good audio hardware to debug audio code.

+

Debugging the audio code

+

Square vs Sine Waves

+

Because square waves are already pretty harsh, they prevent our ability to diagnose some audio bugs. A Sine wave is a + "purer" tone, and will enhance our ear's ability to pick up on weirdness. The sin function, however, is defined to + return a value between -1 and 1, so we need to talk how to represent fractional numbers on a computer.

+

Fixed-point arithmetic

+

Fixed point is just integer math. We define some number of bits at the low end of our integer to represent the + fractional part of the number, and the remaining bits represent the whole part. Normal addition, subtraction, + multiplication, and division work fine, although we need to be aware of the rounding characteristics of fixed-point + when doing any numeric computation.

+

Fixed-point math was used more widely before computers commonly had floating point hardware. Today every computer, GPU, + and phone has very strong floating point capabilities, and so it is the defacto way to do numerics on a modern computer.

+

Floating-point representation

+

Floating-point is a more complicated (although very rigorously defined) way to represent fractional values. It + approaches the problem by dividing the available bits into:

+
    +
  • Sign bit
    • +
  • Exponent
    • +
  • Mantissa
    • +
+

Such that the value represented is given by (sign)(mantissa * 2^exponent). This allows us to preserve a consistent + number of bits of precision (like "significant figures" from your physics class), given by the size of the mantissa, + regardless of the scale of our numbers, given by the exponent. This means that values representable by floating point + will be more densely packed near zero, and more sparse near the limits.

+

Floating Point values come in a few different precisions: float (single-precision, 32-bit), double + (double-precision, 64-bit), and long double (128-bit). We will rely on single-precision floats almost exclusively, + because they are good enough, and often we can operate on them twice as quickly as doubles.

+

Generating a sine-wave test tone

+

For the test code, we use the c standard sinf function. It's defined in math.h. Its defined to accept a float + "angle" and return a float in the range [-1.0f, 1.0f]. The angle is a function of:

+
    +
  • How many samples we have written in total. Call it RunningSampleIndex.
    • +
  • The sampling frequency
    • +
  • The frequency of the tone we want to play (200-500 Hz is a good range for testing).
    • +
+

When we set the tone frequency, we calculate its period in samples, and call it WavePeriod.

+

The "angle" is then given by 2.0f*PI*((float)RunningSampleIndex / (float)WavePeriod).

+

The SampleValue is given by the sinf(angle) * Volume.

+

Smoothing the waveform on frequency change

+

When you change the frequency with the current code, you'll end up with an artifact. To combat this, you need to track + an additional value in your synth, basically your progress through the period of the wave, here called tSine. + Incrementally accumulate it per sample written:

+ 
tSine += 2.0f*Pi32*1.0f/(float)WavePeriod // tSine = 2*Pi*how many "WavePeriods" we've played since we started
+

Then just use it as the angle for the SampleValue calculation.

+ 
SampleValue = sinf(tSine) * ToneVolume;
+

Additional Fixes

+
    +
  • There is yet another XInput version that may be the only one available on some Windows 8 installs. xinput9_1_0.dll. + Add it to the chain when loading libs.
    • +
  • Bitshifting to divide will give you unexpected results for negative numbers. Use actual divide instead.
    • +
+
diff --git a/cmuratori/hero/code/code010_template.html b/cmuratori/hero/code/code010_template.html index 8889de4..4ffaaf4 100644 --- a/cmuratori/hero/code/code010_template.html +++ b/cmuratori/hero/code/code010_template.html @@ -3,65 +3,65 @@ -
+
- -
-

-

Today we look at some techniques to get basic timing information from your running game. Timing, like everything, is - more complicated than it first appears.

-

A Couple of ideas of time:

-
    -
  • Wall clock time - time as it passes in the real world. Measured in seconds.
    • -
  • Processor time - how many cycles? this is related to wall clock time by processor frequency, but for a long time now - frequency varies a lot and quickly.
    • -
-

Wall Clock Time

-

The Windows platform attempts to provide us with some tools for high precision timing, but as it is a complicated topic, - there are some gotchas.

-

QueryPerformanceFrequency() returns a - LARGE_INTEGER number of counts/sec. It's guaranteed to be stable, so you can get away with just calling it once at - startup. QueryPerformanceCounter() returns - a LARGE_INTEGER number of counts.

-

So, dividing counter/freq will give you a number of seconds since some unknown time in the past. More useful would be - (counter - last_counter)/freq. This will allow us to get an elapsed time since some known point in the past. However, - almost anything we want to time should be less than a second, and since this is an integer divide, anything between 1 - and 0 seconds will return 0. Not super useful. So, we instead multiply the elapsed counts by 1000 to get our formula - to get to elapsed milliseconds.

- 
elapsedMs = (1000*(counter - last_counter)) / freq
-

To get instantaneous frames per second, we can just divide without changing to milliseconds:

- 
fps = freq / (counter - last_counter)
-

Important ideas:

-
    -
  • To time a frame, only query the timer once per frame, otherwise your timer will leave out time between last frame's - end and this frame's start.
    • -
-

Processor Time

-

Every x86 family proccessor has a Timestamp Counter (TSC), which - increments with every clock cycle since it was reset. RDTSC is a processor intruction that reads the TSC into general - purpose registers.

-

For processors before Sandy Bridge but after dynamic clocking, RDTSC gave us actual clocks, but it was difficult to - correlate to wall time because of the variable frequency. Since Sandy Bridge, they give us "nominal" clocks, which - is to say the number of clocks elapsed at the chip's nominal frequency. These should correlate closely to wall clock - time, but make tracking the "number of cycles" notion of processor time more difficult.

-

RDTSC is usually exposed in a compiler intrinsic. Check the docs for your compiler.

-

Resources:

- -

Other topics

-

Casey had to cover a couple of new corners of C in order to work with the techniques above.

-

Union types

-

Union types are a C feature that let you superimpose a number of different - layouts over the same chunk of memory. For example LARGE_INTEGER, the return type of the QueryPerf calls. I can treat - it as an int64 by accessing its QuadPart, or as two int32s via HighPart and LowPart.

-

Compiler Intrinsics

-

An intrinsic is a compiler-specific extension that allows direct - invocation of some processor instruction. They generally need to be extensions to the compiler so they can avoid all - the expensive niceties compilers have to afford functions.

-
+ +
+

+

Today we look at some techniques to get basic timing information from your running game. Timing, like everything, is + more complicated than it first appears.

+

A Couple of ideas of time:

+
    +
  • Wall clock time - time as it passes in the real world. Measured in seconds.
    • +
  • Processor time - how many cycles? this is related to wall clock time by processor frequency, but for a long time now + frequency varies a lot and quickly.
    • +
+

Wall Clock Time

+

The Windows platform attempts to provide us with some tools for high precision timing, but as it is a complicated topic, + there are some gotchas.

+

QueryPerformanceFrequency() returns a + LARGE_INTEGER number of counts/sec. It's guaranteed to be stable, so you can get away with just calling it once at + startup. QueryPerformanceCounter() returns + a LARGE_INTEGER number of counts.

+

So, dividing counter/freq will give you a number of seconds since some unknown time in the past. More useful would be + (counter - last_counter)/freq. This will allow us to get an elapsed time since some known point in the past. However, + almost anything we want to time should be less than a second, and since this is an integer divide, anything between 1 + and 0 seconds will return 0. Not super useful. So, we instead multiply the elapsed counts by 1000 to get our formula + to get to elapsed milliseconds.

+ 
elapsedMs = (1000*(counter - last_counter)) / freq
+

To get instantaneous frames per second, we can just divide without changing to milliseconds:

+ 
fps = freq / (counter - last_counter)
+

Important ideas:

+
    +
  • To time a frame, only query the timer once per frame, otherwise your timer will leave out time between last frame's + end and this frame's start.
    • +
+

Processor Time

+

Every x86 family proccessor has a Timestamp Counter (TSC), which + increments with every clock cycle since it was reset. RDTSC is a processor intruction that reads the TSC into general + purpose registers.

+

For processors before Sandy Bridge but after dynamic clocking, RDTSC gave us actual clocks, but it was difficult to + correlate to wall time because of the variable frequency. Since Sandy Bridge, they give us "nominal" clocks, which + is to say the number of clocks elapsed at the chip's nominal frequency. These should correlate closely to wall clock + time, but make tracking the "number of cycles" notion of processor time more difficult.

+

RDTSC is usually exposed in a compiler intrinsic. Check the docs for your compiler.

+

Resources:

+ +

Other topics

+

Casey had to cover a couple of new corners of C in order to work with the techniques above.

+

Union types

+

Union types are a C feature that let you superimpose a number of different + layouts over the same chunk of memory. For example LARGE_INTEGER, the return type of the QueryPerf calls. I can treat + it as an int64 by accessing its QuadPart, or as two int32s via HighPart and LowPart.

+

Compiler Intrinsics

+

An intrinsic is a compiler-specific extension that allows direct + invocation of some processor instruction. They generally need to be extensions to the compiler so they can avoid all + the expensive niceties compilers have to afford functions.

+
diff --git a/cmuratori/hero/code/code012_template.html b/cmuratori/hero/code/code012_template.html index d404923..c4efed0 100644 --- a/cmuratori/hero/code/code012_template.html +++ b/cmuratori/hero/code/code012_template.html @@ -3,26 +3,26 @@ -
+
- -
-

-

Key ideas:

-
    -
  • Sound is necessarily temporal. You can drop a frame of video and the user probably won't notice, but if your audio - drops out, they probably will notice.
    • -
  • Sound bufers are small, and not all platforms will require us to deal with circular buffers. So one option is to do - a buffer copy per frame and present the game with a contiguous block of memory. This should be cheap enough.
    • -
  • Much like the bitmap, allocate plenty of space for a sound buffer at startup, and reuse it each frame.
    • -
-

C features

-

alloca

-

alloca is a compiler feature that allows for dynamic allocation on the stack. Much was learned and discussed, but - it should be noted that the function is deprecated and probably shouldn't be used in shipping code.

-
+ +
+

+

Key ideas:

+
    +
  • Sound is necessarily temporal. You can drop a frame of video and the user probably won't notice, but if your audio + drops out, they probably will notice.
    • +
  • Sound bufers are small, and not all platforms will require us to deal with circular buffers. So one option is to do + a buffer copy per frame and present the game with a contiguous block of memory. This should be cheap enough.
    • +
  • Much like the bitmap, allocate plenty of space for a sound buffer at startup, and reuse it each frame.
    • +
+

C features

+

alloca

+

alloca is a compiler feature that allows for dynamic allocation on the stack. Much was learned and discussed, but + it should be noted that the function is deprecated and probably shouldn't be used in shipping code.

+
diff --git a/cmuratori/hero/code/code021_template.html b/cmuratori/hero/code/code021_template.html index 472363b..58e5a79 100644 --- a/cmuratori/hero/code/code021_template.html +++ b/cmuratori/hero/code/code021_template.html @@ -3,16 +3,16 @@ -
+ + + diff --git a/cmuratori/hero/code/code118_template.html b/cmuratori/hero/code/code118_template.html index 96fca82..585cf76 100644 --- a/cmuratori/hero/code/code118_template.html +++ b/cmuratori/hero/code/code118_template.html @@ -3,34 +3,34 @@ -
+
- -
-

-

Masking the write:

-

In SIMD, doing operations "4-wide" means that one wide (packed) operation operates on four pixels. So there's no - difference between doing an operation on one pixel or two or three or four, except when it comes to reading and - writing.

-

The way we can make sure we only write the pixels we're actually operating on meaningfully is by masking out the ones we - aren't. Instead of doing a conditional check every loop, we want to build a mask that's filled with 1s in the places - where we'll keep the pixels, and 0s in the places where we'll throw out the pixels. - If we're operating on four pixels at once and we're hanging 2 off the edge, the mask might look like:

-

[0x00000000,0x00000000,0xFFFFFFFF,0xFFFFFFFF]

-

By doing a bitwise AND with the pixel data we generate, we can mask out the values that are invalid, since the zeroes in - the mask will knock out any bits set in our data. Likewise, the 1s will ensure any values we want to keep will remain in - place.

-

We still need to preserve the destination how it was, and the easiest way to do that is to remember what the destination - looked like before, and use those values wherever we knocked out values in our data. So we generate an inverted mask - that might look something like:

-

[0xFFFFFFFF,0xFFFFFFFF,0x00000000,0x00000000]

-

Using the same AND technique, we can grab out the destination values that should remain unchanged. Then, we can combine - that with the set of valid pixel values we generated using the other mask using a bitwise OR. Since the places where the - two sets of values overlap are set to 0s in one of them, the data will effectively just be copied from one onto the - other with no interference.

-
+ +
+

+

Masking the write:

+

In SIMD, doing operations "4-wide" means that one wide (packed) operation operates on four pixels. So there's no + difference between doing an operation on one pixel or two or three or four, except when it comes to reading and + writing.

+

The way we can make sure we only write the pixels we're actually operating on meaningfully is by masking out the ones we + aren't. Instead of doing a conditional check every loop, we want to build a mask that's filled with 1s in the places + where we'll keep the pixels, and 0s in the places where we'll throw out the pixels. + If we're operating on four pixels at once and we're hanging 2 off the edge, the mask might look like:

+

[0x00000000,0x00000000,0xFFFFFFFF,0xFFFFFFFF]

+

By doing a bitwise AND with the pixel data we generate, we can mask out the values that are invalid, since the zeroes in + the mask will knock out any bits set in our data. Likewise, the 1s will ensure any values we want to keep will remain in + place.

+

We still need to preserve the destination how it was, and the easiest way to do that is to remember what the destination + looked like before, and use those values wherever we knocked out values in our data. So we generate an inverted mask + that might look something like:

+

[0xFFFFFFFF,0xFFFFFFFF,0x00000000,0x00000000]

+

Using the same AND technique, we can grab out the destination values that should remain unchanged. Then, we can combine + that with the set of valid pixel values we generated using the other mask using a bitwise OR. Since the places where the + two sets of values overlap are set to 0s in one of them, the data will effectively just be copied from one onto the + other with no interference.

+
diff --git a/cmuratori/hero/code/code124_template.html b/cmuratori/hero/code/code124_template.html index c17e3b8..b5372a6 100644 --- a/cmuratori/hero/code/code124_template.html +++ b/cmuratori/hero/code/code124_template.html @@ -3,26 +3,26 @@ -
+
- -
-

-

Semaphores:

-

A semaphore is essentially a number that the operating system keeps track of, that can be incremented and decremented. - When you wait for a semaphore, you're essentially telling the OS to let you know when the semaphore number becomes - greater than zero. Once it does, then the Wait() call will return and the thread can do something. Calling - ReleaseSemaphore(), maybe a little counterintuitively, increments the semaphore, allowing any threads waiting on it to - continue working. (Thus, it releases those threads to do work). It doesn't actually change the state of the semaphore - other than making the number go up. The semaphore number goes down when a thread has successfully Wait()ed for the - semaphore. In cases like the one demonstrated on stream, this usually means the semaphore number will go up/down really - fast and stick close to 0 as most of the time the threads are waiting for the semaphore to increment.

-

What this allows you to do is tell several threads at once that some work is ready without having to signal to each one - individually. As long as each one is waiting on the same semaphore object, they'll all know when there's more work to be - done.

-
+ +
+

+

Semaphores:

+

A semaphore is essentially a number that the operating system keeps track of, that can be incremented and decremented. + When you wait for a semaphore, you're essentially telling the OS to let you know when the semaphore number becomes + greater than zero. Once it does, then the Wait() call will return and the thread can do something. Calling + ReleaseSemaphore(), maybe a little counterintuitively, increments the semaphore, allowing any threads waiting on it to + continue working. (Thus, it releases those threads to do work). It doesn't actually change the state of the semaphore + other than making the number go up. The semaphore number goes down when a thread has successfully Wait()ed for the + semaphore. In cases like the one demonstrated on stream, this usually means the semaphore number will go up/down really + fast and stick close to 0 as most of the time the threads are waiting for the semaphore to increment.

+

What this allows you to do is tell several threads at once that some work is ready without having to signal to each one + individually. As long as each one is waiting on the same semaphore object, they'll all know when there's more work to be + done.

+
diff --git a/miotatsu/riscy/cinera__riscy.css b/miotatsu/riscy/cinera__riscy.css index 106e84e..1f623eb 100644 --- a/miotatsu/riscy/cinera__riscy.css +++ b/miotatsu/riscy/cinera__riscy.css @@ -3,12 +3,14 @@ #cineraIndex.riscy dt, .cineraMenus.riscy, -.cineraMenus.riscy > .menu .refs, -.cineraMenus.riscy > .menu .filter_container, +.cineraMenus.riscy > .menu > .refs, +.cineraMenus.riscy > .menu > .filter_container, .cineraMenus.riscy > .menu > .refs .ref, .cineraMenus.riscy > .menu > .filter_container .filter_mode, .cineraMenus.riscy > .menu > .credits_container, .cineraMenus.riscy > .menu > .credits_container .credit, +.cineraMenus.riscy > .menu > .view, +.cineraMenus.riscy > .menu > .views_container .view, .cineraPlayerContainer .markers_container.riscy, .cineraPlayerContainer .markers_container.riscy > .marker { background-color: #EEE; @@ -27,12 +29,13 @@ #cineraResults .markerList.riscy > .marker, .cineraMenus.riscy, -.cineraMenus.riscy > .menu .refs, -.cineraMenus.riscy > .menu .filter_container, +.cineraMenus.riscy > .menu > .refs, +.cineraMenus.riscy > .menu > .filter_container, .cineraMenus.riscy > .menu > .refs .ref, .cineraMenus.riscy > .menu > .filter_container .filter_mode, .cineraMenus.riscy > .menu > .credits_container, .cineraMenus.riscy > .menu > .credits_container .credit, +.cineraMenus.riscy > .menu > .views_container, .cineraPlayerContainer .markers_container.riscy, .cineraPlayerContainer .markers_container.riscy > .marker { border-color: rgba(246, 178, 26, 0.8); @@ -85,6 +88,8 @@ .cineraMenus.riscy > .menu > .filter_container .filter_content.focused, /*.cineraMenus.riscy > .menu > .credits_container .credit *:hover,*/ .cineraMenus.riscy > .menu > .credits_container .credit *.focused, +.cineraMenus.riscy > .menu > .view:hover, +.cineraMenus.riscy > .menu > .views_container .view:hover, .cineraPlayerContainer .markers_container.riscy > .marker:hover > .cineraContent { background-color: #FFF8E7; }