Messages

31

General discussions / Re: How to avoid linking my static lib to SFML's?

« on: March 16, 2014, 01:56:40 pm »

I  forward declared all SFML references in my static library and that work.  I think this what they meant by allowing the application to link the dependencies.  However, I am not sure it will always be possible, or painful as they mentioned.

32

General discussions / How to avoid linking my static lib to SFML's?

« on: March 16, 2014, 10:46:32 am »

I've created a static library and added some of my generic game systems for reuse on future projects.  However, when I link SFML I get a few warnings.

warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined...
warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library

Searching around I got plenty of hits.

Never link static libraries to your library! It can be painful, but you have to require that your applications link to your dependencies.

You don't need to add any dependencies when creating a static library. If your library uses d3d9.lib, then let the build of the EXE/DLL link it in.

It's clear I shouldn't be linking a static library to my static library.  However, I don't understand the solution.  Are they suggesting my game, that uses my static library, should link SFML?  If so this is already the case, and I don't see how this would give my static library access to SFML functionality.

33

General discussions / Re: SFML Game Development -- A book on SFML

« on: March 15, 2014, 01:54:59 pm »

Nexus, you mentioned that the command system approach is less common.  I have been wondering why you chose that approach over a more conventional approach, like an event system. 

The main difference I see is the command system couples the event with the action.  Whereas an event system would simply broadcast an event and let the game components handle them.  In this regard the event system seems more flexible.  Also, the command system is reliant on the scene graph. 

Could you explain why you chose this system?  What advantages do you see?

34

General discussions / Re: Managing Keyboard and Mouse support (extending proj from SFML Book)

« on: February 24, 2014, 07:18:30 am »

As always I appreciate your response.  You are right I could learn a lot from an API like Thor.  I will look into it.

35

General discussions / Re: Managing Keyboard and Mouse support (extending proj from SFML Book)

« on: February 23, 2014, 01:41:43 pm »

You should separate the logical actions, e.g. "fire" or "moveRight", from the raw input, e.g. "sf::Key:".

I am blanking on this.  Could you give an example?

I still think two maps would be appropriate. When handling events, instead of traversing only the key binding map, you also traverse the mouse binding map and check if an event triggers an action.

Alright, this makes sense to me.

If you need something more sophisticated or don't want to reinvent the wheel, I recommend having a look at Thor's Actions, they allow arbitrary mapping of input to logic actions. You can even combine multiple keys to use triggers like "Shift+R".

I'm just trying to learn as much as I can in the process of making a simple game.

36

General discussions / Re: Managing Keyboard and Mouse support (extending proj from SFML Book)

« on: February 23, 2014, 07:42:19 am »

I want to have all my input from the keyboard, mouse, and joystick stored in one object.  Using the book as an example, the object would have six member variables for mMoveLeft, mMoveRight, mMoveUp, mMoveDown, mFire, and mLaunchMissile.  Each of these member variables should than correspond to a key, button, analog pad, etc. on a specific input device depending on its binding.

The issue I am having is storing events for the keyboard, mouse, and joystick, which are all of different types, into this singular object.  My shoving the keyboard and mouse into a large enum and then cramming it into mKeybinding was a quick and dirty attempt of this.  However, I am sure there is a better approach.

The reason I would like to do this is I want a uniform object to read for both the player and the AI (reading Game Coding Complete).  On a slightly unrelated note are there any game engine books you would recommend? 

37

General discussions / Managing Keyboard and Mouse support (extending proj from SFML Book)

« on: February 17, 2014, 12:47:34 pm »

I have been working on extending the code base from SFML Game Dev book.  I am adding mouse support, but my solution feels messy.

mKeybinding is declared in player.h as

std::map<sf::keyboard::key, Action> mKeybinding;

The problem is I want sf::keyboard::key to be more general to hold both keyboard and mouse keys/buttons.  I combine the two in a enum and handle the offsets.  I then have to begin converting from sf::Keyboard::key and sf::Mouse::button to my new enum and back.

In the end it will work, but I keep thinking there is a cleaner approach.  Any suggestions?  Thanks.

38

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 10, 2013, 05:16:03 pm »

I think it will be easy to let this one go.  I want to wrap up the book and begin my own project.  Thanks again.

39

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 09, 2013, 03:34:11 pm »

Do you compile in debug mode, and link the SFML debug libraries?

Yes, I do.

Can you use a sf::RenderTexture with the same size in a separate project?

No , I cannot.  I have created a very small test that generates the exact same error.

Unhandled exception at 0x1002CA1C (ig4icd32.dll) in HelloWorld.exe: 0xC0000005: Access violation writing location 0x0000001C.

When you close the window the access violation will occur.  The timing is similar to what is occurring with the book's code.  The book's access violation occurs when the player either dies or finishing the mission causing the GameState and GameOverState to begining destroying its resources.

