I want to create a simple game like Space Invaders. I know that I can use Android NDK, but I have to port the libraries that I use. I can not use third-party proprietary libraries.
I will use OpenGL, but OpenGL API seems different on Android. I have to use jpeg and png textures, and write texts. Can I compile libjpeg, libpng and freetype for Android?
I can not have specific implementation of the game engine (C++) and rendering routines (C++ and OpenGL), because that is the complex part.
There are components that I am disposed to implement for each platform. There is no problem with windowing system and user input, because I will use a specific implementation for each system, it is simple for me.
I use SDL and its extensions for audio on PC, but it is easy to use. I can use specific audio libraries for Android.
Thanks
Can I compile libjpeg, libpng and freetype for Android?
Yes you will have to recompile all the native libraries specifically for Android. Yes, you do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc but unfortunately Android doesn't use glibc due to liscence and performance issues. Android uses a watered down version of glibc called libc. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to Strings and it definitely doesnt have some posix support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc and coding your libs accordingly.
Also, as you righty pointed out you will have to use the NDK to interface Java(Android app/fwk) to native world(C++).
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.
Related
I have been searching to get the source code of the header file <graphics.h> and its associated library in order to integrate it with my C++ program.
At the same time, I am interested in those cross-platform libraries that works on more than one compiler. Just to be more explicit, I am talking about those libraries that are used for drawing shapes, lines, and curves in C++.
<graphics.h> is very old library. It's better to use something that is new
Here are some 2D libraries (platform independent) for C/C++
SDL
GTK+
Qt
Also there is a free very powerful 3D open source graphics library for C++
OGRE
<graphics.h> is not a standard header. Most commonly it refers to the header for Borland's BGI API for DOS and is antiquated at best.
However it is nicely simple; there is a Win32 implementation of the BGI interface called WinBGIm. It is implemented using Win32 GDI calls - the lowest level Windows graphics interface. As it is provided as source code, it is perhaps a simple way of understanding how GDI works.
WinBGIm however is by no means cross-platform. If all you want are simple graphics primitives, most of the higher level GUI libraries such as wxWidgets and Qt support that too. There are simpler libraries suggested in the possible duplicate answers mentioned in the comments.
There is a modern port for this Turbo C graphics interface, it's called WinBGIM, which emulates BGI graphics under MinGW/GCC.
I haven't it tried but it looks promising. For example initgraph creates a window, and
from this point you can draw into that window using the good old functions, at the end closegraph deletes the window. It also has some more advanced extensions (eg. mouse handling and double buffering).
When I first moved from DOS programming to Windows I didn't have internet, and I begged for something simple like this. But at the end I had to learn how to create windows and how to handle events and use device contexts from the offline help of the Windows SDK.
The Borland Graphics Interface, the library fronted by the graphics.h header, has been re-implemented atop SDL. This brings support for modern hardware and operating systems (multiple operating systems, in fact, since SDL is fairly portable).
It can be downloaded here prebuilt for a variety of common desktop targets.
Or if you wish to (or must) build it from source, here is a github mirror.
Note that it is a port of a very old software library and will run atop modern tools, so you should check with the instructor if you intend to use it for class assignments. It would be irritating to fail an assignment because you used idioms that require support from a modern compiler and find that they do not compile on a marking system from the 1980s.
You may find it better to get and develop with a virtual machine clone of the marking system to prevent nasty surprises.
graphics.h appears to something once bundled with Borland and/or Turbo C++, in the 90's.
http://www.daniweb.com/software-development/cpp/threads/17709/88149#post88149
It's unlikely that you will find any support for that file with modern compiler. For other graphics libraries check the list of "related" questions (questions related to this one). E.g., "A Simple, 2d cross-platform graphics library for c or c++?".
I require zlib library for the development of Windows Store app.
Has anyone converted Win32 zlib project to WinRT yet?
Can anyone please describe the steps to convert the existing win32 static lib project to winRT?
Visual C++ is already a supported language for WinRT development, if you wan't to use zlib, just compile it together with your solution. There is nothing that is preventing you from reusing standard ISO C and C++ libraries from within the WinRT, if you are using the C++ language, you might have to expose certain aspects of your library as WinRT Components but only if you need to interface with facilities like XAML or other WinRT languages but that should be a walk in the park. Not something which is tremendously difficult to do.
The whole point of supporting C++ in the WinRT is to allow an existing ecosystem of largely native applications to be ported to the Windows Store. zlib is not an exception. Non-standard ISO C and C++ such as sockets are not supported but there you have alternatives that you can plug-in to, just check that the library you're using has some kind of portability support.
WinRT is very limited with regards to C library functions which are present. What this means is that virtually all cross-platform C libraries are (AFAIK, I'm not a WinRT dev) unusable for that target.
For the case of zlib, there is an alternative: see this question
EDIT: to clarify what I'm saying above, I dug up a list of all CRT functions that are absent for WinRT, which you can find here. As long as zlib or any other C library does not depend on these function calls, you should be able to use the WinRT tools to build that C library. I even found a project file for zlib on winrt by the Ogre team here, not sure how useful it is to you.
You could take a look into this WinRT (Un)Zip component. Its used in production code already.
See the unit tests inside on how to use the component. It compiles on all WinRT architectures including ARM. It has no custom asm for ARM though.
From OpenGL wiki:
"For most libraries you are familiar with, you simply #include a header file, make sure a library is linked into your project or makefile, and it all works. OpenGL doesn't work that way."
I work on Windows 64 and I need OpenGL to use it in C++ application. What library I should use? Does microsoft provide its implementation ( I use MinGW, I do not have MS Visual C++ )?
The one that comes with your GPU drivers that you have installed on your machine, Microsoft also provides a software layer for OpenGL emulation but it's stuck at the version 1.1 and it's really old and useless.
What library should I use?
I recommend using GLEW for easy access to functions of OpenGL 1.2 and higher, GLM for mathematics, and one of these image loading libraries.
Does microsoft provide its implementation (of OpenGL)?
Microsoft provides you with the necessary header files and library files to access the OpenGL API. However, in order to use OpenGL functions of version 1.2 and higher, you must use extensions. GLEW does this implicitly for you.
Take a look at glew. It loads needed extensions and core functions.
I want to get ( or build from source) OpenGL library that is statically linked to the crt on Windows.
I don't want my executable to require OPENGL32.dll.
My compiler is Visual C++ 9.
Where do I begin? The OpenGL website directs me to this wiki http://www.opengl.org/wiki/Getting_started
But that wiki tells me "In all three major desktop platforms (Linux, MacOS X, and Windows), OpenGL more or less comes with the system".
I am on Windows. Is this statement true. How do I verify this?
Statically linked OpenGL library on Windows
I don't want my executable to require OPENGL32.dll.
Impossible. End of story. opengl32.dll is provided by microsoft and may be changed after each system update. So you can't static-link it - it is a system component.
You can only static link with mesa3d which emulates OpenGL on CPU. However, it is not fully compliant to OpenGL, so you can get unexpected problems, and you'll still require several system dlls. (my bet is gdi32.dll) for your application. Also, performance will be very bad compared to normal OpenGL.
I believe what you are saying is that you don't want to be forced to make your application link with the C Runtime libraries dynamically (i.e. Multithreaded DLL or Multithreaded Debug DLL in the Properties/C++/Code Generation/Runtime Library setting).
Since OpenGL is a system provided .DLL, you are still free to choose Multithreaded or Multithreaded Debug (both choices statically link to the C Runtime) for your Runtime Library when using OpenGL.
I have been searching to get the source code of the header file <graphics.h> and its associated library in order to integrate it with my C++ program.
At the same time, I am interested in those cross-platform libraries that works on more than one compiler. Just to be more explicit, I am talking about those libraries that are used for drawing shapes, lines, and curves in C++.
<graphics.h> is very old library. It's better to use something that is new
Here are some 2D libraries (platform independent) for C/C++
SDL
GTK+
Qt
Also there is a free very powerful 3D open source graphics library for C++
OGRE
<graphics.h> is not a standard header. Most commonly it refers to the header for Borland's BGI API for DOS and is antiquated at best.
However it is nicely simple; there is a Win32 implementation of the BGI interface called WinBGIm. It is implemented using Win32 GDI calls - the lowest level Windows graphics interface. As it is provided as source code, it is perhaps a simple way of understanding how GDI works.
WinBGIm however is by no means cross-platform. If all you want are simple graphics primitives, most of the higher level GUI libraries such as wxWidgets and Qt support that too. There are simpler libraries suggested in the possible duplicate answers mentioned in the comments.
There is a modern port for this Turbo C graphics interface, it's called WinBGIM, which emulates BGI graphics under MinGW/GCC.
I haven't it tried but it looks promising. For example initgraph creates a window, and
from this point you can draw into that window using the good old functions, at the end closegraph deletes the window. It also has some more advanced extensions (eg. mouse handling and double buffering).
When I first moved from DOS programming to Windows I didn't have internet, and I begged for something simple like this. But at the end I had to learn how to create windows and how to handle events and use device contexts from the offline help of the Windows SDK.
The Borland Graphics Interface, the library fronted by the graphics.h header, has been re-implemented atop SDL. This brings support for modern hardware and operating systems (multiple operating systems, in fact, since SDL is fairly portable).
It can be downloaded here prebuilt for a variety of common desktop targets.
Or if you wish to (or must) build it from source, here is a github mirror.
Note that it is a port of a very old software library and will run atop modern tools, so you should check with the instructor if you intend to use it for class assignments. It would be irritating to fail an assignment because you used idioms that require support from a modern compiler and find that they do not compile on a marking system from the 1980s.
You may find it better to get and develop with a virtual machine clone of the marking system to prevent nasty surprises.
graphics.h appears to something once bundled with Borland and/or Turbo C++, in the 90's.
http://www.daniweb.com/software-development/cpp/threads/17709/88149#post88149
It's unlikely that you will find any support for that file with modern compiler. For other graphics libraries check the list of "related" questions (questions related to this one). E.g., "A Simple, 2d cross-platform graphics library for c or c++?".