Messages

1

SFML projects / Antennas by the Ladleful

« on: August 06, 2011, 12:30:14 pm »

Antennas by the Ladleful v0.4

Tux leads an epic battle against Citrus and Martin to obtain the best mobile phone coverage on the entire planet.

• Download links for Windows, Mac OS X, source code
  
• Gameplay video (YouTube)

Start with level 1, the game gives tips at the beginning of each level.
Default keys (on a qwerty keyboard): Z - Shield, X - Bomb, C - Ladle

Music: Thanks to Maf!



This is the first game that I manage to complete! Now that I translated it to English, I can post it here. I'm open to any suggestions, and if anyone wants to translate the game to their language, that would be awesome!

2

Window / SFML 2 Suggestion: QWERTY equivalents

« on: July 13, 2011, 01:30:42 pm »

The easiest way I can think of would just be to have an array where the value at the index of the qwerty key they pressed is the azerty key they pressed. And don't forget about us dvorak users!

Well, the program I wrote should work with any keyboard layout that uses latin characters, so dvorak should be fine

The problem with having such an array is that you would have to ask the user "which keyboard layout are you using?", which does not feel very professional. (Or you'd have to find out from digging around in the windows registry. Which may be a nightmare considering Apple keyboards for example have their own Windows layouts!)

Also, I cited AZERTY and QWERTZ as examples because they are widespread, but you would also have to create an array for 'exotic' keyboard layouts... For example, the French equivalent of dvorak, "bépo" is completely different from anything out there. If each country has its own optimized keyboard layout, making an array for every one of them would be pretty difficult.

It would be elegantly solved if SFML itself provided a way to use "physical" scancodes.

Plus, it would solve the problem that some AZERTY users face with unusable keys in SFML such as é, à, !, etc., well, pretty much any symbol key. (And I believe QWERTZ users can't use ü either, swedish users can't use å, and so on.)

EDIT: I meant they can't use these keys with IsKeyPressed (I know you can use something to get unicode text that just got typed in, but this is not meant for 'in-game' use)

3

Window / SFML 2 Suggestion: QWERTY equivalents

« on: July 13, 2011, 12:53:15 pm »

I would like to define default keyboard controls for my game as such: Z, X, and C. Which is nice because all three keys are adjacent.

However, on AZERTY layouts this should be W, X, C, and with QWERTZ this should be Y, X, C. SFML 2 currently handles key codes according to the active keyboard layout, which is nice because you can tell the user that the 'W' key is indeed the 'W' key on an azerty keyboard, and not 'Z', for example.

The drawback to this is that it's pretty hard to define keyboard layout-agnostic default control settings. Since both AZERTY and QWERTZ are in widespread use in Europe, this is quite an issue.  It would be great if SFML provided a way to get key codes according to their position on the keyboard (perhaps in addition to getting which letter it maps to in the local layout).

So far, I have made a quick Python2 program that gives you the "local equivalent" of a QWERTY key, but it only works on Windows. I have yet to find out how to do this in Cocoa and X11. If anyone is interested, it's there (the API calls might be interesting): http://pastebin.com/UWtWmZ58

4

Audio / SFML2: Audible 'clicks' with loud sounds in ogg format

« on: June 05, 2011, 12:19:13 pm »

EDIT: never mind, I just noticed another thread was open about the same issue: http://www.sfml-dev.org/forum/viewtopic.php?t=2410


So I came across this really weird bug that only seems to affect Linux. I suspect it's most likely a problem with the ogg loading code/libraries.
I use Arch Linux and the latest SFML2 git snapshot.

My game uses ogg files for sound effects. A couple of them are quite loud, while others are quieter. Well, when played back, the loud ones produce clicks on Linux (not on Windows). I load sounds in a fairly normal fashion -- actually, just changing the sound file names in the standard 'sound' example yields the bug.

I first thought it was due to some problem with OpenAL and/or my audio config, but using the exact same sound effect as a wave file produces a perfect sound!

Also, if I 'un-amplify' the sound and then save it as an ogg file again, it won't click. (in a sound editor -- setting the sound volume through SFML doesn't take away the clicks)

