SDL 2.0 Test, Need Advice

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SDL 2.0 Test, Need Advice

Anthony Walter-3
SDL 2.0 was locked down Friday in preparation for release in May, and I have been working this weekend on converting the SDL 2 headers to Free Pascal. In addition I have been writing a OpenGL which creates stubs for loading the correct OpenGL library and loading the OpenGL core functions and extensions for every platform.

So far things the basic things are working and I can cross compile an OpenGL application for Linux32 and Win32 from my Linux desktop. However I have a few problems which I am hoping someone on this list can help me with.

Problems:

1) On Linux can build an i386-linux SDL2 application but I cannot cannot run or debug my test applications from the IDE. When I try to run from within the IDE nothing seems to happen. When I open a terminal I can and run my test application runs just fine.

2) I cannot compile a i386-win32 SDL2 application on Linux using the SDL2 static libraries (define static in CrossSDL2.pas which should be reference i386-win32/libSDL2.a) for Windows. I get a bunch of errors similar to this:

  test.lpr(79,1) Error: Undefined symbol: CROSSSDL2_$$_SDL_GL_LOADLIBRARY$PCHAR$$LONGINT
  ...
  test.lpr(79,1) Error: Undefined symbol: CROSSSDL2_$$_SDL_DESTROYWINDOW$PSDL_WINDOW

3) On windows when I run my test sdl app (I must use libSDL2.dll due to problem 2 above) from a cmd prompt I get no SDL window and access violations at termination, but when I run my test applcation using "start my-test-i386-win32.exe" or double clicking in windows explorer it runs jsut fine.

Here is a link to my sources including SDL2 static and dynamic library binaries for Linux32 and Win32. My sources are in a 'draft' state and likely to change drastically in future revisions: 

As a side note, if anyone wants to compile SDL2 libaries for Windows or Linux themselves and needs help I can send your the steps I used to builds SDL2 from the latest mercurial version.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Sven Barth-2

Am 08.04.2013 01:37 schrieb "Anthony Walter" <[hidden email]>:
>
> In addition I have been writing a OpenGL which creates stubs for loading the correct OpenGL library and loading the OpenGL core functions and extensions for every platform.
>

Don't we have that already? And even if not in my opinion it would be better to extend the existing GL units...

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Anthony Walter-3
On Mon, Apr 8, 2013 at 1:59 AM, Sven Barth <[hidden email]> wrote:

Am 08.04.2013 01:37 schrieb "Anthony Walter" <[hidden email]>:


>
> In addition I have been writing a OpenGL which creates stubs for loading the correct OpenGL library and loading the OpenGL core functions and extensions for every platform.
>

Don't we have that already? And even if not in my opinion it would be better to extend the existing GL units...

Regards,
Sven


I don't want my three questions to get too side tracked, but I'll give you my reasoning on this point.

SDL 2.0 adds improved support and unified (all platforms/architectures, android, ios, osx, linux, windows, ect) for OpenGL extension querying, library loading/unloading, context management, but in cases only if you allow SDL to handle the management of OpenGL resources (modules, windows, contexts). Valve brought hired the original SDL author to manage the development of this 2.0 version. The licensing of 2.0 is friendlier (there are no restrictions to static linking), and I believe when it's done, it's going to be a very strong/popular API, especially given how they've added a basic 2D drawing system and much better window management (multiple windows, more event types like touch, full screen toggling without context destruction, and more).

The current Jedi GL unit doesn't mesh well with this. It uses hard coded OpenGL module names, splits extensions into a separate unit (anything beyond OpenGL 1.X), uses an extension loading system which might be incompatible on some platforms when using the SDL 2.0 such as SDL_GL_ExtensionSupported. I think it would be better to have one OpenGL pascal unit which only lists types, constants, function stubs, and leave the actual OpenGL module picking/loading/unloading and extension querying/loading available for other libraries to manage, and dispense of code like:

GL.pas

  {$IFDEF Windows}
  LoadOpenGL('opengl32.dll');
  {$ELSE}
  {$ifdef darwin}
  LoadOpenGL('/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib');
  {$ELSE}   

GLExt.pas

{$IFDEF Windows}
{ Declared in Windows unit as well in FPC; but declared here as well, to be
  fully compatible to upstream version  - sg }
function wglGetProcAddress(proc: PChar): Pointer; extdecl; external 'OpenGL32.dll';
{$ELSE}
function wglGetProcAddress(proc: PChar): Pointer;
{$ENDIF}

And instead have something like this in an OpenGL.pas unit:

