Messages

1

General / Re: Build android example: am I doing right?

« on: July 20, 2018, 12:06:08 pm »

That tutorial starts with "Tried with SFML 2.5: Doesn't work anymore".

The change log of 2.5 mentions the build system has changed, but no documentation on the new system is available. Apparently, it's more "normal" now, but that's all I could find so far.

So, you are better off with SFML 2.4.X, until the instructions are updated, or someone else knows how the new system works.

2

General / Re: SFML on Raspberry PI

« on: July 19, 2018, 06:08:40 pm »

If you enable the experimental OpenGL drivers from raspi-config, you can install SFML from apt-get and it just works, with shaders and everything. No customized version required.

3

General discussions / Re: How do Games Manage Resource Files?

« on: July 19, 2018, 06:06:23 pm »

The define is configured as quoted above.
The ResourceProvider code is at https://github.com/daid/SeriousProton/blob/master/src/resources.h https://github.com/daid/SeriousProton/blob/master/src/resources.cpp

It's not documented. But it also isn't that complex if you combine it with the other link to the main function I provided before. It pretty much gives a method of looking for files in multiple locations, without a lot of fuzz for the user of the code.

4

General discussions / Re: How do Games Manage Resource Files?

« on: July 06, 2018, 08:57:23 pm »

If you would run "make install", then the resources are placed in /usr/share/emptyepsilon/

If you only want to run an out-of-source build, then you would do it like this (I do this all the time):

mkdir _build
cd _build
cmake ..
make -j 5
cd ..
./_build/EmptyEpsilon
 

As my resourceprovider system looks in both the compiled prefixed path AND the current working directory, it can find the files due to the current working directory.

5

General discussions / Re: How do Games Manage Resource Files?

« on: July 05, 2018, 10:45:51 pm »

A lot of applications handles this by having a compile-time prefix before all the resource file names. Empty on Windows, but /usr/share/application_name/ on Linux.

Not sure for OSX, stuff there changes from time to time, and there are different methods used. The linux method used to work, not sure if it still does.



However, I use a different method. My engine has something called "resource providers". You can register multiple of them, and if you request a filename, it goes trough all the providers and find the one path that can provide this resource.
Example with a lot of paths registered:
https://github.com/daid/EmptyEpsilon/blob/master/src/main.cpp#L130
So I can search relative to the current working directory, and in a fixed location at the same time. I have even an implementation that can get resources from a zip file without the user of the code noticing.

6

General / Re: Windows 10 Touch Screen

« on: January 04, 2018, 07:46:59 pm »

I know this is an old topic. But posting this here for future reference for people that run into the "double tap" touch screen issue. The problem is in your handling of the mouse.

In mouse emulation mode, the surface touch screen will send a "mouse down"+"mouse up" event in the same frame. So in 1 loop of "sf::window::pollEvent" calls you will get a down and up. So sf::mouse::isButtonPressed will never return true. And you can miss touchscreen presses if you do this on polling bases.
While polling works fine for normal mouses and certain other touch screens, it doesn't work fine for the surface.

Oddly enough, the 2nd press of a double tab does has a delay between the down and up events.
Info about this finding: http://bridgesim.net/discussion/comment/3074/#Comment_3074

7

Graphics / sf::Shader::setUniform with bool parameter -> bug source?

« on: November 01, 2016, 11:28:58 am »

First off, let me say I love the improvements in SFML 2.4.0, nice upgrade compared to 2.3.x on the shader interface.

However, I just spend half an hour trying to find out why my shader was not rendering with a texture. I finally found out that I was passing an sf::Texture pointer instead of a reference to the setUniform function. And, as C++ does implicit type conversions of pointers to booleans, it was calling the setUniform(name, bool) instead.

With all the new setUniform functions, maybe setUniform(name, bool) is a bit out of place due to the very easy mistake of implicit pointer casts of all the other objects you can pass as parameters to this function.


Possible ways to prevent this problem are:

• Make the setUniform for bool more explicit -> setUniformBool. But this breaks with the rest.
• Add a private setUniform(string name, void*), so the pointer gets implicit cast to a void pointer and thus throws a compile error.
• Tell idiots like myself to depend less on pointers.

(I know I should prefer references. But that is not always a possibility in this case)

EDIT: I just realized. This is also inconsistent with the sf::Texture::bind API, which uses a sf::Texture pointer instead of a reference.

8

Audio / Re: Rare crashes in shipped OpenAL dll

« on: September 07, 2016, 10:58:14 am »

Replied in the issue.

While still possible, I think a general problem in your code would more likely just crash everywhere.

Which version of SFML are you using for compiling?

I'm using 2.3.1, with a slight patch for Android:
Code at: https://github.com/daid/SFML

I've compiled SFML and the final executable with the same compiler which is:

daid@black:~/ee/EmptyEpsilon/_build_win32$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 

SFML is build as "Release", my own application as "RelWithDebInfo"

I'm linking in drmingw 0.7.7 for post-mortom crash debugging.
https://github.com/jrfonseca/drmingw

(Which made it easier to trace down the crashes happening in OpenAL.dll and not somewhere in my own code)

9

Audio / Rare crashes in shipped OpenAL dll

« on: September 03, 2016, 09:48:27 am »

Simply put, I'm having this issue:
https://github.com/daid/EmptyEpsilon/issues/390

For the last year, my project at http://emptyepsilon.org/ has been growing in the amount of users. But 1 problem seems to persist, depending on the user, I'm getting random crashes in OpenAL.
I've noticed that for the users that do not have this problem, there is actually a different OpenAL.dll in windows/system that is being used instead of the one provided with SFML.

