Hi I'm following along on my laptop, which has both intel integrated videocard and an NVidea NVS 5200M card. I'm running windows 10 and vs 2015.

When configure Integrated graphics to be used with win32_handmade.exe it starts up but the cutscene doesn't animate and just shows the first shot slighlty dimmed. So I thought I'd try the NVidea card to see if that helped.
But then the win32_handmade.exe just silently fails. If I step through it using the debugger it breaks with:

Exception thrown at 0x00007FFE8AD13141 (igd10iumd64.dll) in win32_handmade.exe: 0xC0000005: Access violation reading location 0x0000000000000490.

The callstack does not come from handmade-code but is like this bottom to top:
ntdll.dll
kernel32.dll
nvloglv63.dll (5 times)
igd10iumd64.dll (4 times)

The version of C:\Windows\System32\igd10iumd64.dll is 10.18.10.4276

Any ideas?

BTW The GDI path still works at a whooping 260ms per frame. It's only the OpenGL rendering (both ways) that throw the exception.

Sometimes it is expected that system dll's throw various exceptions. They are typically they are caught and processed properly. But because you are using debugger, the execution stops and debugger allows you to examine why exception was thrown. This is called "first chance" exceptions. It's possible to make debugger to ignore these exceptions and continue execution without stopping (Debug -> Exceptions... in main menu).

What happens if you let execution to continue after debugger stops?

What call-stack do you see for threads that are created in handmade code? Switch the active thread and check what's on call-stack, maybe that will give clue at what point this exception happens.

I figured out that it was the
int IntAttribList[] =
{
WGL_DRAW_TO_WINDOW_ARB, GL_TRUE,
WGL_ACCELERATION_ARB, WGL_FULL_ACCELERATION_ARB,
WGL_SUPPORT_OPENGL_ARB, GL_TRUE,
#if HANDMADE_STREAMING
WGL_DOUBLE_BUFFER_ARB, GL_FALSE,
#else
WGL_DOUBLE_BUFFER_ARB, GL_TRUE,
#endif
WGL_PIXEL_TYPE_ARB, WGL_TYPE_RGBA_ARB,
WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB, GL_TRUE,
0,
};

that should be double buffer TRUE otherwise it will through this exception on my machine.



The weird thing was it the time the exception was thrown was kind of random.. sometimes it was on DEBUGFrameEnd sometimes it was on create the gl context itself...

So turn HANDMADE_STREAMING to FALSE in the build works (on my machine)!


I had to make 1 code change though, and that was to initialize the Fader to zero otherwise it would assert invalid fader state. So on line 1915 I added = {}; to initialize the win32_fader to zero.

Yup, I also needed to initialize Fader variable to avoid that assert: https://hero.handmadedev.org/foru...ussion/1134-bug-with-fader-window

We should try to fix these on Monday - someone remind me :) I was thinking we could probably use an environment variable or something so that the no-double-buffer thing only happens by default on my machine (eg., the STREAMING part doesn't get defined otherwise).

- Casey

So in the batchfile start with this maybe and set CASEY_STREAMING to some value on your machine:

@echo off
set Streaming=0
IF "%CASEY_STREAMING%" == "" GOTO BUILD
set Streaming=1
:BUILD

set CommonCompilerFlags=-Od -MTd -nologo -fp:fast -fp:except- -Gm- -GR- -EHa- -Zo -Oi -WX -W4 -wd4201 -wd4100 -wd4189 -wd4505 -wd4127 -wd4244 -Wv:18 -FC -Z7
set CommonCompilerFlags=-DHANDMADE_STREAMING=%Streaming% -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1 -DHANDMADE_WIN32=1 %CommonCompilerFlags%

Another way of doing that is how I'm dealing with building in multiple machines and different Visual Studio versions (and release/debug builds, etc) - inside build.bat I've got something like this

and then I have a separate file env.bat, that isn't pushed to source control, where I can change whatever variables I need. You could easily adapt this for that STREAMING case, only setting the flag in that env.bat :)