It does that with music, too.

I don't really mind, because I can just make my sounds quieter. But I wonder if it has something to do with my set up, or if anyone else has had the same issue.

Here's the test program with the same sound in ogg and wav formats: http://dl.free.fr/qURMG7ZCo

5

Python / Re: PySFML 1.6 + Python 2.7 cannot load font?

« on: May 31, 2011, 05:09:00 pm »

Your method looks correct. Back when I used SFML 1.6, I used to load fonts like you did in the second example.

However, those extra spaces around 'Arial.ttf' seem weird to me.

And you say that Python crashes "without an error" -- as in nothing appears in the console window? Are you running Python from the command line?

If it still doesn't work, then maybe your Arial.ttf file is faulty somehow?

Also, if you're starting a new project, I'd recommand using the new SFML 2 binding: https://github.com/bastienleonard/pysfml2-cython

6

Python / Python binding generation tools

« on: May 27, 2011, 07:14:37 am »

Hi Bastien,
I suggest you add this to sf.pyx within the 'wrap_event_instance' cdef, so as to make the TEXT_ENTERED event useful. So far you couldn't get which Unicode character was typed in.
I put that at line 1082 in sf.pyx. I tested it and it works fine.

Code: [Select]

   elif p_cpp_instance.Type == declevent.TextEntered:
        ret.unicode = p_cpp_instance.Text.Unicode
Then, the Unicode value of the character can be retrieved within a Python program with the unichr() built-in function (unichr(event.unicode))

7

Python / Python binding generation tools

« on: May 22, 2011, 06:42:48 pm »

Hold on-- this problem actually appears with C++ SFML 2 programs. The 'sound' C++ example crashes on exit.

EDIT: ran examples through gdb, found out alcCloseDevice() from openal32.dll is the culprit. This seems to be a known bug, see https://github.com/SFML/SFML/issues/30

8

Python / Python binding generation tools

« on: May 22, 2011, 05:55:28 pm »

Yes that works, but when the App was closed I'm getting this
Message from Windows....

I'm using Windows 7 Home Premium (x86 | 32bit) and
Python 2.7.1

Does this happen with every PySFML program?
I've built it on Windows, so I'll try to do some tests.

