is presently its sole maintainer,
You can support him:
Correction about StretchDIBits()/BitBlt()
Writing our custom BitmapMemory allocator. (Note about aligned/unaligned byte access)
Basic math to determine the bytes needed for BitmapMemorySize. 'Width * Height * BytesPerPixel'
Description and usage of VirtualAlloc(), the WIN32 memory allocation function we will be using
Making sure we free any allocated memory before we resize, using VirtualFree()
Aside about VirtualProtect(), useful to prevent stale pointers and "use after free" bugs
Step through of Win32ResizeDIBSection()
Changing Win32UpdateWindow() to use BitmapMemory
Adding Bitmap dimensions as global variables (temporarily)
Setting Bitmap Width/Height and using them in Win32ResizeDIBSection()
Setting Window Width/Height in Win32UpdateWindow()
Notes on storing a 2D image inside a 1D "block" of memory. Pitch/Stride.
Setting biHeight to a negative number to ensure the window framebuffer uses a top-down coordinate system with its origin in the top left corner
Note on getting MSVC to give full paths to files in the build output log. (Add -FC to build.bat) Allows emacs to jump between build errors
BUGFIX: Win32UpdateWindow() definition change
Drawing pixels into the bitmap
Adding typedefs for specific type sizes
Casting void* to different size types to make pointer arithmetic simpler for bitmap access
Pixel component layout in memory on Win32. Flipped to read RGB when viewed in the memory registers.
Drawing pixel colors based on the X and Y
Moving bitmap rendering into RenderWeirdGradient()
Adding animation and switching GetMessageA() for PeekMessage() so that Windows doesn't block
Making sure we handle WM_QUIT inside our PeekMessage() loop
Adding XOffset/YOffset variables to the main loop, ++1 them each time through the loop
BUGFIX: Adding our window blitting function (Win32UpdateWindow()) to the main loop, so the bitmap will blit each time through the loop
Changing "WindowHandle" to "Window" and "WindowRect" to "ClientRect"
Changing DrawWeirdGradient() to use a 32-bit pointer and write each pixel in one call using bitwise operations
Verification of lack of memory leaks
TOTAL SYSTEM MELTDOWN
Start of Q&A
Is there a reason you prefer using 0 instead of NULL?
Clarification about sized typedefs
What would happen if you called malloc() instead of VirtualAlloc()?
What's the difference between malloc and new and HeapAlloc()?
Do you think you could go as slow as you did previous days in the future?
Are we going to use Valgrind in the future?
Is the project going to take 2 years?
Can you explain why we are using the user32.lib and gdi.lib in the build.bat?
Would there be a significant performance increase if we allocated the memory for the bitmap on the stack instead of the heap?
Do you know what the PAGE_WRITECOPY Memory Protection flag does?
About bytes per pixel and bitmap memory layout. Pitch/Stride. Pitch is byte offset between rows.
You mentioned xxBBGGRR because of little endian, why was the blue channel set in this case instead of the padding?
Could the padding byte be used as an alpha channel here?
Why are we having a wait symbol on the window?
Could you explain the offset to X and Y?
About the global_variables and the static keyword
Static doesn't give you zero on initialization?
Do you consider overflowing numbers to be a good coding practice?
Note about statics and extern global variables being initialized to zero