Hi,
We’re starting the code for a cross platform game (iOS, Mac, Win32) using cocos2d. I’m making sure we can get it running fullscreen on mac and windows, and when I run the default proj.mac and switch to fullscreen, I can’t click the exit menu button in the bottom right hand corner.
Is it expected to work? There’s code to switch to fullscreen in the generated project so I assume so… but I don’t want to get too far down the line with it to find we can’t switch to fullscreen to play the game.
Bit more information: it’s happening because the touch coordinates aren’t being translated to take into account the increased resolution. So the original HelloWorld is 480x320, but switching to fullscreen you have to click the original coordinate of the menu button to activate it, not where the menu button appears on screen.
Look here, same problem: including a fix someone made:
http://www.cocos2d-x.org/boards/6/topics/23270
That is the trouble with cocos2d-x, the devs are too concerned with more and more features and too little with bug fixing (Even the latest “stable” version seems to have bugs) and nothing else. And the community isn’t just as helpful as it was with cocos2d-iphone.
It is a shame really, a bit more support and a more helpful community and this framework could easily be a standard on every platform.
Instead it feels more like, here the framework, we made it now good luck with.
It just feels a bit too much like linux too me. beginnerunfriendly, lack of support, but hey it is open source and free so you can fix it yourself.
And this way of thinking is exactly the problem with linux or cocos2d-x for that matter.
It is not important to have constantly new features if the old ones are not working properly.
Stop adding functionality, start fixing it, look at the comments beneath the latest “stable” release.
This is just a joke. Well I am thinking seriously right now about Unity3D and 2DToolkit just because this framework is more patchwork than something else.
Maybe you really have to invest money to get something useful in this world and Open Source is really just a bad joke.
Somewhere someone said this framework uses desktop only for debugging.
Why? This is just stupid.
This project could easily be so much more, but the people in charge seem to be only driven by the newest and shiniest.
So established plattforms are neglected entirely or to phrase it more with words of the OS-Community:
“If you want it on desktop you can easily port it, it is awesome, because it is open source and free.”
Yeah I can, but that takes time, and if you just want to make a game and not start repairing someone’s work it is just not worth it.
@Mike Heald
Sorry for the rant, I hope the other thread helps you.
Sounds like a familiar rant, and I don’t think it’s as bad as all that.
There are a couple of things that are good news, and a couple of things that would really improve the desktop issues.
Ric has moved from maintaining iphone to focussing onx. He’s already heading up work on v3.0 with a new rendering pipeline, c++11 updates, etc. Keyboard support is planned for the 3.0 preview release.
There will be a cleanup of the platform code. Hurrah!
I looked at the pull request to add keyboard support to Mac and Windows, and I think it highlights something that I would change, if I were in charge. We’re maintaining our own, platform specific code for managing windows and opengl. Along with that goes platform specific code for handling keyboards. Want to add joystick support? You’ve got to write it three times, once for linux, once for mac, once for win32. The thing is, there are already great, well supported, well tested, libraries for doing this. In fact, the linux platform code uses one, GLFW. And GLW has support for keyboard events AND joystick events. And it supports, mac, windows, and linux. It does fullscreen pretty well, as long as your design and your screen resolution have the same aspect ratio, there are no issues with misplaced touch/mouse events on linux using GLFW. It would also allow people producing their game for the desktop to get joystick events from GLFW without having to modify the cocos2d-x code.
It’s the single change I want to see that would have me use cocos2d-x as my only framework. Bugs in PhysicsSprite, I can live with. But I can’t code my game without keyboard and joystick support.
I hope that SDL+OpenAL can help in situation with desktops, win32/OSX/Linux backends can be merged to one that relies to SDL and OpenAL, and joystick or fullscreen support can be implemented on top of these APIs.
Work already started: unified OpenAL engine for Linux, Blackberry, NaCL and Tizen merged to develop branch, OpenAL backend for Windows will be merged soon and OSX uses it too via Objective-C. Linux SDL backend probably will be merged in this month, and can be re-used for Windows and OSX.
Meanwhile android and iOS will use a lot of platform-specific code even in version 3.x, more information here: https://groups.google.com/forum/?fromgroups#!topic/cocos2d-js-devel/97p8KZwkiWE
Sergey Shambir wrote:
Meanwhile android and iOS will use a lot of platform-specific code even in version 3.x, more information here: https://groups.google.com/forum/?fromgroups# How easily could this be reused? I’d much rather use cocos2d-x for my project, so if this is coming soon, I’ll hold off the coding stage.
I fixed the Full Screen toggle so that correctly works w/ proper touch handling. Here is how I did it:
In applicationDidFinishLaunching make sure to create the window to be full size of display. Scale down the window to 60% of screen size by calling [glView setFrameZoomFactor:0.6];
In EAGLView.h add a new float variable to remember zoom factor just like it remembers the rect size when switching to full screen. I called it originalZoomFactor_.
Inside of setFullScreen add originalZoomFactor_ = frameZoomFactor_; when going full screen. After that set zoom factor to 1.0.
When coming out of full screen in the same function set frameZoomFactor_ = originalZoomFactor_;
Done. Now touch handling works properly between full screen and window mode.
@tmsoft wrote:
I fixed the Full Screen toggle so that correctly works w/ proper touch handling. Here is how I did it:
In applicationDidFinishLaunching make sure to create the window to be full size of display. Scale down the window to 60% of screen size by calling [glView setFrameZoomFactor:0.6];
In EAGLView.h add a new float variable to remember zoom factor just like it remembers the rect size when switching to full screen. I called it originalZoomFactor_.
Inside of setFullScreen add originalZoomFactor_ = frameZoomFactor_; when going full screen. After that set zoom factor to 1.0.
When coming out of full screen in the same function set frameZoomFactor_ = originalZoomFactor_;
Done. Now touch handling works properly between full screen and window mode.
I have been trying to understand this post for a while, but I cannot seem to extract the solution from these brief notes.
lets say for example, that I want to use 1.0f for my scale factor. I have tried storing it and setting it as you say, but nothing seems to change.
Is there any additional detail or change that isn’t mentioned in your post?