SFML community forums
Help => Graphics => Topic started by: illuminon on July 20, 2009, 11:13:42 pm
-
Hi out there!
I just started to look into sfml and I wonder whether you could give me a hint how to achieve a splitscreen app. Search wasn't very useful...
Thanks and cheers
illuminon
-
Hi.
There's an easy way to do it in the french wiki (http://www.sfml-dev.org/wiki/fr/sources/ecran_splitte).
-
Hi G.
Merci. I don't yet really understand the example but I'll have a closer look at it. :wink:
greetz
illuminon
-
Very well, I spent some time with this code.
The example out of the french wiki compiles well. But as far as I understand its functionality, it doesnt really show how the split sceen works.
Shouldn't the process be like:
1. clear the screen
2. draw some stuff in the first part
3. call this gl scissor
4. clear the screen (now this only clears the "second part" as defined by the rectangle)
5. draw some stuff (origin of coordinates lies in the top left of the defined rect)
6. unsplit
The example seems to draw only in the "second part". So no split screen effect is shown. Or am I completly wrong with my interpretation??
Believing that it works like mentioned I tried to implement it and ran into the following error (being displayed in the "shell" when running the app):
"Failed to get device context of window - cannot create OpenGL context"
The code for this nice error:
main.cpp
#include "cGame.h"
int main()
{
cGame game;
game.run();
return 1;
}
cGame.h
#ifndef C_GAME_H
#define C_GAME_H
#include <SFML/Graphics.hpp>
//Consts
const int SCREEN_WIDTH = 800;
const int SCREEN_HEIGHT = 800;
const int GAME_FPS = 60;
class cGame
{
public:
cGame(void);
~cGame(void);
void run(void);
private:
bool isRunning;
sf::RenderWindow *Display;
inline void SplitOn(const sf::RenderWindow& Window, const sf::Rect<int>& Zone);
inline void SplitOff();
void handleGameEvents(void);
};
#endif
cGame.cpp
#include "cGame.h"
cGame::cGame(void)
{
Display = new sf::RenderWindow(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 32),"MoonSpire",sf::Style::Close);
Display->SetFramerateLimit(GAME_FPS);
isRunning = true;
}
cGame::~cGame(void)
{
}
inline void cGame::SplitOn(const sf::RenderWindow& Window, const sf::Rect<int>& Zone)
{
glEnable (GL_SCISSOR_TEST);
glScissor(Zone.Left, Window.GetHeight() - Zone.Bottom, Zone.GetWidth(), Zone.GetHeight());
}
inline void cGame::SplitOff()
{
glDisable (GL_SCISSOR_TEST);
}
void cGame::run(void)
{
char runLvl = 2;
// Start game loop
while (isRunning)
{
switch(runLvl)
{
// Menulvl
case 0:
break;
// Create gamestuff
case 1:
break;
// Load game
case 2:
// draw first half of screen
Display->Clear();
sf::Sprite Test;
Test.Resize(20, 40); // "vertical block"
for (int y=0; y<10; y++)
{
for(int x=0; x<10; x++)
{
Test.SetPosition(x*70 + 50, y*50 + 70);
Display->Draw(Test);
}
}
// draw second half of screen
sf::Rect<int> Zone(SCREEN_WIDTH/2, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
SplitOn(Display, Zone);
Display->Clear();
sf::Sprite Test2;
Test2.Resize(40, 20); // "horizontal block"
for (int y=0; y<10; y++)
{
for(int x=0; x<10; x++)
{
Test2.SetPosition(x*70 + 50, y*50 + 70);
Display->Draw(Test2);
}
}
Display->Display();
handleGameEvents();
SplitOff();
break;
}
}
}
void cGame::handleGameEvents(void)
{
sf::Event Event;
while (Display->GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
{
isRunning = false;
break;
}
// Escape key : exit
if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
{
isRunning = false;
break;
}
}
}
Thanks for assistance!
-
The first parameter of SplitOn is a RenderWindow&, but you're passing a RenderWindow* so you need to dereference your pointer.
It should work better this way SplitOn(*Display, Zone); at line 63. :wink:
-
What a shame... Why wasn't Visual Studio even casting a warning?!?
Anyway, it works now :D . Thanks!
-
Why wasn't Visual Studio even casting a warning?!?
Are you using VC 6? If so, I recommend to throw it away and to download a modern version (2008 express).
Acceptable compilers do not compile errors like that.
By the way, you should free your sf::RenderWindow in the destructor unless you like memory leaks. Is there a reason why you use dynamic memory management? You should also think about copy constructor and assignment operator...