You'll notice I only create the RenderTexture and never use it.  The access violation occurs regardless.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1024, 768), "SFML works!");

        sf::RenderTexture mSceneTexture;
        mSceneTexture.create(1024, 768);

        sf::Texture mTexture;
        mTexture.loadFromFile("Textures/Entities.png");
        sf::Sprite mSprite;
        mSprite.setTexture(mTexture);
        mSprite.setPosition(100.f, 100.f);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(mSprite);
        window.display();
    }

    return 0;
}

Do you have the stack trace for it?

        ig4icd32.dll!1002ca1c() Unknown
        [Frames below may be incorrect and/or missing, no symbols loaded for ig4icd32.dll]     
        ig4icd32.dll!1002dae2() Unknown
        sfml-graphics-d-2.dll!589c6bf0()        Unknown
        sfml-graphics-d-2.dll!589c7326()        Unknown
        sfml-graphics-d-2.dll!5899bf72()        Unknown
        Sandbox.exe!`eh vector destructor iterator'(void * ptr, unsigned int size, int count, void (void *) * pDtor)    C++
        Sandbox.exe!std::array<sf::RenderTexture,2>::~array<sf::RenderTexture,2>()      C++
        Sandbox.exe!BloomEffect::~BloomEffect() C++
        Sandbox.exe!World::~World()     C++
        Sandbox.exe!GameState::~GameState()     C++
        Sandbox.exe!GameState::`scalar deleting destructor'(unsigned int)       C++
