This is an SDL problem, however I have the strong feeling that the problem I came across is not related to SDL, but more to C++ / pointers in general.
To make a long story short, this code doesn't work (edited to show what I really did):
player->picture = IMG_Load("player");
SDL_BlitSurface(player->picture, NULL, screen, &pictureLocation);
I see nothing on the screen. However, when I do it like this, it works:
SDL_Surface* picture = IMG_Load("player.png");
player->picture = picture;
SDL_BlitSurface(player->picture, NULL, screen, &pictureLocation);
I can see the little guy just fine.
The real problem is that I cannot instantiate Player::picture directly. Even when I try
picture = IMG_Load("player.png")
in player.cpp, I end up with a nullpointer.
I am so stupid. Turns out like I forgot the file extension ".png" every time I tried to store the surface in Player::picture, and conveniently remembered to add it every time I stired it in an SDL_Surface declared in main.cpp.
I had the feeling I was overlooking something really simple here, but this is just embarassing. What's a fitting punishment for this?
What data type is player->picture? What type does IMG_Load return? It's really hard to come up with a scenario where saving an expression in a temporary variable changes the result, unless a type conversion is involved.
And I wouldn't call this pointer instantiation. You're instantiating an instance of some picture type and storing a pointer to it.
This is why you should always check to see what IMG_Load() returns...
SDL_Surface* picture = IMG_Load("player.png");
if (picture == NULL) {
// there was obviously some sort of error.
// what does SDL_GetError() say?
}
Some SDL functions return -1 if there is an error. Just check the documentation and make sure you're checking your function returns. These steps make debugging a lot easier.
Related
I would like to have a window, in which a picture changes depending on what is happening during an infinite loop.
Imagine someone walking around and when he leaves a given track, the program should display an arrow towards the direction of the track. Therefore I have a program, which determines the distance between user and track, but I have no idea on how to update the image.
I use code::blocks with wxWidgets and think I have to use the wxStaticBitmap class. (If there is a better way, please tell me.)
I tried with:
while(true)
{
updatePosition();
if(userNotOnTrack)
{
if(trackRightOfUser)
{
StaticDirectionBitmap->SetBitmap("D:\\WindowsDgps\\WindowsDgpsGraphic\\arrow_right.png");
}
}
}
(Note that this snippet is mostly pseudocode, except the StaticDirectionBitmap part.)
On default the Bitmap has a "no_arrow" image. With this I get an error: error: no matching function for call to 'wxStaticBitmap::SetBitmap(const char [51])'|. I see from the documentation that this cannot work, but I have no idea what could.
If anyone knows how to handle this, I would be happy to hear. I remember a few years back, when I tried something similar in C# and failed completely because of thread safety... I hope it is not this hard in C++ with wxWidgets.
SetBitmap takes a wxBitmap parameter not a string. So the call should look something like:
SetBitmap(wxBitmap( "D:\\WindowsDgps\\WindowsDgpsGraphic\\arrow_right.png", wxBITMAP_TYPE_PNG) );
Make sure prior to making this call that the png handler has been added with a call like one of the following:
wxImage::AddHandler(new wxPNGHandler);
or
::wxInitAllImageHandlers();
The easiest place to do this is in the applications OnInit() method.
If you want update the static bitmap from a worker thread, you should throw a wxThreadEvent and then make the call to SetBitmap in the event handler. The sample here shows how to generate and handle these events.
I've just used cocos2d-x for creating some games. When I read the HelloWorld.cpp, I saw this line
Scene* HelloWorld::createScene()
That's strange for me. How does it work? A method named creatScene that takes no parameters and returns a pointer to a Scene ?
In different libraries, there are different methods to initialize library or some part of that. So, in this case, it maybe create a new context inside library and return it without any argument. It maybe needs no arguments (use defaults) it this step of get them from somewhere else like configuration file. And note that this is convenient to use this type of initializing. Like this:
rc = redis.Redis() #uses default values for server address
It is really an easy question even it cannot be called as question when you check the source code.
In cocos2d-x, CCScene always create this way.
1. create a Layer, which coded by yourself with a lot of other widgets.
2. create a Scene
3. add the layer to the scene
4. return the scene you create.
I use Cocos2d-x for a game which I am porting from Cocos2d-iphone. The original programmer seems to have used the 'feature' of Objective-C to not crash on calls to nil objects as a way to do a lot of sloppy things.
If this is related to that I don't know, however, in my code I never call release() manually and certainly not delete or anything like that. I don't even call ->removeObject() at all (although that would not result in the same issue as I have).
Now the problem: when the game is running, at random moments (they won't be random but they seem that way now obviously) child nodes get set to NULL. And this does not only affect my code but als the Cocos2d internals. Example:
CCLog("----------------");
for(int j = 0; j < this->getChildren()->count(); j++)
{
CCObject *child = this->getChildren()->objectAtIndex(j);
EnemySprite *enemy = dynamic_cast<EnemySprite*>(child);
if (enemy != NULL) {
CCLog("Enemy with tag %d found", enemy->getTag());
}
}
EnemySprite *enemy = dynamic_cast<EnemySprite*>(this->getChildByTag(i));
if (enemy == NULL) {
CCLog("Now enemy with %d is NULL :(", i);
}
In the getChildren() look, all enemies with the tags are there and print this;
Enemy with tag 1000 found
Enemy with tag 1001 found
Enemy with tag 1002 found
During the game it'll show this a lot, until it shows this;
Enemy with tag 1000 found
Enemy with tag 1001 found
Enemy with tag 1002 found
Now enemy with 1001 is NULL :(
and crashes.
In my mind, this should be impossible with the above code as I just checked, verified and printed exactly that object...
But even more interesting (maybe only to me, maybe it's some stupid mistake), this
this->getChildByTag(i)
randomly goes wrong internally as well; traversing the children, it'll find a NULL and conk out on Cocos2d internal code:
if(pNode && pNode->m_nTag == aTag)
return pNode;
The pNode is then not NULL (that's why the asserts do not trigger) but looks like this:
http://o7.no/137JXC4 (screenshot)
The cocos2d::CCCopying thing is already stuff of nightmares for me in this project; every time I see it I know something is wrong and I have no clue how to find what it is.
I already added a breakpoint at the release() delete line; it's not being called. And I, like I said, am not doing anything like that manually.
I use Xcode / iOS to debug, but the behavior is the same on Android (but on my computer Eclipse is slower that Xcode, especially during debugging).
I understand it would be difficult to give me a solution / cause, however; I would be really happy if someone can tell me how to attack this issue. It happens randomly throughout the (quite large) codebase and I'm at a loss how to find this issue...
I hope someone can help!
At times dynamic_cast returns 0 even tough its argument was not 0. This happens for example when you're casting a super class to a subclass (so called "down casting"). Check this tutorial for more information: http://www.cplusplus.com/doc/tutorial/typecasting/
I can imagine that if the elements in your list have a generic (unrelated) super type, this can be the problem in your case.
As you say it's hard to tell, but here are two ideas.
You might try turning on guard malloc.
Alternatively, you might gain something from putting a static int counter in your suspect class's (like EnemySprite's) deconstructor/constructor to decrement/increment, and break/log when it falls below zero.
I only see the definition of j what is i?
I believe it crashes after CCLog("Now enemy with %d is NULL :(", i);
since this line already been logged, it definitely not crashing here.
CCObjects are subject to the AutoReleasePool by default, which means Cocos2D-x will manage when to release the object. If you use the static constructor for these objects, you can call object->retain() and object->release() so that you can manage the memory yourself.
Source: http://www.cocos2d-x.org/projects/cocos2d-x/wiki/Reference_Count_and_AutoReleasePool_in_Cocos2d-x
If something changes the enemy object to NULL, what I would do is setting a data breakpoint at address of enemy(for 1001). Than,
If breakpoint is hit, that might be a memory corruption.
If breakpoint is not hit and you get NULL, dig into getChildByTag(). What I would do then is replacing this->getChildByTag() with dynamic_cast<EnemySprite*>(this->getChildren()->objectAtIndex()) check if the is any difference.
In Build Settings->Other C Flags->Debug and add -o0 flag and try debugging.
Having a problem here with creating a child window with c++ and win32 api.
If i check the getLastError function its returning "87" but i dont know what that means.
For what i know my code does not contain errors, can someone take a look at my code and help me figure out whats wrong with it.
(This is in the WinProc WM_CREATE section.)
HWND hChildWindow = CreateWindowEx(WS_EX_CLIENTEDGE,0,NULL,WS_OVERLAPPEDWINDOW|WS_VISIBLE,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,hwnd,0,GetModuleHandle(0),NULL);
if(!hChildWindow)
{
char text[256];
int errormsg = (int)GetLastError();
sprintf(text,"Error# %i",errormsg);
MessageBox(0,text,"Error",MB_OK|MB_ICONEXCLAMATION);
return false;
}
87 = Invalid Parameter - be aware that you can use FormatMessage to get a string message from an error code.
The 2nd parameter to CreateWindowEx is a window class (either string or ATOM). Obviously NULL is not a valid value.
P.S.
For what i know my code does not
contain errors...
Beware of such a loud phrases. When something doesn't work everything should be checked carefully. Otherwise you may just accuse something/someone without any good for solving the problem. Check everything vs standard/documentation/specifications/etc. before you make any judgement.
A quick look through the System Error Codes reference indicates ERROR_INVALID_PARAMETER. You're most likely passing in an invalid combination of styles/flags to your window.
I'm writing a C++ MFC program on VS2008 and I'm getting this "Debug Assertion Error" when I first run the program sometimes. When I try to debug it, it takes me to this winhand.cpp file which is not part of the program I wrote so I'm not sure how to debug this.
It takes the error to this place in winhand.cpp
CObject* pTemp = LookupTemporary(h);
if (pTemp != NULL)
{
// temporary objects must have correct handle values
HANDLE* ph = (HANDLE*)((BYTE*)pTemp + m_nOffset); // after CObject
ASSERT(ph[0] == h || ph[0] == NULL);
if (m_nHandles == 2)
ASSERT(ph[1] == h);
}
So why does this error happen? Why does it only happen sometimes (50% of the time)? How would I debug this?
I'll provide some code if is needed.
THANKS!
The code that is asserting is part of MFC's CHandleMap class. MFC deals with windows as CWnd objects, but Windows deals with them as HWND handles. the handle map allows MFC to 'convert' an HWND into a pointer to the MFC object representing that object.
What the assertion seems to be doing is checking that when a lookup of the handle finds an MFC object, that the MFC object also thinks it's wrapping the same handle.
If they're different, then you get the assertion.
So it would appear that something is corrupting the handle map or the MFC object for that handle or you're doing something incorrect that gets these 2 data structures out of sync.
Some things you might do to try to debug the problem is to determine:
what MFC object is being found in the lookup (that's what's being pointed to by pObject)
what the MFC object thinks it's wrapping (that's the handle ph[0] and/or ph[1] - I'm not sure why there can be 2 of them)
what the handle is for (that's h)
Do the handles look like handle values or do they look like garbage? Does pObject point to something that looks like an MFC object, or garbage? Do any of these these things seem related?
The answers to these questions may point to what you need to do next (maybe set a debug write breakpoint on the item that looks like it's trashed).
I got this same assertion few days ago, and after some google search,
I found the solution for my case here:
http://forums.codeguru.com/showthread.php?216770-What-would-cause-this-assertion
In my case, change to misused
CDC* dc = GetDC();
CSize spaceSize = dc->GetTextExtent(" ");
dc->DeleteDC();
to
CDC* dc = GetDC();
CSize spaceSize = dc->GetTextExtent(" ");
ReleaseDC(dc);
would fix it.
Look out for code along those lines (from memory from Stroustrup's book):
c1 = (t2+t3).c_str();
(in spirit, could be other commands and expressions of course).Temporary objects are destroyed after their enclosing full expression has been evaluated, or at least the standard allows them to be. That means that what you would like to allocate to c1 may, or may not, still be in memory where it can be assigned to c1. The compiler may alert you to this issue, and the issue may or may not arise depending on what exactly you assign and other circumstances (I am not compiler writer), which would also explain why you get this error message only sometimes.
So in your shoes, I'd scan my code for similar expressions and clean them up.
When the debugger breaks, head up the call stack to the first bit of your code (if there is any - hopefully there is!). Ideally it's as simple as something in your code calling a library function incorrectly, and the library is catching the error with an assert and alerting you to that. (I don't think anyone will be able to tell what's wrong from the library code, we need to see your code.)
Otherwise, you're in for some tricky debugging: you're doing something wrong with the library that is asserting (looks like MFC) so go back and review all your MFC code and make sure everything is correct and according to the documentation.
This looks suspiciously like an error I had this morning. Is this happening in OnIdle()?
I know this is a very old post, but hoping that someone may get a little help from my answer.
I also faced a similar issue recently because of my simple mistake, then I came across this post and got a hint from "pac"'s post.
What I found is that if I use DeleteDC() to release DC returned from GetWindowDC() or GetDC() I will get the above assertion in MFC frame once CPaintDC object instance goes out of scope.
CDC * pDC = GetWindowDC();
...
ReleaseDC(pDC);
You have to use DeleteDC() only in conjunction with CreateDC() API.
CDC * pDC = new CDC();
pDC->CreateDC();
....
pDC->DeleteDC();
We had this problem when some of our project dlls were linking MFC as static library and some as shared library (check "Use of MFC" in Project settings)