Messages

1

Graphics / Re: sf::Shape rendering seems to break sf::Text rendering (2.0RC)

« on: November 11, 2012, 12:13:29 am »

After spending all afternoon and half the night trying to track this down I can confirm it's an ATI driver issue and is fixed in the new beta drivers.

Apparently happens when you do glDrawArrays(GL_TRIANGLE_STRIP) - the next glTexCoordPointer() won't actually happen until after the next glDrawArrays() or something stupid like that, causing texture coordinates to be wrong in that call, which could be a Text, or a Sprite, or something custom... Most annoying. That's 8 hours I could've spent doing something more important for Fuck This Jam!

2

Feature requests / timestamps for events

« on: September 19, 2010, 07:11:13 pm »

If you find a way to handle it non-intrusively, you should probably prefer that.

I thought I had found one.

I thought I could inherit from (Render)Window and overwrite the OnEvent() method.

The problem is: Events are not received (and subsequently sent to the EventListeners, like the (Render)Window) in realtime (via callback). Events are received on request (via WindowImpl::ProcessEvents(), called by Window::GetEvent()).

So I'm not going to do this. We'll see whether I regret this decision in a couple of years.

3

Feature requests / timestamps for events

« on: September 19, 2010, 09:33:03 am »

Throwing in a timestamp for every event would just be a lot of overhead for the vast majority of users who won't need it.

Which is why I suggested making it optional using an #ifdef.