var
  OpenGLManager: record
    Load: function: Boolean;
    GetProcAddress: function(ProcName: PAnsiChar): Pointer;
    ExtensionSupported: function(Extension: PAnsiChar): Boolean;
  end;

And allow other units to control how the OpenGL unit manages some functions. Essentially what this involves is a rewrite of the GL unit, which is what I am doing. See every one of the function Load_XXX: Boolean in GLext.pas.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Marco van de Voort
In reply to this post by Anthony Walter-3
In our previous episode, Anthony Walter said:
> 2) I cannot compile a i386-win32 SDL2 application on Linux using the SDL2
> static libraries (define static in CrossSDL2.pas which should be reference
> i386-win32/libSDL2.a) for Windows. I get a bunch of errors similar to this:
>
>   test.lpr(79,1) Error: Undefined symbol:
> CROSSSDL2_$$_SDL_GL_LOADLIBRARY$PCHAR$$LONGINT
>   ...
>   test.lpr(79,1) Error: Undefined symbol:
> CROSSSDL2_$$_SDL_DESTROYWINDOW$PSDL_WINDOW

This is related to how you link. Missing FPC generated symbols is extremely
rare when the buildprocess is under FPC's control.

See what you do differently (from just using fpc <xx>), and check it.
Thoroughly.
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Sven Barth-2
In reply to this post by Anthony Walter-3
Am 08.04.2013 08:53, schrieb Anthony Walter:
On Mon, Apr 8, 2013 at 1:59 AM, Sven Barth <[hidden email]> wrote:

Am 08.04.2013 01:37 schrieb "Anthony Walter" <[hidden email]>:


>
> In addition I have been writing a OpenGL which creates stubs for loading the correct OpenGL library and loading the OpenGL core functions and extensions for every platform.
>

Don't we have that already? And even if not in my opinion it would be better to extend the existing GL units...

Regards,
Sven


I don't want my three questions to get too side tracked, but I'll give you my reasoning on this point.

[...]
And instead have something like this in an OpenGL.pas unit:

var
  OpenGLManager: record
    Load: function: Boolean;
    GetProcAddress: function(ProcName: PAnsiChar): Pointer;
    ExtensionSupported: function(Extension: PAnsiChar): Boolean;
  end;

And allow other units to control how the OpenGL unit manages some functions. Essentially what this involves is a rewrite of the GL unit, which is what I am doing. See every one of the function Load_XXX: Boolean in GLext.pas.

Ok, so if you can do this in a way that SDL would not be needed if one doesn't want to use it and that using older OpenGL versions (e.g. 2.1) is supported I'd say: go for it :)

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Anthony Walter-3
So I did a lot of googling and testing and still haven't made progress fixing these problems. 

Problem #1 which prevents me from debugging or running projects which link to libSDL2.so in the IDE (lazarus) is quite annoying. I've put together a minimal example. If anyone with access to a 32 bit linux and lazarus setup could help me figure out why I can't debug or run, I'd very much appreciate your help.

program sdl2_test;

const
  SDL_INIT_VIDEO = $00000020;

function SDL_Init(flags: LongInt): LongInt; cdecl; external 'libSDL2.so';
function SDL_GetVideoDriver(index: LongInt): PAnsiChar; cdecl; external 'libSDL2.so';
procedure SDL_Quit; cdecl; external 'libSDL2.so';

procedure Run;
begin
  SDL_Init(SDL_INIT_VIDEO);
  WriteLn('Initialized');
  WriteLn('Video Driver: ', SDL_GetVideoDriver(0));
  SDL_Quit;
  WriteLn('Quit');
end;

begin
  // issue #1, the line below never executes when Run (F9) from lazarus
  Run; 
  // but runs correctly from a terminal window
end.

Source file of the above here including libSDL2.so binary:

If anyone wants to build the SDL2 static and dynamic versions themselves, type the following in your linux terminal:

mkdir test
cd test
mkdir build 
cd build
cmake ../SDL
make

Mind you, I'll be contributing the conversions (and some demos) when everything seems to work correctly, so you'd be doing everyone a favor if these problems (or at least problem #1) can be resolved.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: SDL 2.0 Test, Need Advice

Anthony Walter-3
I fixed this problem. Apparently settings in my .bashrc are not inherited by launcher applications. I have a ~/lib folder where I would put shared object files I built and added that path it in .bashrc

LD_LIBRARY_PATH=~/lib
export LD_LIBRARY_PATH

I copied the above again in the script which launches lazarus and now I can run/debug tests which reference libSDL2.so from lazarus.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal