Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: If you want to keep them, please help me and review that patch I have posted a few days ago. Please *verify* that the remaining functions do about the right thing past converting them to something that is not even misscompiled. If nobody helps here, I will finally remove them in a few days. I don't really have time to review them and since they are used so little I think they can be ditched. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Wednesday 21 June 2006 13:03, Christian Mayer wrote: These functions can be great - when you know in advance (1) the number range, (2) the required error range and that you are (3) in a very tight loop that is (4) performance critical. So I'd leave them in. Yes, but I doubt that I will identify an *inner* *loop* making use of transcendental functions that are that unimportant for the physics that I would consider using these functions. If you want to keep them, please help me and review that patch I have posted a few days ago. Please *verify* that the remaining functions do about the right thing past converting them to something that is not even misscompiled. If nobody helps here, I will finally remove them in a few days. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Olaf Flebbe wrote: Hi, The comment for fast_log is IMHO incorrect. /** * This function is about 3 times faster than the system log() function * and has an error of about 0.01% */ The relative error can be larger than 7% it is almost nowhere about 0.01% when used in the range [ 0.5 - 1[. Try yourself: This was information that I picked up when searching for those functions. Even 7% can be satisfactory in some circumstances, but one needs to know the error. I'm getting more and more convinced to just remove these functions and use the standard C ones instead. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Olaf Flebbe wrote: Hi, The comment for fast_log is IMHO incorrect. /** * This function is about 3 times faster than the system log() function * and has an error of about 0.01% */ The relative error can be larger than 7% it is almost nowhere about 0.01% when used in the range [ 0.5 - 1[. Try yourself: This was information that I picked up when searching for those functions. Even 7% can be satisfactory in some circumstances, but one needs to know the error. I'm getting more and more convinced to just remove these functions and use the standard C ones instead. These functions can be great - when you know in advance (1) the number range, (2) the required error range and that you are (3) in a very tight loop that is (4) performance critical. So I'd leave them in. But, as premature optimization is the root of all evil, the source code should be freed of any use of those functions where the comments don't indicate that the 4 points above are met. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFEmSeClhWtxOxWNFcRAmw4AJ9trwQ/OZNN9xkmoSGQRtRrz+/4WgCfWg6H fZ8xGQQdRtgyDvGMRNLsFII= =kFwa -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi,
The comment for fast_log is IMHO incorrect.
/**
* This function is about 3 times faster than the system log() function
* and has an error of about 0.01%
*/
The relative error can be larger than 7% it is almost nowhere about
0.01% when used in the range [ 0.5 - 1[. Try yourself:
Olaf
#include math.h
#include stdio.h
float fast_log2 (float val)
{
union {
float f;
int i;
} v;
v.f = val;
const int log_2 = ((v.i 23) 255) - 128;
v.i = ~(255 23);
v.i += 127 23;
v.f = ((-1.0f/3) * v.f + 2) * v.f - 2.0f/3; // (1)
return (v.f + log_2);
}
#ifndef log2
float log2 (float val)
{
return log( val)/ log(2.f);
}
#endif
int main() {
float x = 0.995;
printf(x\tabs. error\trel. error\n);
printf(%g\t%g\t%g\n, x, fast_log2(x)-log2(x ), (fast_log2(x)-log2(x
))/log2(x) );
}___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi,
... was offline, sorry.
On Saturday 17 June 2006 23:28, Erik Hofman wrote:
You know, I did a quick grep in the source code for fast_ and only found
it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and
fast_log). Maybe we can get rid of them after all.
In that time, I have tried to fix fastmath.cpp to compile correctly.
My suggestion would be to keep the transcendent functions and correct them to
make them compile correct.
I have also removed the functions that are very most likely slower than the
libm implementations from the header.
Can you/somebody help me please and double check the attached patch if I have
converted them correctly before I check that in?
I have *not* done any tests with this functions against the libm ones. In fact
I do not know what error is acceptable for the fast implementation.
What do you think?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: simgear/math/fastmath.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.cxx,v
retrieving revision 1.8
diff -u -r1.8 fastmath.cxx
--- simgear/math/fastmath.cxx 16 Jun 2006 09:29:54 - 1.8
+++ simgear/math/fastmath.cxx 19 Jun 2006 17:03:05 -
@@ -35,20 +35,20 @@
* This function is on avarage 9 times faster than the system exp() function
* and has an error of about 1.5%
*/
-static union {
-double d;
-struct {
+double fast_exp(double val) {
+const double a = 1048576/M_LN2;
+const double b_c = 1072632447; /* 1072693248 - 60801 */
+
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
int i, j;
#else
int j, i;
#endif
-} n;
-} _eco;
-
-double fast_exp(double val) {
-const double a = 1048576/M_LN2;
-const double b_c = 1072632447; /* 1072693248 - 60801 */
+ } n;
+} _eco;
_eco.n.i = (int)(a*val + b_c);
@@ -61,30 +61,30 @@
*/
double fast_exp2( const double val )
{
-int e;
-double ret;
-
-if (val = 0) {
-e = int (val);
-ret = val - (e - 1);
-
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int i, j;
#else
-((*(1 + (int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int j, i;
#endif
+ } n;
+} ret;
+
+if (val = 0) {
+int e = int (val);
+ret.d = val - (e - 1);
+ret.n.i = ~(2047 20);
+ret.n.i += (e + 1023) 20;
} else {
-e = int (val + 1023);
-ret = val - (e - 1024);
-
-#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += e 20;
-#else
-((*(1 + (int *) ret)) = ~(2047 20)) += e 20;
-#endif
+int e = int (val + 1023);
+ret.d = val - (e - 1024);
+ret.n.i = ~(2047 20);
+ret.n.i += e 20;
}
-return ret;
+return ret.d;
}
@@ -96,7 +96,12 @@
float result, tmp;
float mp = 0.346607f;
-result = *(int*)val;
+union {
+float f;
+int i;
+} v;
+v.f = val;
+result = v.i;
result *= 1.0/(123);
result = result - 127;
@@ -115,27 +120,14 @@
result = val + 127 - tmp;
result *= (123);
-*(int*)result = (int)result;
-return result;
-}
-
-
-
-/**
- * While we're on the subject, someone might have use for these as well?
- * Float Shift Left and Float Shift Right. Do what you want with this.
- */
-void fast_BSL(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x+=shiftAmount23;
-
+union {
+float f;
+int i;
+} v;
+v.i = (int)result;
+return v.f;
}
-void fast_BSR(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x-=shiftAmount23;
-
-}
/*
@@ -148,20 +140,28 @@
*/
float fast_pow(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
float fast_root(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
Index: simgear/math/fastmath.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.hxx,v
retrieving revision 1.9
diff -u -r1.9 fastmath.hxx
--- simgear/math/fastmath.hxx 17 Jun 2006 16:04:28 - 1.9
+++ simgear/math/fastmath.hxx 19 Jun 2006 17:03:05 -
@@ -45,10 +45,6 @@
float fast_acos(const float val);
float fast_atan(const float val);
-void fast_BSL(float x, register unsigned long
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. They are not designed for that either. It can be useful for sound processing and color adjustments where very high precision isn't necessary. I use it for instance for gamma correction on my O2. It does give me a framerate improvement. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Saturday 17 June 2006 10:05, Erik Hofman wrote: Mathias Fröhlich wrote: I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. They are not designed for that either. It can be useful for sound processing and color adjustments where very high precision isn't necessary. I use it for instance for gamma correction on my O2. It does give me a framerate improvement. Well, but gamma correction happens often. At ervery frame width times height pixels times number of colors. That are easily more than 1e6 operations a second. I can hard imagine an operation in flightgear that happens that often, dominates the computation time *and* that does not require some minimum accuracy. I for myself would not use them for the HUD. Too few invocations (that is: potential speedup) compared to the subtle problems that can arise. For the sound stuff, I do not even see, if sound is disabled or enabled, so I can hard imagine to see the improovement of the fastmath functions from the sound subsystem. Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. I've never advocated using these routines for FMD's or anything like that since it could get messy really quick. But tests using the fastmath routines have revealed a considerable speed increase when compared with the C library functions solely because they are lossy and imperfect. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi Erik, On Saturday 17 June 2006 10:54, Erik Hofman wrote: Mathias Fröhlich wrote: Performance is a critical subject to me. But IMO the possible advantages of the fastmath functions are too few compared to the possible problems. I've never advocated using these routines for FMD's or anything like that since it could get messy really quick. But tests using the fastmath routines have revealed a considerable speed increase when compared with the C library functions solely because they are lossy and imperfect. If you feel that they should be used, can you care for them and make them alias safe? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:34: It think it would be best to use offset and factor just like most of the other configurations (sound/animations). I'm now using property/factor/offset for all numeric values. Some HUD elements need two values. I'm now just using property n=1/ factor n=1/offset n=1 for those. That's a bit ugly and one could put it into a group. But then one would also have to put such a tuple into a group even if there's only one. (?) Also, I'd like to dump the silly element groups, as in: instruments hudladder pathHuds/Instruments/Default/hudladder.xml/path /hudladder hudcard pathHuds/Instruments/Default/hudcard.xml/path /hudcard ... I see no reason why the elements should be grouped by type and loaded in chunks. I'd rather prefer something like: instruments pathHuds/Instruments/Default/hudladder.xml/path pathHuds/Instruments/Default/hudcard.xml/path ladder ... contents ... /ladder card ... /card card // ... /card that is: all HUD elements simply on one level, but a way to import further files. I'd call that include but everywhere else path is used, so that's probably better. Of course, one could use the include attribute (foo include=...), but this is only allowed once, and it doesn't add the imported stuff, but replace the old if the indices are the same, so it's really useless. Ideas? Objections? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: If you feel that they should be used, can you care for them and make them alias safe? Not at this time, I've got other things on my prioritylist. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Saturday 17 June 2006 14:54, Erik Hofman wrote: Mathias Fröhlich wrote: If you feel that they should be used, can you care for them and make them alias safe? Not at this time, I've got other things on my prioritylist. Ok, the ones in fastmath.hxx are easy to fix, I have already prepared a checkin for that. The ones in the fastmath.cxx look really ugly to fix. If we would have no different compiler than gcc I would have suggested to add a special compile flag to fastmath.cxx to avoid gcc optimizing too much away. But we also have to support other compilers ... So I have to note that many of these functions are expected to be misscompiled by modern compilers that care for alias sets like current gcc's do. Anyway, you still try to sell to me that (in case of fast_fabs for example) it is faster to take a floating point value probably already being loaded in the fpu push it into memory reload it into the integer unit do some bit fiddling push it back into memory and reload it into the floating point unit to do further computations with that is faster than just take the fpu register and execute a fabs operation on that? Seriously, I *can* think of fast_atan's polynomials being faster than a full blown correct functioin. But those simple fabs, sign or neg function implemented in the header cannot even be faster than the cpu builtin assembler instructions usually available on current cpu's. Also, in presence of sse instructions forcing that fist legacy i386 fpu instruction in that assembler snipet will not make it faster (unloading from sse unit, loading to legacy fpu, in contrast to do the same directly in the sse unit ...). Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Mathias Fröhlich wrote: Seriously, I *can* think of fast_atan's polynomials being faster than a full blown correct functioin. But those simple fabs, sign or neg function implemented in the header cannot even be faster than the cpu builtin assembler instructions usually available on current cpu's. Also, in presence of sse instructions forcing that fist legacy i386 fpu instruction in that assembler snipet will not make it faster (unloading from sse unit, loading to legacy fpu, in contrast to do the same directly in the sse unit ...). You know, I did a quick grep in the source code for fast_ and only found it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and fast_log). Maybe we can get rid of them after all. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 22:35: That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away. OK. Done that. For now I've decided to make it a regular subsystem that's registered by FGInstrumentMgr (instrumentmgr.cxx) like od_gauge and annunciator. The ::update() method is empty, and there's a method ::draw() that is called from the renderer right after the old fgCockpitUpdate. I think this is the best approach for supporting the old modes (2D 3D). Later I'd like to add render-to-texture HUD instruments in the way wxradar uses od_gauge, by subclassing from the HUD. Those will then not be updated via ::draw() method by the renderer, but via ::update(). Or something. First I need to make it work at all, though. :-) I'll commit the files as soon as the basic, old functionality is restored. The new HUD will be turned off, unless an aircraft asks for it. (And I will make them ask for it. :-) The new XML configs will, of course, not be fully backward compatible. Changes: loadfnfn\become property/path/to/somewhere... data_sourcefn / data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) It think it would be best to use offset and factor just like most of the other configurations (sound/animations). Great work, so far you've processed further than I ever did. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:34: Melchior FRANZ wrote: data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) It think it would be best to use offset and factor just like most of the other configurations (sound/animations). Good point. Great work, so far you've processed further than I ever did. Oh, that's just because I'm stupid enough to do it. Not very smart. :-} BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Maybe simgear/math/fastmath.hxx? It has nothing to do with HUDs, but will be used by the old and new implementation, and could be useful for others. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Melchior FRANZ -- Friday 16 June 2006 09:41: BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Or is it not worth at all to be done in assember nowadays? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Melchior FRANZ -- Friday 16 June 2006 09:41: BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Or is it not worth at all to be done in assember nowadays? I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Erik Hofman a écrit : Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. That will ease the port to MSVC. no C99 here. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Friday 16 June 2006 10:18, Erik Hofman wrote: Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. Well, I doubt that fastmath is useful these days anyway. I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. Compilers do a pretty good job, selecting the right asm code for that stuff. Also I would trust libm and compilers much more in terms of accuracy, behavour in corner situations and even speed. For those few computations the fastmath functions are used now, I believe that you will not even notice a change in framerates if you compute the required results twice with the most expensive function you can find compared to the fastmath stuff. Also these fastmath implementations are not aliasing safe in any way. You can expect an optimizing compiler to completely missoptimize most of the fastmath functions. I would vote for removing that fastmath stuff completely and using standard ones. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 15:32: Melchior FRANZ wrote: (a) an FGInstrumentMgr controlled class instance, and if so: should it be moved to Instrumentation/HUD/? That's my preference, especially since it will be a completely overhauled version of the HUD code. The default HUD could then be a HUD entry in $FG_ROOT/Aircraft/Generic/generic-instrumentation.xml ... hud namehud/name number0/number !-- maybe some day an advanced UFO needs 2 HUDs :-) -- !-- textureAircraft/f16/Models/hud.rgb/texture -- /hud that depends on electricity and serviceable. The texture entry could be used once we have a *usable* render-to-texture HUD version. (My first version wasn't that pretty.) This would then be the virtual texture that can be mapped to a 3D HUD object of the aircraft model. Etc. etc. (d) can I simply switch to properties, [...] I'm trying to guess how many newly created special HUD configurations can be. I think there are at least a few. So I would postpone dropping the old code to after 1.0 (maybe not even counting 1.x subversions). OK. That makes sense. It could first output a warning on log level warning, then on alert, and finally disappear. I'd also write a section about the migration to properties. I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. Hmm ... there is only one HUD, so I'd prefer just HUD (which is still free as a class name). The XML prefix is as redundant as the New in NewGUI will soon be. :-) BTW: in case someone has looked at the current HUD files ... I left quite some FIXME everywhere, and I will, of course, really fix those soon, and also make other changes and improvments. So, don't panic. :-) The HUD look/behaviour shouldn't have become worse. If you notice any degradation, please shout in time! Well, there's one degradation: ticks and digits in the moving scales were before restricted to pixel boundaries. This made them jump, which looked silly. Also the scale ticks weren't evenly spaced because of that. I changed that, but now digits can move between pixels, which may sometimes look like flicker. If this is a problem, then I'd rather make it configurable, as the current method is IMHO more correct. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 15:32: * Melchior FRANZ wrote: My preference is, of course, to switch and let loadfn die immediately. :-) Yes, I can imagine but I think the cases where the old code is/has been used outside of the FlightGear scope are all cases that draw attention to FlightGear (universities and research organizations). I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place. Chicken/Egg. :-/ m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Erik Hofman -- Thursday 15 June 2006 15:32: I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place. That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
How about some stub functions ?It's kind of temporary patch up that's organized in one place.So later on, you know where to look in to delete the obsolete stuff.IsaoErik Hofman [EMAIL PROTECTED] wrote: Melchior FRANZ wrote: * Erik Hofman -- Thursday 15 June 2006 15:32: I would just copy the current code to a new location and rename it's class to maybe XMLHUD or something. And let the old code how and where it is for compatibility reasons? It turns out that I can't do much more improvements and fixes if I have to keep all the old shit that I wanted to get rid of in the first place.That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away.Erik-- http://www.ehtw.info (Dutch) Future of Enschede Airport Twentehttp://www.ehofman.com/fgfs FlightGear Flight Simulator___Flightgear-devel mailing listFlightgear-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
