Sdl 2.0.10 prerelease

SDL Development
1

Thanks to all the people who contributed code and feedback, SDL 2.0.10 is now available as a PRERELEASE build!
http://www.libsdl.org/tmp/download-2.0.php

In addition to lots of bug fixes and build improvements, here are the major changes in this release:

General:

  • Added SDL_SIMDGetAlignment(), SDL_SIMDAlloc(), and SDL_SIMDFree(), to allocate memory aligned for SIMD operations for the current CPU
  • Added SDL_RenderDrawPointF(), SDL_RenderDrawPointsF(), SDL_RenderDrawLineF(), SDL_RenderDrawLinesF(), SDL_RenderDrawRectF(), SDL_RenderDrawRectsF(), SDL_RenderFillRectF(), SDL_RenderFillRectsF(), SDL_RenderCopyF(), SDL_RenderCopyExF(), to allow floating point precision in the SDL rendering API.
  • Added SDL_GetTouchDeviceType() to get the type of a touch device, which can be a touch screen or a trackpad in relative or absolute coordinate mode.
  • The SDL rendering API now uses batched rendering by default, for improved performance
  • Added SDL_RenderFlush() to force batched render commands to execute, if you’re going to mix SDL rendering with native rendering
  • Added the hint SDL_HINT_RENDER_BATCHING to control whether batching should be used for the rendering API. This defaults to “1” if you don’t specify what rendering driver to use when creating the renderer.
  • Added the hint SDL_HINT_EVENT_LOGGING to enable logging of SDL events for debugging purposes
  • Added the hint SDL_HINT_GAMECONTROLLERCONFIG_FILE to specify a file that will be loaded at joystick initialization with game controller bindings
  • Added the hint SDL_HINT_MOUSE_TOUCH_EVENTS to control whether SDL will synthesize touch events from mouse events
  • Improved handling of malformed WAVE and BMP files, fixing potential security exploits

Linux:

  • Removed the Mir video driver in favor of Wayland

iOS / tvOS:

  • Added support for Xbox and PS4 wireless controllers in iOS 13 and tvOS 13
  • Added support for text input using Bluetooth keyboards

Android:

  • Added low latency audio using OpenSL ES
  • Removed SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH (replaced by SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS)
    SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=1, should be replaced by setting both previous hints to 0.
    SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=0, should be replaced by setting both previous hints to 1.
  • Added the hint SDL_HINT_ANDROID_BLOCK_ON_PAUSE to set whether the event loop will block itself when the app is paused.
5 Likes
2

Thanks for the update. I was wondering how SDL will handle the separation of iOS and iPadOS? Does 2.0.10 have an iPadOS target in the Xcode project? I’m happy to see the Xbox/PS4 controller support on iOS/tvOS!

3

On a vaguely similar note, how will SDL handle the forthcoming option to build on UIKit for macOS instead of AppKit?

4

. I was wondering how SDL will handle the separation of iOS and iPadOS? Does 2.0.10 have an iPadOS target in the Xcode project?

So far in the betas of Xcode 11 there is still one target for iOS, no distinction for iPadOS - and I don’t think there ever will be. iPadOS is just a glorified iOS :slight_smile:)

1 Like
5

With SDL 2.0.9, I’ve manually filled pixels and sent them to a “Texture”. My images have always been displayed correctly with version 2.0.9.

I downloaded the pre-release 2.0.10 version, and I changed these parts of my project in Visual Studio 2019:

In “C/C++ -> General -> Additional Include Directories”, I changed this:
C:\SDL2-2.0.9-VC\include

to this:
C:\SDL2-devel-2.0.10-VC-pre-release\include

and in “Linker -> General -> Additional Library Directories”, I changed this:
C:\SDL2-2.0.9-VC\lib\x64

to this:
C:\SDL2-devel-2.0.10-VC-pre-release\lib\x64

And I switched the “SDL2.dll” file in the directory of my final “exe” file to the one included in this folder of the pre-release build:
SDL2-devel-2.0.10-VC-pre-release\lib\x64

After those three changes, compiling my project produces zero errors (with warning level “/W3”) and my built executable file opens without errors, but my window is fully black.

Since the stable version 2.0.9 shows my manually-colored pixels flawlessly, why does version 2.0.10 not display them? I used “printf()” to display the values of variables in the console window and the displayed values were correct, so I know my project is not frozen. It just doesn’t show the images.

Do other steps need to be completed before switching to version 2.0.10? What did I miss?

6

Looking over it, the changes to the compiler and linker settings look ok.

How are you creating the surfaces that you are uploading to the textures? Are making sure that you are using the correct format (see SDL_PixelFormat) etc?

