Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SAS~Storebror]

To circumvent the latter, we could decide to introduce a new method just for IL-2 GE, let's say __SAS_openf, which would be __stdcall and would map to the right calling convention inside wrapper.dll internally.
That way IL-2 GE can become cross compatible for all game versions again, simply by replacing all calls to __SFS_openf by the newly introduced __stdcall __SAS_openf.

To illustrate what I've been talking about, the next wrapper will have the following exports:

Code: [Select]

Exports Table

  Name:            wrapper.dll
  Characteristics: 00000000
  TimeDateStamp:   FFFFFFFF
  Version:         0.00
  Ordinal Base:    00000001
  # of Functions:  00000002 (2)
  # of Names:      00000002 (2)

  Entry Pt  Ordn  Name
  --------------------
  00003B00     1  __SAS_openf@12
  000039C0     2  __SFS_openf
"__SAS_openf@12" is a standard conformant replacement for the "__SFS_openf" method and as such, it's a "C" type export with __stdcall calling convention, hence the decorated name.
It will always be __stdcall, no matter which base game version is being used, whereas the calling convention for "__SFS_openf" depends on whether it's the "pre-4.15" wrapper (__cdecl) or the "4.15+" (__stdcall) wrapper.
In IL-2 GE you would add a few new declarations...

Code: [Select]

typedef int __stdcall SAS_openf_T(unsigned __int64 hash, int flags);
SAS_openf_T *g_sas_openf_func = nullptr;
g_sas_openf_func = (SAS_openf_T*) GetProcAddress(m, "__SAS_openf@12"); // no asserts here, method might not exist in old wrapper.dll versions!...and change two methods accordingly...

Code: [Select]

int open(const char *filename)
{
  if (g_sas_openf_func) return g_sas_openf_func(sfs::getHash(filename), 0); // call new "routing" method __SAS_openf if available
  return g_openf_func(sfs::getHash(filename), 0); // fallback in case old wrapper.dll was loaded
}

int __cdecl wrap_SFS_openf(unsigned __int64 hash, int flags)
{
  if (g_sas_openf_func) return g_sas_openf_func(hash, flags); // call new "routing" method __SAS_openf if available
  assert(g_openf_func); // fallback in case old wrapper.dll was loaded

//   auto it = g_redirections.find(hash);
//   if (it != g_redirections.end())
//     hash = it->second;

  return g_openf_func(hash, flags);
}

Mike

[SAS~Storebror]

*bump*
Merge request created accordingly


Mike

[slibenli]

Thanks!  I'll take a look at it tomorrow.

[SAS~Storebror]

One more thing: https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/java_interface/interface.cpp#L119

You're trying to find a "HotKeys" class here which doesn't seem to exist in recent IL2GE versions anymore, at least my 0.2.0 doesn't seem to ship with any Java stuff at all.
Consequently this generates a Java Exception:

Code: [Select]

[2023-01-28 11:17:21.251 UTC +1] dT:    0 java.lang.NoClassDefFoundError: com/maddox/il2ge/HotKeys
[2023-01-28 11:17:21.252 UTC +1] dT:    0 at com.maddox.il2.engine.RenderContext.Begin(Native Method)
[2023-01-28 11:17:21.252 UTC +1] dT:    0 at com.maddox.il2.engine.RenderContext.activate(RenderContext.java:181)
[2023-01-28 11:17:21.253 UTC +1] dT:    0 at com.maddox.il2.game.Main3D.beginApp(Main3D.java:1271)
[2023-01-28 11:17:21.253 UTC +1] dT:    0 at com.maddox.il2.game.Main3D.beginApp(Main3D.java:1255)
[2023-01-28 11:17:21.254 UTC +1] dT:    0 at com.maddox.il2.game.MainWin3D.beginApp(MainWin3D.java:180)
[2023-01-28 11:17:21.254 UTC +1] dT:    0 at com.maddox.il2.game.Main.exec(Main.java:364)
[2023-01-28 11:17:21.254 UTC +1] dT:    0 at com.maddox.il2.game.GameWin3D.main(GameWin3D.java:235)
Not that it would seem to cause any harm, but if this indeed is just some code legacy, you might as well want to get rid of it.
No Merge Request for this as I'm unsure as to whether this was intentional.


Mike

[slibenli]

Thanks!  I'll take a look at it tomorrow.

Looks good, but I have come across another problem.
https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/sfs/sfs.cpp#L64
I'm using my own SFS_openf wrapper (which wraps around the SAS wrapper).
While It currently does nothing, the intended purpose is to save memory by feeding small dummy terrain textures to the IL-2 engine.
So I would need to supply two versions of that anyway and figure out which is the right one. Is there a good way to query the version via C++ code? Ideally wrapper.dll would export a method like bool is_SFS_openf_stdcall().

One more thing: https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/java_interface/interface.cpp#L119

[...]

You're trying to find a "HotKeys" class here which doesn't seem to exist in recent IL2GE versions anymore, at least my 0.2.0 doesn't seem to ship with any Java stuff at all.
Not that it would seem to cause any harm, but if this indeed is just some code legacy, you might as well want to get rid of it.
No Merge Request for this as I'm unsure as to whether this was intentional.

