I'm working on a c++ project for school, and my implementation at this moment requires mouse input for controlling a ship (It's supposed to be a remake of Tyrian). Everything is working fine, except for the first time I move the mouse, it has an offset depending on where the mouse was when I started the game. I guess this is because I'm using SDL_GetRelativeMouse but how can I prevent it?
You may wish to initialize the mouse to a good known position when the application begins, possibly right before events callbacks are initialized.
Making sure the mouse is within the bounds of the window may also be appropriate. It isn't really relevant to the application outside of its boundaries anyway.
This is what I do to toggle mousegrab in a FPS-type application:
if(event.key.keysym.sym == SDLK_z)
{
if( mouse_grabbed )
{
SDL_WM_GrabInput(SDL_GRAB_OFF);
SDL_WarpMouse( display->w/2, display->h/2 );
SDL_ShowCursor(1);
}
else
{
SDL_ShowCursor(0);
SDL_WM_GrabInput(SDL_GRAB_ON);
int tx,ty;
SDL_GetRelativeMouseState(&tx, &ty);
}
mouse_grabbed = !mouse_grabbed;
}
Consuming a mouse update via the dummy SDL_GetRelativeMouseState() call was the important part.
For the moment I'll just suppress the first time mouse movement is detected. This seems to work, but it seems a rather unprofessional approach.
I use this:
Sdl.SDL_ShowCursor(Sdl.SDL_DISABLE);
Sdl.SDL_WM_GrabInput(Sdl.SDL_GRAB_ON);
e=new Sdl.SDL_Event();
pollOne();
.
.
.
private void pollOne(){
while(Sdl.SDL_PollEvent(out e)==1){
switch(e.type){
case Sdl.SDL_MOUSEMOTION:
float throwAway=((float)e.motion.xrel*headSens);
break;
}
}
}
Basically, when initializing the mouse (grabbing it and making it invisible) call pollOne to throw the first event away. Every event captured hereafter in the main event processing function called by the main loop is with mouse at center screen.
Related
I'm working on a small game project and by mere curiosity I commented the line that makes a refresh to the main WINDOW object.
while(game->state)
{
//Move into player
params->mov = player_1;
params->x = player_1->pos_x;
params->y = player_1->pos_y;
params->game = game;
//curs_set(FALSE);
player_1->key_move(params);
//Move into player
mvwprintw(p_info,y, x, "TERRAIN: [%c]", player_1->inplace);
//wrefresh(main_scene); /* THE LINE I DELETED */
wrefresh(p_info);
sleep(TICK);
}
The game ran without problems and player updated its position graphically. player_1->key_move(params) eventually calls wgetch(), mvwaddch(), and mvinch(), nothing else (from ncurses). wrefresh(p_info) was commented after and, as expected, that WINDOW object never updated. I'm wondering if that function calls wrefresh() at some point. There's no direct indication of this in the manual.
If it does, are there alternatives to mvwaddch() that doesn't update the WINDOW object?
According to man wgetch, and I quote:
If the window is not a pad, and it has been moved or modified since the last call to wrefresh, wrefresh will be called before another character is read.
Because this is a game, inside the loop, and more concrete in the routine call to player_1->key_move(params) there are modifications to the WINDOW object. This is why the program is causing such behaviour.
I realised that game logic was depending on state from the WINDOW, so several reads/writes would potentially come in the future. All game logic is to be handled separately.
I am using Qt creator to make a simple drawing program in c++. I have a mouseevent, that should get the coordinates to the nearest point (dot) allready existing from the point where mouse was clicked, and put them to line starting point coordinates. Thats done. But now the event should wait for a second mouse click to get the nearest dot coordninates again and put them to end point of line. But instead it does not wait for the second input and puts the same first point for the line endpoint also.
How can I make mouseevent take two click inputs, not do everything right away? Is it even possible? Thank you in advance.
You cannot make one event require two clicks (excluding, of course, the double click event). You can, however, establish a state within your application, where the first click starts the state and the second completes it. Pseudo-code to manage this:
// in your constructor:
StartingClickPoint = INVALID; // indicate that we have not entered our special state
// in your mouse event handler:
if (StartingClickPoint == INVALID) {
// we're only now starting this state; we don't have enough information to complete it
StartingClickPoint = CurrentClickPoint;
return;
}
else {
// complete the state handling and arm for the next pair of clicks
EndingClickPoint = CurrentClickPoint;
DoSomethingWithTheClickPoints();
StartingClickPoint = INVALID; // reset for the next pair of clicks
}
I'm creating this 2D game and I'm having problems with the Jump function. It works, the character jumps up and down, but I would like to be able to jump and then move the character while its in the air,e.g. so it can jump onto a platform. I'm using SDLK...
case SDL_KEYDOWN:
switch (event.key.keysym.sym){
RArrow = (event.button.button = SDLK_RIGHT);
Jump = (event.button.button = SDLK_SPACE);
if((RArrow) && (Jump))
{
if(g->getPlayer()->worldY = GROUND_LEVEL)
{
g->getPlayer()->jump();
g->getPlayer()->move(10);
}
}
break;
This is one of the ways I've tried. I've also tried to make a switch function inside the jump case to navigate left or right but I either didn't code it right or just didn't work.
I'm unfamiliar with SDLK and how this actually is done in real game development.
However one way I've implemented this is to see if both keys are pressed on each game tick. So if w+d is pressed the character would go up and right at the same time. But it's a hackish solution in my opinion.
With the implementation listed, looks like the character will only move right when they are on the ground level. You need to change your code so that every tick, the game checks if the character is jumping and if so, moves the character in the direction it is facing/jumping. This code may need to live outside of your event handler.
Ideally, your keyboard event handler would just set a flag on the character indicating that they are jumping and which direction, then in your game loop you call an update() method which actually handles the jumping (and stops jumping when the character collides with the world geometry, like a floor or wall).
Hope this helps!
EDIT:
Without seeing the rest of your code, I can't say much more. I'm also not great with C++, which I'm assuming this uses. One way you could implement this is:
Replace "g->getPlayer()->jump()" with "g->getPlayer()->setJumping()".
Implement "setJumping()" on the Character to set a jumping flag.
In the game loop, call "g->getPlayer()->updatePos()"
Implement "updatePos()" on the Character to update the character's position. In this, check the jumping flag, and if it's true update the position based on your jumping algorithm.
I'm porting a game from Ruby to C++. There is a main render loop that updates and draw the content. Now let's say that during the game, you want to select an item another screen. The way it's done in the original code is to do Item item = getItemFromMenu(); getItemFromMenu is a function that will open the menu and do have its own update/render loop, which mean that during the whole time the player has this other screen open, you are in a nested render loop. I feel like this is a bad method but I'm not sure why. On the other hand it's very handy because I can open the menu with just 1 function call and so the code is localized.
Any idea if this is a bad design or not?
I hesitated to post it on gamedev, but since this is mostly a design issue I posted it here
edit : some pseudo-code to give you an idea:
The usual loop in the main part of the code:
while(open) {
UpdateGame();
DrawGame();
}
now inside UpdateGame() i would do something like:
if(keyPressed == "I") {
Item& item = getItemFromInventory();
}
And getItemFromInventory():
while(true) {
UpdateInventory();
if(item_selected) return item;
DrawInventory();
}
A good way to handle something like this would be to replace the DrawInventory() call with something like InvalidateInventory(), which will mark the current graphical state of the inventory as outdated and request it to be redrawn during the next frame rendering (which'll happen pretty soon after when the main loop gets to DrawGame()).
This way, you can keep running through the main loop, but the only parts of the screen that get looked at for redrawing are the ones that have been invalidated, and during normal gameplay you can invalidate your (2/3)D environment as a normal part of processing, but then inside the inventory you can always mark only inventory assets as needing to be redrawn, which minimises overhead.
The other part of your inner loop, UpdateInventory(), can be a part of UpdateGame() if you use a flag to indicate the current game state, something like:
UpdateGame()
{
switch(gameState)
{
case INVENTORY:
UpdateInventory();
break;
case MAIN:
default:
UpdateMain();
break;
}
}
If you really wanted, you could also apply this to drawing:
DrawGame()
{
switch(gameState)
{
case INVENTORY:
DrawInventory();
break;
case MAIN:
default:
DrawMain();
break;
}
}
But I think drawing should be encapsulated and you should tell it which part of the screen, rather than which separate area of the game, needs to be drawn.
What you've created with your nested render loop is functionally a state machine (as most game render loops tend to be). The problem with the nested loop is that many times you'll want to do the same sorts of things in your nested loop as your outer loop (process input, handle IO, update debug info etc).
I've found that it's better to have one render loop and use a finite state machine (FSM) to represent your actual states. Your states might look like:
Main menu state
Options menu state
Inventory state
World view state
You hook up transitions between states to move between them. The player clicking a button might trigger the transition which could play an animation or otherwise, then move to the new state. With a FSM your loop might look like:
while (!LeaveGame()) {
input = GetInput();
timeInfo = GetTimeInfo();
StateMachine.UpdateCurrentState(input, timeInfo);
StateMachine.Draw();
}
A full FSM can be a bit heavyweight for a small game so you can try a simplified state machine using a stack of game states. Every time the user does an action to transition to a new state you push the state on a stack. Likewise when they leave a state you pop it off. Only the top of the stack typically receives input and the other items on the stack may/may not draw (depending on your preference). This is a common approach and has some upsides and downsides depending on who you talk to.
The simplest option of all is to just throw a switch statement in to pick which render function to use (similar to darvids0n's answer). If you're writing an arcade clone or a small puzzle game that would do just fine.
I am writing a game and am trying to make a person move with the arrow keys.
I have this code
if (Key_Down(DIK_DOWN))
{movedown(player)}
This works but as I want the player to take four steps every time the key is pressed I created and animation loop. so the player cannot input any more move commands until the animation is over and they have taken four steps I made the code this.
if(player.move == false)
{
if (Key_Down(DIK_DOWN))
{movedown(player)}
}
The problem is that now once a button is pressed the program acts like the button is held down and the player keeps moving until another direction is pressed.
Can anyone explain what the outer loop has done to the code and fix the problem ?
it is programmed in visual c++ 2005 and direct x 9.c
Edit:
If I remove the outer loop then the button press is only registered once so I don't think it is the movedown function.
Simply keep track of the keystate in a variable. So you can reset a move counter. Something like this, combining both:
int MovingDown = 0;
...
if (!Key_Down(DIK_DOWN)) MovingDown = 0;
else if (MovingDown < 4) {
MovingDown++;
movedown(player);
}
Hard to tell without seeing more of your codebase but I would guess that you're not re-setting player.move after you've moved the player. Have you tried sticking some break poins in there to see what is being called and why?
If you remove the if(player.move == false) line does it have the same issue? ..or have you changed something elsewhere? If you could post more of your codebase like the whole movedown function and anythnig else which interacts (e.g. the animation code) it would help us help you...
[Edit] Is movedown a macro? Maybe you've got some peculiar side effect eminating from that? If not, it ought to have a semi colon after the function call.
What does KEY_DOWN return? Is that an API call? Try testing against the exact value you expect it to return?