(and that's a pretty low frame rate. Usually framerate will be about 500 fps)

I don't know what kind of supercomputer you have, but in most games my fps aren't even close to 500. A couple of sprites, sure. But a more complex 3D game? (Which is what I'm ultimately aiming for, like I said.) Nope.

For games with either very high keypress rates (RTSes) or twitch-based games (FPSes), high resolution input is important.

This.

If you have a game without thread-safe input handling, grab it in a separate thread, add your own time stamp, lock a shared queue, enqueue the event(s), then let the main thread dequeue and handle.

That would be a possible workaround, thanks.

So yes, it is a completely valid point, but not one that should be added to SFML since most won't utilize it (making use of "fractional input" requires special design considerations) and most also won't need such high input resolution.

I can understand that. Well, there's nothing keeping me from adding it to SFML myself, right?


Unfortunately this is something that has to be designed from the very beginning, but won't be noticed until the very end... I'm only thinking theoretically here, since it'll be another couple of months/years before I'll have a game where this might make a difference. (I'm planning to keep the Input Handling though, which is why I'm thinking about it now.)


Anyway it's good to discuss stuff before adding it, thanks for all the thoughts so far.


Mr. Wonko

4

Feature requests / timestamps for events

« on: September 18, 2010, 11:15:25 pm »

This is not a feature, this is a solution to a problem. And I don't like solving problems before they actually exist for real

So you're saying a problem shouldn't be avoided until it's encountered? Isn't it a little too late by then?

But thanks, you just made input handling so much easier for me

I'll tell you if the problem starts existing for real one day.

5

Feature requests / timestamps for events

« on: September 18, 2010, 09:22:05 pm »

I just realized that another use of this is for axis input:

Imagine someone moves an analog stick (left = -1, right = 1) from left to right within one frame. 90% of the frame are spent left, 5% on the way to the right, 5% right. If you only look at the current position you'll get a value of 1, but if you take into account all the places and the time spent there you get -1*0.9+1*0.05 = -0.85.

This could be important at lower framerates, I don't know... I'd like to take it into account anyway.

6

Feature requests / timestamps for events

« on: September 18, 2010, 06:56:58 pm »

I have no running game yet. Usually you think about such things before the game is done anyway.

Eventually I'm planning to have a game/engine with all the nice features of modern games, programming-wise. That's isn't easy and it might take long to get there, or I may never achieve it at all.

Therefore I'll start with something simple (currently I'm building a Space Invaders kind of game), but the projects will be increasingly more complex while reusing code. Thus I'd like my code to be as reusable/flexible/robust as possible, which includes such things as still working at low framerates.

7

Feature requests / timestamps for events

« on: September 18, 2010, 06:01:53 pm »

Example: If the forward key is pressed and released in the same frame, the player character should still be moved a little.
The Quake 3 Engine does this, I just saw it and wondered if something similar was possible with SFML.

8

Feature requests / timestamps for events

« on: September 18, 2010, 05:04:43 pm »

Hi,

for precise input handling it'd be nice to know when an event occured. How about adding this information to the Event class? At least optionally, with an #ifdef?

Mr. Wonko

9

Window / No rendering with joystick attached on Linux

« on: December 13, 2009, 10:25:42 am »

By the way, I have a similar problem on my Debian, but I don't think that it is the same one: the OS thinks that my Microsoft keyboard is a joystick that triggers events continuously. This has the same effect: the event loop gets stuck, and the whole application is frozen.

Hey, I just found out that my problem is the same: My mouse (Sharkoon Fireglider), besides working as a mouse, also creates a /dev/input/js0. It has 6 Buttons (i.e. 1 more than most mouse interfaces support), thus you might think that the other buttons work as a joystick but that's not the case - I tested it using
jstest [--normal or --event] /dev/input/js0
and neither did anything change when I pressed a button nor did I get thousands of events.

Anyway if I disconnect it while running the program everythings works - no thousands of events. So the problem seems to have something to do with either SFML or the Input Library it uses. Good thing is: Your keyboard causes the same problem so it should be easier to figure out what the problem is.

10

Window / No rendering with joystick attached on Linux

« on: December 13, 2009, 12:25:41 am »

hey I was about to post the same thing!

I use SFML 1.5, .deb package downloaded with Synaptic on Ubuntu 9.10.

I've got an XBox 360 (wired) Gamepad connected and no window would show up. It turned out that it never left the GetEvent-loop.

So I added debug output for every Event. Well, it turned out that...

Event: JoyMoved: 0 - 4.43434
Event: JoyMoved: 0 - -0.601215
Event: JoyMoved: 0 - -100
Event: JoyMoved: 0 - 14.2369
Event: JoyMoved: 0 - -100
Event: JoyMoved: 0 - 100
Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0.1
Event: JoyButtonPressed: 0 - 34
Event: JoyButtonPressed: 0 - 35
Event: JoyButtonPressed: 0 - 37
Event: JoyButtonPressed: 0 - 38
Event: JoyButtonPressed: 0 - 39
Event: JoyMoved: 0 - 4.43434
Event: JoyMoved: 0 - -0.601215
Event: JoyMoved: 0 - -100
Event: JoyMoved: 0 - 14.2369
Event: JoyMoved: 0 - -100
Event: JoyMoved: 0 - 100
Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0.1
Event: JoyButtonPressed: 0 - 34
Event: JoyButtonPressed: 0 - 35
Event: JoyButtonPressed: 0 - 37
Event: JoyButtonPressed: 0 - 38
Event: JoyButtonPressed: 0 - 39
...
you get the idea

And apparently that happens faster than it can be popped from the stack.

I tried removing the gamepad (didn't restart though), resulting in a slightly different output:

Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0.1
Event: JoyButtonReleased: 0 - 32
Event: JoyButtonReleased: 0 - 33
Event: JoyButtonReleased: 0 - 36
Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0
Event: JoyMoved: 0 - 0.1
Event: JoyButtonReleased: 0 - 32
Event: JoyButtonReleased: 0 - 33
Event: JoyButtonReleased: 0 - 36

(Btw there's no output for the Joy::Axis because I was too lazy to look that up - it's not in the doc.)

Well, as a workaround I counted the events received and stopped on 1000 per frame - that way it ran smoothly.
So I started wondering just how many Events there could possibly be... I tried this (I really love the simplicity of SFML - nice work!):

Code: [Select]

       sf::Clock WatchDogTimer;
        while(App.GetEvent(Event))
        {
            ++count;
            if(WatchDogTimer.GetElapsedTime() > 1.0)
            {
                std::cout<<"Event-Overflow: more than 1 second of events per frame. ("<<count<<" events received)"<<std::endl;
                break;
            }
Well, it turned out I got 3 million Events per second! (SFML sure is fast )

I don't know if this is a Ubuntu- or an SFML-related problem but it sure is annoying.


P.S.: AM/PM time style is funny - 11:25PM is after 12:39PM