It's not legacy but optional. I haven't decided yet how to ship those classes - they're designed to be independent of il2ge releases and could also be shipped with modpacks.
Here's the code: https://gitlab.com/vrresto/il2ge_java_interface.
The class GraphicsExtender is auto generated from include/il2ge_java_interface/interface.h and the swig/*.i|*.i.in.

[SAS~Storebror]

I have come across another problem.
https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/sfs/sfs.cpp#L64
I'm using my own SFS_openf wrapper (which wraps around the SAS wrapper).

See reply #1176.
My Merge Request includes a new version of the wrapped method, which dynamically calls either the "routing" method or the plain old __cdecl one, depending on availability of a "routing" method in wrapper.dll.
That way IL-2 GE will work with any 4.x Selector Version (no routing method included) and with any 5.1+ version (routing method available). Only 5.0 would cause crashes, but that version has been superseded meanwhile and never made it into any other modpack but UP 3.4 P2 HF 11, which in turn is superseded by HF 12 so we've got that covered, too.

Is there a good way to query the version via C++ code?

You mean a way to find out whether an exported method is __cdelc or __stdcall?
No way.
Even the highest sophisticated decompilers (IDA Pro anyone?) are just doing guesswork.
Even myself is doing guesswork here, based on the first few things done in assembler code at method start.

Ideally wrapper.dll would export a method like bool is_SFS_openf_stdcall().

That method would not exist in old wrapper.dll versions so you'd be back at square one.
For now, starting with Selector 5.1 we have "__SAS_openf@12" which is a "routing" method with __stdcall declaration, and if that method exists, you can always call it and it will take care of further mangling calling conventions if required - internally inside wrapper.dll.
That's what my Merge request was all about.
Check for presence of that method and use it if it exists, otherwise fall back to calling the good old __cdecl "__SAS_openf" from Selector 4.x wrapper.dll.

It's not legacy but optional.

Okay so we should just not bother about the Exception caused then.


Mike

[slibenli]

I have come across another problem.
https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/sfs/sfs.cpp#L64
I'm using my own SFS_openf wrapper (which wraps around the SAS wrapper).

See reply #1176.
My Merge Request includes a new version of the wrapped method, which dynamically calls either the "routing" method or the plain old __cdecl one, depending on availability of a "routing" method in wrapper.dll.
That way IL-2 GE will work with any 4.x Selector Version (no routing method included) and with any 5.1+ version (routing method available). Only 5.0 would cause crashes, but that version has been superseded meanwhile and never made it into any other modpack but UP 3.4 P2 HF 11, which in turn is superseded by HF 12 so we've got that covered, too.

I think we're talking past each other. I'm talking about the calling convention of my wrap_SFS_openf method itself, not of the method it calls. I'm injecting my method by hijacking GetProcAddress - see here:
https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/main/main.cpp#L250

Is there a good way to query the version via C++ code?

You mean a way to find out whether an exported method is __cdelc or __stdcall?
No way.
Even the highest sophisticated decompilers (IDA Pro anyone?) are just doing guesswork.
Even myself is doing guesswork here, based on the first few things done in assembler code at method start.

No, I meant querying the Il-2 version.

[murkz]

Thank you slibenli, my IL2 has never looked so beautiful, for that I am very grateful.

It amazes me how much love and dedication there is for this wonderful simulation, without modders this game would be a nice old game. Now it is simply on point and very relevant.

jeff

[Dimlee]

Thank you slibenli, my IL2 has never looked so beautiful, for that I am very grateful.

It amazes me how much love and dedication there is for this wonderful simulation, without modders this game would be a nice old game. Now it is simply on point and very relevant.

jeff

Nice pictures. The first one - The Black Death track, I assume? What was FPS, if you remember?

[murkz]

Thank you slibenli, my IL2 has never looked so beautiful, for that I am very grateful.

It amazes me how much love and dedication there is for this wonderful simulation, without modders this game would be a nice old game. Now it is simply on point and very relevant.

jeff

Nice pictures. The first one - The Black Death track, I assume? What was FPS, if you remember?

Just checked, so as I could be correct and not guess. At that exact moment my frames are 36fps @2880*1620

[Graycap]

Thank you slibenli, my IL2 has never looked so beautiful, for that I am very grateful.

It amazes me how much love and dedication there is for this wonderful simulation, without modders this game would be a nice old game. Now it is simply on point and very relevant.

jeff

Could you please specify your installation?

I mean which mods are on ?

Thanks!

[ZtheE]

Thank you slibenli, my IL2 has never looked so beautiful, for that I am very grateful.

It amazes me how much love and dedication there is for this wonderful simulation, without modders this game would be a nice old game. Now it is simply on point and very relevant.

jeff

Could you please specify your installation?

I mean which mods are on ?

Thanks!

Looks like Random Skies and GE to me. But yeah Jeff, what mods do you have to make your install look so darn good?