• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
liZHao

VC++ F5 and Ctrl+F5, I'm mad...

21 posts in this topic

Hi folks,

I'm stuck on a problem.. I wrote a OpenGL rendering framework using VC 2012. It loads model and shader files from hard drive. It works very well when I launch it by F5, BUT if I use Ctrl+F5, nothing is ever drawn on the screen.. Also under both 'modes', all files have been read in properly. I cannot figure out why, please help me if you have any ideas. Thanks in advance.

The libraries I used: glew 1.9, SDL 1.2, glm 0.9.3.4, C++11
0

Share this post


Link to post
Share on other sites
Thanks for your answer Hodgman, regarding
[quote name='Hodgman' timestamp='1346217111' post='4974324']
Most likely you're relying on an uninitialized variable somewhere. Try turning the compiler's warning setting up to it's maximum level.
[/quote]
I maximized the warning levels but there are no variables uninitialized.

[quote name='Hodgman' timestamp='1346217111' post='4974324']
Do you use multi-threading or custom memory allocation?
[/quote]
Neither of them have been used so far. Though I found the rendering results may differ from time to time. E.g. very few times when I start the app only one of two meshes is drawn while other times nothing is drawn. Edited by liZHao
0

Share this post


Link to post
Share on other sites
[quote name='liZHao' timestamp='1346243741' post='4974402']I maximized the warning levels but there are no variables uninitialized.[/quote]This just means there's no [i]obvious[/i] uninitialized variables, there still [i]might[/i] be some :/

e.g. This code creates a new uninitialized variable, but the compiler won't issue a warning about it:[code]MyStruct* data = (MyStruct*)malloc( sizeof(MyStruct) );[/code]
0

Share this post


Link to post
Share on other sites
Note that even without weird creation mechanisms, if you pass the address of an uninitialized variable around, MSVC won't give you a warning. Ex:
[code]
void foo1(int a) {}
void foo2(int * a) {}

int main(int, char **) {
int a;
int b;
foo1(a); // C4700
foo2(&b); // no warning
}
[/code]
1

Share this post


Link to post
Share on other sites
SiCrane - but that's normal usage of output argument. Why would you want warning for that? Then a lot of C style programs will give tons of warnings.
0

Share this post


Link to post
Share on other sites
SiCrane did not say that should produce a warning. He said that is a situation where an uninitialized variable is used in a potentially dangerous context. That is an important point because the OP seems to assume no "uninitialized variable" warnings mean his program does not use them. Edited by BitMaster
0

Share this post


Link to post
Share on other sites
Try to use CppCheck on it, it's usually pretty good at founding uninitialised variables in C++, it has already saved my neck more than a couple of times since I've started using it.
0

Share this post


Link to post
Share on other sites
The thing I don't get about the unitialized variable assumption ist that both F5 and Ctrl+F5 launch the debug build (one with debugger attached, the other without) so the variables that stay uninitialized in release but initialized in debug should be initialized as well. Or am I missing something?

Try to attach the debugger after launching with Ctrl+F5 maybe that helps in seeing what happens?
0

Share this post


Link to post
Share on other sites
I have found the reason: there is a boolean member variable indicating the visibility of a mesh and it has not been initialized explicitly.. thus in debug mode (F5) it is initialized with 'true' otherwise it is random..
What confuses me is why VC initializes a boolean variable with 'true'?
0

Share this post


Link to post
Share on other sites
[quote name='brx' timestamp='1346255554' post='4974460']
The thing I don't get about the unitialized variable assumption ist that both F5 and Ctrl+F5 launch the debug build (one with debugger attached, the other without) so the variables that stay uninitialized in release but initialized in debug should be initialized as well. Or am I missing something?[/quote]
One of life's many little annoyances is that the MSVC CRT behaves differently depending on whether or not a debugger is attached during initialization. Take this code for example:
[code]
int main() {
std::vector<char *> vec;
for (int i = 0; i < 1000; i++) {
vec.push_back(new char);
}
std::sort(vec.begin(), vec.end());
ptrdiff_t min_diff = vec[1] - vec[0];
for (int i = 1; i < 999; i++) {
ptrdiff_t diff = vec[i + 1] - vec[i];
if (diff < min_diff) min_diff = diff;
}
std::cout << min_diff << std::endl;
}[/code]
With MSVC 2010 targeting x86, Debug with F5 spits out 64, Debug with Ctrl-F5 gives 48, Release/F5: 32, Release/Ctrl-F5: 16.

As long as your code relies only on defined behavior, then these differences don't really have much of an impact other than allocations using more or less memory than you might otherwise expect. However, once you dip into undefined or implementation defined behavior, like the contents of uninitialized memory, then these differences can give you all kinds of headaches. Edited by SiCrane
1

