SFML community forums
Help => General => Topic started by: grando on November 01, 2010, 05:15:13 pm
-
hi guys!!
i am new to SFML!! in my considerations i had examined that most of programmers implement their programs just in the "main" without any classes!! i want to know we can not implement OBJECT ORIENTED programs with SFML?? is there any body have an example of OBject oRiented program implemented with SFML?? if you have please help ME!! thanks a lot!
-
He it's possible, but here you will short code for the most. Here (http://dl.free.fr/vkFObO1zC) you will find an old project of mine. I not assure you the code is clean but is object oriented.
-
Most of samples included with SFML are short enough to have all the code written in the main function.
Nevertheless, this does not mean that these samples are not object oriented : They use SFML, which is highly object oriented. "Object oriented" does not necessarily mean that program declare objects.
-
yeah you are right but i want to use SFML in a Robotic project! i want to make a simulator! So for example i want to have a WorldModel class that contains some data 's of World and one another class that im named it BasicPlayer for commanding to the simulated robots( for example move command )
!! any ideas?
-
This has nothing to do with SFML : You can develop your project the way you want ( Object oriented or not ), SFML does not prevent or force you to use a programming paradigm in your own code.
SFML is just a library, not a language or a framework.
-
Quick Tutorial
sf::Image* pImage = new sf::Image();
sf::Sprite* pSprite = new sf::Sprite();
pImage->LoadFromFile("MyImage.png");
pSprite->SetImage( (*pImage) ); // - Remember to include Pointer in brackets, prefixed with an asterix.
pMyRenderWindow->Draw( (*pSprite) );
The easy way to object-orientate SFML.
(Hope this helps!)
-
Quick Tutorial
sf::Image* pImage = new sf::Image();
sf::Sprite* pSprite = new sf::Sprite();
pImage->LoadFromFile("MyImage.png");
pSprite->SetImage( (*pImage) ); // - Remember to include Pointer in brackets, prefixed with an asterix.
pMyRenderWindow->Draw( (*pSprite) );
The easy way to object-orientate SFML.
(Hope this helps!)
Beside the fact that you use dynamic allocation and parenthesis for no reason, I don't see anything special here.
I think pretty much everyone agrees on the fact that good object-oriented programming mainly comes from how you design the relationships between your objects for a specific problem; it's not just applying a generic pattern.
Personally I think there's nothing wrong about starting with the most simple implementation (which is often procedural), then tailor it as needed when the project grows, especially when it's a personal project and no OOP zealot will harass you.
By the way, “pure OOP” in languages such as C++ and Java is just bullshit. When a zealot talks about such things just ignore him. Any worthy design practice has straightforward advantages which should be easily explained; if someone instead keeps talking about how the gods of object-oriented programming don't like your design, then he doesn't know what he's talking about.
-
sf::Image image;
sf::Sprite sprite;
image.LoadFromFile("MyImage.png");
sprite.SetImage( image );
myRenderWindow.Draw( sprite );
is also a perfect OOP program, ( For example, we're using objects member functions ) and is also safer ( No dangerous raw pointer, exception safety ), shorter, in a word better.
(By the way, parenthesis are indeed useless :wink: )
-
Just a quick and dirty method to providing the quick and easy way to creating the objects.
Just assumed it was the answer grando was looking for.
Never Mind Eh
-
You should not use manual memory management without having a good reason to do so. Especially not if the equivalent code can be written using automatic storage.
In the cases where you need dynamic allocations, RAII is your friend. Containers and smart pointer are examples.
-
So used to working with libraries, SDK's, API's etc that demand manual memory management, that it's just second nature now lol...
Will have to revise the KISS philosophy some time soon.
-
You can code your OOP classes with SFML stuff inside it. I usually do this. The only thing I do outside the classes is to instantiate a RenderWindow and a RenderWindow pointer. Then I pass the RenderWindow pointer everywhere else that needs rendering. So the main() keeps clean.
Simple example (not working):
class Engine
{
public:
Engine(sf::RenderWindow *w_ptr)
{
this->window_ptr = w_ptr;
}
Engine::drawEverything()
{
this->window_ptr->Draw(...put your sprite here...);
}
private:
sf::RenderWindow *window_ptr;
}
-
Here is a small, mostly skeletal example of OOP with SFML:
#include "Game.h"
Game::Game(void)
{
App=NULL;
// Create the main rendering window
App = new sf::RenderWindow(sf::VideoMode(800, 640, 32), "TileMap Example");
//hide the mouse cursor in the window
App->ShowMouseCursor(false);
GameState = STARTUP;
stateTime = 0;
the_map = new Map(App);
}
Game::~Game(void)
{
delete the_map;
delete App;
}
void Game::Run(void)
{
while (App->IsOpened())
{
// Process events
while (App->GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
{
App->Close();
return;
}
}
//perform our game logic
Logic(App->GetFrameTime());
// Display window contents on screen
App->Display();
}
}
void Game::DrawLevel(void)
{
the_map->DrawMap();
}
void Game::DoInput(void)
{
}
void Game::DoPhysics(float time_passed)
{
}
void Game::Logic(float time_passed)
{
switch(GameState)
{
case STARTUP:
{
the_map->SetScreen(0, 0, 10, 8);
GameState = LOAD1;
}
break;
case LOAD1:
{
the_map->LoadMap("data/Level1.txt");
GameState = PLAY1;
}
break;
case PLAY1:
{
DoInput();
DoPhysics(App->GetFrameTime());
DrawLevel();
}
break;
default:
break;
}//end switch
}
The Map class saves a pointer to the RenderWindow so it can draw it's sprites..the header file for the Map class might look like this:
#include <SFML/graphics.hpp>
#include <vector>
#include <string>
#include <fstream>
using namespace std;
class Map
{
private:
int rows, cols; //the # of rows and columns in the map array
sf::RenderWindow *App;
sf::Image *tilepic;
sf::Sprite *tilesheet;
float origin_x, origin_y; // pixel offsets of where to start drawing the map on the screen
int num_tiles_across_screen; //how many tiles to display across
int num_tiles_down_screen; //how many tiles to display down
vector<vector<int>> *map; //our 2D map array
int cell_width, cell_height; //dimensions of a single tile, in pixels
int num_tiles_across_tilesheet;//how many tiles are in a row on the tilesheet
public:
void SetScreen(float x, float y, int tiles_across, int tiles_down);
bool LoadMap(string fname);
bool SaveMap(string fname);
void DrawTile(int tile_num, float x, float y);
void DrawMap(void);
void FreeMem(void);
Map(sf::RenderWindow *the_App);
~Map(void);
};
The above is missing lots of stuff, but it gives you the idea of how you could organize your game. Given a Game class like that, the main.cpp becomes simply:
#include "Game.h"
int main()
{
// Create the Game
Game game;
// Start game loop
game.Run();
return EXIT_SUCCESS;
}
-
Gibgezr, why is almost everything a pointer at you? This forces you to use manual memory management. Especially things like
vector<vector<int>> *map;are better to use without the *.
And instead of the following (where the first statement is completely useless, anyway)
Game::Game(void)
{
App=NULL;
// Create the main rendering window
App = new sf::RenderWindow(sf::VideoMode(800, 640, 32), "TileMap Example");
the_map = new Map(App);you could write the constructor with automatic variables like this:
Game::Game()
: App(sf::VideoMode(800, 640, 32), "TileMap example")
, the_map(App)
{
}
Then, the destructor doesn't need to be defined because the compiler-generated one does the right thing.
And the switch statement is probably not the best example for OOP code. Especially if the branches become more complex, they could be outsourced into virtual functions. Apart from that, your map tends to a monolith class with too much responsibilities. Good object-oriented code often separates the game components, especially graphics and logics.
-
Nexus,
What do you mean on "outsourcing branches into virtual functions" ?
I am curious about that because I also do a lot of monster branches...
-
A simple example of different screens/menus/surfaces:
class Surface
{
virtual ~Surface();
virtual void Run() = 0;
};
class MainMenu : public Surface
{
virtual void Run();
};
class Game : public Surface
{
virtual void Run();
};
// In your main game loop
while (inLoop)
{
surface->Run();
}
Transitions from one to the other surface can be realized through the return value of Run(). A possibility is an enum and a std::map that maps the enum to the different surfaces. (In fact, boost::ptr_map might be more appropriate, but the principle remains the same.)
enum SurfaceEnum {InGame, InMainMenu, Exit, ...};
std::map<SurfaceEnum, Surface*> map;
map[InGame] = new Game;
map[InMainMenu] = new MainMenu;
// delete everything in the end
Then, the main loop can look like this:
SurfaceEnum next = InMainMenu;
while (next != Exit)
{
surface = map[next];
next = surface->Run();
}
That's just one of many possibilities :)