I'm running an AMD A10 w 4 cores and VC 2013. I'm able to get Day 131 to compile but it crashes in DrawRectangleQuickly. I switch it over to DrawRectangleSlowly and it appears not to crash but prints the pink background *very slowly* and pegs the CPU.
With time, I can probably trace back the source through the debugger, but I just wanted to check if anyone has tried this on AMD processor yet. I might try this on a different machine myself just to see if there is any difference.
With time, I can probably trace back the source through the debugger, but I just wanted to check if anyone has tried this on AMD processor yet. I might try this on a different machine myself just to see if there is any difference.
So at what line does it crashes? I think it should be something pretty obvious.
Line 663, handmade_render_group.cpp:
__m128i SampleA = _mm_setr_epi32(*(uint32 *)(TexelPtr0),
*(uint32 *)(TexelPtr1),
*(uint32 *)(TexelPtr2),
*(uint32 *)(TexelPtr3));
TexelPtr0 and TexelPtr3 are both null, I expect the other two are invalid values. The arguments to the function all seem to have something in them except TextureMemory is null and Buffer has been optimized away.
__m128i SampleA = _mm_setr_epi32(*(uint32 *)(TexelPtr0),
*(uint32 *)(TexelPtr1),
*(uint32 *)(TexelPtr2),
*(uint32 *)(TexelPtr3));
TexelPtr0 and TexelPtr3 are both null, I expect the other two are invalid values. The arguments to the function all seem to have something in them except TextureMemory is null and Buffer has been optimized away.
If you compile in release mode, then look in assembly what instruction crashes.
If you want to see what crashes in source code then compile in debug mode. Looking at variable values in release mode is not reliable.
If you want to see what crashes in source code then compile in debug mode. Looking at variable values in release mode is not reliable.
I think you misunderstood me. You don't need to turn off optimizations to see assembly. If you have /O2 then look at disassembly in debugger when process crashes. If process crashes with /Od then you can look at source (and variable values) to understand what crashed.
If it isn't loading assets then either you didn't put them in correct folder, or you did not set up correct startup folder for project (it should point to "data"). Are you using Visual Studio IDE to build? Then you need to go in project properties and setup process working directory in debugger settings.
If it isn't loading assets then either you didn't put them in correct folder, or you did not set up correct startup folder for project (it should point to "data"). Are you using Visual Studio IDE to build? Then you need to go in project properties and setup process working directory in debugger settings.
I think I have it fixed, or nearly so. The assets folder gets put into the "build" directory and the program properly picks them up now and doesn't crash.
I'm not using VS to build. I'm using the batch file and it works fine.
I mistook the assets folder for a test suite on the website, because it was named "test assets", so did not download it. I didn't mean to suggest optimizations need to be turned off to see the assembly. It was just something I did to try to see variables in the debugger that the debugger claimed to have optimized out. In any case, debugging should generally be done with compiler optimizations off anyway.
I'm not using VS to build. I'm using the batch file and it works fine.
I mistook the assets folder for a test suite on the website, because it was named "test assets", so did not download it. I didn't mean to suggest optimizations need to be turned off to see the assembly. It was just something I did to try to see variables in the debugger that the debugger claimed to have optimized out. In any case, debugging should generally be done with compiler optimizations off anyway.
Check out Day 1 video starting with 48:40 time "Debug with Visual Studio". Casey explains there how to set up path for current working directory when running result of his build.bat.
Yes, that's very helpful for debugging with the default build/runtime development system Casey setup.
I'm building a bit differently. Since asset loading is a runtime thing, it works just as well if the assets are placed in the build tree, which is where they are going to go anyway on release. Doing this amounts to be the same thing as keeping a "data" directory in your source tree, but it enables you to run the executable directly from the commandline or file explorer as well as from within the debugger - just like a user would do with a released product.
So, for reference, the discussion of asset loading also covered is in several different places on top of Day 1, which you mentioned.
Day 15 (start)
Day 35 (2:30)
Day 131 (start)
It's likely this topic will be dealt with again when Casey's build system is revised to make a release candidate.
The asset zipfile is separate from the source code zips, and I initially found that confusing because of its name (e.g. test_assets) which led me to think they were a bundle of unit tests, and not critical to program execution.
I'm finding if you want to load a new source tree every day, it's a bit easier to setup your assets in a single absolute location that does not change from day to day, independent of whatever source tree you happen to be using.
Right now I just have them in the build directory, and rename whatever source tree I am compiling from to "handmade". When I build a new source tree, the binaries get refreshed, but the assets stay the same.
I'm building a bit differently. Since asset loading is a runtime thing, it works just as well if the assets are placed in the build tree, which is where they are going to go anyway on release. Doing this amounts to be the same thing as keeping a "data" directory in your source tree, but it enables you to run the executable directly from the commandline or file explorer as well as from within the debugger - just like a user would do with a released product.
So, for reference, the discussion of asset loading also covered is in several different places on top of Day 1, which you mentioned.
Day 15 (start)
Day 35 (2:30)
Day 131 (start)
It's likely this topic will be dealt with again when Casey's build system is revised to make a release candidate.
The asset zipfile is separate from the source code zips, and I initially found that confusing because of its name (e.g. test_assets) which led me to think they were a bundle of unit tests, and not critical to program execution.
I'm finding if you want to load a new source tree every day, it's a bit easier to setup your assets in a single absolute location that does not change from day to day, independent of whatever source tree you happen to be using.
Right now I just have them in the build directory, and rename whatever source tree I am compiling from to "handmade". When I build a new source tree, the binaries get refreshed, but the assets stay the same.