Hi All,
I’m using Cocos2d-x C++ version 3.3 and trying to port my project from Mac to Windows 8.1. I’m using the Win32 project and it’s working fine, but the performance is terrible. I’m lucky to get 20 FPS in Windows as opposed to a steady 60FPS on the Mac (same machine).
Has anybody experienced this? Is x86-only compiling the cause of this? Is there an obvious fix that I’m missing?
Any help would be really appreaciated,
Thanks!
Yes, i experienced the same issue for an exe file. But the same project when targeted for android had no issues of fps
Some more info…
I see that cpp-test’s menu page (version 3.3) takes 12% cpu on my quad core cpu, whereas version 3.4 takes ~2% cpu.
Were optimizations added in v3.4?
Quick update…
I updated to latest from git and my project is running at 12 FPS Win32 compared to 60 FPS OSX.
Anybody know if there are known issues with the Win32 build of cocos2d-x?
Hmmm…my also goes slow but not lower than 40. Maybe something wrong with the code, a bottleneck or something?
My game is probably using more resources than yours would be my guess. Either way, it sounds like we’re both seeing performance issues in the Win32 build.
Another quick update:
I got the latest from git and cpp-test was also running with high cpu usage. I’m wondering if there’s an optimization or debug flag that is being applied in the v3.4 tag (the v3.4 cpp-test is running much more efficiently), which isn’t being applied when using the git version. Anybody aware of such a thing?
Just updating with some more info.
v3.4 cpp-test is also running inefficiently - at first I thought it wasn’t. The Mac and Linux build are running significantly faster the Windows version. The Windows build is the highest priority for me because we plan on releasing the game on Steam.
I’m more than happy to help fix this, but I’m not really sure where to start. I’ve tried different compiler optimizations, but that did not seem to help - though I have not tried compiling in 64-bit. Anybody have any idea what the source of the performance issue could be?
Let me ask someone to take a look at this.
Oops, I should’ve tried this sooner.
Just built the Release build of my game and performance is a lot closer to the Mac side now (testing on the same machine). I didn’t think of trying this before because performance was so bad I didn’t think it would make such a big difference. It seems like there’s still plenty of room for optimization (would a 64-bit build have any significant improvement on cpu usage?), but at least I can play my game now.
Hmm… dudde I just posted on the forum regarding this. There is stuttering in my case. running on win7 64bit 8gb ram and gtx560.
Also check if you are still having the same problem if you run the exe from the release or debug folder in win32 (obviously you will have to copy and paste all the asstes into it for the exe to work). Then the performance is better but still stuttering is there.
I am making a sidescroller with tiled. So I dont know if tile rendering is causing the stutter…
Using a junction will definitely make your life easier:
@zhangxm The game builds fine in debug and release modes. The debug build had such bad performance though that I assumed the release build would not be much better - but once I tried the release build I discovered that it runs decently.
It seems like there’s room for improvement though and I’m wondering if there are any obvious optimizations to be done. Perhaps compiler optimizations can be enabled for the release build and/or adding 64-bit builds?
Did you find a solution for it? I am making tilemap game and it stutters from time to time
@siddharthshekar - how does your game run in release mode? The debug mode is unusably slow for me, but once I created the release mode, things were running relatively fine.
@Sheado The debug mode game is unplayable. In the release mode there is slow down on a 3.5ghz machine. fps goes down to 56 fps no matter what i do. I removed all comments and everything but i guess that shouldnt make a difference as it is release mode.
On the mac it works absolutely fine. Maybe I will bring the level size down and see if there is any change in the performance. but still if it can run on a 2.4ghz processor mac why wont it run on a high end PC? This is strange. In 2.x atleast the performance was same through out the systems
@siddharthshekar - out of curiosity how many GL verts and calls are happening in your game?
I recently discovered that culling doesn’t work if you use a custom camera. This happens on all operating systems. I modified CCSprite to cull with the current camera (in a similar way that CCSprite3D does) and I’m already seeing performance improvements.
I have 38000 gl calls and 13 gl calls. I am using tilemap so i dont know how it is coming to 38000 verts!?! And 13 gl calls1?!??!
So I can goto CCSprite class and make culling with current camera.Can you highlight the specific line in the class?
That’s fewer calls and verts than in my game =]
This change made a huge change for my game (Note - this can be optimized and improved further):
void Sprite::draw(Renderer *renderer, const Mat4 &transform, uint32_t flags)
{
#if CC_USE_CULLING
// sheado - modified culling to support any camera
AABB cPositionAABB = AABB(Vec3::ZERO, Vec3(_contentSize.width, _contentSize.height, _positionZ));
cPositionAABB.transform(getNodeToWorldTransform());
// camera clipping
_insideBounds = Camera::getVisitingCamera()->isVisibleInFrustum(&cPositionAABB);
// Don’t do calculate the culling if the transform was not updated
// _insideBounds = (flags & FLAGS_TRANSFORM_DIRTY) ? renderer->checkVisibility(transform, _contentSize) : _insideBounds;
if(_insideBounds)
#endif
Also, I’ve noticed that Spine SkeletonAnimation and ParticleSystem don’t cull as well. Are you using particles?
Anybody know if there’s a open issue related to culling not being fully implemented in all these classes?