Cocos2d-iphone uses the -hd extension for Retina images (and other assets). The cocos2d Retina guide speaks only vaguely of "some incompatibilities" regarding #2x:
Apple uses the ”#2x” suffix, but cocos2d doesn't use that extension
because of some incompatibilities. Instead, cocos2d has its own
suffix: ”-hd”.
WARNING: It is NOT recommend to use the ”#2x” suffix. Apple treats
those images in a special way which might cause bugs in your cocos2d
application.
Great. I feel well informed.
Through a 2-year old bug report regarding #2x I got the link to a forum thread that supposedly explains the issues with #2x. However, it does not. The only hints I found in there is that there are iOS (4.0/4.1) bugs regarding #2x which I suppose are no longer relevant. It's possible that I might have missed some crucial aspect (there was some talk about caching or repeat loading issues) - the thread is very long after all.
I'd like to know what specific issues might a cocos2d developer encounter if (s)he is using the #2x suffix for images instead of -hd?
Please give concrete examples of things that might go or actually will be wrong.
This seems to be the main reason from this link: http://www.cocos2d-iphone.org/forum/topic/12026
Specifically this post by riq:
I don't know if initWithContentsOfFile was fixed, but in 4.0 it was broken and it wasn't working with #2x, ~iphone extensions.
imageNamed caches all the loaded files so it consumes much more memory than initWithContentsOfFile
Also the #2x extension does something (I don't know exactly what) but it doesn't work OK with cocos2d.
Another good point: Back when the iPhone 4 was just released with the retina display, I am sure some users of Cocos2D were using an older version of it so when the user was using the retina display on a version of Cocos2D that didn't support it, things were twice as large as they should've been. Again this is now fixed to most unless you are using a VERY early version of Cocos2D.
Overview, so it seems that the main issue was with initWithContentsOfFile from iOS 4 but they have fixed this since because I use that exact API with Cocos2D 2.0-rc2 in my app and I do not have any issues whatsoever. I use all Apple specified extensions for images and everything works jolly good! :)
It seems as if this has a historic background.
What makes using -hd graphics still worthwhile is that loading them doesn't rely on Apple functionality but is rather done in framework code. So -hd can be loaded for iPads in iPhone Simulator mode and make use of the higher resolution pictures in 2x mode.
Other than that I couldn't find any more reasons to not use #2x when I was looking into this a week ago.
In case you want all the details it is probably best to drop riq an email.
Related
Is there any way to make my app work on ipad 3 without updating to cocos2d 1.0.1 or higher?
I am using cocos2d 0.99.5 and a third party framework (not mine) which uses cocos2d 0.99.5
Updating to cocos2d 1.0.1 or higher would be a colossal work.
My app is working in ipad 1 and ipad 2, but in ipad 3 i just see a black screen (and listen to the music)
Thank you!!
Possibly, if you can retrace what has been done to add iPad 3 support between 0.99.5 and v1.0.1. You can use the github commit history. Though this will not be an easy task, and possibly cost you more time than updating to v1.0.1.
Why would updating be a colossal task? If you tried it and found hundreds if not thousands of errors, this does not mean you'll have to apply the same number of fixes. One renamed cocos2d class can already give you dozens and more errors depending on the class and your project.
To update cocos2d follow the steps described here. Especially important and often forgotten is to actually delete all the old cocos2d files, otherwise you may still be using old version source files in your project causing all kinds of trouble.
From what I recall when I updated the first edition of my book (cocos2d 0.99) to the second edition (cocos2d 1.0.1) there was very little code between those two cocos2d versions that actually forced me to write new code. 99% of the changes are merely renamed classes, methods and properties - renaming them accordingly fixes 80% of the issues, and the rest are new or removed or re-arranged parameters of methods, almost as easily fixed though not as easily because you can't always use refactor respectively search & replace to fix those.
I suggest to fix the easy ones first (renamed classes, methods, properties) and then get to the rest. If you need help, you already know how to use SO. ;)
I'm interested to know if gtkmm w/ ATK (or whatever) works with MSAA like Qt does. We're looking right now at switching toolkit from WX and it turns out that our testing software relies on MSAA to do it's thing (something I wish I'd known 3 years ago when we picked WX to begin with). Of all the GUI toolkits, I prefer GTKmm mainly due to it's use of signals and slots but in a way much more expressive and generic than Qt's....and without the need for the extra build step that requires the Qt VS plugin. The designer is much better too.
So I'd like to use GTKmm but the only discussions and google stuff I can find on the topic are 3+ years old. They lead me to believe the answer is no, it doesn't support it and if it does it's really shoddy. But a lot can change in 3 years.
So, anyone that uses GTK or GTKmm on win32 know if it supports the windows accessibility framework?
I can’t say for sure but I would lean toward very little to no support. I use the Jaws screen reader SOFTWARE SINCE I’m blind. It uses MSAA quite heavily and GTK applications such as Pidgin are almost completely inaccessible. While I can read some of the text on a screen figuring out weather I’m in an edit field or weather a button is selected is impossible. If my screen reader can’t deal with GTK applications I assume your testing software will have major issues as well.
I don't know if this is still being tracked but I will second this assessment as another windows screen reader user. gnuCash was the app I tried and it was pretty rough going. Worked like a dream in Gnome with Orca though. Apparently, it's like this, if you want windows accessibility, use QT and WxWidgets. If you want Linux, use gtk+. QT is going to be accessible in Linux apparently though this is yet to be (not till gnome 3, I think). Pity you had to abandon WxWidgets. I personally like their widgets since it has those sizers which take much of the guess work out of placement of controls. Important when you can't see and you want to build a gui. Looks like about the only cross-platform accessibility solutions right now are Xul and SWT (Java, you know). Sad thing about WxWidgets is that this sort of thing was reported to them two years ago but nothing seems to have been done about it.
http://trac.wxwidgets.org/ticket/9785
I would be delighted to know that I am wrong about this. I doubt it, though.
I wrote a program in C++/OpenGL (using Dev-C++ compiler) for my calculus 2 class. The teacher liked the program and he requested me to somehow put it online so that instead of downloading the .exe I can just run it on the web browser. Kinda like java applets run on the browser.
The question is:
How if possible, can I display a C++/OpenGL program in a web browser?
I am thinking of moving to JOGL which is a java interpretation of OpenGL but I rather stay in C++ since I am more familiar with it.
Also is there any other better and easier 3D web base API that I can consider?
There is a lot activity recently with WebGL. It is a binding for Javascript to native OpenGL ES 2.0 implementations, designed as an extension of the canvas HTML5 element.
It is supported by the nightly builds of Firefox, Safari, Chrome and Opera.
Have a look at these tutorials, based on the well known NeHe OpenGL tutorials.
Several projects based on WebGL are emerging, most notably Scenegraphs APIs.
From Indie teams: SceneJS, GLGE, SpiderGL.
From Google: the team behind O3D plugin is trying to implement a pure WebGL backend (source) for the project, so that no plugin will be necessary.
From W3C/Web3D: There is an ongoing discussion to include X3D as part of any HTML5 DOM tree, much like SVG in HTML4. The X3DOM project was born last year to support this idea. Now it is using WebGL as its render backend, and is version 1.0 since March 2010.
I'm almost sure that WebGL is the way to go in the near future. Mozilla/Google/Apple/Opera are promoting it, and if the technology works and there is sufficient customer/developer demand, maybe Microsoft will implement it on IE (let's hope that there will be no "WebDX"!).
AFAIK, there's only 3 options:
Java. it includes the whole OpenGL stack.
Google's Native Client (NaCL), essentially it's a plugin that let's you run executable x86 code. Just compile it and call it from HTML. Highly experimental, and nobody will have it already installed. Not sure if it gives you access to OpenGL libraries.
Canvas:3D. Another very experimental project. This is an accelerated 3D API accessible from JavaScript. AFAICT, it's only on experimental builds of Firefox.
I'd go for Java, if at all.
OTOH, if it's mostly vectorial works (without lots of textures and illumination/shadows), you might make it work on SVG simply by projecting your vectors from 3D to 2D. In that case, you can achieve cross-browser compatibility using SVGWeb, it's a simple JavaScript library that allows you to transparently use either the browser's native SVG support or a Flash-based SVG renderer.
Do you really have the time to rewrite it? I thought students were meant to be too busy for non-essential assignment work.
But if you really want to do it, perhaps a preview of it running as a flash movie is the easiest way. Then it's just a matter of doing that and you could provide a download link to the real application if people are interested.
Outside of Java, in-browser OpenGL is really in its infancy. Google's launched a really cool API and plugin for it though. It's called O3D:
http://code.google.com/apis/o3d/
Article about the overall initiative:
http://www.macworld.com/article/142079/2009/08/webgl.html
It's not OpenGL, but the Web3D Consortium's X3D specification may be of interest.
Another solution is to use Emscripten (a source-to-source compiler).
Emscripten supports C/C++ and OpenGL and will translate the source into html/JavaScript.
To use Emscripten you will need to use SDL as a platform abstraction layer (for getting an OpenGL context as well as loading images).
Emscripten is currently being used in Unreal Engine and will also be used in the Unity 5 engine.
Read more about the project here:
https://github.com/kripken/emscripten
Two approaches:
Switch to Java. However, your application will suffer from a loss of performance as a trade off for portability. But since Java is everywhere, this approach ensures that your code can be executed in most browsers.
Use ActiveX, which allows you to run native binary code for Microsoft Windows. This is not recommended in production because activeX is well known as a potential security hole, but since your lecturer is the one viewing it, security doesn't seem to be a big deal. This is applicable for Microsoft platform (Windows+IE) only.
I'm trying to understand how graphics card versions, OpenGL versions and the API headers work together. I've read up on the OpenGL 2.0/3.0/3.1 debacle on the OpenGL forums and elsewhere but it's still not clear how this will work out for me as a developer (new to OpenGL). (btw I'm using nVidia in this question as an example because I'm buying one of their cards, but obviously I'd like to be vendor agnostic for the software I develop).
First, there is the GPU which needs to support an OpenGL version. But e.g. nVidia have drivers for older video cards to support OpenGL 3. Does that mean that these drivers implement certain functionality in software to emulate new functionality that isn't in the hardware?
Then there are the API headers. If I decide to write an application for OpenGL 3, should I wait until Microsoft releases an updated version of the platform SDK with headers that support this version? How do you select which version of the API to use - through a preprocessor define in the code, or does updating to the latest platform SDK simply upgrade to whatever is the latest version (can't imagine this last option, but you never know...).
What about backward compatibility? If I write an application targeting OpenGL 1.2, will users who have installed the drivers for their card supporting OpenGL 3 still be able to run it or should I test the card's features/supported version in my application? Reading http://developer.nvidia.com/object/opengl_3_driver.html seems to confirm that at least for nVidia cards applications written against 1.2 will continue to work, but this also implies that other vendors may stop to support the 1.2 API. Basically that would put me (potentially) in a position in the future where the software wouldn't work with recent cards because they don't support 1.2 any more. But if I develop for OpenGL 3 or even 2 today, I may shut out users who's gpu's only support 1.2.
I don't need the fancy features in OpenGL - I hardly use any shading at all, the fixed pipeline works fine for me (my application is CAD-like). What is the best version to base a new application on, with the expectation that it will be a long-lived application with incremental updates over the years to come?
I'm probably forgetting other issues that are relevant in this context, any insights are much appreciated.
From my OpenGL experience, it seems that "targeting" a given version is just accessing the various extensions that have been added for that version. So the only reason you would "target" OpenGL version 3 is if you want to use some of the extensions that are new to version 3. If you don't really use version 3 extensions (if you're just doing basic OpenGL stuff), then you naturally aren't "targeting" version 3.
In Visual Studio, you will always link your application with opengl32.lib, and opengl32.lib doesn't change across different OpenGL versions. OpenGL instead uses wglGetProcAddress() to dynamically access OpenGL extensions/versions at run time instead of at compile time. Namely, if a given driver doesn't support an extension, then wglGetProcAddress() will return NULL at run-time when that extension's procedure is requested. So in your code you will need to implement logic that handles the NULL return case. In the simplest scenario, you could just print an error and say "this feature isn't available, so this program will behave ...". Or you can find other alternative methods for doing the same thing that doesn't use the extension. For the most part, you'll only get NULL returns from wglGetProcAddress if you application is running on old hardware/drivers that don't support the OpenGL version that added the extension you're looking for. However, in future years you'll want to keep abreast of those things that newer OpenGL versions decide to deprecate. I haven't read too much into the 3.1 spec, but apparently they're introducing a deprecation model where older technology/extensions may be deprecated, which will open the door for newer hardware/drivers to no longer support deprecated extensions, in which case wglGetProcAddress will again return NULL for those extensions. So if you put logic in for handling the NULL return on wglGetProcAddress(), you should still be fine even for deprecated extensions. It just might become necessary for you to implement better alternatives, or to make newer extensions default.
As far as the versioned API headers go, the changes to the headers are mostly just changes to allow access to new functions returned by wglGetProcAddress(). So if you include the API header for version 2, you're good to go as long as you only need the extensions for OpenGL 2. If you need to access functions/extensions that were added in version 3, then you just replace your version 2 header with the version 3 header, which just adds some additional function pointer typedefs associated with the new extensions, so that when you call wglGetProcAddress(), you can cast the return value to the right function pointer. Example:
PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL;
...
glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB");
In the above example, the typedef for PFNGLGENQUERIESARBPROC is defined in the API headers. glGenQueriesARB was added in 1.2 I believe, so I'd need at least the 1.2 API headers to get the definition of PFNGLGENQUERIESARBPROC. That's really all the headers do.
One more thing I want to mention about 3.1. Apparently with 3.1 they're deprecating a lot of OpenGL functionality that my company has used pretty ubiquitously, including display lists, the glBegin/glEnd mechanisms, and the GL_SELECT render mode. I don't know much about the details, but I don't see how they can do that without having to create a new opengl32.lib to link with, because it seems that most of that functionality is embedded into opengl32.lib, and not accessed through wglGetProcAddress. Additionally, is Microsoft going to include that new opengl32.lib in their Visual Studio versions? I don't have an answer for those questions, but I would think that, even though 3.1 deprecates it, this functionality is going to be around for a long time. If you keep linking with your current opengl32.lib, it should continue to work almost indefinitely, although you may lose hardware acceleration at some point. The vast majority of OpenGL tutorials available on the web use the glBegin/glEnd methods for drawing primitives. The same is true for GL_SELECT, although a lot of hardware no longer accelerates GL_SELECT render mode. Even opengl.org's tutorial's use the supposedly deprecated glBegin/glEnd methods. And I have yet to find a "getting started" tutorial that uses only 3.1 features, avoiding the deprecated functionality (certainly if someone knows of one, link me to it). Anyway, while it seems 3.1 has thrown away a lot of the old for all new stuff, I think the old stuff will still be around for quite a while.
Long story short, here's my advice. If your OpenGL needs are simple, just use the basic OpenGL functionality. Vertex arrays are supported on versions 1.1 - 3.1, so if you're looking for maximum lifetime and you're starting fresh, that's probably what you should use. However, my opinion is glBegin/glEnd and display lists are still going to be around for a while even though they are deprecated in version 3, so if you want to use them, I wouldn't fret too much. I would avoid GL_SELECT mode for picking in favor of an alternate method. Many of the hardware vendors have considered GL_SELECT deprecated for years now, even though it just got deprecated with version 3. In our application we get lots of issues where it doesn't work on ATI cards and integrated GMA cards. Subsequently we just implemented a picking method using occlusion queries which seems to fix the problem. So to do it right the first time, avoid GL_SELECT.
Good Luck.
As far as drivers go, I think that in some cases missing functionality it written in software. The whole point of using OpenGL (aside from the acceleration) is to write to an API and not care HOW it's implemented.
In my experience, you don't declare OpenGL versions. The function calls between API versions are non-overlapping. Be aware of the spec and if, for example, you call a 2.0 method, your application's minimum version just became 2.0. I have display applications written to target OpenGL (stupid old Sun video cards) and it works just fine on brand new nvidia 200 series cards.
I don't think there is anyway to guaranteee that an api won't change in the future; especially if you don't control it. Your application may stop working in 10 years when we're on OpenGL 6.4. Hopefully you've written a good enough application that customers will be willing to pay for an upgrade.
This fellow, MarK J. Kilgard has been publishing nVidia source code and documents on openGL since the 90's and has been doing so on behalf of one of the two biggest names in gaming hardware.
//-------------------------------------------------------------------------------------
... the notion that an OpenGL application is "wrong" to ever use immediate mode is overzealous. The OpenGL 3.0 specification has even gone so far as to mark immediate mode in OpenGL for "deprecation" (whatever that means!); such extremism is counter-productive and foolish. The right way to encourage good API usage isn't to try to deprecate or ban API usage, but rather educate developers about the right API usage for particular situations.
When I started using SoundEngine (from CrashLanding and TouchFighter), I had read about a few people recommending not to use it, for it was, according to them, not stable enough. Still it was the only solution I knew of to play sounds with pitch and position control without learning C++ and OpenAL, so I ignored the warnings and went on with it.
But now I'm starting to worry. The 2.2 SDK introduced AVFoundation. Using both SoundEngine from CrashLanding (for sounds) and AVAudioPlayer (for music), I found out SoundEngine behaves strangely when the only existing AVAudioPlayer is released (all sounds stop until a new AVAudioPlayer is initiated). Around the same time as the 2.2 SDK came out, the CrashLanding sample code was mysteriously removed from the ADC site. I'm worried there are more bad surprises to come.
My question is, is anyone aware of an Open Source alternative to SoundEngine? Maybe even a C++ library that uses OpenAL?
Look at this library, but i don't know is this what you need.
The Kowalski project provides a data driven and portable sound engine that currently runs on iOS, OS X and Windows. The engine is released under the zlib license and provides positional audio, pitch control etc.
ObjectAL for iPhone
Clone it. Use it. Love it. Enjoy the freedom.
Why not just use AVFoundation? It's pretty simple to handle and nicely flexible - apart from if you need exact timing (says the Apple documentation - but I've been testing it fairly extensively and yet to find any significant practical issues) I don't see any reason for not leveraging it.
AVFoundation lacks sound placement. This makes me sad.
I’ve written a simple sound engine around OpenAL. There are no position controls (I didn’t need them), but they would be trivial to add if you find the rest to your liking. And there is also some experimental sound code in the Cocos2D engine. It has both pitch and position controls and looks quite usable.