just started learning cocos2d-x, but found no corresponding cocos2d-x APIs for the following code from cocos2d-iphone:
CCFileUtils *sharedFileUtils = [CCFileUtils sharedFileUtils];
[sharedFileUtils setEnableFallbackSuffixes:NO]; // Default: NO. No fallback suffixes are going to be used
[sharedFileUtils setiPhoneRetinaDisplaySuffix:"-hd"]; // Default on iPhone RetinaDisplay is "-hd"
[sharedFileUtils setiPadSuffix:"-ipad"]; // Default on iPad is "ipad"
[sharedFileUtils setiPadRetinaDisplaySuffix:#"-ipadhd"]; // Default on iPad RetinaDisplay is "-ipadhd"
so how can I customize suffix names in cocos2d-x?
Thanks.
Since 2.0.2 version you should use directories for different devices against suffixes in file names. You can see details here and in cocos2dx examples.
You can also find a method in CCFileUtils named setiPadSuffix(and also all the methods you mentioned above) to set the suffix.
Related
Code:
var bg = CCSprite(imageNamed:"Background.png")
Images used in Resource:
Background-hd.png
Background-ipad.png
Background-ipadhd.png
Background-iphone5hd.png
Background.png
In all device Background.png(320x480) used, other images are ignored. How to fix this ?
Retina display is not enabled...How to enable retina display in v3 ?
Here is working sample code with this problem.
I'm not really advanced user of SpriteBuilder but have some concerns about your issue.
As you are using Sprite Builder for starting the project, it configures your CCFileUtils to distinguish different devices' resources by looking at folders, not prefixes. In your app delegate you can see this line:
[CCBReader configureCCFileUtils];
going into this method you can see that search mode for file utils is set to CCFileUtilsSearchModeDirectory
sharedFileUtils.searchMode = CCFileUtilsSearchModeDirectory;
So you need to use Publish folders and copy your Background image to each of them with the same name (Background.png), but with different resolution for each device.
You don't need to use image suffixes in SpriteBuilder at all.
Finally Updated Cocos2d and now -hd,-ipad files are used. Just updated one line
sharedFileUtils.searchMode = CCFileUtilsSearchModeSuffix
I want to list all application which had been installed by reading uninstall registry file from HKEY_CURRENT_USER. But look like it can't be done by using QSettings, for some security reason ( i guess ).
QSettings maya("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall
People suggest to use WinAPI to accomplish this (at least, on Window platform)
Can somebody guide me how to add and use this lib please?
Thank
In order to get the list of all sub items under the "Uninstall" one in the Windows registry you need to use QSettings::childGroups() function, i.e:
QSettings m("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall",
QSettings::NativeFormat);
QStringList ak = m.childGroups();
This will return the list of all installed applications.
UPDATE:
After getting the list of installed applications one can read the installation details. There are two ways for doing that. For example to read the "UinstallPath" key for "Autodesk Maya 2014" application:
m.beginGroup("Autodesk Maya 2014");
QString path = m.value("UninstallPath").toString();
m.endGroup();
or simply:
QString path = m.value("Autodesk Maya 2014/UninstallPath").toString();
I’m trying to compile Tesselation’s example from http://www.kdab.com/opengl-in-qt-5-1-part-5/ (source included) with the Compatibility profile and it’s simply incapable to load this profile:
The minor (and only) modifications I’ve made:
#terraintessellationscene.h:
QOpenGLFunctions_4_3_Compatibility* m_funcs;
#terraintessellationscene.cpp:
m_funcs = m_context->versionFunctions<QOpenGLFunctions_4_3_Compatibility>();
if ( !m_funcs )
{
qFatal("Requires OpenGL >= 4.0");
exit( 1 );
}
m_funcs->initializeOpenGLFunctions();
It just crashes when I call versionFunctions(). And it should work. I can compile this source and several other different project of different complexity using any Core Profile desktop profile. I'm going to try to use GLEW later on to see if this problem is related to QT or my usage of QT or my opengl driver.
I’m using lasted AMD’s 14.4 WHQL. I’ve tried to using the pre-built 5.3 source and my self-compiled static version of 5.3. I’ve tried two old AMD drivers to see if this was a problem with the OpenGL package provided by AMD and yet it fails. I really want to use versionFunctions.
Update 2
It seems QOpenGLContext create(), after setting the QSurfaceFormat properly (QOpenGLContext::setFormat(format), is completely rejecting the compatibility settings (format.setProfile( QSurfaceFormat::CompatibilityProfile) and creating a Core Profile context instead, completely ignoring my request for a compatibility context and yet returning true as a successful operation that couldn't follow QSurfaceFormat format rules.
Update 3
Well, I just discovered the issue and it is not related to my modifications, it’s in the original code at kdab:
// Create an OpenGL context
m_context = new QOpenGLContext;
m_context->setFormat( format );
m_context->create();
by creating the context before setFormat, I was able to correctly initiate a proper Compatibility Context, as QT was simply setting part of my settings related to setProfile( QSurfaceFormat::CoreProfile)
Update 4: Final solution
"Creating the context before setFormat() is wrong and works by accident since what you are requesting then is a plain OpenGL 2.0 context and the driver most likely gives you 4.3 compatibility. On other drivers or platforms this may fail so be careful.
The behavior you are seeing is caused by the AMD driver: it refuses to create a proper compatibility profile context unless the forward compatibility set is not set. Qt sets the fwdcompat bit by default, it can be turned off by setting the DeprecatedFunctions option on the QSurfaceFormat. So requesting for Compatibility together with DeprecatedFunctions will give what you want. Other vendors’ drivers do not have this problem, there not setting DeprecatedFunctions (i.e. setting forward compatibility) is ignored for compatibility profiles, as it should be."
via agocs # qt devnet
you are getting the core profile (thanks to Qt) while you want the compatibility profile
you should request the compatibility profile on initializing by setting the format as follows
window.cpp line 24
format.setProfile( QSurfaceFormat::CompatibilityProfile);
and only call the versionFunctions after context has been created
I am trying to make dynamically generated html 5 graphs show up in a webview in Blackberry 10 Cascades. I have confirmed the html5 that I have generated, draws the correct graphs. My problem is that when I try to implement this in the Blackberry 10 Cascades Beta 3 SDK (using the Blackberry 10 Dev Alpha Simulator), the webview that is supposed to show the graph, just looks like this:
Here is the code that leads to this error:
//html_ already contains the html-5 code to make the graph at this point in the code
//This is the file path to a local file that is actually accessable in the emulator
//and not just from Windows
//
QFile *chartFile = new QFile("app/native/assets/data/chart.html");
if (chartFile->open(QIODevice::WriteOnly)) {
chartFile->write(html_.toUtf8());
chartFile->flush();
chartFile->close();
}
if (chartFile) delete chartFile;
if (graphView_) {
graphView_->setHtml("");
graphView_->setUrl(QUrl::fromLocalFile("app/native/assets/data/chart.html"));
}
I checked the permissions of that file, put they are all Allow (777 permissions for those who know Unix style permissions).
I added access_internet to the bar-descriptor.xml, eventhough my app was already able to access remote sites, just to see if that would fix it, but it did not.
I've been searching around trying to find a solution to this problem, but I have not.
If anyone could help me out with this, it would be greatly appreciated.
-------------------------------------------------------
Update:
I changed the code to set the html directly, now I have this:
if (graphView_) {
graphView_->setHtml(html_, QUrl("app/native/assets/data/chart.html"));
}
But nothing shows. It seems I have the wrong relative path relative to my base url.
My base url is this: QUrl("app/native/assets/data/chart.html")
My relative paths all begin with: ./Highcharts/js/...
My relative paths are located under: app/native/assets/data/Highcharts/js
It seems to me that I this should work, but when I do this, I just a blank screen, as if it can not find my relative paths. So I don't know what's going on here either.
I found a solution that works. I'm using the first approach, not the updated approach, but instead of
graphView_->setUrl(QUrl("app/native/assets/data/chart.html"));
I'm using:
graphView_->setUrl(QUrl("local:///assets/data/chart.html"));
And I have left the rest of the code the same, and it works.
I want to use the functions exposed under the OpenGL extensions. I'm on Windows, how do I do this?
Easy solution: Use GLEW. See how here.
Hard solution:
If you have a really strong reason not to use GLEW, here's how to achieve the same without it:
Identify the OpenGL extension and the extension APIs you wish to use. OpenGL extensions are listed in the OpenGL Extension Registry.
Example: I wish to use the capabilities of the EXT_framebuffer_object extension. The APIs I wish to use from this extension are:
glGenFramebuffersEXT()
glBindFramebufferEXT()
glFramebufferTexture2DEXT()
glCheckFramebufferStatusEXT()
glDeleteFramebuffersEXT()
Check if your graphic card supports the extension you wish to use. If it does, then your work is almost done! Download and install the latest drivers and SDKs for your graphics card.
Example: The graphics card in my PC is a NVIDIA 6600 GT. So, I visit the NVIDIA OpenGL Extension Specifications webpage and find that the EXT_framebuffer_object extension is supported. I then download the latest NVIDIA OpenGL SDK and install it.
Your graphic card manufacturer provides a glext.h header file (or a similarly named header file) with all the declarations needed to use the supported OpenGL extensions. (Note that not all extensions might be supported.) Either place this header file somewhere your compiler can pick it up or include its directory in your compiler's include directories list.
Add a #include <glext.h> line in your code to include the header file into your code.
Open glext.h, find the API you wish to use and grab its corresponding ugly-looking declaration.
Example: I search for the above framebuffer APIs and find their corresponding ugly-looking declarations:
typedef void (APIENTRYP PFNGLGENFRAMEBUFFERSEXTPROC) (GLsizei n, GLuint *framebuffers); for GLAPI void APIENTRY glGenFramebuffersEXT (GLsizei, GLuint *);
All this means is that your header file has the API declaration in 2 forms. One is a wgl-like ugly function pointer declaration. The other is a sane looking function declaration.
For each extension API you wish to use, add in your code declarations of the function name as a type of the ugly-looking string.
Example:
PFNGLGENFRAMEBUFFERSEXTPROC glGenFramebuffersEXT;
PFNGLBINDFRAMEBUFFEREXTPROC glBindFramebufferEXT;
PFNGLFRAMEBUFFERTEXTURE2DEXTPROC glFramebufferTexture2DEXT;
PFNGLCHECKFRAMEBUFFERSTATUSEXTPROC glCheckFramebufferStatusEXT;
PFNGLDELETEFRAMEBUFFERSEXTPROC glDeleteFramebuffersEXT;
Though it looks ugly, all we're doing is to declare function pointers of the type corresponding to the extension API.
Initialize these function pointers with their rightful functions. These functions are exposed by the library or driver. We need to use wglGetProcAddress() function to do this.
Example:
glGenFramebuffersEXT = (PFNGLGENFRAMEBUFFERSEXTPROC) wglGetProcAddress("glGenFramebuffersEXT");
glBindFramebufferEXT = (PFNGLBINDFRAMEBUFFEREXTPROC) wglGetProcAddress("glBindFramebufferEXT");
glFramebufferTexture2DEXT = (PFNGLFRAMEBUFFERTEXTURE2DEXTPROC) wglGetProcAddress("glFramebufferTexture2DEXT");
glCheckFramebufferStatusEXT = (PFNGLCHECKFRAMEBUFFERSTATUSEXTPROC) wglGetProcAddress("glCheckFramebufferStatusEXT");
glDeleteFramebuffersEXT = (PFNGLDELETEFRAMEBUFFERSEXTPROC) wglGetProcAddress("glDeleteFramebuffersEXT");
Don't forget to check the function pointers for NULL. If by chance wglGetProcAddress() couldn't find the extension function, it would've initialized the pointer with NULL.
Example:
if (NULL == glGenFramebuffersEXT || NULL == glBindFramebufferEXT || NULL == glFramebufferTexture2DEXT
|| NULL == glCheckFramebufferStatusEXT || NULL == glDeleteFramebuffersEXT)
{
// Extension functions not loaded!
exit(1);
}
That's it, we're done! You can now use these function pointers just as if the function calls existed.
Example:
glGenFramebuffersEXT(1, &fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, colorTex[0], 0);
Reference: Moving Beyond OpenGL 1.1 for Windows by Dave Astle — The article is a bit dated, but has all the information you need to understand why this pathetic situation exists on Windows and how to get around it.
A 'Very strong reason' not to use GLEW might be that the library is not supported by your compiler/IDE. E.g: Borland C++ Builder.
In that case, you might want to rebuild the library from source. If it works, great, otherwise manual extension loading isnt as bad as it is made to sound.
#Kronikarz: From the looks of it, GLEW seems to be the way of the future. NVIDIA already ships it along with its OpenGL SDK. And its latest release was in 2007 compared to GLEE which was in 2006.
But, the usage of both libraries looks almost the same to me. (GLEW has an init() which needs to be called before anything else though.) So, you don't need to switch unless you find some extension not being supported under GLEE.
GL3W is a public-domain script that creates a library which loads only core functionality for OpenGL 3/4. It can be found on github at:
https://github.com/skaslev/gl3w
GL3W requires Python 2.6 to generate the libraries and headers for OpenGL; it does not require Python after that.