Messages

16

Graphics / Re: sf::Texture::loadFromFile "Reason : Unable to open file"

« on: May 25, 2016, 02:49:15 am »

Let me "bounce" an idea off you. (I'll show myself out... later)

Have you tried Windows Folder Options and confirm that "Hide extensions for known file types" is not checked?

Also if you could just copy and paste the exact Working Directory name you found in Visual Studio here for us to see?

I usually just select the <Browse...> option to see what directory it takes me to.

17

General / Re: How to do Real Animation in C++ SFML

« on: May 22, 2016, 05:22:45 am »

Ok Erdrick! Thanks for that! But one question.. I dont know how to change the program so that when the user dosent click any controls, it just dosent go on running state.. But as soon as he does it starts to actually show the running motion. Any ideas on how to acomplish that?

For this, you will need to wrap the logic below in an if condition.  This if condition will need to check if the user is pressing the keyboard buttons again and only do this logic if one of those four keyboard buttons is being pressed.

        source.x++;
        if (source.x * 32 >= _texture.getSize().x)
            source.x = 0;
 

The condition you write for this will be separate from the event logic above.  Please read the SFML tutorials on this site to understand the difference between Events and Real Time Inputs

Once you have read these two topics thoroughly and understand them, you will know why Events and Real Time Inputs are different.

• Events explained
  
• Keyboard, mouse and joysticks

You are making good progress on your learning, but doing the tutorials in order on this site is also very beneficial!

18

General / Re: How to do Real Animation in C++ SFML

« on: May 21, 2016, 10:53:33 pm »

Hi amanuel2,

The sprite sheet you are working is 3x4, so there are 3 animation frames for each direction and 4 directions.

Row 1 are the walking down frames
Row 2 are the walking left frames
Row 3 are the walking right frames
Row 4 are the walking up frames

The screen coordinate system is different than the cartesian coordinate system you may have learned in math.  X still increases as you go right but Y increases as you go DOWN.

When you are checking the keyboard for the direction pressed, it is setting source.x and source.y.  X is always set to 0 in the switch statement so it will start with the first frame for that direction.  Y is set to 0,1,2, or 3 to pick the row for the appropriate direction.

When you  call  _sprite.setTextureRect at the bottom you are "isolating" the first frame for the direction you chose for display purposes.

To get to the next frame for that direction, you need the second piece of code you wrote

source.x++;                                                      

// This line increased X from 0 to 1
// This means that the next time you call
// setTextureRect it will pass 1*SPRITE_WIDTH
// instead of 0xSPRITE_WIDTH.  This has the effect
// of picking the frame 32 pixels to the right which is
// essentially the next frame of that direction.

if (source.x * 32 >= _texture.getSize().x)

// Once the multiplication produces a number of pixels
// that is greater than the size of the texture, that means
// it has already gone through all of the frames for that
 // direction and needs to start at 0 again for the first frame
                                                                                   
            source.x = 0;

 

19

General / Wierd Mouvment C++

« on: May 21, 2016, 06:57:11 am »

Hi.  Why are you setting x and y to 3 after each event? That means you will keep moving right and down.

20

General / Re: use "static sf::Texture texture"as a member of a class

« on: May 21, 2016, 03:46:26 am »

I found this on the interweb

Cause of Ntdll.dll Errors

The causes of ntdll.dll error messages can vary greatly. However, most ntdll.dll errors result from a corrupt or damaged version of the ntdll.dll file itself, corrupt hardware drivers, or issues between Windows and other programs.

Ntdll.dll errors can sometimes mean that a piece of hardware in your computer is malfunctioning, but this is rare.

How repeatable is this issue and does it repeat itself after a reboot?

21

Audio / Re: open AL unexpected message

« on: May 20, 2016, 01:55:41 pm »

Yes it does sound very similar. I found your post when originally looking for the problem on google. But figured it may be different because of the warning numbers and also because, if my memory serves me, you built sfml yourself, whereas im using a release build. Im thinking that i'll try and download a new or newer version of sfml and replace the dll, see if it is possibly corrupt somehow. Will report back if anything works.

Correct on different warning number but i didnt build sfml myself.

Ill report a call stack next time this happens.

22

Audio / open AL unexpected message

« on: May 20, 2016, 07:03:28 am »

This reminds me of the warning I am getting

http://en.sfml-dev.org/forums/index.php?topic=20053.0

I also get the crash 4 mins or so after leaving things to run

23

Graphics / Re: sf::Drawable and const question

« on: May 18, 2016, 03:55:45 pm »

Thanks a lot Laurent, this helps.  I'll take it from here and make it work!

24

Graphics / Re: sf::Drawable and const question

« on: May 18, 2016, 06:41:56 am »

I would like to add I just made these two class members mutable

        mutable std::vector<column> m_column_headers;
        mutable sf::Text m_text;
 

and now the code works, but I'd still like feedback on the approach.

25

Graphics / sf::Drawable and const question

« on: May 18, 2016, 06:32:38 am »

Hi,

I have a class that is inheriting from sf::Drawable and in the draw() pure virtual function that I am defining for this class I decided that I wanted to loop through a vector of objects and draw some sf::Text output by re-using the same member object and just changing the string, position, and then drawing it.

I soon ran into problems because the draw() function is declared as const.

void gui_table::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
        // apply the transform
        states.transform *= getTransform();

        // draw the table background
        target.draw(m_vertices);

        // draw the column names
        std::vector<column>::iterator itr;

        for (itr = m_column_headers.begin(); itr != m_column_headers.end(); ++itr) {
                m_text.setPosition(itr->rect.left + 5, itr->rect.top + 5);
                m_text.setString(itr->value);
                target.draw(m_text);
        }
}
 