Can you show a minimal example that shows the problem?

7

New information:

The top-right part of the window has three buttons. One of the buttons is “Maximize/Restore Down”. If I click that button, one frame of my rendered images will appear.

If I resize the window by pulling the edges of the window with the mouse pointer, that will cause a single frame to be rendered too.

Dragging the window didn’t work. Minimizing and un-minimizing didn’t work.

I tried this idea:
I pressed the maximize button to display one frame, then I waited a few seconds, and pressed it again to display a newer frame. I noticed that my objects moved a large distance during that time, so my gameplay continued to work.

Then I removed the “SDL_WINDOW_RESIZABLE” flag from “SDL_CreateWindow()”, but that didn’t fix the problem.

Setting the game to full-screen mode with this line didn’t help:

SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN);

Using this line fixed the problem:

renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_SOFTWARE);

I was using this before:

renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);

The solution reduces my frame-rate.

I may share a minimal code example later. I don’t have time now.

8

I found a solution that allows the game to work while “SDL_RENDERER_ACCELERATED” is used!

My game normally has this:

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);
SDL_UpdateTexture(texture, NULL, pixels, SCREEN_WIDTH * sizeof(Uint32));

With those lines, the black-screen problem happens.

This fixes the problem:

SDL_RenderClear(renderer);

SDL_Rect rectangle;
rectangle.x = 0;
rectangle.y = 0;
rectangle.w = 1;
rectangle.h = 1;
SDL_RenderFillRect(renderer, &rectangle);

SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);
SDL_UpdateTexture(texture, NULL, pixels, SCREEN_WIDTH * sizeof(Uint32));

The size of the rectangle doesn’t matter. It won’t even be displayed on my screen. The correct images of my game will be displayed.

This version of the “rectangle” part fixes the problem, too:

SDL_Rect rectangle;
rectangle.x = -2000;
rectangle.y = 2000;
rectangle.w = -2000;
rectangle.h = 2000;
SDL_RenderFillRect(renderer, &rectangle);

This also fixes it:

SDL_Rect rectangle;
SDL_RenderFillRect(renderer, &rectangle);

And this:

SDL_RenderFillRect(renderer, NULL);

Even changing a single pixel with “SDL_RenderDrawPoint()” fixes it!

Like this:

SDL_RenderClear(renderer);

SDL_RenderDrawPoint(renderer, 0, 0);

SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);
SDL_UpdateTexture(texture, NULL, pixels, SCREEN_WIDTH * sizeof(Uint32));

This order works, too:

SDL_RenderDrawPoint(renderer, 0, 0);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);

SDL_UpdateTexture(texture, NULL, pixels, SCREEN_WIDTH * sizeof(Uint32));

9

Please try this minimal example that shows the problem.

I used a “Debug” x64 build in Visual Studio Community 2019 (version 16.1.4).

This example should show a blue square at the top-left part of the window, but when I open the compiled executable file, I see a fully black screen.

If I uncomment the line that uses “SDL_RenderDrawPoint()” and recompile the file, the blue square will be shown correctly.

This is the minimal example:

#include <SDL.h>
#include <stdio.h>
#include <string.h>

Uint32 new_pixels[230400];

int SCREEN_WIDTH;
int SCREEN_HEIGHT;

void PutPixel(int x, int y, Uint32 color)
{
new_pixels[y * SCREEN_WIDTH + x] = color;
}

int main( int argc, char* args[] )
{

SCREEN_WIDTH = 640;
SCREEN_HEIGHT = 360;

SDL_Window* window = NULL;

SDL_Surface* surface = NULL;

unsigned char quit = 0;
SDL_Event event;

SDL_Renderer* renderer = NULL;

SDL_Texture* texture = NULL;

if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
printf( "SDL could not initialize! SDL_Error: %s\n ", SDL_GetError() );
}
else
{

  window = SDL_CreateWindow("example", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_RESIZABLE);
  
  renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
  
  texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, SCREEN_WIDTH, SCREEN_HEIGHT);
  
  memset(new_pixels,   0, 640 * 360 * sizeof(Uint32));
  
  if( window == NULL )
  {
  	printf( "Window could not be created! SDL_Error: %s\n", SDL_GetError() );
  }
  
  else
  {
  	
  	surface = SDL_GetWindowSurface( window );
  	
  	while(quit == 0)
  	{
  		
  		while (SDL_PollEvent(&event))
  		{
  			
  			switch (event.type)
  			{
  				case SDL_QUIT:
  					quit = 1;
  					break;
  			}
  			
  		}
  		
  		memset(new_pixels,   0, 640 * 360 * sizeof(Uint32));
  		
  		Uint32 color;
  		color = SDL_MapRGB(  surface->format, 0, 0, 255);
  		
  		for (int y = 0; y < 100; y++)
  		{
  			for (int x = 0; x < 100; x++)
  			{
  				PutPixel(x, y, color);
  			}
  		}
  		
  	//	SDL_RenderDrawPoint(renderer, 0, 0);
  		
  		SDL_RenderClear(renderer);
  		SDL_RenderCopy(renderer, texture, NULL, NULL);
  		SDL_RenderPresent(renderer);
  		
  		SDL_UpdateTexture(texture, NULL, new_pixels, SCREEN_WIDTH * sizeof(Uint32));
  		
  	}
  }

}

