pascalgamedevelopment/sdl2-for-pascal

Unit files for building Free Pascal and Delphi applications using the SDL2 library

sdl2-for-pascal's Issues

Check and update sdlvideo.inc

Check sdlvideo.inc carefully for necessary update:

E. g.

• make TSDL_Window structur opaque, make it a pointer

Add some CI

It would be useful to have Continuous Integration set up for the project, so we can check if PRs compile successfully. I have some experience with CircleCI and GitHub Actions, so I can handle setting this up. I'm opening this issue mostly to discuss the matter and ask some questions.

• Which platforms do we want to test with? GHActions support Linux, Windows and MacOS runners. Setting up a Linux workflow would be trivial; Windows and MacOS would be more complicated.
• Do we define a specific version of the compiler we want to use, or just go with whatever version can be installed via apt / dnf / brew / chocolatey?
• FPC doesn't seem to have an equivalent to GCC's -Werror option (i.e. treat warnings as errors). Do we want to try and figure out some solution for detecting warnings and marking the CI job as failed when they do?
• Do we only compile the headers, or do we want to add some small tester program and then compile and run it?

TODO: add missing "preciseX" and "preciseY" fields to the "TSDL_MouseWheelEvent" structure

As of version 2.0.18, the SDL_MouseWheelEvent structure contains two additional fields — preciseX and preciseY of type float. These fields are missing from the TSDL_MouseWheelEvent declaration.

TODO: Implement Functions "SDL_JoystickPath" and "SDL_JoystickPathForIndex" (as of release of SDL 2.24.0)

The following functions are not implemented:

• SDL_JoystickPath
• SDL_JoystickPathForIndex

These functions are available since SDL 2.24.0

SDL_JoystickHasLED function has invalid parameters count

The function SDL_JoystickHasLED has the following declaration in the sdljoystick.inc file, in line 479:

function SDL_JoystickHasLED(joystick: PSDL_Joystick; button: cint32): TSDL_Bool; cdecl;
  external SDL_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_SDL_JoystickHasLED' {$ENDIF} {$ENDIF};

This function should have only one parameter — the joystick handle, button is not needed to determine if the joystick has LED or not. This import is inconsistent with the documentation, in which the following declaration is given:

SDL_bool SDL_JoystickHasLED(SDL_Joystick *joystick);

Check and update sdlthread.inc

This issue is created mainly to clean up todo list of README.MD.

Nevertheless, sdlthreads needs a major review and this seems to be a more difficult task.

Impossible to use "TSDL_SysWMInfo.Win.Window

Video mode window minimization loops endlessly

Run window in exclusive video mode, e.g. in 800x600 resolution:

SDL_SetWindowSize(Window, 800, 600);
SDL_SetWindowFullScreen(Window, SDL_WINDOW_FULLSCREEN);

Everything is working fine. Now, press the Alt+Tab combination — the program window will be minimized, the resolution will be automatically changed to the original (desktop) resolution, then SDL falls into an endless minimize and restore loop. It will try to minimize the window, restore resolution, restore video mode, minimize it again, and so on. The effect is that the screen flickers rapidly and only closing the program stops this process.

The temporary solution is to disable automatic window minimalization when the window loses focus:

SDL_SetHint(SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS, '0');

I don't know if this hint exists because of this looping problem, at least the fact that it does exist indicates a bug. This problem occurs at least on Windows 10, on different computers, so it's not my laptop's fault.

Update sdlatomic.inc according to code style guidelines

To be in accordance with the code style guidelines, which states to stay as close as possible with the C code, I would suggest the following updates for sdlatomic.inc:

Line 42: Rename TSDL_Atomic into TSDL_atomic_t and lower-case Value + also adapt all parameter lists consequently
Line 49 + 87: Rename param. list (oldValue into oldval, ...)
Many param lists: Rename atomic by a and value by v.

Should we use unit ctypes for FPC?

I wonder,

in sdlstd.inc we define all the types used in SDL2. We lead them back to basic Pascal types. In this example we lead UInt16 back to Word.

