Crazy booleans..

Started by
17 comments, last by Guthur 15 years, 3 months ago
Quote:
When you run the debugger, what does is say the value of the booleans are when you go through the if statements? Are they the right values and it is simply ignoring them? Or are they the right values, going into the if statement, and what you call in the If statement isn't working right?

Basically I'm asking if you are positive you are getting into the if statement(Try putting a break on the call to move() ).

Beyond that, you didn't post your "game" class, so we can't see what it does. Perhaps it is getting into the if statement but the "game.get_input().get_move_forward()" call isn't doing what you thought it would, or it should?

How do you do that?

I am not sure what part of my code to show...

Here's the game class(Only header though, the source file is quite large)
#ifndef GAME_H#define GAME_Hclass Game;#include <d3d9.h>#include <d3dx9.h>#include "Application.h"#include "Direct3D.h"#include "Input.h"#include <vector>class Game{private:	Application *application;	Direct3D *direct3d;	Input *input;	std::vector<Object*> game_objects;	std::vector<Object*> destroy_queue;	std::vector<Object*> add_queue;	DWORD spawn_rate;	DWORD time_since_last_spawn;	DWORD frame_rate;public:	Game(Application&, Direct3D&);	//Run	void run();	void load_graphics();	void init_game();	void render();	void update();	void main_loop();	//Create	void create_ship(D3DXVECTOR2, float);	void create_missile(D3DXVECTOR2, float);	void create_asteroid(D3DXVECTOR2, float);	void create_effect(D3DXVECTOR2, float, Sprite*, int);	//Application	Application get_application();	//Input	Input get_input();	//Game Objects	std::vector<Object*> get_game_objects();	//Destroy Queue	std::vector<Object*> get_destroy_queue();	//Frame Rate	DWORD get_frame_rate();	//Extra	double random_number(int, int);};#endif


The game class constructor
Game::Game(Application &new_application, Direct3D &new_direct3d):application(&new_application),direct3d(&new_direct3d),input(&new_application.get_input_data()),spawn_rate(1700),time_since_last_spawn(0),frame_rate(170){}


the 'get_input' function
Input Game::get_input(){	return *input;}
Advertisement
I suspect dragongame is correct in that you do not set it to false once you have consumed the key state.

Maybe try the following :

//Move Forwardvoid Input::set_move_forward(bool new_move_forward){	move_forward = new_move_forward;}bool Input::get_move_forward(){        if(move_forward)        {             move_forward = false;             return true;        }	return false;}


Personally I don't like multiple return paths but this gets the job done. Of course you would have to do this in all the get key state functions. This may not be the problem but its worth looking into.
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
I tried the last suggestion but nothing changed.
class Game{Input *input; //pointerInput get_input(); //Returns Value}//ship updateif(game.get_input().get_move_forward()){	move();}


Are you certain you are returning the Input objects value properly, post get_input(). May not be an issue but its worth a look :)

[Edited by - Guthur on January 15, 2009 1:26:48 PM]
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Antonym
the 'get_input' function

Mmm, returns a copy by value. Not likely to cause the symptom you're seeing unless your Input copy constructor does something weird, but it's kinda a waste to be creating and destroying temporary objects all over the place like that.

Stephen M. Webb
Professional Free Software Developer

Actually double check that the Input object (input_data) you are setting in the windows message loop is getting copied to the one in your Game object (*input), I suspect it isn't.
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Antonym
the 'get_input' function
*** Source Snippet Removed ***


This makes a copy of the pointed at Input instance each time (because you return a value, and it can't very well rip the existing value out of its current spot). If you make a change to the copy, the original won't be affected. If you then request another copy of the original, it will not reflect the change, because it's a copy of the original, not a copy of the modified copy.

But this is only a symptom: the real problem appears to be that you are building multiple levels of "OO" wrapping to "encapsulate" concepts like "Game" and "Application", without really understanding why (and possibly not really accomplishing the goal, anyway). Get/set pairs for data members (such as set_move_forward and get_move_forward) are a symptom of not-well-thought-out attempts at encapsulation, driven by (often outdated) guidelines rather than real understanding.
How do I work with the members then? Should I make them public? I just started using classes a while ago so I am not really sure if I am doing/how to do things right.
Making them all public wouldn't really solve much besides removing the need for the accessor methods.

For the case of the Input object; you have it tightly held in all classes that require access to it, to the point where they are nearly all treating it as their own little object when in fact it should be the same object, there is currently only one source of input afterall.

There is a number of options I can think of but I'm worried about giving you an even worse design strategy :s. Others here could give you a better solution but I will throw in the start of one.


class InputManager{friend class Application;public:    InputManager( );private:    KeyEventListeners* CreateKeyListener ( WORD KeyValue );    std::vector< KeyEventListener* > KeyListeners;}  class KeyEventListener{public:    KeyEventListener( WORD KeyValue );    bool ConsumeState( );    bool PeekState( );    void KeyPressed( );private:    bool State;    WORD KeyValue;}


The application class would hold the InputManager; call the CreateKeyListener to get the required keylisteners and pass the returned listener pointer to the game class or what ever. It would then iterate through any key listeners in the std::vector<KeyEventListeners*> during the message loop to update everything.

I don't like the public KeyPressed function, it means any class can change key state but it could be easily removed, or made private and then make the application class a friend. A nice way might be to use a std::map instead of a vector and have the input manager update the state through a function call with the passed key value.

I'm tired though, and off to bed so I can't really take it any further :|.

[Edited by - Guthur on January 16, 2009 5:55:25 AM]
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.

This topic is closed to new replies.

Advertisement