I have noticed that some modern mobile hardware support 2D hardware accelerated bitBLT operations. Is there are any fairly standard libraries that allow an application developer to take advantage of 2D hardware acceleration? (Something that is for 2D what OpenGL is for 3D would be nice)
Edit: I know that OpenGL can be used for 2D operations but when one uses openGL one uses the 3D Hardware block and not the 2D hardware block. I am looking for an API that makes direct use of the 2D hardware block.
OpenGL can be used not only for 3d, but for 2d too. So the answer is: OpenGL
Almost every game on the market (including 2d games) use OpenGL for rendering. You might want to take a look at Cocos2d-x. It is a crossplatform c++ game engine, that use OpenGL for 2d graphics
Related
I know that DirectX and OpenGL are both built into a graphics card and you can access them when you need to so all the rendering will be hardware based accelerated.
I can't find anything about GDI but i'm sure it's not a graphics card based acceleration.
How does those technologies differ and what am i missing here?
The GDI library dates back to the early 90s and the first versions of Windows. It's supports a mix of hardware-accelerated raster ops and software vector graphics drawing. It is primary for drawing 'presentation' graphics and text for GUIs. GDI+ was a C++ class-based wrapper for GDI, but is basically the same technology. Modern versions of Windows still support legacy GDI APIs but modern graphics cards don't implement the old fixed-function 'raster ops' hardware accelerated paths--it's not really accurate to even refer to the video cards of the early 90s "GPUs".
OpenGL and Direct3D are graphics APIs built around pixels, lines, and triangles with texturing. Modern versions of both use programmable shader stages instead of fixed-function hardware to implement transform & lighting, texture blending, etc. These enable 3D hardware acceleration, but by themselves do not support classic 'raster ops' or vector-based drawing like styled/wide lines, filled ellipses, etc. Direct2D is a vector graphics library that does these old "GDI-style" operations on top of Direct3D with a mix of software and hardware-accelerated paths, and is what is used by the modern Windows GUI in combination with DirectWrite which implements high-quality text rendering.
See Graphics APIs in Windows, Vector graphics, and Raster graphics.
In short, for modern Windows programming you should use Direct2D/DirectWrite for 'presentation graphics' perhaps via a wrapper like Win2D, and Direct3D for 2D raster "sprite" graphics or 3D graphics rendering (see DirectX Tool Kit).
GDI is pure 2D image access and rendering (with very limited acceleration on a raster level if not disabled). So in GDI there are no:
textures
shaders
buffers
depth/stencil buffers
transform matrices
gfx pipeline
The differences are:
transparency is done by specific color value instead of alpha channel
blending is possible in only per channel add,xor,copy modes
you can get direct pixel access
got windows font access and text functions support
window related GDI calls should be called just from it's main thread (WndProc)
I've started learning OpenGL a few days ago, and I'm mainly focusing OpenGL on 2D game development...
I've learned the basics of OpenGL - Creating a window, handling keyboard input.
What I did not find in tutorials (and did not found a clear solution in the net), is how to draw 2D image (such as a "player" image in a casual 2D game) using OpenGL.
I've learned XNA before, and remembered there was a structure called 2DTexture, though I did not find any in OpenGL..
I'm not looking toward 3D currently in OpenGL...
Edit:
if it makes it anyway easier, I can have the image's RGB in an array (array sized [WIDTH][HEIGHT], every cell contains the Pixel's R, G, B
First of all, OpenGL is a much lower level API than XNA and it is not primarily focused on 2D rendering.
In older versions of OpenGL, the function glDrawPixels() could serve the purpose of old school bit blitting on the screen, but is was ridiculously inefficient.
The efficient way of rendering 2D images, like sprites for a 2D game, on modern OpenGL is by mean of drawing a flat quadrilateral with an orthographic projection camera and applying a texture on top of it.
I can't remember any tutorial right now that covers 2D rendering specifically, but I think it would be best for you to first get a good grasp on texture mapping and the basics of polygon rendering. For this, ogldev is a good starting point; opengl-tutorial.org is also a great source.
I assume that SDL 2 uses OpenGL rendering in the background (or perhaps DirectX if on Windows) and this decision is made by SDl itself.
I have seen tutorials which show the use of OpenGL directly in SDL and wondered what benefit, if any would you get from using OpenGL direct? Are there things which SDL would not be able to achieve natively?
If you completely rely on SDL functionality for graphic purposes, you only have access to simple image and buffer functions.
Accelerated 2D render API:
Supports easy rotation, scaling and alpha blending,
all accelerated using modern 3D APIs
But what SDL also does is providing an OpenGL context. This means you also have full access to OpenGL functionality including 3D objects, shaders, etc.
You can use SDL simply to create your context and provide you with sound, input, and file i/o, and use OpenGL to bring color to the screen, or use the SDL video API to draw sprites and images.
http://wiki.libsdl.org/MigrationGuide
Simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, or
software rendering behind the scenes
SDL2 just give you easy start with 2D graphics (and other matters) but you can't do "real 3D" only with SDL. (or i don't know about something?)
I don't know what SDL do "behind the scenes" but if you use directly OpenGL (or other API like Direct3D)
you have full control over the code and rendering process and you aren't limited to SDL graphics API.
I use SDL only for creating window, graphics context and using input devices like mouse.
I am starting to learn OpenGL and I was wondering if it is possible to have it draw on a video memory buffer that I've obtained through other libraries?
For drawing into video memory you can use framebuffer objects to draw into OpenGL textures or renderbuffers (VRAM areas for offscreen rendering), like Stefan suggested.
When it comes to a VRAM buffer created by another library, it depends what library you are talking about. If this library also uses OpenGL under the hood, you need some insight into the library to get that "buffer" (be it a texture, into which you can render directly using FBOs, or a GL buffer object, into which you can read rendered pixel data using PBOs.
If this library uses some other API to interface the GPU, there are not so many possibilities. If it uses OpenCL or CUDA, these APIs have functions to directly use their memory buffers or images as OpenGL buffers or textures, which you can then render into with the mentioned techniques.
If this library uses Direct3D under the hood, it gets a bit more difficult. But at least nVidia has an extension to directly use Direct3D 9 surfaces and textures as OpenGL buffers and textures, but I don't have any experience with this and neither do I know if this is widely supported.
You cannot let OpenGL draw directly to arbitrary memory, one reason is that in most implementations OpenGL drawing happens in video RAM, not system memory. You can however draw to an OpenGL offscreen context and then read back the result to any place in system memory. A web search for framebuffer objects (FBOs) should point you to documentation and tutorials.
If the memory you have is already in VRAM, for example decoded by hardware acceleration, then you might be able to draw to it directly if it is available as an OpenGL texture - then you can use some render to texture techniques that will save you transferring data from and to VRAM.
Short version: What's the best practice going forward for efficiently rendering large numbers of independent texture-mapped, lighted 2D/3D primitives (circles, rects, etc.) in OpenGL?
For example: a typical particle system using billboarded quads/triangles, point sprites, or whatever other technique, with blending.
alt text http://www.codingthewheel.com/image.axd?picture=lucent1.jpg
Because after reading this thread on the messiness of OpenGL versioning/deprecation I'm starting to have my doubts.
My specific question is not the ABCs of displaying primitives in OpenGL, but rather how to do so efficiently in post-deprecation (or pre-deprecation) OpenGL, in a way that's going to be compatible with a wide range of commodity hardware and in a way that's not going to break or itself get deprecated, five years down the line.
Thanks!
I'm still trying to get a handle on the post-deprecation OpenGL world myself.
From what I understand though, the recommended methods for specifying geometry are Vertex Buffer Objects (VBOs) or vertex arrays. VBOs are the first preference, because the vertex data lives in the GPU's memory.
Also, you have to use shaders, because all the fixed-pipeline functionality is deprecated.
This stuff all works in OpenGL 2.1 and above (and OpenGL ES 2.0 it seems).