Share this post


Link to post
Share on other sites
[quote name='liZHao' timestamp='1346257194' post='4974471']
I have found the reason: there is a boolean member variable indicating the visibility of a mesh and it has not been initialized explicitly.. thus in debug mode (F5) it is initialized with 'true' otherwise it is random..
What confuses me is why VC initializes a boolean variable with 'true'?
[/quote]
MSVC's debug heap fills uninitialized memory with [url=http://www.nobugs.org/developer/win32/debug_crt_heap.html]certain bit patterns[/url] to make debugging common errors easier to find. Note that they are all non-zero, which means translates into [tt]true[/tt] in most cases they are treated as a boolean value.
1

Share this post


Link to post
Share on other sites
Thanks SiCrane, I didn't know that. I always thought it only depends on the build configuration.
0

Share this post


Link to post
Share on other sites
this is one of the things that really drives me mad about C++ ... there should be (is there?) a compiler switch to auto initialise every variable to zero and get rid of this '60 cold war age nonsense, I'd happily pay the performance penalty for that.
0

Share this post


Link to post
Share on other sites
Another really simple way to get uninitialized variables with no compiler warnings is when they are class / struct member variables - the compiler won't complain if the constructor doesn't initialize all member variables.


It's not too hard to override global operator new so that it sets the memory to zero before returning it, just don't forget to do it for all the different variations (array version, nothrow version, etc). Of course there's an obvious performance cost to doing that, and it only works for heap allocations - doing that for stack allocated objects would need some help from the compiler, and Visual Studio can usually catch those in debug anyway.
0

Share this post


Link to post
Share on other sites
[quote name='kunos' timestamp='1346257924' post='4974477']
this is one of the things that really drives me mad about C++ ... there should be (is there?) a compiler switch to auto initialise every variable to zero and get rid of this '60 cold war age nonsense, I'd happily pay the performance penalty for that.
[/quote]

And make your code completely unsafe for anybody else that uses it.

Automatically initializing variables to zero is not just a trivial performance issue, it can have huge performance implications on some code and algorithms, and the potential benefits of doing so are marginal; it can eliminate some bugs, while making other bugs harder to track down.
2

Share this post


Link to post
Share on other sites
[quote name='brx' timestamp='1346257669' post='4974476']
Thanks SiCrane, I didn't know that. I always thought it only depends on the build configuration.
[/quote]
The MSVC CRT heap behavior actually depends on a number of variables. One of them is operating system, this being because most of the time the CRT delegates allocations to the Windows API HeapAlloc() function, so if the OS behavior changes, the CRT behavior will change. However, older versions of MSVC takes a bit further. MSVC 2005 and earlier would only use HeapAlloc() if the OS was Win2000 or later. On earlier OS versions, they would use an internal heap management system... unless an environment variable was set to override the heap selection mechanism. MSVC 2008 defaulted to always using the OS heap, unless overridden by the environment variable. As far as I can tell MSVC 2010 got rid of the alternate heaps entirely, and instead adds a check to see if the OS is Win XP or 2003 Server, in which case it explicitly enables the low fragmentation heap. And to mix things up a bit, the OS heap itself depends on at least one environment variable. If _NO_DEBUG_HEAP is set to 1, then some of the behavior changes for when a debugger is present aren't used.

I also don't make any promises about this being a comprehensive list.
0

Share this post


Link to post
Share on other sites
I normally use [url="http://valgrind.org/"]valgrind[/url] to check for things like this. It walks through your program and gives dynamic warnings on uninitialized variables and also memory leaks
1

Share this post


Link to post
Share on other sites
[quote name='Simian Man' timestamp='1346343101' post='4974837']
I normally use [url="http://valgrind.org/"]valgrind[/url] to check for things like this. It walks through your program and gives dynamic warnings on uninitialized variables and also memory leaks
[/quote]
Vagrind would have been an option, but he stated he's using the Visual Studio and afaik valgrind does unfortunately not work in windows.

However, I just remembered that starting with VS2012 the static code analysis is included in all versions starting with professional (it used to be limited to higher versions before). That should have caught it as well. Additionally, they finally made the profiler and the concurrency visualizer available for VS professional as well.
0

Share this post


Link to post
Share on other sites
Good static analysys tools should be good for this -- there's [url="http://www.gamedev.net/page/resources/_/technical/general-programming/mame-emulator-disease-memset-r2938"]an article on the site[/url] that talks about catching buggy memset calls that were supposed to initialize allocations but didn't.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0