Bastien, I also ran into this bug, that is, a crash when quitting Python on Windows (doesn't seem to happen for me on Linux). I don't mind because the rest of the program runs flawlessly. But it may be intimidating to an end user.

I traced it back to loading sound buffers into memory from a file, or opening a music file.

For example, this two-line program will crash:

Code: [Select]

import sf
sbuf = sf.SoundBuffer.load_from_file('data/clear.ogg')
load_from_file itself does not crash, that is, you can make a Sound out of sbuf and it'll play just fine; it rather seems to me there's a destructor that went wrong somewhere.

Interestingly, it doesn't crash immediately after sbuf goes out of scope; for example:

Code: [Select]

import sf
def foo():
sbuf = sf.SoundBuffer.load_from_file('data/clear.ogg')
foo()
foo()
foo()
print "Yay"
This program gets to "Yay" allright, and then crashes on exit.

Music similarly gets Python to crash on exit:

Code: [Select]

music = sf.Music.open_from_file('data/maf-shroomy.ogg')

Hope this helps. And btw, great job fixing the joystick bug and converting time to integers! I have to test it out. (after porting my program to use millisecs)

EDIT: the 'pong' example is, of course, affected by this bug. It also uses a wav file, while I have used oggs, so the crash may not be file format-specific.

9

Python / pysfml2-cython building problems

« on: May 19, 2011, 10:28:28 pm »

Thanks for your response. I will try a "standalone" MinGW.

Another thing that confuses me is that I don't have a PCbuild dir.

Well. I will try some things and tell you how it worked out

Well, I just took a peek and I don't have a PCbuild dir either... So I believe you'll be fine.

10

Python / pysfml2-cython building problems

« on: May 19, 2011, 07:13:22 pm »

The final command you have there is different from mine.

Code: [Select]

g++ -mno-cygwin -shared -s build\temp.win32-2.7\Release\sf.o build\temp.win32-2.7\Release\sf.def -LF:\python\271\libs -LF:\python\271\PCbuild -lsfml-graphics -lsfml-window -lsfml-audio -lsfml-system -lpython27 -lmsvcr90 -o sf.pyd
This works for me.  No mention of libsf.a, and I don't think it creates one.
If you use this command make sure to alter the paths (esp. with the -LF switches)

EDIT: I don't know how relevant this is, but you seem to be using the MinGW install that came as part of Code::Blocks.  I haven't tried that, and I use a 'fresh', manual MinGW install with which I built an SFML 2 snapshot from Git.
If you want, I could put together a zip file with the library files for Python.

11

Python / Python binding generation tools

« on: May 09, 2011, 06:27:28 pm »

Hi,

First of all thanks for your hard work on this refreshing binding. I have just ported a sizeable chunk of my code that used the official PySFML 1.6 to this new binding and it does feel cleaner.

However, get_joystick_axis() (from sf.Input) seems to be broken, which kind of renders the joystick unusable.

Here is the incriminating code (where "glob.win" is an sf.RenderWindow):

Code: [Select]

jx = glob.win.get_input().get_joystick_axis(0, 0) / 100.
Which yields:

Code: [Select]

Traceback (most recent call last):
              <...snip...>
  File "/home/lapin/Desktop/ANTCURR/st_jeu.py", line 291, in update
    jx = glob.win.get_input().get_joystick_axis(0, 0) / 100.
  File "sf.pyx", line 1111, in sf.Input.get_joystick_axis (sf.cpp:11965)
AttributeError: 'sf.Input' object has no attribute 'GetJoystickAxis'

Out of curiosity I opened sf.pyx and here is the portion that seems to be wrong:

Code: [Select]

cdef class Input:
             <...snip...>
    def get_joystick_axis(self, unsigned int joy_id, int axis):
        return self.GetJoystickAxis(joy_id, axis)

I use the latest SFML 2 snapshot from Git (as of May 9th 2011) and the latest snapshot of the new binding.

EDIT 2: I guess a "p_this" is missing in there.
So if I change line #1111 of sf.pyx to:

Code: [Select]

       return self.p_this.GetJoystickAxis(joy_id, axis)
I get the following error when compiling sf.cpp after having being cythoned from sf.pyx:

Code: [Select]

sf.cpp: In function ‘PyObject* __pyx_pf_2sf_5Input_1get_joystick_axis(PyObject*, PyObject*, PyObject*)’:
sf.cpp:11962:132: error: invalid conversion from ‘int’ to ‘sf::Joy::Axis’ [-fpermissive]
/usr/include/SFML/Window/Input.hpp:120:11: error:   initializing argument 2 of ‘float sf::Input::GetJoystickAxis(unsigned int, sf::Joy::Axis) const’ [-fpermissive]
My guess here is that the API has changed and now uses a "sf::Joy::Axis" instead of a simple int (as in the current .pyx file)

EDIT 3: (Sorry for the long long post) For those who want to get the job done quickly, modify line #1111 of sf.pyx as shown above, run setup.py build, which will generate the huge C++ file. gcc will fail, but don't worry about it right now. Open the huge C++ file named sf.cpp, and head down to line #11962 (I guess the exact line number is subject to change in the near future, but anyway, this is a temporary fix.)
Change it from this:

Code: [Select]

 __pyx_t_1 = PyFloat_FromDouble(((struct __pyx_obj_2sf_Input *)__pyx_v_self)->p_this->GetJoystickAxis(__pyx_v_joy_id, __pyx_v_axis)); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 1111; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
to this:

Code: [Select]

 __pyx_t_1 = PyFloat_FromDouble(((struct __pyx_obj_2sf_Input *)__pyx_v_self)->p_this->GetJoystickAxis(__pyx_v_joy_id, static_cast<sf::Joy::Axis>(__pyx_v_axis))); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 1111; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
We're just casting the integer as a sf::Joy::Axis. It's dirty but it does the trick for now, because I don't know how to fix the cython files yet. Then of course run setup.py build again, then setup.py install.