I don't have a specific code example that is triggering this, after all, this is a rare crash. But my code that does sound isn't that complex. It runs a single sf::Music and a maximum of 16 sf::Sound items. The sf::SoundBuffer objects are not moved around in memory. Everything is allocated in the heap. The sf::Music and sf::Sound objects are allocated on start. Everything is single-threaded.
I mixing positional sounds and non-positional sounds.

https://github.com/daid/SeriousProton/blob/master/src/soundManager.cpp



In the end, I cannot think of anything I did wrong in my code anymore. And the problems seems to be gone with a different OpenAL library of which I don't know the origin.
But I don't know the origin of this OpenAL library beyond the fact that they are in the SFML repository and not updated for a while.

10

General / Re: [Android] Best way to handle sf::Event::LostFocus and sf::Event::MouseLeft

« on: July 31, 2015, 04:07:15 pm »

If you really care about (even minimal) power consumption, store your gamestate when the context is destroyed and close your app. The next time you start, check for that state and load it right away.

Otherwise using waitEvent() should be just fine.

Problem is, closing the app does not really seem to work properly right now. If I end the main thread, and start the application, I get an exception. Second start seem to start it from scratch again.


waitEvent DOES loop the CPU as I pointed out, as it sleep 10 milliseconds in a loop. It works, but pretty it is not IMHO. As you are putting extra drain on the battery even tough your user isn't actively using the application.

(Losing state isn't a huge issue for my app)

11

General discussions / Re: Android and iOS ports Status

« on: July 28, 2015, 07:36:47 am »

The android port is definitly ready. I put Kroniax in the PlayStore when the ports came up and since then a lot of bugs got fixed. About the iOS port I have no clue.

Can I ask you how you managed the application lifecycle? As I cannot seem to figure it out without causing battery drain:
http://en.sfml-dev.org/forums/index.php?topic=18614.0


Other then that. I found the Android port quite mature, I only had to change a few small things for my application to work on Android. But information about it is quite limited. I'm posting my finding in topics that start with [android] so it can be found easier.

12

Window / Re: Triple Buffering support?

« on: July 20, 2015, 07:21:57 am »

Pretty sure you could implement triple buffering yourself at the application level with a set of sf::RenderTextures and a thread that pushes it to the renderwindow.

13

SFML projects / Re: EmptyEpsilon - Spaceship bridge simulator.

« on: July 19, 2015, 11:29:44 am »

When it's fully polished etc. you should really lobby some (tech) companies. I bet you could find a lot of Trekkies.

I work at Ultimaker. I'm pretty much surrounded by Trekkies ;-)

14

Network / Problem with sf::UdpSocket::Send with sf::IpAddress::Broadcast on Windows + fix.

« on: July 19, 2015, 09:10:57 am »

Discovered and worked around this issue a while back. But putting it here for reference.

When using sf::UdpSocket::Send with the target address of sf::IpAddress::Broadcast on windows. You would expect the UDP packet to be broadcast to the whole network you are connected to. However, this isn't happening. What is happening is that it is broadcast on the first enabled network adapter. And nothing else. This is extremely evident when you are connected to both wifi and wired network, or have VirtualBox virtual networks setup.

The end result is that local server discovery did not always for for me. Now, even with this fixed (fix below), broadcasting on windows only works if the network is not classified as "public network". So for the broadcasting server discovery implementors out there, I do recommend you broadcast both ways, from the server to let them know you are there, and from the clients to let them know you are looking for a server. This gives the highest chance of success.

The fix isn't that complex to code. You need to iterate on all networks, and broadcast your packet per network:

#ifdef _WIN32
#include <winsock2.h>
#include <iphlpapi.h>
#endif
[code]

[code=cpp]#ifdef _WIN32
    //On windows, using a single broadcast address seems to send the UPD package only on 1 interface.
    // So use the windows API to get all addresses, construct broadcast addresses and send out the packets to all of them.
    PMIB_IPADDRTABLE pIPAddrTable;
    DWORD tableSize = 0;
    GetIpAddrTable(NULL, &tableSize, 0);
    if (tableSize > 0)
    {
        pIPAddrTable = (PMIB_IPADDRTABLE)calloc(tableSize, 1);
        if (GetIpAddrTable(pIPAddrTable, &tableSize, 0) == NO_ERROR)
        {
            for(unsigned int n=0; n<pIPAddrTable->dwNumEntries; n++)
            {
                sf::IpAddress ip(ntohl((pIPAddrTable->table[n].dwAddr & pIPAddrTable->table[n].dwMask) | ~pIPAddrTable->table[n].dwMask));
                socket.send(packet, ip, port_nr);
            }
        }
        free(pIPAddrTable);
    }
#else
    socket.send(packet, sf::IpAddress::Broadcast, port_nr);
#endif

And you need to link to "iphlpapi" as well for the GetIpAddrTable function.

15

General / Re: game runs in debug mode, crashes in release (win 8 / gcc / code::blocks)

« on: July 19, 2015, 08:40:33 am »

Most likely the problem isn't SFML related at all, but just some uninitialized pointer or memory on your side of the code. As stack&memory layout is different in debug vs release, you'll end up with different values.

Or you could be overflowing a buffer, which corrupts the heap easier in release then debug.

Compile with -g, to add debug symbols, even in release, and you might get a better stacktrace then effectively nothing.