Messages

46

Graphics / Re: Problem with IntRect or setTextureRect

« on: October 24, 2018, 07:18:56 pm »

Ok, yeah your texture looks to be 319x424.

sf::IntRect rectSourceSprite(300, 0, 300, 400);
sf::Sprite sprite(texture, rectSourceSprite);
 

You're setting your sprite to be almost the same size as the whole texture.

47

Graphics / Re: Problem with IntRect or setTextureRect

« on: October 24, 2018, 07:05:31 pm »

What is the width and height of dragonFrames.png? Is it only 300x400?

48

General / Re: Strange animation behaviour

« on: October 17, 2018, 11:03:28 pm »

Oops, somehow in my last post I missed that your buffer variable was static. That's going to cause you problems because both _idle and _idleElectro are sharing the same 'buffer'. It would be better as a member variable instead of static in that function.

49

General / Re: Strange animation behaviour

« on: October 17, 2018, 08:59:56 pm »

What have you tried so far to debug it?

static sf::Time buffer = sf::Time::Zero;

// Update with an elapsed time
buffer += delta;
 

This looks fishy to me. You set this "buffer" to 0 every update and then add this frame's delta. As you have it right now, if the delta is always small then the buffer will always be less than frameDuration. I would guess you actually want to accumulate the deltas over time.

Presumably clicking on the window border makes it work because it causes the delta to be larger for that one frame.

50

Graphics / Re: Application will freeze when using sf::Clock

« on: September 14, 2018, 11:39:22 pm »

You should probably change delta_time == 50 to delta_time >= 50. Right now if your delta time ever jumps from, say 49 to 51, your code will never update the text again.

51

Graphics / Re: sf::Rect

« on: September 10, 2018, 10:28:55 pm »

Dude, learn math please before posting here

Yikes, no need to be an ass to people trying to help you. It's possible I'm wrong as I'm not at a place where I can try things out, but let's take another stab at it. It's easy to end up with off-by-one errors.

Let's now imagine Left=0 and Width=1.Based on what you said width 1 would be 0-1, but what are you expecting to happen if you were to draw it to the screen in red? Would you expect both pixel 0 and 1 to be red? That would feel like a width of 2 to me.

Width of 1 doesn't include all of 0 and all of 1. In other words [0,1).

52

Graphics / Re: sf::Rect

« on: September 10, 2018, 08:51:01 pm »

Imagine Left=0 and Width=5. The 5 horizontal points in your rectangle would then be 0, 1, 2, 3, 4.

Now imagine x=5. (x < Left + Width) becomes (5 < 0 + 5), which will evaluate to false. This is correct because the horizontal point 5 is not in the rectangle. If it were "<=" then it would incorrectly evaluate to true.

53

General / Re: Switching between states

« on: August 10, 2018, 07:30:04 pm »

I'm glad I could help.

It's still strange to me that one press of a key goes into two switch statemants

I might be easier for you to understand if we replace the event variable with just an integer. Your code would then be similar to this

int a = 5;
bool loc_chosen = false;
bool job_chosen  = false;

switch (a)
{
   case 5:
   {
      loc_chosen = true;
      break;
   }
}
if (loc_chosen)
{
   switch (a)
   {
      case 5:
      {
         job_chosen = true;
         break;
      }
   }
}
 

As you can see, 'a' never changes, so there's no reason why you wouldn't end up in the same 'case' for each switch statement.

could you elaborate how using enum would change anything

I didn't elaborate too much in my first post because there are many ways to handle states in a program. I didn't mean that it would fix your problem directly, just that it might make your logic a little easier to follow and extend. Using enums is just one option that is pretty simple and straightforward, but there are many other more sophisticated (and possibly overkill) options too for tracking state. You're right that you will still need some 'else' statements, but just using one variable for state tracking is a little easier to wrap your head around than using multiple booleans. Basically, the enum would just look something like this

enum class eState
{
   ShowMenu1,    // Equivalent to !loc_chosen && !job_chosen
   ShowMenu2,    // Equivalent to loc_chosen && !job_chosen
   DoOtherThings // Equivalent to loc_chosen && job_chosen
};
 

and then you could make a variable of type eState instead of your current booleans to track what state you're in.

54

General / Re: Switching between states

« on: August 10, 2018, 03:44:30 pm »

