Call for Testing: SDL2 Windows Build (faster software!)

As someone who has weird framerate issues in Vanilla Software (the reason I exclusively use OpenGL), I'm pretty interested in checking this out.
[ Windows 7 64-Bit - NVIDIA Geforce GTX 660 (2GB) - 8GB RAM - Intel i5-3570K @ 3.4Ghz ]
[ ~ 1, 3 & 5 ~ ]
NOTE: Fraps is running simply to verify the game's framerate, and to see how glitchy it looks when running Software mode. ;D
Vanilla included for comparison.
Vanilla 640x400W: Choppy. Game claims to be at 35FPS, but I beg to differ. Left / Right turning appears to be somewhat affected (Aren't they linked to framerate?)
Vanilla 1280x800W: Choppier. Game still claims to be at 35FPS. Rotating seems to be even more affected (Sonic can occasionally remain in his running state while turning, implying he's not turning MUCH)
Vanilla 1280x800F: Silky smooth, almost as good as OGL. Apparently alt-tabbing works pretty well too, as I did so to report my screen resolution to this post. Camera works properly, and I wasn't running into things NEAR as much. Fraps displayed glitchy palettes.
Vanilla OpenGL 1280x800W: (My usual setup, for comparison) Silky smooth. I swear it's going faster than 35FPS, but even Fraps seems to think that it's running at 35. Hm. Camera works properly here too, as to be expected.
SDL 1280x800W: Silky smooth. . . I might just use this as my actual SRB2 exe, actually. If it works on the MS, that is. Also the same for 640x400W.. so I didn't make an extra section to say exactly the same thing.
SDL 1280x800F: Silky smooth. Seemingly as good as OGL. Alt-Tabbing works perfectly (Though the Windows 7 "preview" looks glitchy - and Fraps didn't want to appear until I alt-tabbed back INTO the game [Although did NOT display glitchy palettes])

[ ~ 2 ~ ]
I WOULD compare vanilla mouse stuff.. but I don't appear to be having the usual mouse glitch that I often have with SRB2 (Though note, only tested with my Usual: OpenGL Windowed) - It's not happening today and it's STRANGE. (Although a test did produce THIS GIF for comparison.)
SDL 1280x800W: .. Broken. The mouse movement feels WAY slow for some reason - if I move my mouse very slowly, it seems to work fine.. very quickly, and it seems to only move a tiny bit. Perhaps THIS GIF will show more info on that.

( I do not use a joystick, nor have one to test [ ~ 4 ~ ] with. )

the good thing of this , is that every key is in it's place ( i already was talking about this before )
before :
w = z
a *q
m= ,
but everything works fine in the SDL2 Port (almost)
http://mb.srb2.org/showpost.php?p=746121&postcount=27

Why does 960x600 look so odd in comparison to older aspect-correct resolutions?

Win7 64-bit, Nvidia GTX 560, 1920x1080, i7-3770 @ 3.40 GHz

1. Works perfectly fine, even when I rapidly switch.
2. It's a lot slower than the normal exe. I can completely switch direction with one swipe normally, but I can barely go half that with this exe.
3. It runs slightly better than the normal exe, although there's still some jitter with the camera (software's fault?)
4. Don't have a gamepad to use
5. Alt-tabbing works without any issue

There also seems to be a lack of widescreen resolutions, considering I can't play this build in my default resolution. Even using the -width and -height commands in the shortcut just reverts it to 320x200 windowed.

Linux 64-bit (Peppermint 4 / Ubuntu 13.04), compiled from source.

1. Fullscreen <--> Windowed - MENU IS BROKEN. The game beeps repeatedly while the screen slightly glitches out, as if it's trying so hard to go fullscreen, before giving up and returning to a window. Using the console, it works. After switching about 20 times back and forth using the console, no crash, so I say it works. The menu just needs to get fixed.
2. Mouse Movement - Without patch*, significantly slower. With patch*, same. Patch will be described after these numbers.
3. Performance - Unfortunately, slower. At least, in this one particular point, the FPS drop is significantly higher in SDL2 compared to SDL1.
4. Multiple Gamepads - Extremely bugged. The name of one of my controllers (Logitech RumblePad 2) is very long, and gets cut off at "Logitech Logitech Rumble". When any controller selected, the console reports the name as (null). My other controller, a Logitech F310, is detected as "Generic X-box Pad". When each are plugged in alone, they function fine. When both are plugged in, player 1 defaults to the F310, and switching to the RumblePad 2 results in a crash. Same with telling Player 2 to use it. If I had to guess this has to do with the console reporting the name as (null).
5. Alt-tabbing: Without patch, PHYSICALLY IMPOSSIBLE in both windowed and fullscreen. With patch, I am able to alt-tab in both safely, which is an improvement over SDL1, where I can't alt-tab in fullscreen.

So, about this patch I keep mentioning. I remember years ago I reported a bug with the Linux version of 2.0, being unable to alt-tab. In SDL2, it's back. SDL_SetWindowGrab is bugged in Linux. It will always grab the keyboard input, which makes actions such as alt-tabbing physically impossible. The patch changes how a few lines are commented, which brings mouse input back to how it is in SDL1. By the time anyone reads this, I will have submitted a pull request.

Are you certain alt-tab doesn't work with SDL_SetWindowGrab? It works fine for me on Trusty Tahr. Either way, restoring the mouse behavior to its original code would be nice, I couldn't figure out why it wouldn't work correctly in fullscreen.

Also, the joystick code needs to be rewritten to correctly use the new API, I'm pretty sure it's the source of all the crashes people get.

Are you using the open source driver for your video?

Furyhunter said:

Are you certain alt-tab doesn't work with SDL_SetWindowGrab? It works fine for me on Trusty Tahr. Either way, restoring the mouse behavior to its original code would be nice, I couldn't figure out why it wouldn't work correctly in fullscreen.

Click to expand...

On my desktop I'm using Peppermint 4, a derivative of Ubuntu 13.04. My netbook which I'm responding on is using Lubuntu 13.10. I'll try a build on my netbook with the stock code later today, and see if the issue persists. I did study SDL2's code, and the only reason it's grabbing the keyboard is if X11's XGrabPointer is incorrectly grabbing the keyboard as well as the mouse, which violates its own documentation. There's likely a bug in the version of X11 used in Ubuntu 13.04.

If the mouse movement code was broken in fullscreen, I'm glad to have fixed it by accident. I never even bothered to test in fullscreen when I got the keyboard grabbing behavior.

Also, the joystick code needs to be rewritten to correctly use the new API, I'm pretty sure it's the source of all the crashes people get.

Click to expand...

Makes perfect sense.

Are you using the open source driver for your video?

Click to expand...

No. On my desktop, I'm using the Nvidia binary blob for my old 9800 GT. I'll get you the exact version when I get home much later today. My netbook uses an Intel piece-of-crap which I think is actually licensed from PowerVR or something insane like that. Software is faster, and the CPU is a 1.6 Ghz single-core. That's how bad it is, but that's beside the point. I'll test on my netbook later today.

ForgiveThisNewb said:

No. On my desktop, I'm using the Nvidia binary blob for my old 9800 GT. I'll get you the exact version when I get home much later today. My netbook uses an Intel piece-of-crap which I think is actually licensed from PowerVR or something insane like that. Software is faster, and the CPU is a 1.6 Ghz single-core. That's how bad it is, but that's beside the point. I'll test on my netbook later today.

Click to expand...

I ask because SDL2 uses an opengl viewport (direct3d on windows) to display surface graphics that were once software-drawn to the window in SDL 1.2, and this may introduce a performance caveat for systems with slow drivers or slow graphics hardware.

I still can't even open it. This seems to happen only in my laptop, as everyone here could at least open srb2sdl.

EDIT: Nevermind. I was using SRB2 2.1.5, while this was supposed to run with 2.1.6.

Specs:
Windows 8.1 64bit
CPU: A8-4500m APU 4 cores 1.9Ghz - 2.8Ghz
GPU: AMD Radeon 7640g


(1. Works fine, had a solid 35fps only till I hit 960x600 where I lost about 5 but I would think that's because my specs aren't great but I'm getting a new PC/Laptop probably 20x better than the one I already have so I can check and see how it runs on that to.


(2. Slower but easily can be edited, unfortunately the Mlooksens can't be edited.


(3. Pretty much answered in 1.


(4. Don't have a joystick.


(5. Works fine.

Here are my machine's stats.
I haven't read this thread at all, so sorry for repeats of information

• Works great.
• The mouse feels more responsive, but the sensitivity is much slower.
• Game runs much better than srb2win does in software mode. Speed is basically on par with OpenGL mode.
• I will try to test joysticks later.
• Alt-tabbing works great.

Mostly, I have to report that my game froze and crashed after less than minute of the CEZ3 boss. I was Tails, if that makes any difference.

Windows 8.1 32-bit

1.) No problems switching
2.) Mouse movement feels a little smoother
3.) The same as before. Runs smooth in 640x480 (Steady 35fps), but higher resolutions bring it to a crawl (6fps average in Egg Rock, up to 11fps in GFZ1). It seems like performance wise SRB2 is getting incrementally worse with each release and something isn't being addressed. It behaves like there are sporadic memory leaks with no discernible cause from the players perspective.
4.) No problem with joysticks
5.) Works smoothly other than the music stopping.

Specs: Windows 8.1 64-bit, Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 4GB of RAM, Intel HD Graphics 3000
1.Anything above 960x720 is choppy in both windowed and fullscreen mode
2.Mouse seems to be better.
3.Performance is better.
4.No joysticks
5.Alt-tab works fine. But I noticed that if I alt-tab out into a different program, then alt-tab back in to srb2sdl.exe, the music won't play. Yet the controls are responsive. But this can be fixed by switching between fullscreen and windowed mode or changing the music that is currently playing using tunes command.



It seems that the server names are cut off in the SDL2 build, and joining none SDL2 build servers causes SRB2 to stop responding.

XSpeedGodX said:

I can't believe this. I- I honestly can't believe this.

Click to expand...

Believe it. It was one of the fake images posted for Fury's april fools joke.

I'm using a laptop running Windows 8.1 (64-bit) with an Intel Core i5-3230M @ 2.6GHz, 6 GB RAM and an NVIDIA GeForce 610M graphics card.

1. Works absolutely fine.
2. Mouse movement/mouselook definitely seems slower.
3. Runs much better, 35 fps nearly everywhere, unlike srb2win.exe.
4. Can't test, I don't own any joysticks.
5. Works fine.

EDIT: nevermind, just me being stupid

Windows 8.1 64-bit, AMD Radeon HD7770 1GB, 1600x900, AMD Athlon II X4 630 at 2.8GHz, 8GB RAM.

1) Windowed and fullscreen worked flawlessly. Video modes in windowed mode do change the window size, however, in fullscreen, it seems to project the selected screen resolution at the current desktop resolution, i.e. not actually changing my monitor resolution.

This did cause quirks like going as close or above my resolution to dump SRB2's framerate.

Most strange of all was it went beyond my monitor resolution and didn't even provide a setting for it, or for ANY 16:9 resolutions. I settled on 1120x720, which worked flawlessly with no framedrops.

To be fair, I kinda like the way it's doing this resolution thing. When my monitor has to physically squash the screen size, it just blurs everything.

2) It is much much slower than in srb2win, I had to move it up to about the middle, and I have a multi-DPI mouse running 1100dpi, as is my standard.

3) It performs fantastically, and this isn't even in OpenGL. Software of srb2win was sluggish on any resolution at all times. This is running without a hitch.

4) Used two DirectInput joysticks, and both were mapped to the same one. Controls weren't functioning (I presume a fault in trying to process two commands at once) and on attempting to change the second player joystick to the proper one, it crashed the game. I left the RPT here.

5) Alt+Tab is silky-smooth and fantastic.

Tested it ... everything works fine,but i prefer the Original build, not sure but it seems like this build is slower (Not too much to be Exact)
OS : Win7 SP1 Ultimate 32x
RAM : 2GB
VGA : 1024mb

Here's a weird issue... playing Nev3r's Hydrocity levels in the SDL version results in extremely staticy music.

SSNTails said:

Here's a weird issue... playing Nev3r's Hydrocity levels in the SDL version results in extremely staticy music.

Click to expand...

Were those ever publicly released?