Share this post

Link to post

Share on other sites

>Maybe it does not like an empty array and complains about>it?!Probably... It works just fine without it! I've no idea why Easy Gauge creates that "array" anyway, but the MinGW compiler doesn't seem to care one way or another... >Besides, just a tip I'm often using to avoid having a CPU>stalling with miss branch predictions....>>if ( cabinlights == 0 ) { cabinlights = 1 ; } else {>cabinlights = 0 ; }>>is safely replaced, and P4/Athlon better, by:>>cabinlights = 1 - cabinlights;Hmmm... that's a lot less "typing" too! :)Of course, my ultimate "goal" is to take a whole bunch of small gauges and combine 'em into one multi-gauge. Thanks to your able assistance, I'm close to achieving my goal!One other anomaly I found was hiding in the .h file:EG produces...#define Rec0 0x100 :)

Share this post

Link to post

Share on other sites

Bill,What MingGW version are you using. I seem to only be able to use the 2.95.2 version. The later versions I tried seem to not work with the make files provided by Dai Griffiths and Arne Bartels in sd2gau15.zip.W. Sieffert

Share this post

Link to post

Share on other sites

>Bill,>>What MingGW version are you using. I seem to only be able to>use the 2.95.2 version. The later versions I tried seem to>not work with the make files provided by Dai Griffiths and>Arne Bartels in sd2gau15.zip.MinGW - Minimalist GNU for Win32Version 2.0.0http://www.mingw.orgMinGW version 2.0.0 contains the following list of packages:GCC-3.2-core-20020817-1binutils-2.13-20020903-1mingw-runtime-2.2w32api-2.0gdb-5.1.1-1make-3.79.1-20010722 (binary renamed as mingw32-make)I tend not to "upgrade" stuff that's working well as it! :)

Share this post

Link to post

Share on other sites

Guest JeanLuc_

tested with BorlandC and seen in VC++ compiled code:var = !var; does not produces pairable UV instructions in all cases (context dependant)var = 1 - var; does better from my experience.Also, binding an int to test a TRUE/FALSE condition is compiler dependant, and language dependant (differences between C and C++, for which there is a real boolean type). This means that you know it is TRUE or FALSE, but you can't ensure the value of the int.In most cases, !var; with var as an int may produce a sequence of 0 and -1. If the int value is also used to index an array for example, from which you get a value (bitmap, whatever...) then it becomes useless. var = 1 - var; ensures the values are the ones you want.I may be completely wrong though.:-)

Share this post

Link to post

Share on other sites

Here's a new puzzle!I have a very simple "Audiopanel" gauge that works 100%, but for some reason FS Panel Studio will choke on with a nasty error (occasionally causing complete computer lockup!).What is odd is that it was working in FSPS, but after changing the "click sounds" and recompiling, FSPS will crash... adding to the mystery is that FS2k2 and FS9 have no issues with this gauge, but will happily run with it installed.This same thing has suddenly occurred with my EHSI (which is extremely complex); one day FSPS would load/display it perfectly, after a recompile to change/add a few elements, FSPS is choking on it. As with the "Audiopanel" gauge, all versions of FS have no problems with it.Just for the sake of building experience and skills, I recompiled the "Audiopanel" gauge with the BCC55 compiler; FSPS still chokes on the gauge, but FS is happy!On another note, the MinGW compiler seems able to compile "tighter" than the BCC55 compiler. There is a huge difference in file size of the .gau files:MinGW = 187 KBBCC55 = 223 KBIs the difference in sizes related to the extra header info needed (I compiled in BCC55 as a multi-gauge)?

Share this post

Link to post

Share on other sites

Guest bartels

The size difference is possibly due to different "optimization" settings, mainly inserting or letting out quite big chunks of zero data in the end result. Any extra header info will only add marginally to the gauges size (some Kbs maybe, presumably only a hand full bytes). In my experience the CFGedit choked on gauges that had some extra dll linkage in them, e.g. sound dlls, FSPS might do the same. You can ignore it or try to find the right dll in the FS modules folder and copy it to the FSPS program directory (or directly in windowssystem).Arne Bartels

Share this post

Link to post

Share on other sites

>The size difference is possibly due to different>"optimization" settings, mainly inserting or letting out quite>big chunks of zero data in the end result. Any extra header>info will only add marginally to the gauges size (some Kbs>maybe, presumably only a hand full bytes).That's likely what is happening then.>In my experience the CFGedit choked on gauges that had some>extra dll linkage in them, e.g. sound dlls, FSPS might do the>same. You can ignore it or try to find the right dll in the FS>modules folder and copy it to the FSPS program directory (or>directly in windowssystem).Arne, what is truly puzzling is that FSPS was loading/displaying the "Audiopanel" gauge perfectly!The only change made was the name of the .wav file from "click.wav" to "push.wav..."The same is true of the EHSI. Other gauges that were modified to use "push.wav" still load/display in FSPS, so the .wav name is a "red herring," and cannot account for the anomaly, and they also use the same GaugeSound.dll for sound.Ah well, as a "workaround" I've simply placed a "dummy .gau" in the gauges folder which only has a background bitmap for gauge placement purposes; the "real" .gau is in the a/c's panel folder for developmental purposes! :)I've encountered this problem with FSPS in the past with other people's gauges, and had worked with the author of FSPS to "fix" the problem. I'll have to contact him again to see if there's a new "fix" available... :)

AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

Donation Goals

AVSIM's 2019 Fundraising Goal

Donate to our annual general fund. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.