The purpose is to test different texture formats. Can I specify DirectX or OpenGL for starling/stage3D? Otherwise, for textures like ETC, I have to test on mobile.
No, you can't. It's OS specific. For win7 it's d3d9 and win8 d3d11. For other platforms it's openGL.
Related
Topic is pretty much the question. I have OpenGL-based game with a lot of shaders. What I wanna do is convert it to Metal, so it can gain some perfomance from conversion, but I also want to have old devices support. Is it possible?
I dont know for sure if that works but
You could check which iOS device is used
Detect the specific iPhone/iPod touch model
And than execute the metal Code or the OpenGL es Code
Have a look at MetalGL. It is an implementation of OpenGL ES that runs on Metal. You write your app in OpenGL ES, and if Metal is available on the device, MetalGL will run the OpenGL ES code on Metal automatically, including shader conversion. If Metal is not available on the device, MetalGL will run the native OpenGL ES engine.
Depending on the nature of your app bottlenecks, your app may be more performant when running on Metal, and MetalGL can help you understand if and how your app will benefit from Metal, without you having to rewrite your app in Metal.
Full disclosure...I work on the MetalGL development team.
Yes it is possible. I do it in a released game.
To test for Metal support on a device call:
// this returns NULL if the device does not support Metal
Class metalAvailable = NSClassFromString(#"CAMetalLayer");
Then take separate paths in your code to either initialise your Metal renderer or your OpenGL ES renderer. It's all pretty easy.
I have a number of GLSL fragment shaders for which I can pretty much guarantee that they conform to #version 120 They use standard, non-ES conformant values and they do not have any ES-specific pragmas.
I really want to make a web previewer for them using WebGL. The previewer won't be used on mobile. Is this feasible? Is the feature set exposed to GLSL shaders in WebGL restricted compared to that GLSL version? Are there precision differences?
I've already tried playing with THREE.js but that doesn't really rub it since it mucks up my shader code before loading it onto the GPU (which I cannot do).
In short: is the GLSL spec sufficient for me to run those shaders?.. because if it isn't what I am after is not doable and I should just drop it.
No, WebGL shaders must be version #100. Anything else is disallowed.
If you're curious why it's because, as much as possible, WebGL needs to run everywhere. If you could choose any version your web page would only run on systems with GPUs/Drivers that handled that version.
The next version of WebGL will raise the version number. It will allow GLSL ES 3.0 (note the ES). It's currently available behind a flag in Chrome and Firefox as of May 2016
If I want to do scaling and compositing of 2D anti-aliased vector and bitmap images in real-time on Windows XP and later versions of Windows, making the best use of hardware acceleration available, should I be using GDI+ or DirectX 9.0c? (Actually, Windows XP and Windows 7 are important but we're not concerned about performance on Vista.)
Is there any merit in using SDL, given that the application is not cross-platform (and never will be)? I wonder if SDL might make it easier to switch to whichever underlying drawing API gives better performance…
Where can I find the documentation for doing scaling and compositing of 2D images in DirectX 9.0c? (I found the documentation for DirectDraw but read that it is deprecated after DirectX 7. But Direct2D is not available until DirectX 10.)
Can I reasonably expect scaling and compositing to be hardware accelerated on Windows XP on a mid- to low-spec PC (i.e. integrated graphics)? If not then does it even matter whether I use GDI+ or DirectX 9.0c?
Do not use GDI+. It does everything in software, and it has a rendering model that is not good for performance in software. You'd be better off with just about anything else.
Direct3D or OpenGL (which you can access via SDL if you want a more complete API that is cross-platform) will give you the best performance on hardware that supports it. Direct2D is in the same boat but is not available on Windows XP. My understanding is that, at least in the case of Intel's integrated GPU's, the hardware is able to do simple operations like transforming and composing, and that most of the problems with these GPU's are with games that have high demands for features and performance, and are optimized for ATI/Nvidia cards. If you somehow find a machine where Direct3D is not supported by the video card and is falling back to software, then you might have a problem.
I believe SDL uses DirectDraw on Windows for its non-OpenGL drawing. Somehow I got the impression that DirectDraw does all its operations in software in modern releases of Windows (and given what DirectDraw is used for it never really mattered since the win9x era), but I'm not able to verify that.
The ideal would be a cross-platform vector graphics library that can make use of Direct3D or OpenGL for rendering, but AFAICT no such thing is available. The Cairo graphics library lacks acceleration on Windows, and Mozilla has started a project called Azure that apparently has that but doesn't appear to be designed for use outside of their projects.
I just found this: 2D Rendering in DirectX 8.
It appears that since Microsoft removed DirectDraw after DirectX 7 they expected all 2D drawing to be done using the 3D API. This would explain why I totally failed to find the documentation I was looking for.
The article looks promising so far.
Here's another: 2D Programming in a 3D World
Apple provides the texturetool tool to cook textures into the PowerVR compressed texture format. My toolchain runs on Windows so I would like to create this texture data on a Windows PC. It looks like this will be simple because Imagination provides a tool and SDK that runs on windows. So I've downloaded PVRTexTool and will use that in my existing in-house texture cooking tool. Has anyone tried this? I'm wondering if there are any known incompatibilities between this and the iOS OpenGL ES implementation.
I now have this working and did not have any issues of compatibility with iOS.
One thing that confused me at first is that the standard formats that the tool does processing on are all ABGR format. You can convert your original data (mine was ARGB) into a standard format using the DecompressPVR function (even though my original data is not compressed).
Other issues that came up along the way:
- Compressed textures have to be square. You can use the ProcessRawPVR function to resize non-square textures to square
- the layout of the generated mipmaps in the resulting buffer is not obvious. You end up with one buffer containing all the mipmaps but, at runtime you need to add each mip map separately using glCompressedTexImage2D or glTexImage2D.
I want to use some of the features of OpenGL 4 (specifically, tessellation shaders and newer shader language versions) from WebGL. Is this possible, in either a standards-compliant or a hackish way? Is there some magic value I could use instead of, say, gl.FRAGMENT_SHADER to tell the underlying GL implementation to compile tessellation shaders?
WebGL is based on the OpenGL ES 2.0 Specification so you wouldn't be able to use GL4 unless the browser also somehow exposes a GL4 interface to JavaScript which i doubt. Even if a browser would give you such an interface it would only work on that browser.