Hi all,
I'm new to this but I've been going at a good pace and haven't had too many problems, and the ones I had I was able to figure out. Anyway, after making it through the minutiae of audio debugging, I was soooo excited to do the dynamic loading and editing, but I've hit a problem I can't figure out.
I followed this episode very carefully and about 45 mins into the episode, when I run the code, I get an "Access violation executing location 0x00000000" exception when I hit the second line in this part of handmade.cpp.
At this point, in the watch-window for Filename, I see:
[hex address] "h:\\code\\handmade.cpp"
I looked at the hex address in the register and it does point to h:\code\handmade.cpp, so the double backslashes are being handled properly and that seems fine.
Also when I do it this way (running until I hit the exception) in the watch window, Result and FileHandle (the first two things declared in DEBUGPlatformReadEntireFile) are listed as 'undefined'.
So I set the breakpoint at Filename = __FILE__ part, and after I get the Filename as above, I manually move into the DEBUG_PLATFORM_READ_ENTIRE_FILE(DEBUGPlatformReadEntireFile) call in the win32_handmade.cpp file, but when I do that, it changes the hex address of Filename, and the filename itself becomes blank. I wonder if that's because I jumped from one function to another maybe, but I don't see why.
When I step manually through this function, the first line correctly initializes both components of Result to 0.
Now, according to MSDN, you can use either forward or backslashes in a filename, so I guess that's not the issue. But I really can't get a handle (no pun intended... well, maybe just a little bit) on this problem.
It's really weird. If I run until I hit the exception, the pointer to the filename remains in the right place, but the call to DEBUG_PLATFORM_READ_ENTIRE_FILE just fails. But if I manually step through the call, that somehow alters the pointer to the filename, but I have no idea how.
As I'm thinking about this, it seems that the problem is the call itself, but I've compared the relevant functions to Casey's code and I can't see any differences.
I'm really struggling with this. I even scrapped my code, pulled up my day 020 code and restarted the video, but when I get to that point, I get the same problem. I also tried replacing 'char *Filename' with variations of 'char Filename[] = "h:\\code\\dummy.txt" ' (literally just a dummy text file containing a single word) using different path/backslash/forwardslash combinations, but the same thing happened.
I don't currently have the source code to compare to (I'm thinking of making that my xmas present) so for now I'm following along manually (and faithfully!) but here's my code if it helps:
[edited to remove links, just realized it was a bad idea, sorry]
Honestly I'd be fine with finding out I made some embarrassingly obvious mistake but any help would be appreciated, thanks!
I'm new to this but I've been going at a good pace and haven't had too many problems, and the ones I had I was able to figure out. Anyway, after making it through the minutiae of audio debugging, I was soooo excited to do the dynamic loading and editing, but I've hit a problem I can't figure out.
I followed this episode very carefully and about 45 mins into the episode, when I run the code, I get an "Access violation executing location 0x00000000" exception when I hit the second line in this part of handmade.cpp.
1 2 | char *Filename = __FILE__; debug_read_file_result File = Memory->DEBUGPlatformReadEntireFile(Filename); |
At this point, in the watch-window for Filename, I see:
[hex address] "h:\\code\\handmade.cpp"
I looked at the hex address in the register and it does point to h:\code\handmade.cpp, so the double backslashes are being handled properly and that seems fine.
Also when I do it this way (running until I hit the exception) in the watch window, Result and FileHandle (the first two things declared in DEBUGPlatformReadEntireFile) are listed as 'undefined'.
So I set the breakpoint at Filename = __FILE__ part, and after I get the Filename as above, I manually move into the DEBUG_PLATFORM_READ_ENTIRE_FILE(DEBUGPlatformReadEntireFile) call in the win32_handmade.cpp file, but when I do that, it changes the hex address of Filename, and the filename itself becomes blank. I wonder if that's because I jumped from one function to another maybe, but I don't see why.
1 2 | debug_read_file_result Result = {};
HANDLE FileHandle = CreateFileA(Filename, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0);
|
When I step manually through this function, the first line correctly initializes both components of Result to 0.
Now, according to MSDN, you can use either forward or backslashes in a filename, so I guess that's not the issue. But I really can't get a handle (no pun intended... well, maybe just a little bit) on this problem.
It's really weird. If I run until I hit the exception, the pointer to the filename remains in the right place, but the call to DEBUG_PLATFORM_READ_ENTIRE_FILE just fails. But if I manually step through the call, that somehow alters the pointer to the filename, but I have no idea how.
As I'm thinking about this, it seems that the problem is the call itself, but I've compared the relevant functions to Casey's code and I can't see any differences.
I'm really struggling with this. I even scrapped my code, pulled up my day 020 code and restarted the video, but when I get to that point, I get the same problem. I also tried replacing 'char *Filename' with variations of 'char Filename[] = "h:\\code\\dummy.txt" ' (literally just a dummy text file containing a single word) using different path/backslash/forwardslash combinations, but the same thing happened.
I don't currently have the source code to compare to (I'm thinking of making that my xmas present) so for now I'm following along manually (and faithfully!) but here's my code if it helps:
[edited to remove links, just realized it was a bad idea, sorry]
Honestly I'd be fine with finding out I made some embarrassingly obvious mistake but any help would be appreciated, thanks!
Edited by Herc
on
All pointers to platform-layer functions in game memory are zero in your code:
Presumably, that is the reason for your crashes. You're trying to call a function from a zero pointer.
Here's how it looks in Casey's version from day 021 and it makes sense for it to be that way:
1 2 3 | GameMemory.DEBUGPlatformFreeFileMemory = 0;
GameMemory.DEBUGPlatformReadEntireFile = 0;
GameMemory.DEBUGPlatformWriteEntireFile = 0;
|
Presumably, that is the reason for your crashes. You're trying to call a function from a zero pointer.
Here's how it looks in Casey's version from day 021 and it makes sense for it to be that way:
1 2 3 | GameMemory.DEBUGPlatformFreeFileMemory = DEBUGPlatformFreeFileMemory;
GameMemory.DEBUGPlatformReadEntireFile = DEBUGPlatformReadEntireFile;
GameMemory.DEBUGPlatformWriteEntireFile = DEBUGPlatformWriteEntireFile;
|
Edited by r2d2
on
Oh my god!
Oh that's funny. When Casey was writing that part, it was behind the little picture-in-picture of him, and all I could see was a bit of the first character, and since I only heard one keypress, I figured "hey, just one button, looks kinda oval, must be a 0". Didn't even occur to me it was a paste. Welp, I just learned a valuable lesson about assumptions.
And yeah, in hindsight that is... a really silly mistake... heck. Thanks a lot!
Oh that's funny. When Casey was writing that part, it was behind the little picture-in-picture of him, and all I could see was a bit of the first character, and since I only heard one keypress, I figured "hey, just one button, looks kinda oval, must be a 0". Didn't even occur to me it was a paste. Welp, I just learned a valuable lesson about assumptions.
And yeah, in hindsight that is... a really silly mistake... heck. Thanks a lot!