So my question is: I'm trying to make a "carousel" of images (select image from file, load it and display it using "next_button" or load the previous one using "previous_button"). My problem is that i have no clue how to access the same window, I have defined at main, so I can attach the selected picture.
I tried passing my_Window& win but I get an error at cb_next saying that I cannot use this type (struct)
Any ideas would be greatly appreciated. Thank you very much for your valuable time!
Here is a sample of the code:
struct my_Window : Graph_lib :: Window
{
//Defined buttons
//...
//Example of how I create and call the next_button(to display the next picture)
static void cb_next(Address, Address); // callback for next_button
void next();
};
//Here is what I use to make the button work
void my_Window::cb_next(Address, Address pw)
{
reference_to<my_Window>(pw).next(); //cannot pass my_Window
}
void my_Window::next()
{
//Load the next picture!
//This is where I want to attach the image
//but when I use attach(image) it doesn't know where to attach ( as expected)
redraw();
}
int main()
{
my_Window win(Point(100,100),800,600,"Images"); //I want this "win" to be accessed by the next button so I can attach the new picture.
return gui_main();
}
It's more of a C++ question.
Why is cb_next() a static method?
If you make it a normal method, you can access the same struct/window you defined in main using the this pointer. Writing this is also optional, you already call redraw in the next() method, which is actually this->redraw();.
I'm trying to make a mini game in c++ and i have encountered a problem. I am currently trying to make a board for my game and i've made a function to draw the borders but i don't want to call it, i want it to be called by the constructor.
Board.h :
class Board
{
public:
Board(Graphics& out_gfx);
private:
void DrawBoardBorder();
Graphics& in_gfx;
Color borderColor = Colors::MakeRGB(94,35,113);
};
Board.cpp :
Board::Board(Graphics & out_gfx)
:
in_gfx(out_gfx)
{
DrawBoardBorder();
}
The borders are drawn correctly if the function is moved to public and called with the help of the object, but the borders are not drawn if i let the constructor do the job. Why?
In my game I have an animated sprite. I added box2d to my game to add gravity. now I want to update my sprite's position using the schedule function. I got it working with objective-C, but I want it to be a multiplatform game so now I'm trying it in c++.
In my init I have the following line:
this->schedule(cocos2d::SEL_SCHEDULE(View::tick(1.0f)));
and the method tick:
void View::tick(float dt) {
world->Step(dt, 10, 10);
for(b2Body *b = world->GetBodyList(); b; b=b->GetNext()) {
if(b->GetUserData() != NULL) {
}
}
}
I get the following error on the line in my init: "cannot cast from type ' void' to member pointer type 'coco2d::sel_schedule' (aka void coco2d::CCobject::*)(float)
I have no idea what to do now. I tried to google, but everyone either uses objective - c or schedule_selector (which apparently doesn't work anymore)
Thanks in advance
You should probably not be using the schedule function to update a single sprite.
In your scene class, override the virtual method for update(...):
virtual void update(float dt)
{
CCLOG("This was called.");
// Do updates for everything in the scene you need to call on a tick.
}
Also, override onEnter() and onExitTransitionDidStart(). In the first, call scheduleUpdate to set up your scene for automatically being called on a tick. In the second, call unscheduledUpdate (as the scene is exiting) to stop the updates.
void IntroScene::onEnter()
{
CCScene::onEnter();
scheduleUpdate();
}
void IntroScene::onExitTransitionDidStart()
{
CCScene::onExitTransitionDidStart();
unscheduleUpdate();
}
Doing it this way gives you explicit control over what gets updated when...you only have a single function called during an update cycle.
HOWEVER, if you really want to do it:
Declare your custom updater like this:
void IntroScene::myUpdate(float dt)
{
CCLOG("Also called");
}
Schedule it like this:
schedule(schedule_selector(IntroScene::myUpdate), 1.0f);
Unschedule it like this:
unschedule(schedule_selector(IntroScene::myUpdate));
** NOTE ** As far as I know, you can only "schedule" objects derived from CCNode.
Was this helpful?
I have a game engine written my my team, it's component based. It has logic components and visual components. In visual components there is a function named updateVisual(delta) and everything is drawn there.
For example, let's take physic ball entity in world:
class LogicBallComponent
{
// ...
};
class VisualBallcomponent
{
sfml::Texture mBallTexture;
void updateVisual(float)
{
mBallTexture.translate(...);
GlobalDisplayManager::instance().draw(mBallTexture);
}
};
GlobalDisplayManager returns some window representation which creates gl-states, etc. (sf::RenderWindow in sfml). This system is easy to integrate.
Now I need to make android-game using my engine. I've chosen cocos2d-x to use for window creation, rendering, fonts, resources etc.
There is another way to do the job:
class Ball : public CLayer
{
bool Ball::init() {
CSprite* sprite = CSprite::create(...);
this->addChild(sprite, 0); // [!]
}
};
And I don't know how to use it in my way. Is there such possibility?
You should check out the function "void CCDisplayLinkDirector::mainLoop(void)", which is the main loop of coco2d-x rendering engine.
coco2d-x provides wrappers for periodic calling loop. In iOS you should check the function startMainLoop of CCDirectorCaller.mm in platform/ios.
So I am semi-new to C++, and completely new to SDL. Most of my conceptual knowledge of OOP comes from Java and PHP. So bear with me.
I am trying to work out some simple design logic with my program / soon to be side-scroller. My problem lies with trying to make my 'screen' layer (screen = SDL_SetVideoMode(...)) accessible to all my other classes; Hero class, background layer, enemies, etc. I have been loosely following some more procedural tutorials, and have been trying to adapt them to a more object oriented approach. Here is a little bit of what I have so far:
main.cpp
#include "Game.h"
#include "Hero.h"
int main(int argc, char* argv[])
{
//Init Game
Game Game;
//Load hero
Hero Hero(Game.screen);
//While game is running
while(Game.runningState())
{
//Handle Window and Hero inputs
Game.Input();
Hero.userInput();
//Draw
Game.DrawBackground();
Hero.drawHero();
//Update
Game.Update();
}
//Clean up
Game.Clean();
return 0;
}
As you can see, I have a Game class, and a Hero class. The Game class is responsible for setting up the initial window, and placing a background. It also updates the screen as you can see.
Now, since my Game class holds the 'screen' property, which is a handle for SDL_SetVideoMode, I am stuck passing this into any other class (ex: Hero Hero(Game.screen);) that needs to update to this screen... say via SDL_BlitSurface.
Now, this works, however I am getting the idea there has GOT to be a more elegant approach. Like possibly keeping that screen handler on the global scope (if possible)?
TLDR / Simple version: What is the best way to go about making my window / screen handler accessible to all my subsequent classes?
I like the way you are doing it.
Though rather than passing the screen reference I would pass a reference to a game itself. Thus each hero object knows which game it belongs too, it can then ask the game object for the screen as required.
The reason I would do this is so that in a few years when your game is a wide and successful product and you convert it for online-play you really need to do no work. The game server will be able to easily support multiple game objects, each game object hosting multiple hero objects. As each hero object wants to draw it asks the game for the screen abd updates the screen (the screen can now very from game object to game object and still work perfectly (as long as they have the same interface).
class Game
{
public:
Game(Screen& screen)
: screen(screen)
{}
virtual ~Game() {}
virtual Screen& screen() { return theGameScreen;}
void update() { /* Draw Screen. Then draw all the heros */ }
private:
friend Hero::Hero(Game&);
friend Hero::~Hero();
void addHero(Hero& newHero) {herosInGame.push_back(&newHero);}
void delHero(Hero& newHeor) {/* Delete Hero from herosInGame */}
// Implementation detail about how a game stores a screen
// I do not have enough context only that a Game should have one
// So theoretically:
Screen& theGameScreen;
std::vector<Hero*> herosInGame;
};
class Hero
{
public:
Hero(Game& game)
: game(game)
{game.addHero(*this);}
virtual ~Hero()
{game.delHero(*this);}
virtual void Draw(Screen& screen) {/* Draw a hero on the screen */}
private:
Game& game;
};
Main.
#include "Game.h"
#include "Hero.h"
int main(int argc, char* argv[])
{
//Init Game
Screen aScreenObject
Game game(aScreenObject);
//Load hero
Hero hero(game); // or create one hero object for each player
//While game is running
while(game.runningState())
{
//Handle Window and Hero inputs
Game.Input();
Hero.userInput();
//Update
Game.update();
}
//Clean up
// Game.Clean(); Don't do this
// This is what the destructor is for.
}
I don't know if it's elegant, but what I do for the side-scrolling game I'm making is to make a show() function in each class than draws to the screen, and passing the screen handle as a parameter. Then whenever I want to draw something to the screen I just do foo.show(screen). The screen handle is in main().
The first, and honestly, easiest solution, is to use a global variable. Yes, yes, yes, everyone says global variables are horrible, but in this situation, it's perfectly fine.
The other solution, which is a bit more work, but can result in somewhat more portable code, is to encapsulate your drawing functions into a single, static class. This way, you can draw to the screen directly without having to pass around a variable, or have to lie awake at night thinking the code review police will get you because you used a global variable. Plus, this can potentially make it easier if you ever decide to port your game to a new library. Some quick and dirty pseudocode:
class Drawing
public:
static void Draw(x, y, sdl_surface graphic, sdl_rect & clip=null);
static void init(sdl_surface & screen);
private:
sdl_surface screen;
void Drawing::Draw(x, y, sdl_surface graphic, sdl_rect & clip=null)
{
sdl_blit(x, y, graphic, clip);
}
void Drawing::init(sdl_surface & screen)
{
this.screen=screen;
}
It sounds like you're looking for a way to implement the Singleton design pattern, where you would have a single Screen object. If you know you're only ever going to have a single Screen object it should work fine.
In this case you would implement a static method on the Game class:
class Game
{
public:
static Game *GetTheSceenObject();
private:
static Screen *theScreen; // details of initialisation ommitted
}
that would return a pointer to the single Screen object.
If there is a possibility that you'll end up using multiple SDL screens, though, it may be worth creating a Draw() method in your Hero class that is responsible for drawing the hero on each of the Screens managed by the Game class by iterating through a list provided by the Game class.
That functionality could be contained in the methods of a common DrawableThingy class that Hero and Enemy are derived from.
Passing Game.screen around is more OO (though it might be better to have a getter function) than having one instance of it that can be accessed from any class, because if you have one global version, you can't have more than one Game.screen at any one time.
However if you know you'll only ever need one in the entire lifetime of the program, you might consider making Game::Screen() a public static function in the Game class that returns a private static member screen. That way, anyone can call Game::Screen() and get the screen.
Example (assuming ScreenType is the type of screen and that you store a pointer to it):
class Game {
public:
static ScreenType* Screen() {
if (!screen)
screen = GetScreenType(args);
return screen;
}
}
private:
// if you don't already know:
// static means only one of this variable exists, *not* one per instance
// so there is only one no matter how many instances you make
// the same applies to static functions, which you don't need an instance to call
static ScreenType* screen;
};
// and somewhere in a .cpp file
ScreenType* Game::screen = NULL;
// and you use it like this
ScreenType* scr = Game::Screen();
// use scr