PUInt16 = ^UInt16;
UInt16 = Word;

I suggest to have a conditional type conversion bound to the ctypes unit for Free Pascal.

{$IFDEF FPC}
  UInt16 = cuint16;
{$ELSE}
  UInt16 = Word;
{$ENDIF}

The advantage is that type sizes should be chosen even more reliably for different platforms (at least in case of FPC).

SDL_RenderGeometry

Hi
i just download sdl2-for-pascal and notice that SDL_RenderGeometry is missing , do you plan to add this function ?

Remove Strings/AnsiStrings unit dependency for string handling

See PR #109 and discussion there.

In short:

• replace the Strings.StrLen (FPC) / AnsiStrings.StrLen (Delphi) function calls by SDL_strlen() function calls
• remove dependency from Strings (FPC) / AnsiStrings (Delphi) unit

TODO: Implement "SDL_FlashWindow" function

SDL_FlashWindow and the type TSDL_FlashOperation are not implemented.

How to handle deprecated sdl2 functionality?

This issue is about a problem I ran into recently and saw also in a pull request recently.

Simple example:
Lets say there are some defines which are translated.

const
  SDL_DEFINE1 = 0;
  SDL_DEFINE2 = 1;
  SDL_DEFINE3 = 2;

In a newer version of the header file one of the defines is missing. Let's say the second define is missing. So the inc-file would be updated to:

const
  SDL_DEFINE1 = 0;
  SDL_DEFINE3 = 2;

However, this raises (at least) two problems.

1. The define is (obviously) missing if someone is using an older version of sdl2 instead of the particualrly one to which the inc-file got updated.
2. The second concern is raised particularly because we are not always updating consistently to one particular version AND not all files at the same time: Let's say some files are not updated yet (very old version), some are updated (not the most recent version), some are updated to the latest version of sdl2. If now in the newest version some defines are deleted because they are gone, this may conflict with functions or expectations which are present in very old or older versions as they need or at least expect these defines/functions to be present.

The example above can be extended to structs/records where in newer version fields are missing or change their variable type.

Solution:
Actually, I don't know a simple solution yet. except to have some conditional compilation. Something like:

const
  SDL_DEFINE1 = 0;
  {$IFDEF DEPRECATED_IN_NEWER_SDL2} SDL_DEFINE2 = 1; {$ENDIF}
  SDL_DEFINE3 = 2;

What are better solutions or should this be adressed anyway?

Best regards
Matthias

How to react to (soon to come) release of SDL3?

Hi there,

I wonder what would be the best option to react if SDL3 is released. Their main branch is already dedicated to SDL3.

Unfortunately our repo has the version 2 ingrained in the name, so we have the following options

1. rename the repo
2. start a new repo "SDL3-for-Pascal" based on SDL2-for-Pascal (no fork)
3. branching SDL3 off within the SDL2-for-Pascal repo

I prefer the second option so far, as this allows for further development of SDL2-for-Pascal and keeps all links to this repo intact and it prevents confusion. Option 1 would break links to this repo. Option 3 is confusing if the repo is not renamed to SDL3-for-Pascal.

I would suggest to base SDL3 at least on our next release as soon as the last few include files are updated.

Best regards

@suve
@AthenaOfDelphi

Add extra pointer types to keep things tidy

The source code for these headers uses various data types, with aliases included. I don't know exactly how many of them there are, but some of them don't have declared pointer equivalents, so you have to declare them yourself, apart from the code of the headers library.

One such example is TSDL_JoystickPowerState. This is a dedicated integer type, but there is no pointer equivalent — there is no PSDL_JoystickPowerLevel declared anywhere. A good practice would be to add missing pointer types to the library for each existing non-pointer data type.

---

BTW: Why the TSDL_JoystickPowerState is declared as Integer?

type
  TSDL_JoystickPowerLevel = type Integer;

The same with TSDL_JoystickType:

type
  TSDL_JoystickType = type Integer;

If cint* and cuint* types are used everywhere else, it's fine to actually use them everywhere to keep things tidy.

Should unit ctypes be shipped with our project for Delphi users?