Presumably most of this code is within a pollEvent() loop. Your "event" variable will not change until the next time through the loop. I'll distill your problem down to the few lines of code that matter. That might make it easier to see your problem. I made comments in the code to also help walk you through it.

// we'll assume loc_chosen is initially false and the user has pressed the return key.
if (!loc_chosen)
{
   switch (event.key.code)
   {
      case sf::Keyboard::Return:
      {
         loc_chosen = true; // User pressed return, so loc_chosen is now true
         break;
      }
   }
}
if (loc_chosen) // loc_chosen was set to true earlier, so we enter this if statement as well
{
   switch (event.key.code) // The event variable is still the same as before. Nothing has changed it.
   {
      case sf::Keyboard::Return:  // The event variable still contains return from before.
      {
         job_chosen = true;
        // You can (hopefully) now see that one press of the return key will always set both job_chosen and loc_chosen.
         break;
      }
   }
}

 

The quick way to fix your problem would be by changing that 2nd 'if' statement into an 'else'. That way you can't enter it until the next iteration of your pollEvent() loop. A possibly better solution would be to also use something slightly more sophisticated than multiple booleans to keep track of your state, like an enum for starters.

55

General / Re: How to organise data? And what about dinamic/static memory?

« on: July 27, 2018, 03:59:07 pm »

In general these are game design questions that you would have to solve even if you were using a different library from SFML. These forums tend to be more focused on SFML directly, so you may not get the best help here.

Having said that, here are some thoughts:

• Since you are a beginner in C++ I would recommend not bothering with threads for anything. They add a lot of complexity and it is very easy to introduce hard to debug race conditions and other problems. You don't need threads to solve the types of problems you're facing.
• look up how to use std::vector. It may hep you with your problem of holding on to multiple arrows or multiple frames of an animation. For example, perhaps your player class could have a std::vector member variable for holding in-flight arrows. You could add more arrows to the vector as they are shot and remove arrows as they hit enemies. This is just one possibility of many.
• Why not try to learn game design by following some examples. You could take a look at the books listed on the Learn SFML page.

56

Graphics / Re: unable to draw sf::Text - with BAD_ACCESS exception being raised

« on: July 02, 2018, 05:24:09 pm »

From the SFML documentation of sf::Text::setFont()

The font argument refers to a font that must exist as long as the text uses it. Indeed, the text doesn't store its own copy of the font, but rather keeps a pointer to the one that you passed to this function. If the font is destroyed and the text tries to use it, the behavior is undefined.

You are creating a sf::Font object locally in your Game::setUp() function. The font will go out of scope and be destroyed when that function ends. You will then get undefined behavior when you try to draw your text in Game::update().

Similarly, textures need to exist for as long as sprites use them and SoundBuffers need to exist for as long as sounds use them.

57

General / Re: Good way to create a menu ?

« on: June 25, 2018, 10:59:27 pm »

As eXpl0it3r mentioned, one viable approach would be to use a state machine design. There are several different ways you could implement a state machine, but the high level idea is you have some way of keeping track of what state you are in. Then, only pass events to your menu objects when you are in a "menu" state and only pass events to you game objects when you are in your "game" state.

58

General / Re: RPG Sprites - Equipment and spritesheets

« on: June 20, 2018, 03:55:13 pm »

You listed 2 viable options, though as you mentioned the first would be a lot of work depending on how may combinations of characters and equipment you had in mind.

You could alternatively create the equipment sprites separate from the character sprites and just layer them on top of each other in-game. Also, if the different equipment looks the same other than being different colors, you could try creating one sprite sheet and re-color it on the fly in the game.

59

Graphics / Re: Tilemap behaving WEIRD...

« on: June 18, 2018, 11:18:40 pm »

Are you drawing your tilemap to non-integer coordinates? Or are you using a sf::View that can be at a non-integer position? Just based on your images this looks like an issue that many people run into. For example, see this post. Specifically check out eXpl0it3r's responses and see if this sounds like what you're running into.

60

Graphics / Re: Loading Images and Textures Failed

« on: June 12, 2018, 12:21:41 am »

Some sources seem to indicate that you need to use the OFN_NOCHANGEDIR flag if you want GetOpenFileName() to restore the current working directory afterwards. However, I've never tried these things for myself, so I can't speak to the accuracy of that.