• 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
Tispe

Logical comparison of a DWORD and #define 0xXXXXXXXX

13 posts in this topic

Hi

 

I have a std::vector<DWORD> that I want to loop through and compare each DWORD against a defined value. The problem is that either "&", "&&" or "==" will currupt the vector.

 

How can I do this check without messing up the vector?

 

#define StopLoadingThread	0xffffffff
std::vector<DWORD> LoadThread_RequestFiles;

 

for(int i=0;(int)LoadThread_RequestFiles.size();i++)
{
	if(LoadThread_RequestFiles[i] && StopLoadingThread)			//Fix comparison
	{
		m_quit = true;
	}
}
for(int i=0;(int)LoadThread_RequestFiles.size();i++)
{
	if(LoadThread_RequestFiles[i] == StopLoadingThread)			//Fix comparison
	{
		m_quit = true;
	}
}

 

0

Share this post


Link to post
Share on other sites

== should work fine.

 

Seeing the word "thread" appears in your code, the corruption is likely being caused by two threads accessing the vector at the same time... Can you explain what your threads are doing, and how you're synchronising them?

1

Share this post


Link to post
Share on other sites
for(int i=0;(int)LoadThread_RequestFiles.size();i++)

Ought to be:

for(size_t i = 0; i < LoadThread_RequestFiles.size(); i++)

You'll have to give more details on this apparent vector corruption but as Hodgman has said, it's possibly something to do with your threading.

2

Share this post


Link to post
Share on other sites

Well, there are 6 std::vectors<DWORD>, for buffered bi-directional communication. Two for Main thread, Two for Mutex and Two for the Load thread. The Main thread can call a function RequestFile(DWORD) which puts the DWORD value on the "send" vector. Another function (try)enters a mutex and copies from the "main_request" vector to the "mutex_request" vector. The loading thread will then enter the mutex and copy from the "mutex_vector" to the "LoadThread_RequestFiles" vector.

 

So the Main thread is the only one controlling the two main vectors and the loading thread is the only one controlling the thread_vectors. And there are two vectors in between main and thread can access via mutexes. The vector that gets corrupted is only accessed by the loading thread.

 

Send:

   MainReq_vector -> MutexReq_vector -> ThreadReq_vector

 

Recieve:

   MainCompleted_vector <- MutexCompleted_vector <- ThreadCompleted_vector

0

Share this post


Link to post
Share on other sites

I did this

for(size_t i = 0; i < LoadThread_RequestFiles.size(); i++)

But the result is the same.

void MyLoadingClass::GetRequestedFiles()
{
	EnterCriticalSection(&RequestLoadMutex);

	for(size_t i=0;i<Mutex_RequestFiles.size();i++)
	{
		LoadThread_RequestFiles.push_back(Mutex_RequestFiles[i]);		//Retrieves all requests from shared vector to loading thread
	}

	Mutex_RequestFiles.clear();										//Clear to prevent duplicates on next call
	LeaveCriticalSection(&RequestLoadMutex);
}
0

Share this post


Link to post
Share on other sites
Threading bugs are evil. Just because variable Foo appears to be clobbered doesn't mean that the problem lies in code that handles Foo.

Check all of your thread synchronization and design. Chances are the problem is someplace else and/or rooted more deeply than just this vector.
0

Share this post


Link to post
Share on other sites

hmmm, I tried to copy the element to a test variable to see if it was the checking. Turns out that the act of copying the DWORD to test broke the vector.... How can that be.

 

	for(size_t i=0;i<LoadThread_RequestFiles.size();i++)
	{
		DWORD test = LoadThread_RequestFiles[i];			//Breaks LoadThread_RequestFiles
		if(test == StopLoadingThread)
		{
			m_quit = true;
		}
0

Share this post


Link to post
Share on other sites

Broken means that prior to

DWORD test = LoadThread_RequestFiles[i];

the vector containes the correct value and has a size of '1'. After this line of code the vector gets a size of '4260741497' and the elements value are just '(...,...,....)'.

 

I tried using iterator but the same thing happens:

 

	for(std::vector<DWORD>::iterator it = LoadThread_RequestFiles.begin(); it!= LoadThread_RequestFiles.end(); it++)
	{
		DWORD test = *it;						//does not work
		if(test == StopLoadingThread)			//Fix comparison
		{
			m_quit = true;
		}
0

Share this post


Link to post
Share on other sites
Broken means that prior to
DWORD test = LoadThread_RequestFiles[i];

the vector containes the correct value and has a size of '1'. After this line of code the vector gets a size of '4260741497' and the elements value are just '(...,...,....)'.

 

?

 

Just a shot in the dark, but could you try cleaning and rebuilding the project? I want to say that I've run into this before but I can't remember what it was. I just vaguely remember stepping through the STL code with the debugger.

Edited by Khatharr
0

Share this post


Link to post
Share on other sites
Also make sure you're not trying to debug a release build. That's a classic symptom of the debugger getting confused because of low-level optimizations.
0

Share this post


Link to post
Share on other sites

Multithreading is an extremely advanced topic. Make sure you first understand how STL template library works, how debugging applies to Debug & Release modes.

Also look for naming conventions. CamelCase is commonly used for functions (and sometimes variables, sometimes theyStartWithLowerCase but still camel case) and ALL_CAPS for macro definitions.

 

But mixing CamelCase with CamelCase_undercored_spaces is very weird and will confuse/annoy most coworkers you will encounter throughout your life.

0

Share this post


Link to post
Share on other sites

Ok, so I cleaned the solution and rebuilt everything again. And now it works. But that is strange because I already tried that several times. Why would that work on the 7th time....

0

Share this post


Link to post
Share on other sites

Because you rebuilt everything.  Meaning you updated object files that may not have been properly updated when they should have been.

Now every object file is “on the same page”.

 

 

L. Spiro

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