Steam wrapper, exploring options

[klausvdl]

Ok, first of all: it is possible to make use of Steam's callback mechanism.

The tricky thing is that you have to pass a C++ class as an argument. So you have to mimic this class by the means of Pascal. This requires defining a record for example and arranging it's internals. It needs a tabel of virtual functions and some parameters. Also you have to mimic the calling convention thiscall which requires to read out the ECX register by an inline asm instruction. Fortunately that C++ class is not too big.

Moreover I found an old discussion on Steam dev forums where two guys worked out that stuff, one of them Relfos.

It appears in Relfos' unit SteamCallback.pas (Object Pascal) and although his whole project is based on Steamworks.NET (CSteamworks.DLL) that callback handling part doesn't really need that, unless I am mistaken.

As for myself I don't use classes in my implementation. By now I'm using the callback mechanism only for one thing: every time the player activates/deactivates the Steam overlay (Shift+Tab) I pause/unpause the game. Some questions remain regarding the handling of calling conventions on CPU64 and/or Linux etc.
Now I should be able to use common Steam features (achievements, leaderboard, save files to cloud etc.) We'll see about that.

If anyone wants to see plain Pascal code then I can provide another listing. Otherwise I'm pointing to Relfos' unit.

[Chebmaster]

Maybe this is worth worth feature request for adding thiscall convention to future fpc?

P.S. and

  Asm
    mov myself, ECX;
End;

should be

{$ifndef cpu64}
  Asm
    mov myself, ECX;
  End['ecx'];
{$endif}

[klausvdl]

I guess it's not clearly readable (nested), but Relfos did it just the other way round:

{$IFDEF CPU64}
...
{$ELSE}
  ...
  Asm
    mov myself, ECX;
  End;
  ...
{$ENDIF}

Hm, adding that calling convention thiscall would probably make little sense without additional mechanisms for accessing C++ classes. Would be nice if one could declare a whole pascal class as "cppdecl" or whatever, so that somehow the linker would be able to access the C++ classes symbols/properties within a DLL ...