Bug: TGB fails to launch on ALL Windows 98, Win ME configs

#1 Win98 and WinME are officially abandoned by Microsoft and Hardware Manufacturers and not any further supported officially anywhere in the world ...

Especially if Win98 and ME did not get the additional packages and updates needed to make it a little more "like XP" the chance you will get anything to run on them goes toward 0.

To make it short: Unless the users do have the unicode patch installed, TGB will fail launching. To get around that, remove unicode support in the solution and rebuild the program for those machines with own settings to make them "stone age compliant".

#2 Unfortunatelly, the distribution portals are asking for games that run on Vista and every Windows before and simply not accepting those that not comply with this, meaning any developer using non-Pro edition will have a lot of closed doors.

#3 I'm not here to defend Win 98 and Win ME - they're crappy and old, and I came face to face with that in testing. It's arguable which blows more, Win 98 or Vista. Cancel or Allow? Allow...

However TGB ran well with Rack Em' Up. Well. Smoothly, very smoothly. As long as the older machines have good hardware and enough RAM, they should be supported if it's possible, and by the fact Rack Em Up ran so well, it's obvious that it is possible.

I am assuming that since Win 98 and ME support are claimed on the TGB page, that perhaps the engine just hasn't been tested on those configs lately. It'd be difficult to find Win 98 boxes in any developer's shop so I understand, we don't have em either.

Since we do have Pro and are prepared to recompile the engine, yet not wanting to waste time on it, is the post here the way to do it, in its entirety?

http://tdn.garagegames.com/wiki/Torque/Code/MSLU

Thanks

K.

PS. Wanted to mention that overall, the TGB engine is well compatible with just about ALL new configs out there - no major issues with Win XP or Vista with hardware cards. There are some troublesome onboard Intel chipsets, but generally - happy with compatibility results given TGB's awesome power.

#4 Some work went into getting Rack 'Em Up running on Win98 and WinME machines. I would say the majority of that was in OpenAL and our D3D wrapper. So I would definitely look there first. Particularly with OpenAL since they have 'officially' dropped support for the platform altogether. The unicode work described on the page you linked is important as well.

So the first thing I would do is get the Unicode linked in correctly, though it isn't strictly important. I was able to get the engine running on a dev Win98 machine without those changes, but every machine is different.

The next thing to tackle would probably be OpenAL. If you want to see if OpenAL is a cause of the engine not running, I would find where it attempts to load the OpenAL library and comment it out to see if this will get the engine running on your Win98 box. The further back you go in OpenAL versions the more likely that driver will work on Win98 but the buggier it will be. Eventually I ended up grabbing the OpenAL source trunk and compiling the driver so I could debug what the problem was and found that the driver was failing in Win98 when attempting to load EAX functionality. For Rack 'Em Up, I believe we shipped with a custom OpenAL version that disabled the EAX functionality but I don't remember exactly. If you are on the OpenAL mailing list this should be mentioned by several people in the archives and Creative developers were aware of the issue at the time, but I do not know if they have put a proper fix in place. The best thing to do would be to grab the latest source and find out.

The D3D wrapper problems are due to the wrapper not properly checking D3D error states correctly when filling or locking a vertex buffer, so these should be mostly easy fixes if you know what you are doing. This happens for instance, when the window goes from windowed to full screen, or a screen savor appears, etc. Sometimes it even happens when the device is initializing. There was some hackery involved however, in relaying that error state back to the engine so that it could reset the device. I ended up hijacking one of the unused OpenGL -> D3D API calls that was not implemented in our D3D wrapper to do this (Luckily one was available that returned a bool). I'll share that code with you below:

void D3DDevice::swapBuffers()
{
   if( smInErrorState )
   {
      // hijacked CopyContext API call in D3D wrapper
      smInErrorState = dwglCopyContext(NULL, NULL, NULL);
      if( !smInErrorState )
         Video::reactivate(true);
      else
         return;
   }
   else
      smInErrorState = dwglSwapBuffers( winState.appDC );
}

I also had to change the D3D wrapper SwapBuffers to actually return something other than True all the time ;) Again this involved noting in the wrapper when a Lock or Fill failed.


I'm not sure how many of these changes made it back into the TGB source from Rack 'Em Up but hopefully that gives you some ideas of where to look. The problems to get Win98 up and running aren't impossible, but they are difficult ones. Some of our changes, like the D3D ones noted above, probably didn't make it back into our core source repos because they are fixes that happen to work but aren't necessarily the best thing for all people.

#5 >I would say the majority of that was in OpenAL and our D3D wrapper.

Under the gpl, you're required to make the OpenAL changes available.

>I believe we shipped with a custom OpenAL version that disabled the EAX

That would be a work dervied and distributed, therefore you must distribute the modifications.

#6 @David
Aren't the Apple and Creative licenses different than the LGPL? I don't know what versions are shipped with Torque. It seemed like they were quite a while ago. Creative had their own license for the libraries.

Of course, if the wrapper was changed to not support EAX but the library was not, then it wouldn't fall under the LPGL terms of release.

Regardless, it would be a nice resource for developers to have, even if it is extremely particular to the project at hand.

#7 >Aren't the Apple and Creative licenses different than the LGPL?

I think you're a little confused. OpenAL is a cross-platform audio library - which GG uses for all platforms. Apple and Creative doesn't apply here at all. It's not a "wrapper" - the wrapper he's talking about is the d3d stuff.

>I believe we shipped with a custom OpenAL version

Here's the key phrase. If you do indeed ship a custom version of a GPLed (or LGPL) library or program, you have to make the changes available. Which is really the whole point of using GPLed projects.

#8 I know, but the Creative license has absolutely nothing about the LGPL included with it, which was where my question came from. I know that OpenAL is a cross-platform library that Loki created and released under the LGPL when it died. But I thought that Creative, who was a partner on the Windows side, had a share in the development. I know they and NVIDIA (under the LGPL) are the primary Windows versions. But I didn't know if the LPGL was straight across the board since it's not mentioned anywhere at Creative. It's only the platform page which notes where the LPGL seems to apply to which version. I'm not exactly sure what support options came out of the Loki fallout.

I just didn't know if it was across the board or if other, continued support companies, had different licenses (I didn't notice anything about the LGPL on Apple development site either, which prompted my question).

But it is definitely possible that I'm confused about the wrapper (as well as everything else, which is why I was asking about the license). I was thinking of TGE's GL wrapper for DirectX rather than the LGPL DirectX wrapper from the OpenAL site. Basically, the hooks into the OpenAL library (the reason that it was LGPL was because it needed to plug into proprietary code for Loki to port traditional closed-source Windows games to Linux).

Regardless, it would be a nice resource. I haven't looked at the audio code enough to know how it plugs into OpenAL, uses OpenAL, or wraps to the platform layer to access DirectX.

#9 So we're either going to dive in and attempt these uh, "hackarounds", or perhaps sub-contract this potentially sticky engine modification to an expert at such compatibility.

Can anyone recommend a top-notch best of the best 98/ME workaround engineer? I am looking for someone really good at the low level platform engineering for specialized contract engineering such as this.

Thanks for the details, y'all. Not giving up on the 98 until 2008!

#10 First step to making it easier and working out of the box is adding the "you need to install Unicode patch from microsoft site, found at: **** if you are using Windows 98 / ME" to your download page.

That would already remove one of the core problems of those stone age OS.


Sidenote: Systems not capable to run XP most likely won't be able to run TGB at an acceptable performance as well due to the 3D card requirement and the RAM requirements. Users not willing to go to XP (although they have capable machines) for some other reasons are the only potential costumers for TGB.