At the moment we have this file ctypes.inc to map native c data types for Delphi users. Would it be better to ship the ctypes unit from FPC along with our project?

Advantage

• we do not need to maintain a separate file ourselves
• both compilers have the same condition: on the same system, the mapping will be the same
• many different systems would get the correct C types mapping (our ctypes.inc is very, very basic)
• we don't need to IFDEF the ctypes unit anymore

Disadvantage

• not sure about the compatibility of the ctypes unit with Delphi (there are delphi conditionals within the file, but are they meant for Delphi or FPC's Delphi mode?)
• Not sure about the licensing, can our MPL-zlib dual license still apply if we ship the unit along with our project? (If not, case is closed, we can not do it.)
• We need to make sure to keep the most recent version of the ctypes unit (but it seems, it is updated very, very rarely)

Best regards

Edit: Correct typo in license abbreviation.

Resizing the window right after turning off video mode sometimes does not work

In my test program I implemented the toggle fullscreen function. After pressing a given button, the video mode is activated, after pressing a second time it returns to the window mode. However, resizing the window with SDL_SetWindowSize right after SDL_SetWindowFullScreen has no effect in most cases — the window size remains as used in video mode. Most of the time, because sometimes it works.

Code to enable video mode:

procedure TurnOnFullScreen(AWindow: PSDL_Window);
begin
  SDL_SetWindowSize(AWindow, 800, 600);
  SDL_SetWindowFullScreen(AWindow, SDL_WINDOW_FULLSCREEN);
  SDL_ShowCursor(0);
end;

Code to disable video mode, restore window size and center it on the screen:

procedure TurnOffFullScreen(AWindow: PSDL_Window);
var
  DisplayBounds: TSDL_Rect;
  DisplayIndex: SInt32;
begin
  SDL_SetWindowFullscreen(AWindow, 0);
  SDL_ShowCursor(1);

  DisplayIndex := SDL_GetWindowDisplayIndex(AWindow);

  if SDL_GetDisplayBounds(DisplayIndex, @DisplayBounds) = 0 then
  begin
    SDL_SetWindowSize(AWindow, 640, 480);
    SDL_SetWindowPosition(
      AWindow,
      DisplayBounds.X + (DisplayBounds.W - 640) div 2,
      DisplayBounds.Y + (DisplayBounds.H - 480) div 2
    );
  end;
end;

The effect is that the window is sometimes centered correctly and the size does not always change from 800×600 to 640×480. This problem occurs on at least Windows 10.

Folder names and structure of extensions of the pure translation project

As the project grows more complex, we need to decide on senseful names and folder structure of project extensions (e. g. examples, tests, docs,...) which are not directly related to the original sdl2 package. Otherwise the main folder will be polluted with all kinds of different files which complicates everything unncecessarily.

The main goal is to make clear from the folder names that these contain files which are not directly related to the original sdl2 lib.

My proposal would be a prefix "pascal" to make this clear:

E.g.
\ (main source, as is)
\pascaldocs\
\pascalexamples\
\pascaltests\

The substructure in these folders could then be as expected:
\pascalexamples\renderbitmap\
\pascalexamples\handleevents\

Please let us discuss if there are other and/or better ways to keep the files ordered.

The function "SDL_PIXELFLAG" has incorrect name

SDL2-for-Pascal/units/sdl2.pas

Lines 356 to 359 in 3feb476

	function SDL_PIXELFLAG(X: cuint32): cuint32;
	begin
	Result := (X shr 28) and $0F;
	end;

This macro-function should be named SDL_PIXELFORMAT, since it is used to return the pixel format, one of the SDL_PIXELFORMAT_* values. Am I right?

Unable to hide cursor when HitTest callback is set

If the window does not have a defined hit-test callback, it is possible to hide the cursor using the SDL_ShowCursor function. However, if I set a callback and hide the cursor, this one is still visible. Try the following code:

SDL_SetWindowHitTest(Window, @MyHitTestCallback, nil);
SDL_ShowCursor(0);

The cursor won't hide in both windowed mode and exclusive video mode. This problem occurs on at least Windows 10.

TSDL_Bool not cbool

SetColorKey requires an integer as the second parameter.
(SDL_surface.h; line: 446)

extern DECLSPEC int SDLCALL SDL_SetColorKey(SDL_Surface * surface, int flag, Uint32 key);

And SDL_FALSE & SDL_TRUE are also declared as integers.
(SDL_stdinc.h; line: 184)

typedef enum
{
     SDL_FALSE = 0,
     SDL_TRUE = 1
} SDL_bool;

So, in my opinion, TSDL_Bool should also be declared as an integer.
I modified the following in "sdlstdinc.inc":

type
   TSDL_Bool = cint;
// TSDL_Bool = cbool;

Do you also think that this is more the case?

I am using Lazarus 2.2.4

SDL software renderer fails with Floating Point Exception

This is mostly for visibility - I'm not sure where this would be best fixed.

It seems any SDL application compiled with Pascal will crash if trying to use software renderer video output, on Linux. To verify, run any SDL application with the environment variable LIBGL_ALWAYS_SOFTWARE=1 set. The failure happens either immediately on SDL_InitSubSystem(SDL_INIT_VIDEO), or when calling SDL_CreateRenderer. The error that appears can be EInvalidOp: Invalid floating point operation or EDivByZero: Division by zero depending on environment.

Doing this through GDB, I got this callstack pointing at the LLVMpipe software rasterizer:

lp_build_tgsi_info () from /usr/lib64/dri/swrast_dri.so
llvmpipe_create_fs_state () from /usr/lib64/dri/swrast_dri.so
ureg_create_shader () from /usr/lib64/dri/swrast_dri.so
util_make_fragment_tex_shader_writemask () from /usr/lib64/dri/swrast_dri.so
util_make_fragment_tex_shader () from /usr/lib64/dri/swrast_dri.so
blitter_get_fs_texfetch_col () from /usr/lib64/dri/swrast_dri.so
util_blitter_cache_all_shaders () from /usr/lib64/dri/swrast_dri.so
llvmpipe_create_context () from /usr/lib64/dri/swrast_dri.so
st_api_create_context () from /usr/lib64/dri/swrast_dri.so
dri_create_context () from /usr/lib64/dri/swrast_dri.so
driCreateContextAttribs () from /usr/lib64/dri/swrast_dri.so
drisw_create_context_attribs () from /lib64/libGLX_mesa.so.0
dri_common_create_context () from /lib64/libGLX_mesa.so.0
CreateContext () from /lib64/libGLX_mesa.so.0
glXCreateContext () from /lib64/libGLX_mesa.so.0
glXCreateContext () from /lib64/libGLX.so.0
X11_GL_LoadLibrary.part.0 () from /lib64/libSDL2-2.0.so.0

So it's a problem in Mesa. This doesn't affect Pascal/SDL programs on Windows since users don't normally run Mesa there. An internet search turned up this bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3096

They say the FPE should normally not be enabled in the first place, and the caller should just disable the exception mode. A commenter notes that the affected software was made with Delphi, which suggests to me that Free Pascal and Delphi are both deliberately keeping this FPE enabled (and are unlikely to change that because it would break compatibility).

As a workaround, it's simple to disable the exception by applying a mask, via the Math unit:

uses Math, SDL2;
var m : TFPUExceptionMask;
        window : PSDL_Window;
        renderer : PSDL_Renderer;
begin
        m := GetExceptionMask;
        include(m, exInvalidOp);
        SetExceptionMask(m); // <-- comment out this and it breaks again

        writeln(SDL_InitSubSystem(SDL_INIT_VIDEO));
        window := SDL_CreateWindow(NIL, SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
                640, 400, SDL_WINDOW_SHOWN);
        if window = NIL then writeln('failed to create window: ' + SDL_GetError);
        renderer := SDL_CreateRenderer(window, -1, 0);
        if renderer = NIL then writeln('failed to get renderer: ' + SDL_GetError);
        writeln('no crash, all ok!');
end.

Where is the pcsize_t.

I try to compile the units in Delphi， report error as follow:

[dcc32 Error] sdlrwops.inc(220): E2003 Undeclared identifier: 'pcsize_t'
[dcc32 Error] sdlrwops.inc(236): E2005 'pcsize_t' is not a type identifier
[dcc32 Error] ctypes.inc(94): E2240 $EXTERNALSYM and $NODEFINE not allowed for 'SIZE_T'; only global symbols
[dcc32 Fatal Error] SDL2Sample.dpr(9): F2063 Could not compile used unit 'sdl2.pas'
Failed

TODO: add missing "SDL_JOYBATTERYUPDATED" event

There is a new event called SDL_JOYBATTERYUPDATED, which provides information about a change in joystick battery status. Corrently undocumented, but exists in the sources (last):

/* Joystick events */
SDL_JOYAXISMOTION  = 0x600, /**< Joystick axis motion */
SDL_JOYBALLMOTION,          /**< Joystick trackball motion */
SDL_JOYHATMOTION,           /**< Joystick hat position change */
SDL_JOYBUTTONDOWN,          /**< Joystick button pressed */
SDL_JOYBUTTONUP,            /**< Joystick button released */
SDL_JOYDEVICEADDED,         /**< A new joystick has been inserted into the system */
SDL_JOYDEVICEREMOVED,       /**< An opened joystick has been removed */
SDL_JOYBATTERYUPDATED,      /**< Joystick battery level change */

https://www.libsdl.org/tmp/SDL/include/SDL_events.h

It fits to keep an eye on it.

Is it possible to static link `libSDL2.a` in windows x64?

Hi, I was trying to static link libSDL2.a, x64, (from SDL2-devel-2.26.5-mingw.zip) and I am getting windows api related undefined symbols. Can you shed some light on this?

eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_LoadLibraryA (first seen in libSDL2.a(SDL_dynapi.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetProcAddress (first seen in libSDL2.a(SDL_dynapi.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_FreeLibrary (first seen in libSDL2.a(SDL_dynapi.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_MessageBoxA (first seen in libSDL2.a(SDL_dynapi.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_OutputDebugStringW (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_AttachConsole (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetStdHandle (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetConsoleMode (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_WriteConsoleW (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetLastError (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_WriteFile (first seen in libSDL2.a(SDL_log.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: strlen (first seen in libSDL2.a(SDL_string.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_CloseHandle (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_SetFilePointer (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_ReadFile (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_SetFilePointerEx (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetFileSizeEx (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_SetErrorMode (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_CreateFileW (first seen in libSDL2.a(SDL_rwops.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetSystemMetrics (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetAsyncKeyState (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetForegroundWindow (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetClipCursor (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetKeyState (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_ClipCursor (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetCursorPos (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_ScreenToClient (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetPropW (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetWindowLongW (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_DefWindowProcW (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_CallWindowProcW (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetMessageExtraInfo (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetWindowRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_SetCursor (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_IsIconic (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetClientRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_IsRectEmpty (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_ClientToScreen (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_InvalidateRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_CreateSolidBrush (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetDC (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_FillRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_DeleteObject (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetUpdateRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_ValidateRect (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_DragQueryFileW (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_DragFinish (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_SetWindowPos (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_TrackMouseEvent (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Error: Undefined symbol: __imp_GetMenu (first seen in libSDL2.a(SDL_windowsevents.o))
eyelink_project.lpr(23,1) Verbose: There were 50 errors compiling module, stopping
Verbose: Compilation aborted

Naming convention for C-identifiers? (Style guide development)

As raised in a pending PR #53 :

We need to decide for a naming convention of the C-identifiers from ctypes unit.

Naming conventions

1) ctypes unit
All lower-case, hence a 16 bit unsigned integer is cuint16.

2) SDL2-for-Pascal (this project)
All lower-case

Pro:

• consistent with ctypes unit
• consistent within the whole project (for now)

Con:

• ugly/low readability

Some question which come to mind to be dicussed alongside:

• What style to adopt exactly? ("Specification")
• What are the benefits of changing the style? What are the pros/cons?
• Does the effort pay out?
• Should we allow several styles? Should we restrict to a certain style at all?

Best regards
Matthias

Handle SDL_bool like a real boolean

Actually we should translate SDL_bool by TSDL_Bool. This will generate compiler errors in situations as shown below:

(from sdl2.pas)

function SDL_VERSION_ATLEAST(X,Y,Z: cuint8): Boolean;
begin
  Result := SDL_COMPILEDVERSION >= SDL_VERSIONNUM(X,Y,Z);
end;

How should we handle or fix this?

Problem with missing "SDL.dll" library and with the names of required libraries

1. To handle sounds, the SDL2_mixer.pas unit and the SDL2_mixer.dll library are required. However, a program that uses functions from this unit requires the SDL_mixer.dll library, not SDL2_mixer.dll. Changing the name of this dll solves the problem, but the SDL should use original dll names, with 2 in dll filenames.

2. The change of name described above is not enough. The second problem is that in addition to the SDL2.dll library, the SDL.dll library is also required, which is not available for download from the official SDL website. This problem can be solved simply by copying the SDL2.dll library and naming it SDL.dll. However, keeping two copies of the same library just for the program to run properly is just a madness.

Unfortunately, the sources contain the correct dll names (all of them with the SDL2_* prefix, and the main library is named SDL2.dll, so also correctly). If so, where is the problem?

TODO: Implement function "SDL_SetWindowMouseRect" and others (introduced in older SDL2 releases) + DISCUSSION: How to handle opaque structures

Functions to implement:

• SDL_GetWindowMouseRect
• SDL_SetWindowMouseRect
• SDL_GetWindowMouseGrab
• SDL_SetWindowMouseGrab
• SDL_GetWindowKeyboardGrab
• SDL_SetWindowKeyboardGrab

TODO in pixels.inc: Examine/translate macros from pixels.h

Description: See lines 90-150 in pixels.inc and compare with pixels.h. The macros should be translated and implemented as functions in sdl2.pas. For reference see the macros which are translated already.

You don't have to ask for approval, just take this task and do it, then file a pull request. If you want to claim this task though, just ask here and we will assign you.

Impossible to use "TSDL_SysWMInfo.Win.Window" after last pull request

In my main project, I'm creating the window in this way:

type
  TWindow = class(TObject)
  private
    FHandle: THandle;
    FWindow: PSDL_Window;
    FRenderer: PSDL_Renderer;
  {...}
  end;

{...}

constructor TWindow.Create();
var
  SysInfo: TSDL_SysWMInfo;
begin
  FWindow := SDL_CreateWindow('Fairtris', SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 0, 0, SDL_WINDOW_BORDERLESS);
  if FWindow = nil then Halt();

  FRenderer := SDL_CreateRenderer(FWindow, -1, SDL_RENDERER_ACCELERATED or SDL_RENDERER_TARGETTEXTURE);
  if FRenderer = nil then Halt();

  SDL_Version(SysInfo.Version);
  SDL_GetWindowWMInfo(FWindow, @SysInfo);

  FHandle := SysInfo.Win.Window;
end;

The above code works fine, creates a window and renderer, and takes the window handle correctly and puts it in the FHandle field.

A moment ago I noticed that the last pull request was accepted, so I downloaded fresh source, recompiled the project and... I get a SIGSEGV exception right after starting the program. The problem now is reading the window handle — an exception is thrown when executing the following statement:

FHandle := SysInfo.Win.Window;

I checked if the SDL_GetWindowWMInfo function is working correctly and yes — it returns SDL_TRUE and fills the structure correctly. If I comment out the lines about getting the handle, the program starts up and runs fine with no exceptions or other problems:

constructor TWindow.Create();
//var
//  SysInfo: TSDL_SysWMInfo;
begin
  FWindow := SDL_CreateWindow('Fairtris', SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 0, 0, SDL_WINDOW_BORDERLESS);
  if FWindow = nil then Halt();

  FRenderer := SDL_CreateRenderer(FWindow, -1, SDL_RENDERER_ACCELERATED or SDL_RENDERER_TARGETTEXTURE);
  if FRenderer = nil then Halt();

  //SDL_Version(SysInfo.Version);
  //SDL_GetWindowWMInfo(FWindow, @SysInfo);
  //
  //FHandle := SysInfo.Win.Window;
end;

So the problem definitely concerns accessing the SysInfo.Win.Window field. And when I go back to the SDL headers before the pull request, the code works fine again and the handle is assigned to the FHandle field properly.

Tested on Windows 10 64-bit using Lazarus 2.0.12 (FPC 3.2.0).

sdl2_ttf.pas compile failed in delphi

function TTF_OpenFontIndex(file_: PAnsiChar; ptsize: cint; index: clong): PTTF_Font; cdecl;
external TTF_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_TTF_OpenFontIndex' {$ENDIF} {$ENDIF};
function TTF_OpenFontIndexRW(src: PSDL_RWops; freesrc: cint; ptsize: cint; index: clong): PTTF_Font; cdecl;
external TTF_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name 'TTF_OpenFontIndexRW' {$ENDIF} {$ENDIF};
function TTF_OpenFontIndexDPI(file: PAnsiChar; ptsize: cint; index: clong; hdpi: cuint; vdpi: cuint): PTTF_Font; cdecl;
external TTF_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_TTF_OpenFontIndexDPI' {$ENDIF} {$ENDIF};
function TTF_OpenFontIndexDPIRW(src: PSDL_RWops; freesrc: cint; ptsize: cint; index: clong; hdpi: cuint; vdpi: cuint):
PTTF_Font; cdecl;
external TTF_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_TTF_OpenFontIndexDPIRW' {$ENDIF} {$ENDIF};
function TTF_FontFaces(font: PTTF_Font): clong; cdecl;
external TTF_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_TTF_FontFaces' {$ENDIF} {$ENDIF};

compile error:
[dcc32 Error] sdl2_ttf.pas(245): E2003 Undeclared identifier: 'clong'

Major review of sdlstdinc.inc (from SDL_stdinc.h) necessary

The C header file SDL_stdinc.h contains a lot of functions, types and features which are not found in the corresponding sdlstdinc.inc.

A major review of this file is necessary:

• find defines/types/functions which are potentially useful for Pascal programmers, add them
• e. g. math functions

Game controller D-Pad is handled incorrectly

I have a problem with handling my controller using SDL. It is about such a controller:

As you can see, it has a D-Pad (two axes) and four buttons. Windows 10 detects it correctly, everything works normally:

SDL detects this controller correctly, but when I press the D-Pad's arrows, it generates much more events than it should. Pressing the left arrow sends eight events to four axes (two for each axis), even though the controller only has two. Also, the SDL_JoystickNumAxes function in this case returns 5, which is also invalid (it should return 2).

In the SDL_Init function I pass the SDL_INIT_JOYSTICK flag and the initialization is successful. I connect the controller to the USB port, SDL sends the SDL_JOYDEVICEADDED event, so I call the SDL_JoystickOpen function — it opens the joystick correctly. Then I read the provided data in the SDL_JOYAXISMOTION event handler.

I wrote the debug code. After receiving the SDL_JOYAXISMOTION event, I display the data provided in the event to the console. The code is simple, it looks like this:

  case AEvent.Type_ of
    {..}
    SDL_JOYAXISMOTION:
    begin
      WriteLn('Event: SDL_JOYAXISMOTION');
      WriteLn('Type:  ', AEvent.JAxis.Type_);
      WriteLn('Axis:  ', AEvent.JAxis.Axis);
      WriteLn('Value: ', AEvent.JAxis.Value);
      WriteLn();
    end;
  end;

Pressing and holding the left arrow on D-Pad produces this:

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  0
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  0
Value: -32768

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  1
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  1
Value: -32768

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  2
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  2
Value: -32768

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  3
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  3
Value: -32768

Left arrow released:

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  0
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  1
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  2
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  3
Value: -256

Pressing and releasing up arrow:

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  4
Value: -256

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  4
Value: -32768

Event: SDL_JOYAXISMOTION
Type:  1536
Axis:  4
Value: -256

And so on. I checked my code on two other cheap (Chinese) controllers and those are properly handled by SDL (and Windows 10 too), but retro-bit is not. Although as I wrote — Windows has no problem with all my controllers, various emulators also have no problems (Mesen, FCEUX etc.), but SDL does with one.

Update sdl2_ttf.pas to match code style guidelines

The function declarations have to be checked for the cdecl modifier to satisfy our code style guidlines (at the bottom). The cdecl modifier should be behind the function line, the external modifier should be in the next line with two letters indentention.

Best regards

TODO: Add Metal functions in sdlrender(er).inc

See title and PR #48

Lack of "SDL_JoystickHasRumble" and "SDL_JoystickHasRumbleTriggers" function imports

Headers does not contain imports of the following functions:

• SDL_JoystickHasRumble
• SDL_JoystickHasRumbleTriggers

The following imports works on Windows 10, using SDL 2.0.20.0 dll file:

function SDL_JoystickHasRumble(joystick: PSDL_Joystick): TSDL_Bool; cdecl;
  external SDL_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_SDL_JoystickHasRumble' {$ENDIF} {$ENDIF};

function SDL_JoystickHasRumbleTriggers(joystick: PSDL_Joystick): TSDL_Bool; cdecl;
  external SDL_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name '_SDL_JoystickHasRumbleTriggers' {$ENDIF} {$ENDIF};

You should check if those are proper for other platforms.

TODO: add missing "SDL_GetMemoryFunctions" procedure (SDL 2.0.7)

In the SDL 2.0.7, the function SDL_GetMemoryFunctions was introduced. There is a lack of import of it. It would be good to add not only the import of this function, but also type declarations of templates of the functions to which the SDL_GetMemoryFunctions returns pointers. Something like:

type
  TSDL_MallocFunc = function(size: csize_t): pointer; cdecl;

Project docs: PasDoc vs. FPDoc

I'd like to suggest to use PasDoc instead of FPDoc for our project, as PasDoc is reading in the comments directly from the source code and generating the docs from this. For FPDoc we would have to maintain a separate description file.

Using FPDoc means we would need to cut out the comments and transfer them into the description file (additional work). This means for the user also, he/she HAS TO look at the documentation files to get what a function is doing or returns, etc, Or, if we decided to keep the original comments in the code also (what I prefer), then we had to maintain/synchronize both, the comments in the source code and in the description file (additional work).

On the other hand, if we used PasDoc, we just keep the comments as they are. Some C-editor tags like \sa could be directly transformed into @seealso and voila.

What do you think?

{$EXTERNALSYM SIZE_T} should be {$EXTERNALSYM csize_t} in ctypes.inc

Versioning of files / Supported SDL2 version

This issue is based on a discussion started in another issue #19.

Author: @suve

@Free-Pascal-meets-SDL-Website: I think we should formally define what "SDL version" means in our headers. So far, we've been (informally) going by "pick the newest function, if it was introduced in X.Y.Z, we put X.Y.Z as our version". This bug suggests that we should go with "what's the version of the library that we're 100% up-to-date with". Some parts can be newer than the X.Y.Z we're declaring, but no parts should be older.

Author: @Free-Pascal-meets-SDL-Website

@suve
I like the idea. The realization is tough though. We would need to track the version of every file individually as nobody is updating all the file at once, right? - What way do you propose?Just a comment at the first line?

Check the first line of sdljoystick.inc . What do you think of this simple solution for the time being? When all files reached a certain minimum version, we can say we support this particular version.

In the README.MD todo list we could also list all files which should be updated to a certain version.

TODO: missing "display" field in the "TSDL_Event" and the "TSDL_DisplayEvent" structure.

Some time ago the SDL_DisplayEvent was introduced, but there is no display field in the TSDL_Event structure that would allow the data to be read for this event. What is interesting, the SDL_DISPLAYEVENT and other enums are added to the sdlevents.inc file, but there is no support for them.