Severity   Code   Description   Project   File   Line   Suppression State
Error   C2679   binary '=': no operator found which takes a right-hand operand of type 'std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<gui_table::column>>>' (or there is no acceptable conversion)   Dark Ruins   C:\Users\Erdrick\Documents\Visual Studio 2015\Projects\Dark Ruins\Dark Ruins\gui_table.cpp   64   

This got me to thinking about why draw() is declared as const?  I guess we should not expect to change things here, but I was thinking which of several approaches would be best.

1.) Should I be setting up a vector of sf::Text ahead of time to draw before i get to the draw() function?
2.) Should I make my own draw() function that is not const?
3.) Is there another recommended approach for what I am trying to do?

26

SFML projects / Re: SFGUI (0.3.0 released)

« on: May 14, 2016, 05:59:07 pm »

I am still stuck so I put some questions in the SFGUI forum to see if I can get some help.

http://sfgui.sfml-dev.de/forum/post2662.html#p2662

27

SFML projects / Re: SFGUI (0.3.0 released)

« on: May 13, 2016, 04:19:23 am »

If you have also checked SFGUI_USE_STATIC_STD_LIBS but your SFML version hasn't been built with SFML_USE_STATIC_STD_LIBS being checked, thus you get compatibility issues. Either uncheck it for SFGUI or rebuild SFML with the check active.

Hi eXpl0it3r, thanks.  I got a couple of builds to work now after starting from scratch.  One non-static and one static build.  Both had SFGUI_BUILD_EXAMPLES and SFGUI_BUILD_DOC turned off, i'll try with that next.

28

General / Re: AW: How To Better Optimize This Code?

« on: May 12, 2016, 05:19:57 pm »

Adding if else changes the behavior slightly. Now you can't move up and to the right at the same time.

The code can't be really optimized more.

thanks for mentioning this.  He mentioned switch so i thought he was accepting the change in behavior but i should have said it anyway

29

General / Re: [Q] Proper way to slow down a Sprite during movement?

« on: May 12, 2016, 01:43:43 am »

You're welcome, good luck!

30

General / Re: How To Better Optimize This Code?

« on: May 12, 2016, 01:39:49 am »

Use "else if" instead of "if" on the last three so it doesnt need to check unnecessary conditions