SDL_DestroyTexture(texture);
SDL_DestroyRenderer(renderer);

SDL_DestroyWindow(window);

SDL_Quit();

return 0;
}

10

I think this might already be fixed in SDL since the prerelease binary was created. If you’re up for it, you could try compiling the latest SDL source from https://hg.libsdl.org/SDL/archive/tip.zip

11

I compiled SDL from your link and received “SDL-dd9169424181.zip”.

The problem seems solved!

I apologize for wasting your time! I thought the phrase “pre-release” meant that this was planned to be the final stable version unless people find critical problems, and all small problems would have been shifted to version 2.0.11.

Compiling the newest source will be my first step next time.

12

I found a bug today (or rather, a Yamagi Quake II user did a few days ago and we reproduced it today), I think it’s kinda bad…
Basically, on Win32 (doesn’t seem to happen on Linux/X11, didn’t test anything else) if you request a “real” fullscreen window at a higher resolution than the current desktop resolution, you get a fullscreen window at current desktop resolution (instead of the requested resolution).
It does work the other way around (requesting a lower resolution than current desktop resolution).

I created a bugzilla issue (incl. minimal testcase) at https://bugzilla.libsdl.org/show_bug.cgi?id=4700

I didn’t really debug this any further myself, because I’m not really familiar with WinAPI window creation or with the SDL Win32 video backend.

13

In case you (like me, initially) wonder why someone would run the game at a higher resolution than the desktop: Apparently nvidia has a feature called “DSR”: https://www.geforce.com/hardware/technology/dsr/technology
You render the game at a multiple of your actual display resolution and their driver scales it down - basically full screen antialiasing (aka super sampling). From the game’s point of view it’s just a high resolution display mode, so it doesn’t need much special support (ok, probably an option for scaling up the UI helps).
So, this currently doesn’t work with SDL and I think that’s bad - especially when you consider that SDL is used in lots of source ports of older games, for which DSR is especially attractive, as they can easily be rendered in very high resolutions by modern GPUs.
UPDATE: By the way, AMD seems to have a similar feature and they call it VSR: https://www.amd.com/en/technologies/vsr

Another weird thing I noticed when testing a bit more: If I, after creating the fullscreen window that gets the wrong resolution, call SDL_SetWindowDisplayMode to set the higher resolution I wanted to have, the display flickers (appears to change mode) and according to SDL_GetWindowDisplayMode() the window indeed has the desired mode, but SDL_GetWindowSize() still returns the old lower mode?!

1 Like
14

I’ve got an issue with 2.0.10 (actually it started with 2.0.9 but I just noticed it now.) When I toggle fullscreen desktop with SDL_SetWindowFullscreen(window, fullscreen_desktop ? SDL_WINDOW_FULLSCREEN_DESKTOP : 0); I get a black screen when going from fullscreen desktop to windowed. If I toggle it back to fullscreen desktop it works again.

I can do some bisecting if need be. 2.0.8 works fine.

EDIT: I tracked the change down to 12269:754cd2042e21. I was able to work around the problem in my own (questionable) code anyway so sorry for bringing this up.

15

Yes, if you can bisect it, that would be great. Thanks!

16

@slouken, check my edit. I’ve written the commit that caused it but also found a way around it without changing SDL (the fix was to change an instance of SDL_WINDOWEVENT_RESIZED to SDL_WINDOWEVENT_SIZE_CHANGED.)

17

@slouken: I gave the wrong commit I just noticed. It’s 12270:52dddda6fba7.

18

That change caused me a lot of headaches. I have to change it back to RESIZED on iOS/tvOS - if I use SIZE_CHANGED then I can’t run my ‘resize’ stuff which crashes because OpenGL can’t be used at that point (I get crashes in GL calls which when I Google says you can’t be accessing GL at that point.)