Csfml.pas

[drezgames]

Hi, yea SFML is cool. Its was certainly easier to compile the C/C++ sources vs the others I've tried. It coded/structured in a style similar to my own which makes it also easier for me to work with and way easier to import and use in my project. I am working on the examples, but having a bit of a problem with the event structure:

typedef union
{
    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    sfEventType            type; ///< Type of the event
    sfSizeEvent            size;
    sfKeyEvent             key;
    sfTextEvent            text;
    sfMouseMoveEvent       mouseMove;
    sfMouseButtonEvent     mouseButton;
    sfMouseWheelEvent      mouseWheel;
    sfJoystickMoveEvent    joystickMove;
    sfJoystickButtonEvent  joystickButton;
    sfJoystickConnectEvent joystickConnect;
} sfEvent;

Here is the delphi version of this that I have:

  { TsfEvent }
  TsfEvent = record
    case Integer of
      0: (cType          : TsfEventType);
      1: (size           : TsfSizeEvent);
      2: (key            : TsfKeyEvent);
      3: (text           : TsfTextEvent);
      4: (mouseMove      : TsfMouseMoveEvent);
      5: (mouseButton    : TsfMouseButtonEvent);
      6: (mouseWheel     : TsfMouseWheelEvent);
      7: (joystickMove   : TsfJoystickMoveEvent);
      8: (joystickButton : TsfJoystickButtonEvent);
      9: (joystickConnect: TsfJoystickConnectEvent);
  end;

ctype, and size are returning values, but for some reason key is not. I've checked and rechecked the structure, alignment, etc. Not sure what the problems is at the moment. key.code is always zero but the sfEvtKeyPressed event is returned, just not the key code value. Is there anything wrong with this structure?

[code_glitch]

Hmm, I'm on linux and debugging under wine doesnt really appeal to me. Would it be possible to get the source for a test app of some description? I should have time to play with it tomorrow if you're still having trouble with it.

[drezgames]

Hi, sure here ya go: cfml2_testbed. Thanks. At the moment I am at a lost as to why keyboard event codes are not returning properly. If I set it to some value before the poll event call, afterwards its always set to ZERO (which is sfKeyA in the enum structure). Also included is an updated cfml2.pas file.

UPDATE: Alright, I think I found the problem. Turns out the enum size was causing the problem. It needs to be: {$MINENUMSIZE 4}. So I will get the header fixed up now, make some examples and push up a new version soon.

[code_glitch]

Hey there piradyne - took the liberty of modifying your header so it plays nice on linux and with the default library layout. I stuck in a tar.gz up here: https://www.dropbox.com/s/yiv2r0m13j...csfml_2.tar.gz

I put the testbed program in it too along with the assets it needs. I should point out the .so files in there are for csfml2 for 64 bit gcc. If you're on a 32 bit box - you're going to want to replace 'em for the appropriate versions.

And a quick screenie of everything working more or less as it should: Screenshot-1.jpg

Edit: Almost forgot to look at this keyboard problem... Be right back with an update once I have that nailed

Edit2: Solved it!

type     
  TsfKeyCode = longword;

And in the testbed:

writeln('KeyCode: ',SwapEndian(event.key.code));

It has an offset of 1 but I guess you can't get everything XD

[code_glitch]

So, quick update with everything working... Albeit with a bit of a kludge - if anyone has a way to do this properly please do chime in. What I've done is this:

Header:

function  bad_sfRenderWindow_pollEvent(renderWindow: PsfRenderWindow; event: PsfEvent): Boolean; cdecl; external CSFML2_LIB_GRAPHICS; external name 'sfRenderWindow_pollEvent'; 
function sfRenderWindow_pollEvent(renderWindow: PsfRenderWindow; event: PsfEvent): Boolean; Overload;

And in the implementation section:

function  sfRenderWindow_pollEvent(renderWindow: PsfRenderWindow; event: PsfEvent): Boolean; 
   
begin 
    sfRenderWindow_pollEvent := bad_sfRenderWindow_pollEvent(renderWindow, event); 
    event^.key.code := SwapEndian(event^.key.code) + 1; 
end;

And now the testbed works flawlessly on my system I've bundled it all up so if you're on a 64 bit linux system - see here: https://www.dropbox.com/s/a0x4krmxbd...rdfixed.tar.gz

Having seen the testbed code - I'm quite tempted to pick this up as an API for some really quick n dirty development (ala ludum dare ) nice work piradyne

Edit/Disclaimer: for my 'kludge' to work, 32 bit users may have to change from longword to a 32 bit equivalent. And systems with a different endian-ness may need to remove the swapendian call... But hey - I don't have my username for no reason at all

[drezgames]

Ahh cool. In the updated header I had changed the types to enum and set the min enum size to 4 which solved the keycode issue on my end (at least for delphi). The next problem (there is always a problem, haha) is how Delphi handles function result for a structure. I found this reference:
http://rvelthuis.de/articles/articles-convert.html (go down to the return types section)

If you call any of the routines that return a record value you will find that they do not work.... Arrrrrrrg! I've been trying to sort this out using the advance in that article but to no avail. The problem is that (at least in Delphi XE6) it simply will not let you type cast the Int64 type to anything ... other than a record that just so happens to be the same size as the Int64.... freaking Arrrrrg! So the sfVectorXXX types will work fine using this methods, but any other structure larger than Int64, Delphi will just say "invalid typecast". I have not tested this on any other Pascal compiler so not sure if it will be a problem say on FPC or not. But, code_glitch if you can check this it would be much appreciated.

The only solution that I know of is the change the signature of the routines on the c side. I really do not want to have to do this which then means I have more work to keep them up to date and then the same for all the other platforms. Oh my... what started out a looking like a fast and simple solution is turning into a small nightmare... Such as life however... good times, good times. Haha.

[drezgames]

Alrighty then... looks like I will have to make necessary changes to the function signatures to NOT return c structs. So it's not a simple matter of "hooking" to existing DLLs or just recompiling the CSFML sources from the sfml site. I'm having to make some important changes to the code base to make it all work. It will be a little more time before the latest round of changes are completed... maybe another day or so. Because the DLL is being changed to work better with Pascal, I will rename it to PSFML.PAS. I finally was able to get the OGL spinning cube thingy to work. And now... the mission continues....

code_glitch... thanks bro for your help. Maybe you can help me figure out how to get the code base compiled for Linux and OSX at some point.