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 - BlueCobold

Pages: 1 2 [3] 4 5 ... 7
31
General / Re: State machines and map transitions
« on: November 12, 2015, 07:20:14 am »
In our game, transitions are a state themselves. That means that for example from the pause state to the game state, we have an intermediate state which renders both of the others to a renderbuffer and then uses these to make fancy transitions with it. When done, it switches to the 2nd state-parameter of the transition.

32
General / Re: State machines and map transitions
« on: November 11, 2015, 10:14:28 pm »
Imo screw the concept of queues or stacks. That's not how a state machine works anyway. Typically they can go from any state to any other. Mostly they don't even need more than the last state (for example to return from pause to play), as they barely ever go back and mostly only go forward.
In our game, we don't use any queue or stack at all. There's one state at a time and we can go from one to another. While doing so, we're sometimes passing additional informations to a state in order to "resume" an old one (we don't resume, we just go forward to the a new state of the same type as the previous one by passing that info). Never had any issues and never had any memory overhead due to a queue which is filled, but unused.

33
General / Re: Failed to load Image errors with SFML for Visual Studio C++
« on: November 02, 2015, 07:27:24 am »
There are 28 commits in that repo. The last one is 3 years old. I won't expect that code to be working at all.

34
Graphics / Re: Make a sprite brighter
« on: October 22, 2015, 07:22:52 pm »
Not really, because it's unclear what the result shall be. You can either blend a semi-transparent white one over it or apply various filters by using a shader.

35
SFML projects / Re: Rickety Racquet [including Beta download]
« on: October 22, 2015, 07:19:55 am »
Update!

Finally we found the time to port everything. So now we can officially announce that the final game does and will support the following platforms:
  • Windows
  • Linux
  • Mac OS X
  • iOS
  • Android



Thanks to everyone on the SFML-team for helping to kill the SFML-internal issues which stopped us from porting :)

36
General discussions / Re: Android and iOS ports available for testing
« on: October 21, 2015, 01:07:10 pm »
Tested and accepted :D

37
Graphics / Re: [Android] Creating texture in thread crashes the app
« on: October 21, 2015, 12:20:55 pm »
Looks like it gets fixed by this: http://en.sfml-dev.org/forums/index.php?topic=19106.0

38
General discussions / Re: Experimental internal-context-less branch
« on: October 21, 2015, 12:19:07 pm »
I tested the branch in android. It causes glLoadGen to receive NULL when asking for extension-strings which caused a segfault in glLoadGen-code. I bypassed the segfault, but still can't get any extension-string whatsoever. This used to work properly in the master-branch.
PS: gl::getIntegerv(GL_MAX_TEXTURE_SIZE) of glLoadGen also returns 0. That's said to happen without a valid context.

Apart of that, it fixes the following bug: http://en.sfml-dev.org/forums/index.php?topic=19180.0

39
Graphics / [Android] Creating texture in thread crashes the app
« on: October 21, 2015, 11:12:06 am »
Hi.

I got my game running on Windows, Linux, OS X and iOS, but I have an issue with Android. Whenever I create a texture inside a thread (which is used to load assets while still rendering/updating/animating the UI fluidly), the app crashes. Using current git branch "feature/system-handle". Mind that the following code works on the other 4 operation-systems without a problem.

Minimal sample:
#include <SFML/Window/Event.hpp>
#include <SFML/System/Thread.hpp>
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Graphics/Texture.hpp>

int main(int argc, char* argv[])
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "access violation in constructor");

    bool loaded = false;

    sf::Texture* tex;
    sf::Thread thread([&]()
    {
        tex = new sf::Texture(); // crashing in this line on Android only
        loaded = tex->loadFromFile("res/img/gui/Window.png");
    });

    thread.launch() ;

    while ( window.isOpen() )
    {
        sf::Event event ;
        while ( window.pollEvent(event) )
        {
            if ( event.type == sf::Event::Closed )
                window.close() ;
        }
        if(loaded)
            window.setTitle("Thread done, close now");
    }
    delete tex;

    return 0;
}

40
General discussions / Re: Android and iOS ports available for testing
« on: October 20, 2015, 04:31:25 pm »
The instructions for Android are pretty straight forward. You should really install MinGW though. CMake GUI is no magic, there's just 2 buttons and 2 textfields. The tutorials show it pretty good. iOS is not much different. Run CMake(-GUI), build+install everything with Xcode, create your app and import the frameworks to it.

41
General discussions / Re: Android and iOS ports available for testing
« on: October 20, 2015, 09:00:19 am »
I am using SFML on iOS for Rickety Racquet and can't complain so far. I currently do not have any issues, no matter if using iOS 7, 8 or 9. I'm still thinking to make a PR to be able to handle applicationWillResignActive and applicationDidEnterBackground on the user-side of the application, as it often requires the app to persist some kind of state.


Android looks pretty stable too, currently preparing to build/port it to Android.

42
General discussions / Re: Android and iOS ports available for testing
« on: October 19, 2015, 02:08:16 pm »
My kind of coding is C++ mixed with OBJC and my friend BJ said that SFML is C++ but need some support on Apple side.
SFML works for iOS fluidly, there's no need for any apple support and you can mix your SFML with Obj-C without a problem.

43
Window / Re: [Mac] Fullscreen modes not scaled to screen size
« on: September 25, 2015, 01:19:11 pm »
Basically by rendering into a RenderBuffer and then rendering this in a scaled version (keeping aspect-ration by adding black areas or not keeping it by filling the full screen) to the desktop resolution. I still understand the Apple hint like: "Don't change without asking" which actually is a good advise for any kind of game imo - switch only if the user wants to explicitely (via menĂ¼ or config files). However, I'm not sure that Apple compliance is a topic for SFML at all. And even if SFML would implement soft & hard-switch, the games using SFML would still need different code for different systems, because of not allowing to hard-switch resolutions on OS X (and thus using soft-switch on OS X and using hard-switch everywhere else). So either make it a hidden soft-switch on OS X being true fullscreen or change it to a hard-switch. Both of these would result in what the devs expect. I don't think the devs need both options as long as the result looks correct.

44
Window / Re: [Mac] Fullscreen modes not scaled to screen size
« on: September 24, 2015, 08:38:58 am »
Wrong topic, dude. But in the end, it doesn't matter, you won't notice any performance issues. It would be enough to make it on resize, but it's no problem to do it every frame.

45
Window / Re: [Mac] Fullscreen modes not scaled to screen size
« on: September 22, 2015, 01:09:53 pm »
Any news on this topic?

Pages: 1 2 [3] 4 5 ... 7
anything