>       Sandbox.exe!std::default_delete<State>::operator()(State * _Ptr) Line 1152      C++
        Sandbox.exe!std::unique_ptr<State,std::default_delete<State> >::_Delete() Line 1445     C++
        Sandbox.exe!std::unique_ptr<State,std::default_delete<State> >::~unique_ptr<State,std::default_delete<State> >() Line 1400      C++
        Sandbox.exe!std::unique_ptr<State,std::default_delete<State> >::`scalar deleting destructor'(unsigned int)      C++
        Sandbox.exe!std::allocator<std::unique_ptr<State,std::default_delete<State> > >::destroy<std::unique_ptr<State,std::default_delete<State> > >(std::unique_ptr<State,std::default_delete<State> > * _Ptr) Line 624       C++
        Sandbox.exe!std::allocator_traits<std::allocator<std::unique_ptr<State,std::default_delete<State> > > >::destroy<std::unique_ptr<State,std::default_delete<State> > >(std::allocator<std::unique_ptr<State,std::default_delete<State> > > & _Al, std::unique_ptr<State,std::default_delete<State> > * _Ptr) Line 758    C++
        Sandbox.exe!std::_Wrap_alloc<std::allocator<std::unique_ptr<State,std::default_delete<State> > > >::destroy<std::unique_ptr<State,std::default_delete<State> > >(std::unique_ptr<State,std::default_delete<State> > * _Ptr) Line 909    C++
        Sandbox.exe!std::_Destroy_range<std::_Wrap_alloc<std::allocator<std::unique_ptr<State,std::default_delete<State> > > > >(std::unique_ptr<State,std::default_delete<State> > * _First, std::unique_ptr<State,std::default_delete<State> > * _Last, std::_Wrap_alloc<std::allocator<std::unique_ptr<State,std::default_delete<State> > > > & _Al, std::_Nonscalar_ptr_iterator_tag __formal) Line 89      C++
        Sandbox.exe!std::_Destroy_range<std::_Wrap_alloc<std::allocator<std::unique_ptr<State,std::default_delete<State> > > > >(std::unique_ptr<State,std::default_delete<State> > * _First, std::unique_ptr<State,std::default_delete<State> > * _Last, std::_Wrap_alloc<std::allocator<std::unique_ptr<State,std::default_delete<State> > > > & _Al) Line 80 C++
        Sandbox.exe!std::vector<std::unique_ptr<State,std::default_delete<State> >,std::allocator<std::unique_ptr<State,std::default_delete<State> > > >::_Destroy(std::unique_ptr<State,std::default_delete<State> > * _First, std::unique_ptr<State,std::default_delete<State> > * _Last) Line 1480   C++
        Sandbox.exe!std::vector<std::unique_ptr<State,std::default_delete<State> >,std::allocator<std::unique_ptr<State,std::default_delete<State> > > >::clear() Line 1416     C++
        Sandbox.exe!StateStack::applyPendingChanges() Line 91   C++
        Sandbox.exe!StateStack::update(sf::Time dt) Line 24     C++
        Sandbox.exe!Application::update(sf::Time dt) Line 81    C++
        Sandbox.exe!Application::run() Line 57  C++
        Sandbox.exe!main() Line 13      C++
        Sandbox.exe!__tmainCRTStartup() Line 536        C
        Sandbox.exe!mainCRTStartup() Line 377   C
        kernel32.dll!74bd336a() Unknown
        ntdll.dll!76f69f72()    Unknown
        ntdll.dll!76f69f45()    Unknown

40

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 08, 2013, 07:49:40 pm »

Does your system support render textures?

I thought so.  The call to

mSceneTexture.create(mTarget.getSize().x, mTarget.getSize().y);

returns true.  That being said I searched around and dug a couple threads on render textures and Intel GPUs.   

http://en.sfml-dev.org/forums/index.php?topic=9149.0
https://github.com/SFML/SFML/issues/418. 

Both issues have been fixed and neither sounds similar to what I am experiencing, but it is concerning as I have an Intel GPU.

Shaders are not supported at all, or do the examples in the SFML SDK work?

Shaders are supported.  I can run the book code, but it just performs poorly.  I tested the SFML SDK shader example and it ran smoothly.

Is there an error message on the console?

No error message.

41

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 08, 2013, 01:28:39 pm »

With Ch 8's code I have been experiencing a crash when the game transitions from the GameOverState from either finishing the level or dying.  I've set a breakpoint within StateStack::applyPendingChanges() on mStack.clear().  The mPendingList contains an Action to perform a clear and then push the MenuState.  The stack itself contains the GameState and the GameOverState.  Everything looks good.  When I continue I get the following.

Unhandled exception at 0x1002CA1C (ig4icd32.dll) in 08_Graphics.exe 0xC0000005: Access violation writing  location 0x0000001C.

To be safe I got the most recent code from Laurent's SFML-Game-Development-Book repo.  I realized this did not occur in Ch 7, so I began removing new additions.  To be clear the following two changes are the only changes I have made to the code.

First I comment out the drawing of the shader.

void World::draw()
{
//   if (PostEffect::isSupported())
//   {
//      mSceneTexture.clear();
//      mSceneTexture.setView(mWorldView);
//      mSceneTexture.draw(mSceneGraph);
//      mSceneTexture.display();
//      mBloomEffect.apply(mSceneTexture, mTarget);
//   }
//   else
//   {
      mTarget.setView(mWorldView);
      mTarget.draw(mSceneGraph);
//   }
}

The crash will still occur, but if I then comment out the following line from the body of World's ctor the crash goes away.

// mSceneTexture.create(mTarget.getSize().x, mTarget.getSize().y);

My understanding of the access violation is that a read or write is occurring to memory that cannot be accessed.  The usage of the sf::RenderTexture looks nearly identical to documentation provided on this site.  I've inspected the object and that looks good too. 

I'm not so concerned with the issue.  I can't use shaders regardless, but it does bother me I don't have an idea how to debug this.  What approach should I take?  Thanks.

42

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 07, 2013, 08:59:29 pm »

I only mentioned the issue with the jungle texture, because previously I had said chapters 8-10 were crashing and that was the issue. 

I've finished chapter 8 now and can definitely say the issue is the bloom effect which uses shaders.

PostEffect::isSupported()

This returns true, but my video card just can't handle it, so I have simply commented out the alternative draw code in World::draw().  The previously FPS numbers were from release mode.  With shaders disabled I have jumped up to 160 FPS from 1 FPS in debug mode.

43

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 03, 2013, 09:14:57 pm »

Previously, I had said chapters 8-10 were crashing on entering gameplay (reply #127).  I've made it to chapter 8 and started looking into it.  What happens is an exception is thrown when trying to load the jungle texture.  The message i receive is "Failed to create texture, its internal size is to high (1024x4023, maximum is 2048x2048)."

I've switched to the desert texture and it allows me to play the game.  I've never seen the intended gameplay, but it's running at about 26-30 fps and feels a little choppy.  The effect on HP text, bullets, and pickups seems to be leaving cloud bursts (I've attached a screenshot).  I'm assuming these are the shader effects that are being introduced.

44

General discussions / Re: SFML 2.0 C++ book questions

« on: December 02, 2013, 09:42:13 pm »

These are both C++ 11 features.   

The auto keyword deduces the type from the initializer.  In this case std::find_if returns an iterator of type std::vector<Ptr>::iterator.

The next feature is a lambda expression.  This allows you to create an anonymous function. 

[&]

Captures all automatic variables in the lambda body by reference.

(Ptr& p)

Is simply the parameter list for the lambda expression (same as in named functions).  In this case find_if is iterating through a vector of Ptrs feeding your lambda expression with them.

-> bool

Is the optional return type of the lambda expression.

return p.get() == &node

Compares the addresses of the nodes and returns true if they match.  p is a unique _ptr and get() returns a pointer to the managed object and the address operator returns the address of the node leaving two addresses to be checked for equality. 

45

General discussions / Re: SFML Game Development -- A book on SFML

« on: November 30, 2013, 07:53:48 pm »

Thanks Nexus, you made that very clear.  Also, thanks georger for the heads up.  I downloaded Violet and will give it a shot.  I think this will be very helpful for me.