SDL & Linux ARM

[Allanon]

Andreas & SamuraiCrow thank you both for your time

This time the program runs without errors and artifacts, the frame rate is still a bit low but I have to compare it how it performs on the pi2, there is not much on the screen a part the background rendered as an hardware brush at each frame and some smaller hardware brushes on the screen.

Anyway thank you again, at least there are no errors or glitches

[SamuraiCrow]

When I tried the demos from RebelSDL, they worked on the ODroid but the frame rate was many times faster than what they were supposed to be.

[Allanon]

I will try them on my odroid just to be sure that my distro isn't messed up

[airsoftsoftwair]

When I tried the demos from RebelSDL, they worked on the ODroid but the frame rate was many times faster than what they were supposed to be.

If that is the case, maybe the ODroid doesn't support correct vsyncing? In that case you'd have to implement a manual throttle because by default all those RebelSDL examples expect vsync to be working so there is no throttle because they expect the double buffer to be flipped with the vsync.

[SamuraiCrow]

testing from the command line reveals an error message:

ALSA lib pcm.c:7963:(snd_pcm_recover) underrun occurred

It runs the correct speed until this error message is given a split-second later.

[airsoftsoftwair]

Hmm, which example are you talking about? Does it even use sound? If it does, have you tried disabling sound and see if it works correctly then?

[SamuraiCrow]

It was the Beast scrolled. I'll try without music tomorrow.

[SamuraiCrow]

Flase alarm. It wasn't the audio, it was pausing when I moved the mouse over the window.

[airsoftsoftwair]

My bet is that this is an issue in the GL driver on the Odroid. Can you try to compile SDL2 and its samples on the Odroid and see if they show the same issue?

[SamuraiCrow]

It appears to be a driver issue. The --vsync option on ./testgles and ./testgles2 did nothing and the framerate was stuck at 400+ FPS.