Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - DxE

Pages: [1] 2
1
General / Re: __gxx_personality_v0
« on: July 10, 2014, 11:42:32 pm »
I believe this is a compatibility issue between your libraries and your compiler.

Try with GCC 4.7 TDM (SJLJ) - 32 bits instead of the MingW one. Doing this worked for me back when I used C::B. Otherwise you'll probably have to use CMake to compile from source (there's a tutorial on this site that talks you through the process).

2
General / Re: Static Linking Crash Error
« on: June 05, 2014, 08:16:29 pm »
Ahh, force of habit on the window.close() at the end there; usually I'm using a variable in the while loop instead of window.isOpen(), the fact that the program closes when I open it leads me to believe this doesn't effect the issue (and I suspect window.close() checks whether or not the window is actually open before trying to do whatever it is going to do anyway).

I've never had any issues with a global sf::RenderWindow in the past but from the tone of your reply I suspect it's bad enough that it could potentially be the cause of my issue? If so, is there an explanation that you can either give or link me to on why global SFML objects in particular are worse than others?

3
General / Static Linking Crash Error
« on: June 03, 2014, 08:47:36 pm »
In response to the original thread's author wanting a new thread for my issue I've made this, mods can nuke posts or whatever in the other thread if they wish to keep it clean. All the information I can think of giving is below:
I set up a second, smaller and simpler program in VS2013 with the debug build set up to statically link and the release build to dynamically link and both work... Most of the time.

With the following code:
(click to show/hide)

This happens with the Debug (statically linked) build: http://puu.sh/9c2Eo.png
This happens with the Release (dynamically linked) build: http://puu.sh/9c2T4.png

The following images are of my settings in the Debug build configuration:
Directories: http://puu.sh/9c2W9.png
Pre-Processor: http://puu.sh/9c2Yc.png
Code Generation: http://puu.sh/9c2ZH.png
Linker Input: http://puu.sh/9c32l.png

Does this just mean I haven't compiled SFML correctly, or is there a flaw in my linker settings?

4
General / Re: CMake Libraries Version/Dependency Problem
« on: June 02, 2014, 07:15:18 pm »
Oops, my bad. I added SFML_STATIC to debug however errors (different ones) cropped up and I was still having errors when compiling the release build anyway so I've assumed there is some flaw in my programming or linker setup that I've overlooked and can't remember.

I set up a second, smaller and simpler program with the debug build set up to statically link and the release build to dynamically link and both work... Most of the time.

With the following code:
(click to show/hide)

This happens with the Debug (statically linked) build: http://puu.sh/9c2Eo.png
This happens with the Release (dynamically linked) build: http://puu.sh/9c2T4.png

The following images are of my settings in the Debug build configuration:
Directories: http://puu.sh/9c2W9.png
Pre-Processor: http://puu.sh/9c2Yc.png
Code Generation: http://puu.sh/9c2ZH.png
Linker Input: http://puu.sh/9c32l.png

Does this just mean I haven't compiled SFML correctly, or is there a flaw in my linker settings?

5
General / Re: CMake Libraries Version/Dependency Problem
« on: June 02, 2014, 12:41:50 am »
I think so? Whether I did it right or not is another matter:


6
General / Re: CMake Libraries Version/Dependency Problem
« on: May 30, 2014, 06:31:51 pm »
I should maybe also note that the only 'unresolved blah blah blah' errors I'm getting are related to sfml-window-s.lib:

I switched back to Debug configuration and got more errors, looks more like stuff in the OP this time:
(click to show/hide)

7
General / Re: CMake Libraries Version/Dependency Problem
« on: May 30, 2014, 06:26:24 pm »
I apologise in advance, I'm rather uninformed when it comes to linking in general and I dug around for the thread that I (misinterpreted) that led me to believe dynamic linking is the issue: http://en.sfml-dev.org/forums/index.php?topic=3976.0

Basically my issue matches up closely with the 3rd post (2nd reply), being that my app runs and closes fine on my desktop and several of my friends' but crashes on my own laptop and college's desktop computers, both of which use use Intel's integrated graphics processors, when I close the application. Notably that thread is about an SFML 2 issue and this is about  SFML 2.1.

