Topic: How was SFC2:CE made compatible with Windows 8? (Read 3567 times)

JanB · « **on:** March 06, 2015, 08:37:43 pm »

Like the title says I want to know what the people behind the community edition did to make it compatible with Windows 8. I found I can run SFC3 without even using compatiblity mode on Windows 7 64bit, but it simply won't run on Windows 8/8.1 (black screen, and yes I tried all the usual tricks). Windows 8 should only be a small evolution from Windows 7, the 534_b patch for SFC3 made it run off of DX9 and it's simply newer than SFC2. Yet, SFC3 doesn't run on Win 8 while SFC2:CE does. In light of all the recent hex editing and cracking of the SFC games lately I was wondering if the people behind the community edition could give some pointers on what they did to make CE Win 8 compatible (and I'm hoping it would be easier to pull of for SFC3).

So tl,dr: would the people involved in the making of SFC2:CE give some hints on how they made that game Win 8 compatible (and perhaps indicate which of these steps would not be necessary for SFC3, which is a newer game)?

Strat · « **Reply #1 on:** March 07, 2015, 03:01:05 pm »

Hi JanB,

I received your PM. So glad to hear things are active here!

The reason we were able to fix SFC2 was because we had the source code to fix it. The problems were not something a 'compatibility mode' could fix. There changes needed to the actual code itself.

In the case of SFC3- I'm sorry to say I've never played it. I was not aware SFC3 didn't work on Windows 8. From your description, it is not exactly the same compatibility problem as we had with the original SFC2. As far as I can remember, it didn't have graphics problems like that.. But my memory is very old... So what I'm saying is, I can't exactly comment on what you are seeing, although it sounds like you already did some homework.

What I can contribute is.. During working on CE, I did see a similar problem to what you describe while working on code. As a tiny background, the code we received was not exactly like what SFC 2 was in last release. The code for SFC2 we were given had sections of newer 'never before seen' code and original code. In what we had been given there was a section for this version of SFC2 to use the same graphics sub-system as SFC3. It didn't work out of the box, and revealed itself as a black screen but visible mouse, etc, similar to what you describe. My fix was to rewrite the affected section to NOT use the SFC3 graphics subsystem, and connect to DirectX in Windows directly, which was how the original SFC2 was written. But you can tell something else from all this... In SFC 3.. The mouse.. it renders directly to Windows... the rest of the screen.. it renders through its own graphics library.

Now, I don't say I know whats wrong with SFC3, because I haven't played it. But I know a tiny bit about how it connects to Windows to display graphics. Based on what I had experienced before, I would say its showing that same old thing. Where the game connects directly to Windows DirectX, it is able to work (mouse), but where it attempts to use its own graphics library (the user inferface) it fails. I would suppose the problem lies in the code of SFC 3's graphics library.

And unfortunately, we don't have the code for SFC3. So we can't rewrite it. And as to what changed in Windows as to why Win 8 doesn't like it anymore.. I don't know, I'm sorry.

If I was really dedicated too all this.. There might be clues to make a new graphics library for SFC3. Recall that the code we were given had incomplete pieces of it? Well that could give clues to just make a new one and replace the library SFC3 uses... Buts that's a lot of work...

I'm sorry I'm not more helpful.. When it came to SFC2, no compatibility mode ever fixed our problems. They were not fixed until we got source code. It may be that SFC3 succumbs to the same fate.

JanB · « **Reply #2 on:** March 07, 2015, 03:32:40 pm »

Thank you for your quick reply. So who would you say the problem lies in one of the graphics DLLs of the game (I'm assuming that would be GUIR.dll) or does the main .exe have something to do with it as well?

Strat · « **Reply #3 on:** March 07, 2015, 03:39:54 pm »

Hi Jan,

SFC2 handled all graphics in the EXE. SFC3 has it all in a DLL (minus the mouse, right?). The code we received had begun to migrate SFC2 to graphics outside the EXE to a DLL- just as SFC3 was done. However, when I tried to write SFC2:CE to use the DLL included with SFC3.. Well, I just never got it to work. They were compiled too differently. So failed back to just opening a DirectX object right in the EXE of SFC2:CE. Which is probably better because I was able to upgrade the API...

TO answer your question, though, yes, SFC3 is using a DLL. Which one, I cannot remember. EDIT: But it is in the local game directory.

EDIT2:

I believe the problem lies in the SFC:3 DLL.

The code we received for SFC2 had a call to a graphics DLL, but not did not include the code for the DLL. The original game had no graphics DLL. So we could see the beginning of the SFC3 way of doing things, but we could not actually see how the DLL worked inside. That is why I tried to use the DLL that came with SFC3- but that failed. So I wrote it back to work without a DLL.

All we know is that this DLL initializes graphics, weather it was DirectX, OpenGL, or whatever other options there were back then. And the main EXE, as I understood it, only called to it once, to initialize whatever graphics API the DLL opened for it.

JanB · « **Reply #4 on:** March 07, 2015, 03:57:58 pm »

All the relevant (graphics) DLLs are in the components folder, there's "GUIR.dll", "TAL3DEngineR.dll", "ModelRenderer.dll" and a few others, it seems logical that GUIR.dll handles the menus. It's only 700kb and much of it is empty or the same byte repeated thousands of times. Does CE have an equivalent dll?

EDIT: I cannot find a "SFC3.dll" file and cannot remember ever having seen it, perhaps you had a bundled version of the dll files that are in the components folder.

Strat · « **Reply #5 on:** March 07, 2015, 04:02:59 pm »

No, CE has no DLL's like that.

JanB · « **Reply #6 on:** March 07, 2015, 04:24:51 pm »

Ugh, this is so frustrating. It's probably something really small since there are no issues with Win 7, and no error messages, freezing or crashing under Win 8.1. Also many other DX9 and even DX8 games function under Win 8.1. It's probably some needle in a haystack...

P.S. playing around with Wine (latest beta version) under Ubuntu I got the same behavior from SFC3 as under Win 8.1...

JanB · « **Reply #7 on:** March 07, 2015, 04:39:29 pm »

Eureka!

I got SFC3 to work under Win 8.1, using windowed mode and a bunch of downloaded dll files! I'll try to figure out the precise recipe now.

Strat · « **Reply #8 on:** March 07, 2015, 04:46:15 pm »

Awesome!!!

JanB · « **Reply #9 on:** March 07, 2015, 05:05:25 pm »

Ok, it seems to work with a native D3D8.dll file ( http://www.dll-files.com/dllindex/dll-files.shtml?d3d8 ). You have to place that in the game's main directory (not in components). Then run the game in windowed mode by opening sfc.ini and setting "windowed=1". No compatibility settings are necessary. Do note that placing D3D8.dll in the game's main directory can cause an error when the operating system is not Windows 8.1.

News: