Hello

I'm a beginner in game programming and I'm programming in visual studio 2017 with OpenGL and SDL2 libraries
Every time I try to build my project i have this problem and i don't what is the problem:
 

1>------ Build started: Project: TheGame, Configuration: Debug Win32 ------
1>Cube.cpp
1>c:\users\king0k13\documents\games\thegame\thegame\game.h(18): error C2143: syntax error: missing ';' before '*'
1>c:\users\king0k13\documents\games\thegame\thegame\game.h(18): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Main.cpp
1>Generating Code...
1>Done building project "TheGame.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

These are my Project files:

- Game.h

#pragma once

#ifndef _GAME_H_
#define _GAME_H_

#include <iostream>
#include <SDL.h>
#include <SDL_opengl.h>
#include <SOIL.h>
#include <gl/gl.h>
#include <string>

#include "Cube.h"

#define ScreenWidth 600
#define ScreenHeight 600

Cube* cube1;

class Game
{
public:
    // Constructors
    Game();
    ~Game();

    // Functions
    void Initialize();
    void SetOpenGLAttributes();

    void InputHandler();
    void Update();
    void Render();
    void Clean();

    // Globals
    bool RunningStatus;

private:
    SDL_Window* GameScreen;
    SDL_GLContext GameContext;
    SDL_Event GameEvents;
};

#endif

Error Line is: Cube* cube1;

---------------------------------------------------------------------------------------------------------------

- Game.cpp
 

#include "Game.h"

Game::Game()
{
}
Game::~Game()
{
}

/****************************************************************************/

void Game::Initialize()
{
    // Initilizng SDL
    if (SDL_Init(SDL_INIT_VIDEO) == 0)
    {
        std::cout << "SDL Initialized succesfully!" << std::endl;
    }
    else
    {
        std::cout << "Failed Initializing SDL : " << SDL_GetError() << std::endl;
        RunningStatus = false;
    }

    // Setting-Up The Game Screen
    GameScreen = SDL_CreateWindow("The Game",
        SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
        ScreenWidth, ScreenHeight, SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN);
    if (GameScreen == NULL) // Handling Errors
    {
        std::cout << "SDL Failed Creating Window : " << SDL_GetError() << std::endl;
        RunningStatus = false;
    }
    else
    {
        std::cout << "Creating Window Succesful!" << std::endl;
        std::cout << "Window Data : \n" << "\tTitle : The Game\n\tX , Y Position : (CENTERED , CENTERED)\n\tWidth and Height : (" << ScreenWidth << " , "  << ScreenHeight << ")\n\tFlags : OpenGL | Shown\n" << std::endl;
    }

    // Creating Game Context for OpenGL use
    GameContext = SDL_GL_CreateContext(GameScreen);
    SetOpenGLAttributes(); // Setting OpenGLAttributes
    SDL_GL_SetSwapInterval(1);

    RunningStatus = true; // Turning on The Game Loop

    cube1->LoadTexture();
    cube1->ActiveTexture();
}

/****************************************************************************/

void Game::SetOpenGLAttributes()
{
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
    SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
}

/****************************************************************************/

void Game::InputHandler()
{
    while (SDL_PollEvent(&GameEvents))
    {
        switch (GameEvents.type)
        {
        case SDL_QUIT:
            RunningStatus = false;
            break;

        case SDL_KEYDOWN:
            switch (GameEvents.key.keysym.sym)
            {
            case SDLK_w:
                break;

            case SDLK_a:
                break;

            case SDLK_s:
                break;

            case SDLK_d:
                break;

            default:
                break;
            }
            break;
        default:
            break;
        }
    }
}

/****************************************************************************/

void Game::Update()
{
    cube1->SetPosition(0, 0);
}

/****************************************************************************/

void Game::Render()
{

    SDL_GL_SwapWindow(GameScreen);
}

/****************************************************************************/

void Game::Clean()
{
    cube1->UnloadTexture();

    SDL_GL_DeleteContext(GameContext);
    SDL_DestroyWindow(GameScreen);
    SDL_Quit();
}

-----------------------------------------------------------------------------------------------------------------

- Cube.h
 

#pragma once

#ifndef _CUBE_H_
#define _CUBE_H_

#include "Game.h"

class Cube
{
public:
    // Constractors
    Cube();
    ~Cube();

    // Functions
    void SetPosition(int x, int y);
    int GetPosition();
    void LoadTexture();
    void ActiveTexture();
    void UnloadTexture();

    // Globals
    //bool Hide;

private:
    // Cube Position
    int X_pos;
    int Y_pos;
    //int Z_pos;

    // Cube Graphic
    unsigned char* CubeTexture;
    GLuint TextureID;
    int Channels;
    int Format;
    int T_Width;
    int T_Height;
};

#endif

-----------------------------------------------------------------------------------------------------------------

Cube.cpp

#include "Cube.h"

Cube::Cube()
{
}
Cube::~Cube()
{
}

/****************************************************************************/

void Cube::SetPosition(int x, int y)
{
	X_pos = x;
	Y_pos = y;
}

/****************************************************************************/

int Cube::GetPosition()
{
	return X_pos, Y_pos;
}

/****************************************************************************/

void Cube::LoadTexture()
{
	Channels = 0;
	CubeTexture = SOIL_load_image("assets/Block.png", 
		&T_Width, &T_Height, &Channels, SOIL_LOAD_AUTO);
	if (CubeTexture == NULL)
	{
		std::cout << "SOIL Failed to Load Texture" << std::endl;
	}

	Format = GL_RGB;
	if (Channels == 4)
	{
		Format = GL_RGBA;
	}

	glGenTextures(1, &TextureID);
	
	glBindTexture(GL_TEXTURE_2D, TextureID);
	glTexImage2D(GL_TEXTURE_2D, 0, Format, T_Width, T_Height, 0, 
		Format, GL_UNSIGNED_BYTE, CubeTexture);
	
	SOIL_free_image_data(CubeTexture);

	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
}

void Cube::ActiveTexture()
{
	glBindTexture(GL_TEXTURE_2D, TextureID);
}

void Cube::UnloadTexture()
{
	glDeleteTextures(1, &TextureID);
}

-------------------------------------------------------------------------------------------------------------------
- Main.cpp
 

#include "Game.h"

int main(int argc, char* argv[])
{
    Game TheGame;

    TheGame.Initialize();

    while (TheGame.RunningStatus)
    {
        TheGame.InputHandler();
        TheGame.Update();
        TheGame.Render();
    }

    TheGame.Clean();

    return 0;
}

I would be really happy if someone helps me to fix the error.

P.S. : If someone have any good advice to help me coding my project better please tell me!

Lactose is right about GetPosition(), although that won't actually result in a compilation error (which is all the worse, since the error can go unnoticed).

As for the compilation error you mention, can you post Cube.h? It looks like you meant to, but posted Cube.cpp instead. Also, although we can make a reasonable guess as to the offending line by counting the lines in your code, it'd be easier if you could add a comment in your code indicating the exact statement that's generating the error.

9 hours ago, Lactose said:

At least your GetPosition function is all wrong. It says it returns an int, but you're actually trying to return 2 ints from it. Either swap to GetPositionX and GetPositionY, or create a Position struct/class with x and y inside them, and return that from GetPosition.

Thank you I will probably use GetPositionX and GetPositionY instead of GetPosition

9 hours ago, Zakwayda said:

Lactose is right about GetPosition(), although that won't actually result in a compilation error (which is all the worse, since the error can go unnoticed).

As for the compilation error you mention, can you post Cube.h? It looks like you meant to, but posted Cube.cpp instead. Also, although we can make a reasonable guess as to the offending line by counting the lines in your code, it'd be easier if you could add a comment in your code indicating the exact statement that's generating the error.

Thank you so much.

I'm actually a beginner and this is my first Post so I probably make some mistakes for example forget to add file or commenting the error line.

Thanks for posting Cube.h.

There may be other issues, but it looks like you have a circular inclusion between Cube.h and Game.h. I would start by resolving that.

At least three ways out of this:

1. Cube.h doesn't use anything from Game.h, so the #include in Cube.h isn't needed.

In a sense it's also weird to have this dependency. At each level you include "lower" things, including the world from an object inside the world is the "wrong" way around.

In general, avoid #include in .h files as much as possible, and prefer #include in .cpp files instead.

2. In Game.h, declare a class Cube exists earlier using "class Cube;" (saying "there is class called Cube, I'll tell you later what's in it").