I've made a separate thread for the issue to avoid clogging up this one:
http://en.sfml-dev.org/forums/index.php?topic=15399.0

8
My post from another thread:
Quote
I apologise in advance, I'm rather uninformed when it comes to linking in general and I dug around for the thread that led me to believe dynamic linking is the issue: http://en.sfml-dev.org/forums/index.php?topic=3976.0

Basically my issue matches up closely with the 3rd post (2nd reply), being that my app runs and closes fine on my desktop and several of my friends' but crashes on my own laptop and college's desktop computers, both of which use use Intel's integrated graphics processors, when I close the application. Notably that thread is about an SFML 2 issue and this is about  SFML 2.1.

If I use some sf::Text features (I have yet to try with minimal code, I'll do that soon) my application crashes on some devices. After a small amount of experimentation and looking around it seems likely to be linked to the issue in the link above (http://en.sfml-dev.org/forums/index.php?topic=3976.0). This started after I switched from Code::Blocks to VS2013. Yes, I did compile SFML again for VS 12.0 from the source available on the github repo.

Any help is appreciated!


EDIT: Sorry if I've annoyed anyone with this, but the issue has turned out to be something with my code, likely due to something unrelated to graphics hardware and more specific to std::string stuff.

9
General / Re: CMake Libraries Version/Dependency Problem
« on: May 30, 2014, 06:04:38 pm »
I'm having a related issue with static linking, I'm pretty certain I've done something wrong but wish to clarify if my (release) linker setup should look like:

opengl32.lib
ws2_32.lib
gdi32.lib
winmm.lib
freetype.lib
sndfile.lib
glew.lib
jpeg.lib
openal32.lib
sfml-main.lib
sfml-system-s.lib
sfml-window-s.lib
sfml-graphics-s.lib

I should maybe also note that the only 'unresolved blah blah blah' errors I'm getting are related to sfml-window-s.lib:

(click to show/hide)

Also I have a dynamic linking problem which I believe only occurs on integrated graphics hardware where sf::Text stuff causes the program to crash, which is why I'm trying to statically link in the first place as reading around led me to believe this was only an issue with dynamically linked libraries. I imagine that's an issue for another thread though.

EDIT: I'm using Visual Studio 2013

10
SFML projects / Re: Flappy Girls Encore
« on: February 18, 2014, 11:10:12 pm »
Uhm, well it shouldn't be crashing, but if you touch the top or bottom you should die and restart after a second.

Silly me on the frame-rate thing, I'll change that now (along with fixing a couple of bugs with the red haired and pink haired girls' power).

EDIT: Fixed now http://www.mediafire.com/download/sgw2v1q64y9loy7/Flappy+Girls+Encore+1.22.zip

11
SFML projects / Flappy Girls Encore
« on: February 18, 2014, 10:27:19 pm »
The game can be downloaded here:
http://www.mediafire.com/download/sgw2v1q64y9loy7/Flappy+Girls+Encore+1.22.zip

This started of yesterday as a bit of a joke, but today I updated it to make it not as laughable. It's basically just a Flappy Bird clone (made with SFML, of course) using characters from the 2D fighting game, Skullgirls Encore (of which I am a big fan).

The main differences between this and Flappy Bird are that each character has a unique power that they can use every now and then to help them along the way (i.e. removing all pipes on screen and stopping them from spawning for 3 seconds) and that I probably spent more time on it than the Flappy Bird dev did.

Here's the latest trailer:



Here's the thread I originally posted it in:
http://skullgirls.com/forums/index.php?threads/update-flappy-girls-encore-skullgirls-fan-game.1821/

12
SFML game jam / Re: Jam 2 completed! Now what?
« on: February 17, 2014, 05:28:42 pm »
I feel having it as a separate event would be nice as it would not impede on the regular jam and so that the regular jam would not impede upon the extended one. Also some people might want to participate in both events so having them separate seems best to me.

13
SFML game jam / Re: Jam 2 completed! Now what?
« on: February 10, 2014, 11:52:21 am »
I like the idea of a 1-3 week jam, maybe we could have it annually in addition to 72 hour jam?

