-
There seems to be an uptick in Political comments in recent months. Those of us who are long time members of the site know that Political and Religious content has been banned for years. Nothing has changed. Please leave all political and religious comments out of the forums.
If you recently joined the forums you were not presented with this restriction in the terms of service. This was due to a conversion error when we went from vBulletin to Xenforo. We have updated our terms of service to reflect these corrections.
Please note any post refering to a politician will be considered political even if it is intended to be humor. Our experience is these topics have a way of dividing the forums and causing deep resentment among members. It is a poison to the community. We appreciate compliance with the rules.
The Staff of SOH
Compiling FS98 / CFS Gauges
- Thread starter Ivan
- Start date
Thanks Shessi, but what I am trying to do is just compile two gauges to start. I already have enough tools to put them into a panel once I have the gauges. Neither of the tools you listed will actually build .gau files from code according to their documentation.
At the moment, I have been successful on a Windows Vista machine in doing the compile using MinGW, but I can't install this on a Windows 98 machine and the gauges resulting from the Vista machine will crash CFS on the Windows 98 system.
- Ivan.
At the moment, I have been successful on a Windows Vista machine in doing the compile using MinGW, but I can't install this on a Windows 98 machine and the gauges resulting from the Vista machine will crash CFS on the Windows 98 system.
- Ivan.
Moparmike
Administrator
Ivan,
It's been many years since I've built any FS98 gauges and I do remember a few little quirks if you're using the MinGW or Borland compilers. I use MS Visual Studio (I think I was using version 5.x back then).
This was long before the days of 64-bit OSes or Vista/7/8 so I don't know of any issues with building FS98 gauges on those operating systems. Is your Vista machine 64-bit? If so, that would be the hangup I suspect but I'm not positive. I think there should be some project settings you could use to allow the GAUs to be used on a Win98 machine but I don't know for sure.
You should be able to find an older version of the MinGW compiler that works on a Win98 machine. I did use it on 98 back when I was just starting on the gauges.
I know there have been a couple of guys using the MS Visual Studio Express IDE for gauges, but this was for FS2000 and newer stuff. This is the free for non-commercial use version and does have some limitations.
http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#DownloadFamilies_4
Sorry, I'm not of much help.
It's been many years since I've built any FS98 gauges and I do remember a few little quirks if you're using the MinGW or Borland compilers. I use MS Visual Studio (I think I was using version 5.x back then).
This was long before the days of 64-bit OSes or Vista/7/8 so I don't know of any issues with building FS98 gauges on those operating systems. Is your Vista machine 64-bit? If so, that would be the hangup I suspect but I'm not positive. I think there should be some project settings you could use to allow the GAUs to be used on a Win98 machine but I don't know for sure.
You should be able to find an older version of the MinGW compiler that works on a Win98 machine. I did use it on 98 back when I was just starting on the gauges.
I know there have been a couple of guys using the MS Visual Studio Express IDE for gauges, but this was for FS2000 and newer stuff. This is the free for non-commercial use version and does have some limitations.
http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#DownloadFamilies_4
Sorry, I'm not of much help.
Hi MoparMike,
Thanks for the suggestions. I have a Vista Home Edition which is 32 bit. I also do some C Programming for utilities on the Windows 98 machine which is what I use for a CFS development machine. I figure if it will run on this old machine, it will run anywhere. The compiler I have been using is Delorie's GnuC. It works fine for a OS independent project such as manipulating binary or text files, but doesn't have the include files and libraries for developing Windows DLLs. There isn't a version of Delorie GnuC for Vista.
The funny thing about MinGW and working with the Gauge SDK is that the header files included by <windows.h> have type definition conflicts with those in the SDK from Microsoft. With a successful compile, the gauge works on Windows 2000, but crashes the sim on Windows 98.
I figure others have obviously done this, so it must be possible. To start, I am trying for a twin engine Tachometer and Manifold Pressure gauge.
Would appreciate any other ideas for a workable combination of compilers / libraries.
- Ivan.
Thanks for the suggestions. I have a Vista Home Edition which is 32 bit. I also do some C Programming for utilities on the Windows 98 machine which is what I use for a CFS development machine. I figure if it will run on this old machine, it will run anywhere. The compiler I have been using is Delorie's GnuC. It works fine for a OS independent project such as manipulating binary or text files, but doesn't have the include files and libraries for developing Windows DLLs. There isn't a version of Delorie GnuC for Vista.
The funny thing about MinGW and working with the Gauge SDK is that the header files included by <windows.h> have type definition conflicts with those in the SDK from Microsoft. With a successful compile, the gauge works on Windows 2000, but crashes the sim on Windows 98.
I figure others have obviously done this, so it must be possible. To start, I am trying for a twin engine Tachometer and Manifold Pressure gauge.
Would appreciate any other ideas for a workable combination of compilers / libraries.
- Ivan.
Update - Partial Success
Hello All,
Since the last post in this thread, many changes have come about.
The Vista Computer that I was using died at the end of 2014.
It was replaced with a Windows 8.1 machine in early 2015.
My Daughter's computer needed to be replaced last year.
When my Daughter got her new machine, I needed to install a copy of MS Office for her.
I knew I had the installation disks and license key for the old Vista machine and it was never going to be used again.
The problem was to find the installation media.....
I went through my stash of old installation media and found several complete versions of Microsoft Visual Studio.
I had never used them because I never had a need for them.
In doing a little checking online, I found that I had a version that was suitable for Windows 98.
Unfortunately, that version did not install correctly (probably because of a lack of available space on my C: drive).
(Why does everything want to install on the C: drive? I have plenty of space on other drives.)
In poking around a little further, I found that I also had a full version of Visual Studio 2005 as well.
It seems to work on my Windows 8,1 machine even though the Compiler is 32-bit.
Ever nicer is the fact that the code it generates runs just fine on my old Windows 98 SE development machine.
My belief was that Microsoft's SDKs should be pretty compatible with their own compilers.
It turned out that I wasn't entirely correct but it was close. There was much less incompatibility with Visual C++ than with any of the other compilers I had tried.
At this point, I still cannot get everything in the FS98 SDK to work, but most of it does and from them, I have been able to build a couple Tachometers and Manifold Pressure Gauges.
There are still issues though:
The Tachometers seem to work well enough with AIR files derived from the stock P-51D but not with some other AIR files.
The Manifold Pressure variable in the FS98 SDK only reads up to about 65 inches Hg.
Some WW2 Engines ran at much higher boost settings.
I have also managed to build a N2 Tachometer for Jet Engines with the same process.
At least this is a start. Hopefully I can work out the remaining issues.
The limit now is my own lack of knowledge.
- Ivan.
Hello All,
Since the last post in this thread, many changes have come about.
The Vista Computer that I was using died at the end of 2014.
It was replaced with a Windows 8.1 machine in early 2015.
My Daughter's computer needed to be replaced last year.
When my Daughter got her new machine, I needed to install a copy of MS Office for her.
I knew I had the installation disks and license key for the old Vista machine and it was never going to be used again.
The problem was to find the installation media.....
I went through my stash of old installation media and found several complete versions of Microsoft Visual Studio.
I had never used them because I never had a need for them.
In doing a little checking online, I found that I had a version that was suitable for Windows 98.
Unfortunately, that version did not install correctly (probably because of a lack of available space on my C: drive).
(Why does everything want to install on the C: drive? I have plenty of space on other drives.)
In poking around a little further, I found that I also had a full version of Visual Studio 2005 as well.
It seems to work on my Windows 8,1 machine even though the Compiler is 32-bit.
Ever nicer is the fact that the code it generates runs just fine on my old Windows 98 SE development machine.
My belief was that Microsoft's SDKs should be pretty compatible with their own compilers.
It turned out that I wasn't entirely correct but it was close. There was much less incompatibility with Visual C++ than with any of the other compilers I had tried.
At this point, I still cannot get everything in the FS98 SDK to work, but most of it does and from them, I have been able to build a couple Tachometers and Manifold Pressure Gauges.
There are still issues though:
The Tachometers seem to work well enough with AIR files derived from the stock P-51D but not with some other AIR files.
The Manifold Pressure variable in the FS98 SDK only reads up to about 65 inches Hg.
Some WW2 Engines ran at much higher boost settings.
I have also managed to build a N2 Tachometer for Jet Engines with the same process.
At least this is a start. Hopefully I can work out the remaining issues.
The limit now is my own lack of knowledge.
- Ivan.
Moparmike
Administrator
I don't have a copy of the FS98 gauges.h file anymore (not sure what happened to my old FS98 SDK pack), so I'm kinda working from memory and the FS2k gauges/h file that I used to use for CFS2.
If you've still got my email address, can you send me a copy of the FS98 SDK or at least the gauges.h file?
-Which tach/rpm variables are you using? It sounds like you're using the CFS1 and newer "RECIP_ENGINE1_ENGINE_RPM". These variables work for CFS1 and newer airfiles but not FS98 airfiles.
I honestly don't remember the variable for the FS98 rpm. I think that the RPM_SCALER variable is the one that reads the actual prop rpm.
" ENGINE1_RPM_SCALER, // *16384 gives actual prop rpm in dx (= 65535 for jets)" is what I have for notes in my CFS2 gauges.h file.
-The FS98 manifold pressure is indeed limited to 64inHg.
" UINT16 manifold_pressure; // manifold pressure (0-65535=>0-64)"
It's an unsigned 16-bit integer, 65535 being the upper limit which is hard-coded into the sim DLLs as 64inHg. Unfortunately, that's what we've got to work with.
If I'm reading my notes correctly, if you use the CFS1-newer "RECIP_ENGINE1_MANIFOLD_PRESSURE", I have a comment from Jerry Beckwith that 70.72636 = 1inHg. I think those variables are also UINT16 with 65535 as a maximum value but I'm not positive.
-I have never monkeyed with making gauges for the jet engine airfiles. Not sure if any quirks on them.
Double-needle gauges shouldn't be a problem with an FS98 gauge. I'm sure I've seen them before but I've never built one. I would think that you would just need to build your source .c file with the elememts drawn in the correct order. NEEDLE1 MAKE_NEEDLE macro, then NEEDLE2's MAKE_NEEDLE macro, then your BACKGROUND's MAKE_STATIC macro.
Also, don't share resources in your .rc file between the two needles. You can call the same bitmap but give each macro's resource a different entry.
Hope that helps.
Thanks MoparMike,
Actually what I am actually trying to build is a set of CFS1 multi engine gauges.
The problem is that I don't believe a real CFS1 SDK was ever released.
Yes, there are a couple ZIP files out there, but they look like just inter-gauge communications examples.
If you know differently, please point me at the source.
My belief is that with CFS, Microsoft's "SDK" was ESP 1.0,
Although I have seen it described on the MSDN site, I have not seen a place to download it.
The FS98 SDK does not actually have a RECIP_ENGINE_RPM Token.
I believe they use either the N1 and N2 Tokens possibly with another token (SCALER???) to set the value.
My issue is that when I tried that, I could not get the correct output values.
Instead, what I did was to take the N2 Token and put in a constant multiplier to get the value to match the RPM.
It works great (within 1 RPM) but it only works with certain AIR files.
Now here is the really funny thing:
The CESSNA RPM gauge from FS98 reads high but the EXTRA300 RPM gauge reads correctly and it was also for FS98, so I am presuming that if a FS98 EXTRA300 can do it, it was probably built with the FS98 SDK and the correct combination of tokens will work.
As for Jet gauges, I programmed one (actually a pair) for a friend. I actually have no interest there.
My goal is still a set of multi engine and other assorted gauges for CFS1.
If you know of a better solution than the FS98 SDK, please let me know.
Thanks.
- Ivan.
Actually what I am actually trying to build is a set of CFS1 multi engine gauges.
The problem is that I don't believe a real CFS1 SDK was ever released.
Yes, there are a couple ZIP files out there, but they look like just inter-gauge communications examples.
If you know differently, please point me at the source.
My belief is that with CFS, Microsoft's "SDK" was ESP 1.0,
Although I have seen it described on the MSDN site, I have not seen a place to download it.
The FS98 SDK does not actually have a RECIP_ENGINE_RPM Token.
I believe they use either the N1 and N2 Tokens possibly with another token (SCALER???) to set the value.
My issue is that when I tried that, I could not get the correct output values.
Instead, what I did was to take the N2 Token and put in a constant multiplier to get the value to match the RPM.
It works great (within 1 RPM) but it only works with certain AIR files.
Now here is the really funny thing:
The CESSNA RPM gauge from FS98 reads high but the EXTRA300 RPM gauge reads correctly and it was also for FS98, so I am presuming that if a FS98 EXTRA300 can do it, it was probably built with the FS98 SDK and the correct combination of tokens will work.
As for Jet gauges, I programmed one (actually a pair) for a friend. I actually have no interest there.
My goal is still a set of multi engine and other assorted gauges for CFS1.
If you know of a better solution than the FS98 SDK, please let me know.
Thanks.
- Ivan.
Ali Cat
Charter Member
I have. through many gauges (all CFS2), come to gravitate to gcc. Open source and of course free but that is not the reason I have moved to it. One of the difficulties of using MS stuff is it a moving target. As an example, I have actually tried with the latest version of Visual Studio to compile gauges and it does not work (at least on this old rig). My take, and I could be wrong, is that it is just too far in the past and MS just does not support it anymore.
All of that said, using gcc can be frustrating. The best of that world is perfect and always works. The documentation, however, is often very confusing and shall I say cryptic? It took a while but here is the bat file I have used to test making a gauge with just a text editor and gcc.
gcc -c sdktest.c
windres --input=fuelbmps.rc --output=fuelbmps.output
gcc -shared -o sdktest.gau sdktest.o fuelbmps.output
If you want an IDE I have used Eclipse in conjunction with gcc and, in the end, had good results.
AC
All of that said, using gcc can be frustrating. The best of that world is perfect and always works. The documentation, however, is often very confusing and shall I say cryptic? It took a while but here is the bat file I have used to test making a gauge with just a text editor and gcc.
gcc -c sdktest.c
windres --input=fuelbmps.rc --output=fuelbmps.output
gcc -shared -o sdktest.gau sdktest.o fuelbmps.output
If you want an IDE I have used Eclipse in conjunction with gcc and, in the end, had good results.
AC
Hello Ali Cat,
I had totally forgotten about this forum.
Once I had gotten things to work, I started a thread in the CFS1 Forum on Gauges for Combat Flight Simulator.
It took a while to get other things to work, and you can follow along the several years process in that thread.
The machine I was using to compile gauges stopped working a couple years back, so I stopped gauge development.
For some odd reason, as I was about to strip the disk out of it for all the data that it contained, the machine booted again and is still running though I have no idea for how long it will stay running.
As for gcc / GNU C, that is pretty much a hopeless cause. The updates on that compiler were terminated years ago. It still works as a basic ANSI C compiler though and I use it for that when all the features I need are strictly ANSI C. The same applies to MinGW.
The problem with Gauge Development is that it isn't strictly ANSI C.
Just about every compiler for the Windows environment has Windows extensions of some kind. These extensions are not ANSI and the method that two different vendors choose to implement the same functionality may be very different.
As an example, often custom types are defined in the headers for the SDK and for the specific compiler.
Let's say we need a 32 bit unsigned integer.
One compile may define it as a structure containing 4 unsigned characters while another may define it as a 4 character string.
The typedef will be in the header and probably have a different name though the functionality is the same.
Obviously they won't match. Figure there are HUNDREDS of those.
The Windows functions which are extensions to the ANSI standard will have different function prototypes in the header files.
Fixing all of those to get things to actually work except for the simplest of gauges is not a worthwhile task.
As such, it is the best idea to stick to a M$ compiler because their extensions at least will agree with their own SDK.
What I found however is that even M$ compilers that are too far off chronologically from the target operating system may not be able to generate object code (DLLs / GAU files) that will run on the target system. You will have to experiment a bit with versions there. I can tell you what I used that worked for Windows 98 SR2 on forward. It is documented in the Gauges for Combat Flight Simulator Thread.
The fellow that was helping me solve a couple problems was using something much older that worked as well.
As for compilations, simple Make Files seem to be the best idea and the M$ development packages support those.
- Ivan.
I had totally forgotten about this forum.
Once I had gotten things to work, I started a thread in the CFS1 Forum on Gauges for Combat Flight Simulator.
It took a while to get other things to work, and you can follow along the several years process in that thread.
The machine I was using to compile gauges stopped working a couple years back, so I stopped gauge development.
For some odd reason, as I was about to strip the disk out of it for all the data that it contained, the machine booted again and is still running though I have no idea for how long it will stay running.
As for gcc / GNU C, that is pretty much a hopeless cause. The updates on that compiler were terminated years ago. It still works as a basic ANSI C compiler though and I use it for that when all the features I need are strictly ANSI C. The same applies to MinGW.
The problem with Gauge Development is that it isn't strictly ANSI C.
Just about every compiler for the Windows environment has Windows extensions of some kind. These extensions are not ANSI and the method that two different vendors choose to implement the same functionality may be very different.
As an example, often custom types are defined in the headers for the SDK and for the specific compiler.
Let's say we need a 32 bit unsigned integer.
One compile may define it as a structure containing 4 unsigned characters while another may define it as a 4 character string.
The typedef will be in the header and probably have a different name though the functionality is the same.
Obviously they won't match. Figure there are HUNDREDS of those.
The Windows functions which are extensions to the ANSI standard will have different function prototypes in the header files.
Fixing all of those to get things to actually work except for the simplest of gauges is not a worthwhile task.
As such, it is the best idea to stick to a M$ compiler because their extensions at least will agree with their own SDK.
What I found however is that even M$ compilers that are too far off chronologically from the target operating system may not be able to generate object code (DLLs / GAU files) that will run on the target system. You will have to experiment a bit with versions there. I can tell you what I used that worked for Windows 98 SR2 on forward. It is documented in the Gauges for Combat Flight Simulator Thread.
The fellow that was helping me solve a couple problems was using something much older that worked as well.
As for compilations, simple Make Files seem to be the best idea and the M$ development packages support those.
- Ivan.
Hello Ali Cat,
My example above for analogous extended types probably wasn't the best.
Consider the alternatives of
Structure containing 4 unsigned characters
Structure containing 2 integers.
Both are four byte types while the size of the character string I suggested earlier isn't necessarily that.
I do hope you understood my meaning though.
- Ivan.
My example above for analogous extended types probably wasn't the best.
Consider the alternatives of
Structure containing 4 unsigned characters
Structure containing 2 integers.
Both are four byte types while the size of the character string I suggested earlier isn't necessarily that.
I do hope you understood my meaning though.
- Ivan.