I'm developing a game, actually my first game, so I'm new in this world, I'm using OpenGL with NDK and C++ for the render part, and I call it from java with JNI. I'm stuck with the textures topic, since I need to use PNG with alpha channel and use TTF for some text.
I can include the libpng, but since I'm using the experimental gradle puglin, I don't know how to add the library and use it, I saw that the library can be precompiled and be added, but from what I saw, only for one architecture, then, I don't know if I'm wrong, but I think if I add the source code of the library and compile it with the program, I think, it will be compiled for the architectures that I need (MIPS, 64-bit ARM, x86, 64-bit x86, ARM), so that is one, I was thinking in pre-convert the png in raw RGBA and use that vector directly with opengl but again, I dont know how to do this.
and with the TTF issue, well I am in blank, if you have any advice for this I would greatly appreciate it.
Thanks for your help.
You can build the whole FreeType engine into your code, or you can just use what's already part of Android: use Canvas to render glyphs to a Bitmap. You can find an example of this in Android Breakout. The game is written in Java rather than C++, but the Java-language GLES code is just a thin wrapper around the native stuff, so it's pretty similar.
There's a pretty good blog post about GLES text on Android here.
On a similar note, you already have a copy of libpng in your app. You can call through the Bitmap API to use it.
If you have as a goal the creation of an entirely self-contained native app, then the approach of calling into Canvas/Bitmap isn't viable. I don't think that's a particularly useful goal, however. You're better off separating the "game engine" from the game logic, e.g. have platform-specific "decode PNG" and "pass this pile of RGBA pixels into glTexImage2D()" functions, and platform-agnostic "use texture N".
Taking that one step further, your best approach is to use an existing graphics engine or game engine, and focus on creating the game rather than writing the engine. Learning about engines by writing one is a worthwhile endeavor, but if your actual goal is to write a game then you should focus on the game itself.
Related
I want to manually draw the graphics, what that mean is without using any library or frame work like QT, directX , whindow.h .... like giving command to every pixels on the screen to show some specific color at different time. Every body gives tutorials on based on these library or whatever they are called. What i want is to make my own GUI. As far as I could think it is going to be very complicated, hard to learn and to understand, messy and a lot of time consuming, but I am ready for that. I need some resources to understand that.
and Yes i know C++ so it would better if I had to work with this language but I will learn other language if it is required, just i want to know which language i should learn.
In the old days, you could write directly to video memory with no help from the operating system/ROM. Today, on current hardware, you have to go through the operating system in order to write to the screen. That means using a separate library (like Qt) or using the OS features (windows.h). You could use directX or something and get more raw access to video memory, but that is still using a library/framework.
If you want with C++ and native Windows API (without DirectX) , you should use GDI(Microsoft Graphics device interface) + MFC(Microsoft Foundation Classes) this is a classic implementation of Windows GUI, If you want complicated graphics with shaders you need DirectX/OpenGL without hesitation. meanwhile if you want higher programming framework you can use C#(CSHARP) or Java.
I started working at this company that uses an 2D OpenGL implementation to show our system's data (which runs on Windows.) The whole system was built with C++ (using C++Builder 2007). Thing is, all the text they print there are pixelized when you zoom in, which I think happens because the text is a bitmap:
From what I know they use the same font files as Windows does. I asked around here on why this happens and the answer I got is that the guy who implemented it (which doesn't work at the company anymore) said fonts on OpenGL are hard and this was the best he could do or something like it.
My question is: is there any simple and effective way to make the text also a vector (the same way those lines in the picture are?) So when I zoom the camera, which happens a lot, they don't pixelize. I have little knowledge of OpenGL and if you have some guide and/or tutorial related to this to point me towards the right direction I'd be very thankful. Basically any material would be great.
Most of OpenGL text rendering libraries come to this: creating bitmaps for the fonts. This means you are going to have problems with scaling and aliasing unless you do some hacks.
One of the popular hacks is Valve's approach: Chris Green. 2007. "Improved Alpha-Tested Magnification for Vector Textures and Special Effects.". You use signed distance field algo to generate your fonts bitmap which then helps you to smooth the text outlines on scale during rendering. Wikidot has the C++ implementation for Distance field generation.
If you stick to NVidia specific hardware, you can try the NVidia Path extension which allows you to render graphics directly on GPU. Remember, it is a NVidia only thing.
But in general, signed distance field based approach is the smoothest and easiest to implement.
BTW, freetype-gl uses Valve's approach and also the modern pipeline.
You can try freetype-gl its a library for font rendering in OpenGL.
The issue with using fonts in OpenGL is that they are handled inconsistently across platforms, and that they have minimal support. If you're willing to go with a helper library for OpenGL (SDL comes to mind), then this behaviour will likely be wrapped, meaning that you merely need to provide a suitable font file for them to use.
You may try out FTOGL4 , the fonts for OpenGL4
I'm playing around with OpenGL and I'm finding myself writing code that I feel like I shouldn't have to write.
GLU and GLUT are nice but not really what I'm thinking of.
Code to load .obj models (vertex and normal vectors) from Blender and render them.
Code for collision detection.
Code for navigation/camera stuff.
Code for simple terrain generation.
But at the same time I feel like a full-blown game engine is more than I need.
Are there any good libraries built on top of OpenGL that I could take advantage of, perhaps to create relatively simple games? I don't necessarily need all of the items listed above. Those are just examples of what I'm thinking of.
Yes.
I can't be more specific as I don't write my own game engines but I do have a list of libraries online at this location, most of which sit below being a full engine.
Ogre
Irrlicht
openscenegraph (replaces performer)
Depending on how much you need, one of these toolkits / libraries might suit your purpose.
GLUT - OpenGL Utility Toolkit
Ogre3D - OGRE Object Oriented Graphics Library
Open Inventor - OpenGL toolkit for scene management created by SGI
Performer - OpenGL toolkit for real-time rendering created by SGI
I learnt my opengl stuff from GameTutorials and Gamedev. Unfortunately gametutorials are no longer a free selection of tutorial (there's some examples) but they were good. Coupled with SDL, you would have code to do everything you wanted - and you'd be able to understand what is going on under the covers, something I find is very useful later on (if, for example you wanted to write HTML5/WebGL code later).
A lot of the game engines aren't as well documented as I'd like (well, weren't a few years back when I was looking), but they might still do what you need. Sourceforge has many, including Ogre3d, Irrlicht, and CrystalSpace.
In general I agree with your sentiment. There is a school of thought that says that programming should consist of pluggable modules. Once youve written an OpenGL app, you should be able to grab a model loader, and/or a skeletal animation engine and plug them in.
The depressing thing is, most of the game engines on that list (that Ive looked at) are all or nothing propositions. They provide an entire framework and do not really take into account the more common real case scenario.
That said, all is not lost. A lot of those engines package up a number of other 'utility' libraries into their distribution. With a bit of patience it is possible to piece together the component libraries yourself: OpenAL for the sound, Freetype for font rendering, libpng, libjpeg etc for image codecs
One thing I always shy away from is 3d graphics programming, so I've decided to take on a project working with 3d graphics for a learning experience. I would like to do this project in Linux.
I want to write a simple 3d CAD type program. Something that will allow the user to manipulate objects in 3d space. What is the best environment for doing this type of development? I'm assuming C++ is the way to go, but what tools? Will I want to use Eclipse? What tools will I want?
OpenGL/SDL, and the IDE is kind-of irrelevant.
My personal IDE preference is gedit/VIM + Command windows. There are tons of IDE's, all of which will allow you to program with OpenGL/SDL and other utility libraries.
I am presuming you are programming in C, but the bindings exist for Python, Perl, PHP or whatever else, so no worries there.
Have a look online for open-source CAD packages, they may offer inspiration!
Another approach might be a C#/Mono implementations ... these apps are gaining ground ... and you might be able to make it a bit portable.
It depends on what exactly you want to learn.
At the heart of the 3d stuff is openGL, there is really no competitor for 3d apps, especially on non-windows platforms.
On top of this you might want a scenegraph (osg, openscengraph, coin) - this handles the list of objects you want to draw, their relationship to each other in space the ability to move one relative to the others, selecting objects etc. It calls opengGL to do the actual rendering.
Then on top of this you need a gui library. Qt, Fltk, wxWigets or one built into the scene library or written directly in openGL. This handles the menus, dialogs frames etc of your app. It provides an openGL canvas to draw into.
Personal choices are openscenegraph and Qt
For the 3D part, I strongly recommend the SDL Library with the OpenGL library
You can get some tutorials here
Qt has a pretty decent OpenGL-based graphics module.
Maybe you should consider using a graphics rendering engine such as OGRE. Coding a CAD program from scratch using OpenGL will take lots of time.
On Linux you have no competition to OpenGL.
It's one of the big players in the 3D field, so it's definitely worth learning.
This site has some excellent guides and code examples (on various languages).
You can use OpenGL with many languages, naturally on C and C++ but also for example with JAVA using LWJGL or other API's.
If you want to program at "a higher level" than opengl, use vtk. It is quite easy to get started and has bindings to many languages.
See www.vtk.org
you may use OpenSceneGraph for rendering.. it is an OpenGL based library..
and you may use OpenCascade.. it is good for 3D modelling...
we are implementing such an IDE at work and we use these things.. using pure OpenGL may be hard for you... anyway you may try...
for interface it is good to use Qt..
and i suggest you to use Eclipse if it is Linux..
(if it was Windows, suggestion would be Visual Studio)
For a C/C++ IDE, you have the following options:
KDevelop - KDE-based
Anjuta - GTK-based
Netbeans
Eclipse
Of course, you could also use a language like C# or Java:
Best OpenGL Wrappers for Mono and .Net
JOGL
There's really no reason why a simple CAD application would have to be written in C++.
For those not familiar with Core Image, here's a good description of it:
http://developer.apple.com/macosx/coreimage.html
Is there something equivalent to Apple's CoreImage/CoreVideo for Windows? I looked around and found the DirectX/Direct3D stuff, which has all the underlying pieces, but there doesn't appear to be any high level API to work with, unless you're willing to use .NET AND use WPF, neither of which really interest me.
The basic idea would be create/load an image, attach any number of filters that can be chained together, forming a graph, and then render the image to an HDC, using the GPU to do most of the hard work. DirectX/Direct3D has these pieces, but you have to jump through a lot of hoops (or so it appears) to use it.
There are a variety of tools for working with shaders (such as RenderMonkey and FX-Composer), but no direct equivalent to CoreImage.
But stacking up fragment shaders on top of each other is not very hard, so if you don't mind learning OpenGL it would be quite doable to build a framework that applies shaders to an input image and draws the result to an HDC.
Adobe's new Pixel Blender is the closest technology out there. It is cross-platform -- it's part of the Flash 10 runtime, as well as the key pixel-oriented CS4 apps, namely After Effects and (soon) Photoshop. It's unclear, however, how much is currently exposed for embedding in other applications at this point. In the most extreme case it should be possible to embed by embedding a Flash view, but that is more overhead than would obviously be idea.
There is also at least one smaller-scale 3rd party offering: Conduit Pixel Engine. It is commercial, with no licensing price clearly listed, however.
I've now got a solution to this. I've implemented an ImageContext class, a special Image class, and a Filter class that allows similar functionality to Apple's CoreImage. All three use OpenGL (I gave up trying to get this to work on DirectX due to image quality issues, if someone knows DirectX well contact me, because I'd love to have a Dx version) to render an image(s) to a context and use the filters to apply their effects (as HLGL frag shaders). There's a brief write up here:
ImageKit
with a screen shot of an example filter and some sample source code.