Superbible 6th edition undefined platform error - opengl

I just started off with learning openGL from the superbible(6th edition) with code::blocks.
But when i try to run the first sample code i get an undefined platform error from the sb6.h file.
sample code:
#include "sb6.h"
// Derive my_application from sb6::application
class my_application : public sb6::application
{
public:
// Our rendering function
void render(double currentTime)
{
// Simply clear the window with red
static const GLfloat red[] = { 1.0f, 0.0f, 0.0f, 1.0f };
glClearBufferfv(GL_COLOR, 0, red);
}
};
// Our one and only instance of DECLARE_MAIN
DECLARE_MAIN(my_application);
Does anyone know how to fix this?

This is because that header file expects one of _WIN32, _LINUX or __APPLE__ to be defined. Usually these are defined by the compiler or one of the platform's headers. You could also pass them to your compiler, e.g. -D_LINUX or define it in your source file before you include their header, e.g.:
#ifndef _LINUX
#define _LINUX
#endif
gcc actually defines __linux, but this is not what the header file is checking for.

It appears you are not using the CMake provided along with the projects. The CMake build process automatically adds -D_LINUX, on Linux systems when detected. Refer to the file CMakeLists.txt (https://github.com/prabindh/sb6code/blob/master/CMakeLists.txt) around line 135. If you are not using CMake, you will need to do a similar addition to the build flags.

The end of sb6.h has a set of preprocessor defines for various operating systems, and the '#elif defined _LINUX || defined APPLE' is not reached for some reason. I commented out from '#if defined _WIN32' to 'APPLE' and from '#else' to second last '#endif'. Between those commented out sections is the #define DECLARE_MAIN(a)' that is needed.
Good luck getting the rest of the programs to compile.

Related

Manual CubeMX C to C++ project conversion fails when including FreeRTOS

Toolchain is the SW4STM32, gcc, processor is STM32F303K8 (Nucleo 303K8), minimal test project with no actual user code at all.
The process how to convert a project generated by ST CubeMX is well documented and apparently works. However, when i specify FreeRTOS in Cube, linker fails to find the init function MX_FREERTOS_Init(). The function prototype is included in main.cpp and the definition exists in another source file (freertos.c). This works in C but when converting the project to C++ the linker fails to link the function.
The C2C++ conversion i did as follows:
add ccnature to the .project file
copy main.c to main.cpp (& remove main.c from the build)
duplicate gcc compiler settings over to g++ in project properties
point linker script to the one in the project directory
The above enable Eclipse to compile main using g++ and to link using G++ linker. However linking consistently fails in ...\Debug/../Src/main.cpp:97: undefined reference to `MX_FREERTOS_Init()'
What is remarkable is that even when i delete all references to MX_FREERTOS_Init() from main.cpp so that the text simply does not exist anywhere, linker STILL fails exactly the same. It even reports the same line number even though the text is completely different. This behavior does not change never mind if i clean the project, rebuild and refresh all indexes etc etc.
Any suggestions anyone? Or do i have to skip specifying FreeRTOS in Cube and do it all manually?
I have the same question using atollic for stm32,
solved by adding extern "C" to main.cpp
/* USER CODE BEGIN PV */
/* Private variables ---------------------------------------------------------*/
#ifdef __cplusplus
extern "C" {
#endif
/* USER CODE END PV */
/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config();
void MX_FREERTOS_Init(void); /* (MISRA C 2004 rule 8.1) */
/* USER CODE BEGIN PFP */
/* Private function prototypes -----------------------------------------------*/
#ifdef __GNUC__
/* With GCC, small printf (option LD Linker->Libraries->Small printf
set to 'Yes') calls __io_putchar() */
#define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
#define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
#endif /* __GNUC__ */
#ifdef __cplusplus
}
#endif
/* USER CODE END PFP */
I have faced with the same issue.
So, I would like to suggest renaming freertos.c file to freertos.cpp.
I would suggest a C++ RTOS for example the free disortos. (Google it)

C++ Inclusion guards being "ignored" between projects

I have two projects; a static library and an executable (standard Win32 setup, using the multithreaded debug dll setting for both).
In my libray, I have a Globals.h, with the following code:
#ifndef _GLOBALS_H
#define _GLOBALS_H
#include <SDL.h>
#include <string>
namespace Eng
{
bool Run = true;
SDL_Window *Window = NULL;
SDL_GLContext GlContext;
Uint32 WindowFlags = SDL_WINDOW_OPENGL;
}
#endif
This is all fine and dandy, and within that project everything works fine. However, as soon as I include that file within more than one file in my executable project (all protected by inclusion guards), I start getting multiply defined symbol errors for each variable within Globals.h.
As well, I'm getting quite a few macro redefinition warnings from math.h (M_PI macro redefinition). I'm not sure if this is linked, but it seems likely due to the similar nature of error (guards defined in one project seemingly not applying in the other).
Anyone have any ideas how to resolve this? I feel like I'm missing some vitally important compiler setting somewhere :(

Playing cutscenes in c++

I'm using SDL for opening a window and handeling events. And OpenGL to render my objects to the screen. SDL_mixer for sound, and SDL_ttf for text. Now I'm trying to figure out how to be able to put a video on display. Like an animated logo or something before the game starts. Just to experiment with it. At some point I will need to know it...
I've found and tried installing FFMPEG, I've included the "include" folder, and set the "lib" folder. At first I got an error telling me it was unable to load "inttypes.h". So I downloaded a package with that and put it in the include folder for FFMPEG.
Now I'm stuck with this error, which I can't seem to be able to solve.
c:\program
files\ffmpeg-20140507-git-4cdea92-win64-dev\include\libavutil\common.h(87):
fatal error C1004: unexpected end-of-file found
And another question, is there other libraries aviable that may be easier to use for displaying a simple video? I read something about SDL being able to do it, but nothing was to be found about it.
EDIT: Here is line 78 to 96:
#if FF_API_AV_REVERSE
extern attribute_deprecated const uint8_t av_reverse[256];
#endif
#ifdef HAVE_AV_CONFIG_H
# include "config.h"
# include "intmath.h"
#endif
/* Pull in unguarded fallback defines at the end of this file. */
#include "common.h"
#ifndef av_log2
av_const int av_log2(unsigned v);
#endif
#ifndef av_log2_16bit
av_const int av_log2_16bit(unsigned v);
#endif
Wrap your #include <libav*.h>s inside a block like this:
#ifndef __STDC_CONSTANT_MACROS
#define __STDC_CONSTANT_MACROS
#define UNDEFINE_STDC_CONSTANT_MACROS
#endif
extern "C"
{
#include <libavdevice/avdevice.h>
#include <libavdevice/version.h>
}
#ifdef UNDEFINE_STDC_CONSTANT_MACROS
#undef __STDC_CONSTANT_MACROS
#endif
There's probably a way around using the UNDEFINE_STDC_CONSTANT_MACROS hack but the logic just isn't coming to me right now.
Worked for me on VS2012 using Zeranoe's 32-bit ffmpeg development binaries and msinttypes' inttypes.h.
Hmm, I found the DLL-files, and it gave me a linker error with the 64-bit library.
I changed back to 32-bit and the 32-bit dlls and it worked fine. I guess that libraries ask if you have 32/64-bit Visual Studio insteath of Windows.

Sudden issues with glut and glew includes and type specifiers

I’m currently working on a final programming project for a games development course, and chose to make use of C++ and OpenGL for the 3D rendering side of the program (despite the fact I have little experience with it).
I was working with it until now absolutely fine with no serious errors, and then left it for a few days. But when I returned I started to get various "C4430 - Missing Type Specifier" errors with the few GLfloat variables I had used.
This was my previous definitions, which worked fine until I reloaded today:
#include <gl/glew.h>
#include <gl/glut.h>
... Other variable and object definitions
const GLfloat DEFAULT_X = -5.0f; //C4430: missing type specifyer on all 3 lines and
const Glfloat DEFAULT_Y = -4.0f; //C2146: syntax error : missing ';' before identifier 'DEFAULT_Y' on this line only
const GLfloat DEFAULT_Z = -20.0f;
GLfloat viewX = DEFAULT_X; //This line is fine
GLfloat viewY = DEFALUT_Y; //Resulting C2065: Undeclared identifyer
GLfloat viewZ = DEFALUT_Z; //on both these lines
In an attempt to fix this I began altering the #includes (perhaps, a daft approach, but I was pretty confused at this point) and found that adding Windows.h and gl/GL.h, as some have suggested, fixed all but one of the problems.
#include <Windows.h>
#include <gl/GL.h>
#include <gl/glew.h>
#include <gl/glut.h>
The new problem is that attempting to use gl/GL.h before gl/glew.h throws the error "C1189: gl.h included before glew.h" because, at a guess, glew includes gl.h itself. But any alteration brings back the previous type specifyer errors.
What's confusing me is that if glew was including GL.h, then wouldn’t these type specifiers have also been included? I’m going to continue method coding what I can without testing for the time being, but need to be able to test what I’m doing soon. Can anyone offer help or suggestions?
#include <Windows.h>
#include <gl/GL.h>
#include <gl/glut.h>
#include <gl/glew.h>
This is the wrong order to include these headers in.
GLEW (or whatever OpenGL loader you're using) always comes first. You never include gl.h with an OpenGL loader headers; you just include theirs (glew.h in this case). And it comes before all other headers for OpenGL or OpenGL tools.
FreeGLUT's headers come next. After that... you shouldn't be including window.h at all, unless you're doing some Windows-specific code. If you are, you include it after FreeGLUT's stuff.

Windows/opengl glext.h build issue

So I'm trying to bring a c++ project using Qt and OpenGL written and compiled on a Linux machine over to my Windows 7 machine at home, but I'm running into some difficulty. First I learned that some gl things (like GL_TEXTURE0) were no longer defined because gl.h doesn't define them for windows. Also, the glext.h that I have does not define some functions like glActiveTexture. Both of these issues I found could be solved by bringing in a newer glext.h.
My most immediate issue seems to be that I'm not bringing it in correctly. If I do:
#define GL_GLEXT_LEGACY //should prevent old glext.h from being included
#define GL_GLEXT_PROTOTYPES //should make glActiveTexture be defined
#include <qgl.h>
#include "glext.h" //local up-to-date glext.h
#include <QGLShaderProgram>
then make tells me that I have undefined references to glActiveTexture. If I include QGLShaderProgram before glext.h, then I still have that problem, but make also warns me that I am redefining quite a few things that are defined in both QGLShaderProgram and glext, so I know the latter file is being included. Any help would really be appreciated.
You are on a right path, but like Nick Meyer wrote, you need to get pointers to the functions at runtime.
There is a nice and clean example already in Qt installation directory, at least since 4.6. Check "Boxes" from "demos"-directory. There is glextensions.h/cpp that takes care of those required functions in Qt-way, using Qt's QGLContext etc.
If you're lazy like me, just hop over to
http://glew.sourceforge.net
and use that, no need to fiddle around with different header files and manually retrieving function pointers. It's as simple as
/* in every source file using OpenGL */
#include <GL/glew.h>
and
/* for each OpenGL context */
if( createGLContext(...) == SUCCESSFULL )
glewInit()
If you're using Qt you should probably use qmake - and just add
QT += opengl
to your qmake project file.