In my game i am having a very weird problem. Sometimes in the game the userdata attached to body suddenly hides themselves but the bodies still show... I am using cocos2d version 0x00020000 and it does not help searching on the net. Problem occurs both on release mode and debug mode. the children attached to these bodies still are seen but the userdata sprites do not
Related
After upgrading to qt version 6.2 from qt5 I faced the problem with starting the app in the maximized mode. The widget is first painted with it's normal size and then repainted fine. The intermediate state is shown on the gif below:
The code of the app from the giff comes together with Qt (my version is Qt-6.2.3) and called "styles" (path is Qt/Examples/Qt-6.2.3/widgets/widgets/styles) or can be found on the qt.io. I have just changed widget.show() to widget.showMaximized() in main.cpp.
I figured out that sometimes widget starts fine, but this is rather rare. Also the more complicated widget is, the more time it takes to correctly paint it on the first show.
In the example from the gif the start is so quick that it is almost invisible, but in the heavy app I'm working with this slow startup really catches the eye.
If this can not be easy fixed, does anybody have any idea how to mask this behaviour? I thought about painting the widget on the virtual framebuffer and moving it back to the main display right after first show, but I did not find any easy means to create it in c++.
Any help is appreciated.
EDIT:
I finally reported a bug to qt developers.
See QTBUG-104357
After upgraded to ios7, I found the Cocos2d application run slowly (or frame skipped) after checking the notification center.
Reproduce the problem:
Launch a cocos2d game, better with some fast moving sprites
Swipe down from the top of the screen to drop down the notifaction center, then swipe it up.
Now the game becomes like frame skipped. (slow). But after a while, or after some operation within the game, the frame speed recovers.
I tested on iphone5.
Anyone see the same problem? Any idea how it happens?
EDIT:
Since this problem only happens in rare case, I d like to close it.
I have a cocos2d game that has a loading scene where we load a bunch of assets. The game starts with the splash screen, and then launches the loading scene. The loading scene starts by loading the background, so the user sees the loading scene background while the assets are being loaded.
I load the loading scene background by calling CCSprite::spriteWithFile: and passing the filepath: loadingbackground.pvr.ccz
It seems to work differently on different devices:
On iphone (3gs) simulator, I see the loading scene as expected.
On iphone retina simulator, I don't see the loading scene (there aren't many assets yet, so may be happening quickly) and it goes directly to the main menu scene.
On the ipad 3 device, the splash screen comes up, and then there is a half second of black screen, and then the main menu scene shows up.
I want to see what I can do to avoid that black screen showing up on iPad 3. I suspect this is because of the time taken to load the loading background.
I have tried the following optimizations (mostly based on #Steffen's blog post on memory optimization):
Moved the loading background (originally 2.3 MB RGB8 png file) into a pvr.ccz spritesheet by itself, which reduced its size to 1.8 MB.
Removed the image from the texture soon after use.
I still see a black screen on iPad 3. Any suggestions?
Update: Found the issue - I had some code where I was overriding OnEnter and calling [[CCDirector sharedDirector]replaceScene] in it, and also calling the same from the background thread. Removed the OnEnter overload and it worked without flicker.
Thanks
Ignore whatever happens in Simulator. That's not relevant, focus on the device.
When the loading scene initializes and you add the loading scene's background, make sure you schedule update and load your assets in the update method. Otherwise if you load the assets in init, the background won't be drawn because you're loading all the assets before cocos2d gets to redraw the screen.
If this still fails, simply send the visit message to the background sprite followed by [[CCDirector sharedDirector] drawScene]. This forces a redraw of the scene.
Is this cocos2d-iphone or cocos2d-x ? make sure the tags are correct :)
I think you're referring to the startup flicker, there are a few ways to avoid that.
first thing you need to make sure you're handling the rootViewController correctly for iOS 6 and iOS 5 and below, there are a little changes for each.
You can find a little reference here:
http://www.cocos2d-iphone.org/forum/topic/34471
Second thing you need to know that simulator's behaviour is not stable, you should always rely on real devices for testing, but it's very likely you'll still have the flicker issues.
Sorry I didn't provide example code, but you haven't supported enough information to know what's the real issue here.
I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.
I've recently noticed that things accommodate differently on the simulator and a real device when using Cocos2d.To make sure I did the following:
1. I created a blank Cocos2d project. In the init method I created 7 sprites from Icon-72.png(which is found in the resources folder of the Cocos2d template) and added them to the screen.In the simulator only 6.5 sprites could accommodate side-by-side whereas in the iPod touch all seven sprites could accommodate easily and almost half of the screen width remained unused.
2.Then I created a project from Single View Application template. I added the same Icon-72.png to the project. Then on the storyboard I added 6 image views and set their image property to Icon-72.png. This time I had exactly the same result with both simulator and the device.
I guess there should be some tweak as to how to fix this issue with Cocos2d because it's not Apple's fault. Do you know how to handle this?
The iPod Touch could have the retina display and the simulator wont have have it. If you need the same display as of the iPod Touch You can use the iPhone Simulator with the Retina Display and you would get the same screen. Another Option you can use is Copy and paste the Same file with -hd prefix ex:(Icon-72-hd.png) with 72x72 size and you can get the same result.
There is no problem with either the version of cocos2d or with the Apple for the issue you are facing.
I guess I do have poor explanation but you would understand my explanation.
The iPod Touch will be a retina display. Cocos2d doesn't automatically double the size of images.