Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Open Source version - Run-Time Check Failure #2 - Stack corruption - help?

Author
Message
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Dec 2013 05:16 Edited at: 2nd Jan 2014 04:44
Edit: January 1, 2014 - This topic is no longer relevant. The open source has been updated and the issue fixed.

I just got and successfully compiled the open-source version of DarkGDK. And when I run my game using it instead of the previous released version of libraries, I get several run-time errors. All are stack corruptions. The first is this one:

Run-Time Check Failure #2 - Stack around the variable 'pCheck' was corrupted.

And it is triggered in the midst of executing the dbSetDisplayMode() command. Within the DarkGDK source-code, it the error is triggered when this command is executed:

if(g_Image_RefreshD3D) g_Image_RefreshD3D(iMode);

in the file CGfxC.cpp (line 1115).


The next several times this type of error is triggered is when I call the dbLoadImage() and dbImageExist() commands. The variables pImage and p, respectively, have corrupted stacks.

What's going on here? I have never seen this error before. Any idea how to fix this, or get an earlier version without this stack bug? It's annoying to compile an open-source program only to have it non-functional.

Q: ...you mean computer imagery was still based on the paradigm that the world was flat? Even into the 21st century??? Talk about doing something the hard way!

A: Yep! Back then people would render simple shapes with complex meshes of thousands of flat little triangles. Next to the bottleneck processors they used, it's the main reason why their computers were so slow. In the last days of the religious atmosphere of centralization and trade, corporate dogmas had people believing that flat was faster.
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Dec 2013 17:21 Edited at: 1st Dec 2013 18:17
I solved my problem with this!

I tracked down the revision that created these errors, it's r55. I was able to keep the latest revision of everything else. So what I have is the latest revision (101), but the 4 files affected by r55, I rolled those back to r54, and kept everything else at r101. And it works fine now.

However, I get a major frame-rate drop with r101 that I don't get with r54 or the latest release in 2010. So something between those two revisions introduces a major slow-down in program execution.

Edit:
I found culprit in the slow-down. It's the camera overhaul made in r97.

Also, r69 was a music overhaul. And it dbSetMusicVolume() does not work after that.
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Dec 2013 00:59 Edited at: 2nd Jan 2014 04:43
Edit: January 1, 2014 - This topic is no longer relevant. The open source version has been updated and the issue fixed.

Q: ...you mean computer imagery was still based on the paradigm that the world was flat? Even into the 21st century??? Talk about doing something the hard way!

A: Yep! Back then people would render simple shapes with complex meshes of thousands of flat little triangles. Next to the bottleneck processors they used, it's the main reason why their computers were so slow. In the last days of the religious atmosphere of centralization and trade, corporate dogmas had people believing that flat was faster.

Login to post a reply

Server time is: 2024-04-26 23:45:29
Your offset time is: 2024-04-26 23:45:29