I like the sound of this too; as it is I wouldn't be able to participate in the 72 hour jam due to real world commitments, but it looks like fun and I'd like to join in too, more time would definitely make that more plausible.

14
Graphics / Re: Parallax Scrolling: Views or no views
« on: January 27, 2014, 07:33:19 pm »
Here's an example to simplify (?) things:

2 views, one for a background with a big face, one for a foreground with a small face. The small face will be drawn so part of it is outside of the viewport, showing where the view cuts off. Here's the result:


#include <SFML/Graphics.hpp>

int main(){
    sf::RenderWindow window;                                    //Declare window
    window.create(sf::VideoMode(640, 480), "Viewport Example"); //Make window

    sf::View vMain;                                             //Declare main viewport
    vMain.setViewport(sf::FloatRect(0, 0, 1, 1));               //Set main viewport
    vMain.setCenter(320, 240);

    sf::View vFace;                                             //Declare other viewport
    vFace.setViewport(sf::FloatRect(0, 0, 0.5, 0.5));           //Set face viewport, different place on screen
    vFace.setSize(640*0.5, 480*0.5);
    vFace.setCenter(320*0.5, 240*0.5);


    sf::Texture texFace;                                        //Declare texture
    texFace.loadFromFile("face.png");                           //Load texture

    sf::Sprite spFaceBig;                                       //Declare big face
    spFaceBig.setTexture(texFace);                              //Set big face's texture
    spFaceBig.setScale(10.f, 10.f);                             //Make big face live up to name
    spFaceBig.setPosition(-320, -320);                          //Set big face to a nice position
    spFaceBig.setColor(sf::Color::Cyan);                        //Change big face's colour a little

    sf::Sprite spFace;                                          //Declare face
    spFace.setTexture(texFace);                                 //Set face's texture
    spFace.setPosition(240, 170);                               //Set face so some of it leaves the viewport

    bool running=true;

    while(running){
        sf::Event event;                                        //Event junk for ending loop
        while(window.pollEvent(event)){
            if(event.type == sf::Event::Closed){
                running=false;
            }
        }
        window.clear();                                         //Clear window

        window.setView(vMain);                                  //Switch active viewport
        window.draw(spFaceBig);                                 //Draw big face on active viewport

        window.setView(vFace);                                  //Switch active viewport
        window.draw(spFace);                                    //Draw face on active viewport

        window.display();                                       //Show the screen
    }

    window.close();

    return 0;
}

Aaand here's the face if you wanna play around with that at all

15
Graphics / Re: Parallax Scrolling: Views or no views
« on: January 27, 2014, 06:54:43 pm »
I see. But does that mean you have to draw the entire text somewhere in an out-of-reach area beside your actual game scene?
And what if you want some transparency for your textbox? Is it possible with a viewport?

I haven't used sf::Text yet, so I thought I'd have to use a sf::TextureRenderer to make my textbox into a texture/sprite and then display it above my game scene.
I think you may have misunderstood how views work with SFML. It sounds like you're confused with views in Game Maker. In SFML views aren't displays of different camera locations, they are like separate screens altogether.

Let's say you had a view which is your main screen (the one with all the main stuff going on in it) and you wanted a HUD overlay.

In something like SDL where views don't exist you would draw the main screen relative to a camera object (something like draw(mySprite, x-camX, y-camY)) and the HUD would be drawn in constant locations (draw(myHUD, x, y)).

With Game Maker views you would draw the HUD in a position relative to the current view's location (draw(myHUD, view_x+x, view_y+y)) so that it's always following the camera.

With SFML it's better to think of views as layers of your window, you'd say, ok here's one view for my screen, now I'll make another view for the HUD. We'll call them vMain and vHUD for convenience. When your player moves vMain would follow them, but vHUD would stay in the same place, so you could draw something at location {0, 0} on vHUD and it would never move, but if you drew it on vMain then it would appear to move left as the player moves right (taking vMain with them).

Views are super fun because you can do all sorts of cool stuff with them (check out this thread here to see a cool little game that takes advantage of some of their features). They are also transparent, so my text box is actually invisible and if I don't draw anything else then there would just be text overlaying my scene.

Pages: [1] 2
anything