Trying To Explain To Qt That I Need QGView To Follow My Player Sprite
-
@Grepur
What is currently "not working"?
Although I have not looked at it in any detail, it seems reasonable to me. -
@JonB Hi. The Player sprite moves without the View following it; it doesn't keep the Player sprite in the centre of the View. The Player sprite can move out of the View; the View doesn't move.
-
@Grepur said in Trying To Explain To Qt That I Need QGView To Follow My Player Sprite:
QGraphicsView *view = new QGraphicsView(scene); view->setFixedSize(1500, 1200); view->centerOn(player);What stands out to me is this:
Gameis aQGraphicsViewbut you still create another independent instance ?!
Is there a reason to have two QGraphicViews?@Pl45m4 I'm not seeing where there are two instances of View that are the same, that one would be redundant. In one case, the Player sprite is made the focus, and in the Lambda expression, the View is intended to re-centre on the Player sprite each time the Player moves.
-
@Pl45m4 I'm not seeing where there are two instances of View that are the same, that one would be redundant. In one case, the Player sprite is made the focus, and in the Lambda expression, the View is intended to re-centre on the Player sprite each time the Player moves.
@Grepur said in Trying To Explain To Qt That I Need QGView To Follow My Player Sprite:
@Pl45m4 I'm not seeing where there are two instances of View that are the same, that one would be redundant. In one case, the Player sprite is made the focus, and in the Lambda expression, the View is intended to re-centre on the Player sprite each time the Player moves.
Your Game class is a QGraphicsView. In its constructor your create a new QGraphicsView that you then use.
That's the second instance @Pl45m4 wrote about.
-
@Pl45m4 I'm not seeing where there are two instances of View that are the same, that one would be redundant. In one case, the Player sprite is made the focus, and in the Lambda expression, the View is intended to re-centre on the Player sprite each time the Player moves.
@Grepur
Have you understood @Pl45m4 post above?In the constructor of
Game, which itself is aQGraphicsView,you create a new instance of aQGraphicsView. That is the one used in theconnect(), but you never show it and it cannot be referenced once the constructor returns. -
-
@Grepur said in Trying To Explain To Qt That I Need QGView To Follow My Player Sprite:
@Pl45m4 I'm not seeing where there are two instances of View that are the same, that one would be redundant. In one case, the Player sprite is made the focus, and in the Lambda expression, the View is intended to re-centre on the Player sprite each time the Player moves.
Your Game class is a QGraphicsView. In its constructor your create a new QGraphicsView that you then use.
That's the second instance @Pl45m4 wrote about.
@SGaist Hi. (Sorry for the delays in responses; I'm being delayed 600 seconds between posts today.)
I have deleted the second call to QGraphicsView, and now the lambda expression gets an error message about 'view' being an undeclared identifier. I'm trying to figure-out what that means now.
Thanks for the pointer. -
One of the error messages was fixed by my adding QGraphicsView * view in game.h .
I'm still snagged on the other one. Very new to lambdas. Barely understand what's expected or what are the rules for what information to place between the brackets.
I generally understand the signal/slot objective: connect Player, Player's changed Position... But I'm just blanking out at that point. Something about pairing the Change with the View, but all my guesses about what to put within those braces are rubbish.
I just need to know how to think about it. I'm lost down in the Code instead of up in the Overview where everything would make sense... -
That's the issue with your architecture.
You should take a pen and paper and draw what you want to achieve and the structure you currently have.
Your Game class should not be a QGraphicsView. Make it a QWidget, set a layout on it and then add that
viewto it.
If you're not yet fluent with lambdas, then let them on the side for now and use a member function for your slot.
Don't make things needlessly complicated while you are learning. Make it work and then refactor and improve. -
That's the issue with your architecture.
You should take a pen and paper and draw what you want to achieve and the structure you currently have.
Your Game class should not be a QGraphicsView. Make it a QWidget, set a layout on it and then add that
viewto it.
If you're not yet fluent with lambdas, then let them on the side for now and use a member function for your slot.
Don't make things needlessly complicated while you are learning. Make it work and then refactor and improve. -
The (simple) fix is quite easy:
Remove your secondviewand everything related to it. Then replace every call toviewwiththis(your actualGameclass)... There might be some other structural flaws asQGraphicsViewisn't the best place to hold all your game logic.
So you could split it into multiple classes likeGame(backend) andGameView(your graphics view).Assuming you're actually looking at the
GameGraphicsView, change your lambda fromview->centerOn(player);to
centerOn(player);Also I wouldn't necessarily let your game/gameview hold a standard scene. You could introduce three classes (in addition to a
QMainWindowfor example):GameGameView(inheritingQGraphicsViewasGamedoes now in your current situation)GameScene(inheritingQGraphicsScene, your game related custom scene, which you might want to modify other than having a standardQGraphicsScene)
-
The (simple) fix is quite easy:
Remove your secondviewand everything related to it. Then replace every call toviewwiththis(your actualGameclass)... There might be some other structural flaws asQGraphicsViewisn't the best place to hold all your game logic.
So you could split it into multiple classes likeGame(backend) andGameView(your graphics view).Assuming you're actually looking at the
GameGraphicsView, change your lambda fromview->centerOn(player);to
centerOn(player);Also I wouldn't necessarily let your game/gameview hold a standard scene. You could introduce three classes (in addition to a
QMainWindowfor example):GameGameView(inheritingQGraphicsViewasGamedoes now in your current situation)GameScene(inheritingQGraphicsScene, your game related custom scene, which you might want to modify other than having a standardQGraphicsScene)