That would resolve your "Cube *cube1;" problem as far as the compiler is concerned (You don't need the content of Cube to create a pointer to objects of it). However, this likely doesn't do what you want, since you define (that is, create) a variable named cube1 here. If you define a variable inside a .h file, it gets defined each time you include the file. Thus if you have 2 .cpp files, and both #include (directly or indirectly) Game.h, you'll have 2 "Cube *cube1" variables, and the linker will get very confused about that.

To fix the linker problem, you declare the variable instead of defining it, using "extern Cube *cube1;". This says "somewhere there is a variable cube1, which is a pointer to the Cube class". Obviously, you then have to fulfill this promise, or the linker will find the variable missing. You do that by adding "Cube *cube1;" in one of the .cpp files (Game.cpp for example).

3. So while both "1" and "2" solve the compiler problem, there is a higher-level question that begs to be asked: Why do you have a global variable, and why is it such a weird name? The name "cube1" suggests there is also "cube2" and "cube3" etc, but the latter aren't here. Secondly, global variables are often more trouble than it's worth, so if you cannot avoid having it, maybe move it into a class somewhere to restrict its scope?

This all depends on what "cube1" is in context of the entire game (since it's in Game.h, which sounds like it will be global-like for the game).

10 hours ago, Alberth said:

At least three ways out of this:

1. Cube.h doesn't use anything from Game.h, so the #include in Cube.h isn't needed.

In a sense it's also weird to have this dependency. At each level you include "lower" things, including the world from an object inside the world is the "wrong" way around.

In general, avoid #include in .h files as much as possible, and prefer #include in .cpp files instead.

 

2. In Game.h, declare a class Cube exists earlier using "class Cube;" (saying "there is class called Cube, I'll tell you later what's in it").

That would resolve your "Cube *cube1;" problem as far as the compiler is concerned (You don't need the content of Cube to create a pointer to objects of it). However, this likely doesn't do what you want, since you define (that is, create) a variable named cube1 here. If you define a variable inside a .h file, it gets defined each time you include the file. Thus if you have 2 .cpp files, and both #include (directly or indirectly) Game.h, you'll have 2 "Cube *cube1" variables, and the linker will get very confused about that.

To fix the linker problem, you declare the variable instead of defining it, using "extern Cube *cube1;". This says "somewhere there is a variable cube1, which is a pointer to the Cube class". Obviously, you then have to fulfill this promise, or the linker will find the variable missing. You do that by adding "Cube *cube1;" in one of the .cpp files (Game.cpp for example).

 

3. So while both "1" and "2" solve the compiler problem, there is a higher-level question that begs to be asked: Why do you have a global variable, and why is it such a weird name? The name "cube1" suggests there is also "cube2" and "cube3" etc, but the latter aren't here. Secondly, global variables are often more trouble than it's worth, so if you cannot avoid having it, maybe move it into a class somewhere to restrict its scope?

This all depends on what "cube1" is in context of the entire game (since it's in Game.h, which sounds like it will be global-like for the game).

Thank you so much for your big help.

This is a Puzzle Game that player just see 2 sides of a 3D Cubic Model and by having 2 Images of the final model (Images of 2 sides) he should move the cubes (which he see them as squares) and make the model sides exactly like the picture of each side.

It's like one of the levels of the indie game 'FEZ'. Here is a screenshot of that level:

So....

I wanted to make a world class and a cube class (for each cube object) and a class for the camera and connect this classes to communicate with each other (which i'm not so good at it).

so if you or anyone else know anything for making this game better please write it down on the post or if it's too long and have some dependencies (files, PDFs, images and etc.) pleases mail it for me to "king0droid13k@gmail.com"

i'm working on this project for something about 2 weeks and i still have problem with it; so i will be really thankful if someone helps me with my project's errors and problems.

You seem to be struggling with overall object structure while coding. That means you're fighting 3 battles currently:

1. What objects live in a running game, how to they fit together, what talks to what, when do I create new instances.
2. Which classes do I have, what do they contain, what inheritance hierarchies exist.
3. How do I explain what I want to the C++ compiler.

I would suggest you take a step back, and first work a bit on winning the first battle. Stop writing code, turn the computer off, and find paper and a pencil.

One of the core game structures is the current situation of the level currently being played. Somewhere you need to record which side is shown, what cubes exist in the level, where they all are, the position of the player, current time (if time is relevant), etc. Basically all information of the current situation that you need to render an image of the game to the screen.

Think what objects you need for that. Give them a name, write down a few sentences about their purpose so anyone else can read and understand it. (it seems silly but having to write it down forces you into deciding the purpose more clearly). Next, think how the boxes relate to each other. Should one box live inside another box? Is one box actually the same as a second box, but just have a different shape? Try to find a structure that makes sense given their purpose.

Next, think how rendering would actually work. To draw anything you need coordinates and an image or texture. How do you walk through the boxes to get that information? Is everything available?

There are other computations that work on the same data structure. Perhaps you want to skip most or all of these puzzles on the first iteration (depending how eager you are to get code), but you'll run into these questions at some point, so I just list a few to give you an idea what they are.

You should be able to decide whether the game has been won or lost. You get input from the player to make a change in the current situation. Is that allowed or not? If allowed, how do you make change happen (so when you render it again, the player sees the result of his/her input)? 

Once you understand how things work inside in the objects, for the puzzles that you solved so far, you're ready for making classes, and explain to the compiler what you want.

Again, do one thing at a time. Being able to see the current situation is a major benefit, as it makes checking and debugging much simpler. Write classes for the core data structure to render the situation. Write some temporary code that hard-coded constructs some objects in some current situation (so you have something to render), and make it draw the right picture. Change the hard-coded situation a bit, and check the picture changes accordingly.

Once that works as expected, add the next thing (solve the puzzle if you haven't done that, and add it to the code). Repeat until you run out of things to add, and you're done!

Simple eh?

13 hours ago, Alberth said:

You seem to be struggling with overall object structure while coding. That means you're fighting 3 battles currently:

1. What objects live in a running game, how to they fit together, what talks to what, when do I create new instances.
2. Which classes do I have, what do they contain, what inheritance hierarchies exist.
3. How do I explain what I want to the C++ compiler.

I would suggest you take a step back, and first work a bit on winning the first battle. Stop writing code, turn the computer off, and find paper and a pencil.

One of the core game structures is the current situation of the level currently being played. Somewhere you need to record which side is shown, what cubes exist in the level, where they all are, the position of the player, current time (if time is relevant), etc. Basically all information of the current situation that you need to render an image of the game to the screen.

Think what objects you need for that. Give them a name, write down a few sentences about their purpose so anyone else can read and understand it. (it seems silly but having to write it down forces you into deciding the purpose more clearly). Next, think how the boxes relate to each other. Should one box live inside another box? Is one box actually the same as a second box, but just have a different shape? Try to find a structure that makes sense given their purpose.

Next, think how rendering would actually work. To draw anything you need coordinates and an image or texture. How do you walk through the boxes to get that information? Is everything available?

 

There are other computations that work on the same data structure. Perhaps you want to skip most or all of these puzzles on the first iteration (depending how eager you are to get code), but you'll run into these questions at some point, so I just list a few to give you an idea what they are.

You should be able to decide whether the game has been won or lost. You get input from the player to make a change in the current situation. Is that allowed or not? If allowed, how do you make change happen (so when you render it again, the player sees the result of his/her input)? 

 

Once you understand how things work inside in the objects, for the puzzles that you solved so far, you're ready for making classes, and explain to the compiler what you want.

Again, do one thing at a time. Being able to see the current situation is a major benefit, as it makes checking and debugging much simpler. Write classes for the core data structure to render the situation. Write some temporary code that hard-coded constructs some objects in some current situation (so you have something to render), and make it draw the right picture. Change the hard-coded situation a bit, and check the picture changes accordingly.

Once that works as expected, add the next thing (solve the puzzle if you haven't done that, and add it to the code). Repeat until you run out of things to add, and you're done!

Simple eh?

 

Thank you for your suggestions but my problem is actually this:

I can program this game without using object-oriented method but i want to learn object-oriented programming in C++ (I program object-oriented in python but i have never test it in C++). and this my 5th time i'm using OpenGL. so i know what are my objects (refereeing to my example 'FEZ' there are just two objects: camera, and cube(s)). i see some example about object-oriented programming in C++ so i decided to make my game objects and class like this:

     1. A world class to define the screen and renderer and game events in it.

     2.A cube class for each cube in the game (Which i now think it would be better if i use it for all cubes --> My mistake?).

     3.A camera class to see what is happening Which player can move through the game.

I make some games before with python and pygame but i changed my language to C++. I'm not pro at C++ so I'm a little bit confused about what i'm doing. I know what stuff should i do and think about before making any game (I have paper that i write everything about the game on it).so my real problem is with C++ graphics library(OpenGL and SDL) and object-oriented programming in C++.?

For making it more clear what i'm doing now and my missions:

My first mission was writing down the game pattern(done). My second mission was setting up the requirements for my game like libraries assets and other(done).My third mission was making making the game world and setting up screen and renderer (i think it's done), and now i'm trying to load an image in this game (which i'm not successful at it). This is my whole problem and i came here because i couldn't find anything in the internet about my problem.

I don't know what you consider "object-oriented", I have a very pragmatic view. It's 'smart' data, data that you can ask questions, or ask it to do something, and that's about it. I still use functions when it makes more sense.

C++ is more strict with typing than Python, and a variable contains a value rather than being a reference to a value as in Python, but that's C++ vs Python, and not object-oriented specific.

Given that SDL is widely used, and one of its core functions is to display graphics, I have a hard time understanding why you can't find things at the Internet about it. Maybe you're looking in the wrong way?

One source I  know about is the LazyFoo tutorials, and of course there is libsdl.org, home of SDL, with a number of links to stuff. Tutorials may not be object-oriented, but that doesn't matter, you only need to know what calls you need to make. You can use any data structure you like including an object-oriented one, as long as you perform the same calls, the library will work (ie the library doesn't care about the structure of your code at all).