gamedevlists-general — List for discussing general game development issues

Re: [GD-General] problems while debugger is attached

[Megan F. <sha...@gm...>]

It may or may not be your problem, but I've had many cases where, due
to the debugger assigning consistent values to uninitialized
variables, the application fails - but if I allow those to remain
uninitialized in release mode, it simply functions (on certain
machines).  In general, that's the first thing I go looking for when I
have a problem that shows in debug mode but not in release.  Usually,
it ends up being me having somehow handed a function a bad pointer to
nothing, rather than the structure I intended to send.

On 7/23/06, Andras Balogh <and...@gm...> wrote:
> I have a strange bug, where if I'm running the program without the
> debugger attached (CTRL-F5 in VS), the program would run correctly both in
> debug and release builds. But when I run the program with F5, so the
> debugger is attached, then it blocks on a function call and never returns.
> If I put a breakpoint before this call, and step through it, then
> everything seems to work fine, and the function returns as expected..
>
> Could this be a deadlocking problem? Any ideas why attaching a debugger
> makes any difference? And hints on how to debug this?
>
> Thanks,
>
>
>
> Andras
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>


-- 
-Megan Fox
Idyllon, LLC
http://shalinor.circustent.us/megan/resume/

Re: [GD-General] problems while debugger is attached

[Chris C. <can...@gm...>]

I've had this many times when coding in a multi-threaded environment.
What will be happening is the attachment of the debugger is enough to
skew the timings of the function calls so that a race condition is
exposed.

When you say 'blocks on a function call and never returns', what
function call are you talking about? A system call or one of your own
functions? If its one of your own functions thats blocking, its a bit
easier to debug, because you can introduce logging around it. A system
call is a harder to diagnose - usually the sub-system the system call
is dealing with has some internal blocking, but its harder to figure
out where the race condition is coming from.

Before I started using test driven development for these things, I
could spend ages beating my head against weird behaviour like that.
The most effective solution I found for debugging strange race
conditions was to introduce sleeps of random and significant duration
around the system, to exacerbate any problems which don't show up
unless locks are held for a long while. Combine that with logging
around lock acquisition/releases so you can see what was going on
immediately prior to the deadlock, without having to use breakpoints.
Breakpoints don't help at all in these cases, because they screw up
the timing, and the nature of debuggers is often to suspend other
threads entirely when single-stepping through a thread - often making
the problem disappear entirely.

ChrisC

On 23/07/06, Andras Balogh <and...@gm...> wrote:
> I have a strange bug, where if I'm running the program without the
> debugger attached (CTRL-F5 in VS), the program would run correctly both in
> debug and release builds. But when I run the program with F5, so the
> debugger is attached, then it blocks on a function call and never returns.
> If I put a breakpoint before this call, and step through it, then
> everything seems to work fine, and the function returns as expected..
>
> Could this be a deadlocking problem? Any ideas why attaching a debugger
> makes any difference? And hints on how to debug this?
>
> Thanks,
>
>
>
> Andras
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

[GD-General] problems while debugger is attached

[Andras B. <and...@gm...>]

I have a strange bug, where if I'm running the program without the  
debugger attached (CTRL-F5 in VS), the program would run correctly both in  
debug and release builds. But when I run the program with F5, so the  
debugger is attached, then it blocks on a function call and never returns.  
If I put a breakpoint before this call, and step through it, then  
everything seems to work fine, and the function returns as expected..

Could this be a deadlocking problem? Any ideas why attaching a debugger  
makes any difference? And hints on how to debug this?

Thanks,



Andras

Re: [GD-General] OpenGl lists

[Sylvain V. <vi...@ii...>]

Research wrote:
> I have been looking for a good OpenGl game mailing list ala GD-Algo, SWENG, 
> etc. There's some activity on the Mac OpenGL list, but the OpenGl Game list 
> seems dead (opengl-gamedev-l ).
>   
The main activity is on the OpenGL forums - 
http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?ubb=forum;f=3

[GD-General] OpenGl lists

[Research <res...@ga...>]

I have been looking for a good OpenGl game mailing list ala GD-Algo, SWENG, 
etc. There's some activity on the Mac OpenGL list, but the OpenGl Game list 
seems dead (opengl-gamedev-l ).

Are there any good OpenGL game lists out there?

Thanks,
Brett 

[GD-General] Re: [Algorithms] C style math libraries versus "proper" C++ maths

[Richard F. <ra...@de...>]

> Regarding profiling, you need to be very careful to get reliable profilin=
g
> numbers. For instance data/code alignment, cache warmups (i.e. the first
> test read data over the bus while next one has advantage of reading it fr=
om
> cache), systematicly executed background tasks while testing (e.g. some H=
D
> activity occuring by OS always after 1sec of testing), etc. can easily ca=
use
> 5% performance difference between tests. Also make sure you profile in fu=
lly
> optimized release version and disable C++ exception handling as it can
> potentially hinder some of the inlining and result in other overheads.
>
> Jarkko
>

I agree that profiling is difficult to get right normally, but i think my
method is safe:

1. write the test as a framework with the timing stuff built in.
2. write the implementation of the test as two seperate modules, one using
one technique, the other using the other technique
3. test the apps one after the other giving them a few runs then giving the
other a few runs, store all the runs sub timings.

this gives me a good idea about what i can expect as best performance, wors=
t
performance, and the average case too.

oddly, i found that the C++ version of the math library has a smaller
standard deviation on the overall time to complete the excercise than the C
style lib, I guess i'll put that down to there being more instructions made
from the C++ version, but less access to memory... so, i'm not holding my
breath for fantastic performance on PS2 where number of instructions being
sent to the CPU is important still.

Re: [GD-General] C style math libraries versus "proper" C++ maths

[Richard F. <ra...@de...>]

Thanks for the help, the C++ library is now marginally faster than the C
library, and now i can approve it for general use at our company. I'm gonna
love being able to change my code from:

    Vector relativeStart, lineDirection;
    VectorSubtract( &relativeStart, pos, lineStart );
    VectorSubtract( &lineDirection, lineEnd, lineStart );
    F32 lineLength =3D VectorLength( lineDirection );
    VectorMultiply( &lineDirection, 1.0f / lineLength );


to:

    Vec3 relativeStart( pos - lineStart ), lineDirection( lineEnd -
lineStart );
    F32 lineLength =3D lineDirection.GetLength();
    lineDirection /=3D lineLength;


thanks again guys

Re: [GD-General] C style math libraries versus "proper" C++ maths

[Andras B. <and...@gm...>]

Isn't it fun when theory meets practice? :)

With a proper compiler, if you used references, and the function was
inlined, then the function should just work straight on the values, no
dereferencing, no copying to the stack, etc.. However, last time I
checked, this was still not the case, so I still pass all my vectors
and matrices by value, rather than reference.

Note that if the function is inlined, then it shouldn't do the copy to
stack in any case.. So my advice would be to simply pass by value.



Andras

Saturday, March 25, 2006, 3:26:53 PM, you wrote:

> I remember some passed days in gameprogramming.
>  
> 3D matrix operations and its implementation on PIII900MHz.
> a class containing an array of float, somethingvery simple.
> And for basic operation, you can pass on reference(using  
> keyword) or pointer (* keyword) or pass directly the array (so
> allfloats are placed into stack.
> Case 1   Case 2 : only 4 bytes on the stack butall computing is using a deference (-> operator)
> Case 3 : for 4x4 array (x,y,z,w), 16 floats so 16 x4 = 64 bytes per matrix.
>  
> At this time the fastest method was the3.
>  
> So better code isn't always the faster one;)
>  
  

Re: [GD-General] RE: [Algorithms] C style math libraries versus "proper" C++ maths

[Scoubidou944 \(Hotmail\) <sco...@ho...>]

I remember some passed days in game programming.

3D matrix operations and its implementation on PIII 900MHz.
a class containing an array of float, something very simple.
And for basic operation, you can pass on reference (using & keyword) or =
pointer (* keyword) or pass directly the array (so all floats are placed=
 into stack.
Case 1 & Case 2 : only 4 bytes on the stack but all computing is using a=
 deference (-> operator)
Case 3 : for 4x4 array (x,y,z,w), 16 floats so 16 x 4 =3D 64 bytes per m=
atrix.

At this time the fastest method was the 3.

So better code isn't always the faster one ;)

  ----- Original Message ----- 
  From: Stephane Etienne 
  To: gam...@li... 
  Sent: Saturday, March 25, 2006 11:00 PM
  Subject: [GD-General] RE: [Algorithms] C style math libraries versus "=
proper" C++ maths


  To do a fair comparison, we would need to see your C implementation. Y=
ou implemented operator+, operator*, etc but these return a temporary wh=
ich may or may not be optimized out. The best way to find out is to look=
 at the disassembly. Also, different compiler may do different things. If your C version usage does not need a=
ny temporaries, then it will most likely be faster indeed. However if u =
use operator+=3D or operator *=3D, you should definitely get similar per=
formances. Also never profile debug builds. Even functions marked inline will not be inlined in debug builds for e=
xample.



  Since C99 support the inline keyword, you should not see any differenc=
e between a C and C++ implementation. As Jarkko said, beware of exceptio=
ns. They can easily make your code a lot slower.



  I have a few suggestions regarding your code. They will not improve ex=
ecution speed but you wrote several things that are unnecessary:



  -          the inline keyword is not necessary for inlined method insi=
de the class body (less to read means it is also easier to read)

  -          Initializer list are only useful when the default construct=
or of constructed objects actually does something. Your use of initializ=
er list here does not buy you anything.

  -          Prefer C style functions over C++ member methods. See Scott=
 Meyer, "How non member functions improve encapsulation" for more info.

  -          No need to have a default destructor that does not do anyth=
ing for non virtual classes.

  -          No need to implement the default copy operator unless you n=
eed to do something special. In your case, the default copy constructors=
 and operators provided by the compiler will do just fine.

  -          Your use of statics to implement zero vector, etc could mes=
s with the cache on platforms such the Xbox 360 and the PS3.



  Understand your code. Look at the disassembly and profile over an over=
 again to understand why something is slow.



  Stephan.



  -----Original Message-----
  From: gda...@li... [mailto:gdalgorith=
ms-...@li...] On Behalf Of Richard Fabian
  Sent: Saturday, March 25, 2006 5:40 AM
  To: gda...@li...
  Subject: [Algorithms] C style math libraries versus "proper" C++ maths



  We've always used a math library that has a function per operation you=
 want to apply to each math construct. We do this because "back in the d=
ay" we found that C++ style math libraries lead to lots of unecessary de=
structors being made... at least in debug, but we suspected in release also. 

  its been a few years, two major microsoft compilers later, a new SN co=
mpiler for PS2, and GCC still getting better and better...

  so, after hearing a workmate claim that he was using a C++ math librar=
y "because it was faster" i decided to update my old C++ math library an=
d make myself a profiling testbed. 
  The sad news is: my old and horrible to read and work with function ba=
sed math library still outstrips the C++ math library by about a 5% spee=
d margin, even on trivial stuff.

  I'm not a C++ newb, i do know about constructor return optimisation, o=
perator overloads copy constructors and the like, but as i tend to write=
 code that is more architectural than the low level stuff like math libr=
aries, i wondered what kind of performance difference (and which way) you were seeing. 

  neither math library uses any platform specific optimisations, such as=
 SSE, SIMD, VU. This is pure C++ only.

  I have pasted my C++ math "header" that i was using for profiling if y=
ou want to take a look at my code and maybe point me in a direction of b=
etterly optimised code..

  http://rafb.net/paste/results/P2kY2O59.html 

Re: [GD-General] C style math libraries versus "proper" C++ maths

[Andras B. <and...@gm...>]

With regards to inlining, I believe that the inline keyword is merely
a suggestion to the compiler. I've found that some compilers might not
inline your code even in optimized release builds, when it's
explicitly specified as inline. If you really know that a function
should be inlined, you might want to use _forceinline or something
similar.

One good example is when your function is complicated, but given a
constant input, it evaluates to a constant result, with no
side-effects (in my case this was a function computing perlin noise).
Using the inline keyword, the compiler made the function call, running
an expensive function. With __forceinline, it could actually compute
the result at compile time and get rid of the function call
altogether!

That said, be very careful, when using __forceinline!




Andras


Saturday, March 25, 2006, 3:00:55 PM, you wrote:

> To do a fair comparison, we would need tosee your C
> implementation. You implemented operator+, operator*, etc but
> thesereturn a temporary which may or may not be optimized out. The
> best way to findout is to look at the disassembly. Also, different
> compiler may do differentthings. If your C version usage does not
> need any temporaries, then it will most likely befaster indeed.
> However if u use operator+= or operator *=, you should definitely
> get similarperformances. Also never profile debug builds. Even
> functions marked inlinewill not be inlined in debug builds for
> example.

>  

> Since C99 support the inline keyword, youshould not see any
> difference between a C and C++ implementation. As Jarkkosaid, beware
> of exceptions. They can easily make your code a lot slower.

>  

> I have a few suggestions regarding yourcode. They will not
> improve execution speed but you wrote several things thatare
> unnecessary:

>  

> -          the inline keyword is not necessary for inlined method
> inside theclass body (less to read means it is also easier to read)

> -          Initializer list are only useful when the default
> constructor of constructedobjects actually does something. Your use
> of initializer list here doesnot buy you anything.

> -          Prefer C style functions over C++ member methods. See
> Scott Meyer,“How non member functions improve encapsulation” for
> more info.

> -          No need to have a default destructor that does not do anything fornon virtual classes.

> -          No need to implement the default copy operator unless
> you need todo something special. In your case, the default copy
> constructors and operatorsprovided by the compiler will do just fine.

> -          Your use of statics to implement zero vector, etc
> could mess with the cache on platformssuch the Xbox 360 and the PS3.

>  

> Understand your code. Look at thedisassembly and profile over an
> over again to understand why something is slow.

>  

> Stephan.

>  

> -----Original Message-----
> From:
> gda...@li...[mailto:gda...@li...]On
> Behalf Of Richard Fabian
> Sent:Saturday, March 25, 20065:40 AM
> To:gda...@li...
> Subject: [Algorithms] Cstyle math libraries versus "proper" C++ maths

>  

> We've always used a math library that has a functionper operation
> you want to apply to each math construct. We do this because"back in
> the day" we found that C++ style math libraries lead to lotsof
> unecessary destructors being made... at least in debug, but we
> suspected inrelease also. 

> its been a few years, two major microsoft compilers later, a
> newSN compiler for PS2, and GCC still getting better and better...

> so, after hearing a workmate claim that he was using a C++ math
> library"because it was faster" i decided to update my old C++ math
> libraryand make myself a profiling testbed. 
> The sad news is: my old and horrible to read and work with
> function based mathlibrary still outstrips the C++ math library by
> about a 5% speed margin, evenon trivial stuff.

> I'm not a C++ newb, i do know about constructor return
> optimisation, operatoroverloads copy constructors and the like, but
> as i tend to write code that ismore architectural than the low level
> stuff like math libraries, i wonderedwhat kind of performance
> difference (and which way) you were seeing. 

> neither math library uses any platform specific optimisations,
> such as SSE,SIMD, VU. This is pure C++ only.

> I have pasted my C++ math "header" that i was using for profiling
> ifyou want to take a look at my code and maybe point me in a
> direction of betterlyoptimised code..

> http://rafb.net/paste/results/P2kY2O59.html

>  

[GD-General] RE: [Algorithms] C style math libraries versus "proper" C++ maths

[Stephane E. <set...@hi...>]

To do a fair comparison, we would need to see your C implementation. You
implemented operator+, operator*, etc but these return a temporary which
may or may not be optimized out. The best way to find out is to look at
the disassembly. Also, different compiler may do different things. If
your C version usage does not need any temporaries, then it will most
likely be faster indeed. However if u use operator+=3D or operator *=3D, =
you
should definitely get similar performances. Also never profile debug
builds. Even functions marked inline will not be inlined in debug builds
for example.

=20

Since C99 support the inline keyword, you should not see any difference
between a C and C++ implementation. As Jarkko said, beware of
exceptions. They can easily make your code a lot slower.

=20

I have a few suggestions regarding your code. They will not improve
execution speed but you wrote several things that are unnecessary:

=20

-          the inline keyword is not necessary for inlined method inside
the class body (less to read means it is also easier to read)

-          Initializer list are only useful when the default constructor
of constructed objects actually does something. Your use of initializer
list here does not buy you anything.

-          Prefer C style functions over C++ member methods. See Scott
Meyer, "How non member functions improve encapsulation" for more info.

-          No need to have a default destructor that does not do
anything for non virtual classes.

-          No need to implement the default copy operator unless you
need to do something special. In your case, the default copy
constructors and operators provided by the compiler will do just fine.

-          Your use of statics to implement zero vector, etc could mess
with the cache on platforms such the Xbox 360 and the PS3.

=20

Understand your code. Look at the disassembly and profile over an over
again to understand why something is slow.

=20

Stephan.

=20

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...] On Behalf Of
Richard Fabian
Sent: Saturday, March 25, 2006 5:40 AM
To: gda...@li...
Subject: [Algorithms] C style math libraries versus "proper" C++ maths

=20

We've always used a math library that has a function per operation you
want to apply to each math construct. We do this because "back in the
day" we found that C++ style math libraries lead to lots of unecessary
destructors being made... at least in debug, but we suspected in release
also.=20

its been a few years, two major microsoft compilers later, a new SN
compiler for PS2, and GCC still getting better and better...

so, after hearing a workmate claim that he was using a C++ math library
"because it was faster" i decided to update my old C++ math library and
make myself a profiling testbed.=20
The sad news is: my old and horrible to read and work with function
based math library still outstrips the C++ math library by about a 5%
speed margin, even on trivial stuff.

I'm not a C++ newb, i do know about constructor return optimisation,
operator overloads copy constructors and the like, but as i tend to
write code that is more architectural than the low level stuff like math
libraries, i wondered what kind of performance difference (and which
way) you were seeing.=20

neither math library uses any platform specific optimisations, such as
SSE, SIMD, VU. This is pure C++ only.

I have pasted my C++ math "header" that i was using for profiling if you
want to take a look at my code and maybe point me in a direction of
betterly optimised code..

http://rafb.net/paste/results/P2kY2O59.html=20

=20

Re: [GD-General] Re: [Algorithms] Colada experience (was Animation Export Problem)

[Richard F. <ra...@gm...>]

Okay, more important to me is:
Is all the data coming out of the exporters and going in via the importers
subjectively accurate?

I don't care if its out by about a gnats bollock on twelve verts in a
6megapoly scene, but: I've had to use some pretty rubbish exporters (ones
that proclaim capability, then don't deliver) and want to know about the
quality of the output of the collada plugins from known "underachievers"
such as 3DSMax.

[GD-General] Re: [Algorithms] Colada experience (was Animation Export Problem)

[Patrick D. <pa...@wa...>]

We are using Collada on our current project.  The Maya exporter is
working great and the importer was straightforward to implement.

Collada accessors are flexible, but I wouldn't consider them to be
overkill.  They are comparable in expressiveness to vertex declarations.

Here is an example:

  <accessor source="#polySurfaceShape30-lib-Position-array" count="2864"
stride="3">
    <param name="X" type="float"/>
    <param name="Y" type="float"/>
    <param name="Z" type="float"/>
  </accessor>

The names are optional.  They just serve as useful documentation when
looking at the file.  You can't store a position in Z,Y,X order.

So basically, this just says:

  1. where to start reading
  2. how many positions to read
  3. what is the stride between positions
  4. positions are 3d


Jon Watte wrote:
> 
> 
> Richard Fabian wrote:
> 
>> How many of us are using colada?
> 
> 
> I looked at it, but it just looks too crazy. For example: All the
> business of defining procedural accessors for each component of a vertex
> array just seems like overkill. It's not like "vertex position" will
> actually be anything other than X,Y,Z... (with a possible fourth
> component if you're especially crafty).
> 
> And before the list admins berate me: check out the headers of this
> reply :-)
> 
> Cheers,
> 
>             / h+
> 
> 

[GD-General] Re: [Algorithms] Colada experience (was Animation Export Problem)

[Jon W. <hp...@mi...>]

Richard Fabian wrote:

> How many of us are using colada?

I looked at it, but it just looks too crazy. For example: All the 
business of defining procedural accessors for each component of a vertex 
array just seems like overkill. It's not like "vertex position" will 
actually be anything other than X,Y,Z... (with a possible fourth 
component if you're especially crafty).

And before the list admins berate me: check out the headers of this 
reply :-)

Cheers,

			/ h+


-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

Re: [GD-General] arialuni.ttf licensing

[Richard M. <mi...@tr...>]

VGhlIHJpZ2h0cyB0byB0aGUgZm9udCBhcmUgb3duZWQgYnkgTWljcm9zb2Z0Lg0KDQpTZWUg
aGVyZSAtDQpodHRwOi8vd3d3LmFzY2VuZGVyY29ycC5jb20vbXNmb250cy9hcmlhbF91bmlj
b2RlLmh0bWwNCg0KLS0gDQooKSgpICAgICAgUmljaGFyZCBNaXR0b24NCiggJy4nKQ0KKCIp
XygiKSAgICAgICBjb2RlIGplc3RlciAuOi4gdHJleWFyY2ggLjouIG1pdHRvbkB0cmV5YXJj
aC5jb20NCg0KDQpJdmFuLUFzc2VuIEl2YW5vdiB3cm90ZToNCj4gTWFueSBnYW1lcyBub3dh
ZGF5cyBzZWVtIHRvIHVzZSBGcmVlVHlwZSBhcyBmb250IHJlbmRlcmluZyBlbmdpbmU7DQo+
IGZyZXF1ZW50bHksIEkgc2VlIGl0IGFjY29tcGFuaWVkIGJ5IGEgdmVyeSBnb29kLWxvb2tp
bmcgQXJpYWwgVW5pY29kZQ0KPiBUcnVlVHlwZSBmb250IChhcmlhbHVuaS50dGYpLiBKdWRn
aW5nIGZyb20gdGhlIHNpemUgb2YgaXQsIGl0IHByb2JhYmx5DQo+IGluY2x1ZGVzIENKSyBj
aGFyYWN0ZXJzLg0KPiANCj4gRG9lcyBhbnlvbmUga25vdyBob3cgdG8gbGljZW5zZSB0aGlz
IGZvbnQgZm9yIHJlZGlzdHJpYnV0aW9uIHdpdGggeW91ciBnYW1lPw0KPiDvv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73ThisSF++/vd616ZqKWO+/ve+/ve+/vSfvv73vv73vv71177+977+9Su+/vW7vv71C
J3Pvv73vv73Ki++/ve+/ve+/vW3vv73vv70u77+9GWjvv73vv71677+96K6a77+9blfvv73v
v73vv73Downloadt77+977+977+977+9AkBex5rvv73vv71e77+9CO+/vXrvv71a77+9Zu+/
vXrvv70eau+/vSHvv714Mu+/ve+/ve+/vQfvv73vv70a77+977+9yass77+977+977+9C2F7
B++/ve+/vTPvv70077+977+9DQo+ICPvv71Q77+977+977+977+9ae+/ve+/ve+/vXpf2rPv
v73vv73vv73vv73vv73vv71/77+977+977+9cmfvv71577+977+9J++/vU3vv73vv71v24nv
v71OPO+/ve+/vVrXrjbvv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv71qZ++/vXrvv71i77+977+977+977+977+93q3vv71maili77+9CWLv
v73Rmu+/ve+/vV7vv71Y77+977+977+977+9enfvv71qX++/ve+/vWzvv73vv70u77+9x5/v
v73vv70e77+9d++/ve+/ve+/vWnvv73vv73vv73vv70rLe+/ve+/vSjvv73vv70efu+/ve+/
vXvvv73et++/vWLvv73vv70/77+9Ky3vv71377+977+9Bu+/vXnXr++/vSst77+977+9Hu+/
ve+/vdqUDQo+INyGK96z77+9be+/ve+/ve+/ve+/ve+/vS7vv73Hn++/ve+/vR7vv71377+9
77+9Zu+/ve+/ve+/vdyGK++/ve+/ve+/vSvvv71v6Yaf36Lvv73vv73vv70nDQo=

[GD-General] arialuni.ttf licensing

[Ivan-Assen I. <iva...@gm...>]

TWFueSBnYW1lcyBub3dhZGF5cyBzZWVtIHRvIHVzZSBGcmVlVHlwZSBhcyBmb250IHJlbmRlcmlu
ZyBlbmdpbmU7CmZyZXF1ZW50bHksIEkgc2VlIGl0IGFjY29tcGFuaWVkIGJ5IGEgdmVyeSBnb29k
LWxvb2tpbmcgQXJpYWwgVW5pY29kZQpUcnVlVHlwZSBmb250IChhcmlhbHVuaS50dGYpLiBKdWRn
aW5nIGZyb20gdGhlIHNpemUgb2YgaXQsIGl0IHByb2JhYmx5CmluY2x1ZGVzIENKSyBjaGFyYWN0
ZXJzLgoKRG9lcyBhbnlvbmUga25vdyBob3cgdG8gbGljZW5zZSB0aGlzIGZvbnQgZm9yIHJlZGlz
dHJpYnV0aW9uIHdpdGggeW91ciBnYW1lPwo=

Re: [GD-General] ieee754 -0.0f?

[Ash H. <hen...@gm...>]

Indeed you are right. I'll be off hanging my head somewhere...

;)

Regardless, it's pretty horrible thing to be doing. I think I originally
wrote it to generate homework answers when I was doing my degree... hand
converting numerical representations in the exam room was perhaps one of th=
e
most boring tasks I've faced. And clearly it didn't help me remember
anything :)

On 2/2/06, Jon Watte <hp...@mi...> wrote:
>
>
> >     struct
> >     {
> >         unsigned m_mantissa : 24;
> >         unsigned m_exponent : 7;
> >         unsigned m_sign : 1;
> >     };
>
>
> I believe the mantissa is only 23 bits, with a leading "implicit" one
> for all exponents that aren't denormal. There are also 8 exponent bits.
>
> Cheers,
>
>                         / h+
>
>
> --
> -- The early bird gets the worm, but the second mouse gets the cheese.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>

Re: [GD-General] ieee754 -0.0f?

[Jon W. <hp...@mi...>]

>     struct
>     {
>         unsigned m_mantissa : 24;
>         unsigned m_exponent : 7;
>         unsigned m_sign : 1;
>     };


I believe the mantissa is only 23 bits, with a leading "implicit" one 
for all exponents that aren't denormal. There are also 8 exponent bits.

Cheers,

			/ h+


-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

Re: [GD-General] ieee754 -0.0f?

[Ash H. <hen...@gm...>]

Peter's earlier message with the union reminded me of some old, (horribly
non portable) code I had lying around. Marginally useful for fiddling with
float values, but mostly just a peculiarity. Scary :)

union __float
{
    struct
    {
        unsigned m_mantissa : 24;
        unsigned m_exponent : 7;
        unsigned m_sign : 1;
    };

    int m_int;
    unsigned int m_uint;
    float m_float;

    // -- a few implicit conversions
    __float(float _f) { m_float =3D _f; }
    __float(int _i) { m_int =3D _i; }
    __float(unsigned int _i) { m_uint =3D _i; }
};

#ifdef _DEBUG
#define float __float
#endif

int _tmain(int argc, _TCHAR* argv[])
{
    float f =3D 0;

    /* -- can set in VC debugger; the one I have here you can at least
    f.m_sign =3D 1;
    f.m_exponent =3D 0;
    f.m_mantissa =3D 0;
    */

    void* p =3D *(reinterpret_cast<void**>(&f));
    ::printf("%.16e =3D %p\n", f.m_float, p);

    return 0;
};

-- Ash.

On 2/1/06, Andras Balogh <and...@gm...> wrote:
>
> > Notice in my previous post that I did "float b =3D 0.0f/-1.0f" ?
>
> Yep, I did, and already answered that, it's just that the turnaround of
> this mailing list is somewhat slow, so we are always one post behind :)
>
>
>
> andras
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>

Re: [GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

> Notice in my previous post that I did "float b = 0.0f/-1.0f" ?

Yep, I did, and already answered that, it's just that the turnaround of  
this mailing list is somewhat slow, so we are always one post behind :)



andras

Re: [GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

Hah, there's the problem! Your program gives me the expected result, but  
if I replace "0.0f/-1.0f" to simply "-0.0f", then I get the wrong result!


andras

On Wed, 01 Feb 2006 11:19:40 -0700, Jim Tilander <jim...@gm...>  
wrote:

> I don't have VC6 here, but for VC7 on a regular P4 box the following
> produces the expected results:
>
> #include <cstdio>
>
> void main()
> {
>     float a = 0.0f;
>     float b = 0.0f/-1.0f;
>
>     printf( "%f = 0x%8.8x\n", a, *(int*)&a );
>     printf( "%f = 0x%8.8x\n", b, *(int*)&b );
> }
>
>
> /j
>

Re: [GD-General] ieee754 -0.0f?

[Jim T. <jim...@gm...>]

Andreas,

Seems like the visual compiler tries to be smart when you say "float b =3D =
-
0.0f;", the outputed assembly looks like this:

mov    DWORD PTR _b$[ebp], 0

Notice in my previous post that I did "float b =3D 0.0f/-1.0f" ? That force=
s
the compiler to output:

mov    DWORD PTR _b$[ebp], -2147483648        ; 80000000H

/j

On 2/1/06, Andras Balogh <and...@gm...> wrote:
>
> Well, I've thought about that too, I'm running in debug mode, no
> optimizations and using improved floating point consistency (/Op). Still,
> -0.0f gives me 0x00000000..
>
> On Wed, 01 Feb 2006 11:15:54 -0700, Ash Henstock <hen...@gm...>
> wrote:
>
> > Hi Andras,
> >
> > I suspect you've got "Fast" floating point model selected in VS project
> > options (check in C++->Code Generation I think).
> > Running your code here with Strict or Precise gives:
> > -0.000000 =3D 80000000
> > but it falls down how you describe (00000000), with Fast selected.
> >
> > (Turion 64 MSVC8 here).
> >
> > Cheers.
> >
> > -- Ash.
> >
> > On 2/1/06, Andras Balogh <and...@gm...> wrote:
> >>
> >> > They are different, on an IEEE compliant system.
> >>
> >> Yeah, I know, that's why I'm surprised! :)
> >>
> >> > -0.0 =3D 0xbf800000
> >> > +0.0 =3D 0x3f800000
> >>
> >> These are -1.0f and +1.0f, but yeah, I've got the point.
> >>
> >> > You didn't mention the language or how you're generating those
> values.
> >> > Using VC6 on a Pentium-M by setting global floats I get the correct
> >> > and expected values.
> >>
> >> VS7.1 running on Athlon64, see source in previous post.
> >>
> >>
> >> thanks,
> >>
> >>
> >>
> >> Andras
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>

Re: SPAM Re: [GD-General] ieee754 -0.0f?

[Peter <pe...@to...>]

then it's your compiler. When it translates the string/token "-0.0f" 
apparently it's smart enough to generate a 'real' zero. I don't know of 
any requirement that a compiler supports explicit generation of -0 in 
any form; only that its underlying math behaves correctly.
  So if you try this:
union { unsigned int asUInt; float asFloat; } val;  val.asUInt = 
0x80000000; printf("%f",val.asFloat);
  you -may- see -0.0f depending on whether your printf implementation 
cares to show the difference!  Personally I've frequently been bitten by 
quirks in the way a debugger's windows accept input or display output - 
you need to look at a hex or binary display of memory and registers, and 
use an assembly (rather than source-level) debug, to be sure of what's 
really happening.

Peter

Andras Balogh wrote:

> I run this code:
>
> float f = -0.0f;
> void* p = *(reinterpret_cast<void**>(&f));
> ::printf("%f = %p\n", f, p);
>
> And it prints all zeroes. For any other number I see the correct  
> hexadecimal representation of the float number.
>
>
> Thanks,
>
> Andras
>
>
>
> On Wed, 01 Feb 2006 10:32:28 -0700, Peter <pe...@to...> wrote:
>
>> what is the context here?  If you're interpreting 0x80000000 (32 bit  
>> int) as a 32-bit IEEE float it's -0.0f   and 0x00000000 is 0.0f.
>>   Where are you seeing the -0.0f? In a debugger? I think you must be  
>> seeing some idiosyncrasy of your development environment or toolchain.
>>
>> Andras Balogh wrote:
>>
>>> I know that -0.0f == +0.0f is true, but the floating point  
>>> representation  of the two numbers should be different, no? 
>>> Shouldn't  the negative zero  have the sign bit set? Well, on my 
>>> machine -0.0 and  0.0 are bitwise  equal!! What's going on here?
>>>
>>> thx,
>>>
>>>
>>> Andras
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

Re: [GD-General] ieee754 -0.0f?

[Brian H. <ho...@bo...>]

> Hmmm, are you sure about those values? It thought the following was
> true:

No, I'm a dumbass.  In my curry to cut and paste I used -1 and +1.   
Sorry for any confusion =3D/

On VC6 it does report 0x00000000 for both -0 and +0.

Brian

Re: [GD-General] ieee754 -0.0f?

[Andras B. <and...@gm...>]

Well, I've thought about that too, I'm running in debug mode, no  
optimizations and using improved floating point consistency (/Op). Still,  
-0.0f gives me 0x00000000..

On Wed, 01 Feb 2006 11:15:54 -0700, Ash Henstock <hen...@gm...>  
wrote:

> Hi Andras,
>
> I suspect you've got "Fast" floating point model selected in VS project
> options (check in C++->Code Generation I think).
> Running your code here with Strict or Precise gives:
> -0.000000 = 80000000
> but it falls down how you describe (00000000), with Fast selected.
>
> (Turion 64 MSVC8 here).
>
> Cheers.
>
> -- Ash.
>
> On 2/1/06, Andras Balogh <and...@gm...> wrote:
>>
>> > They are different, on an IEEE compliant system.
>>
>> Yeah, I know, that's why I'm surprised! :)
>>
>> > -0.0 = 0xbf800000
>> > +0.0 = 0x3f800000
>>
>> These are -1.0f and +1.0f, but yeah, I've got the point.
>>
>> > You didn't mention the language or how you're generating those values.
>> > Using VC6 on a Pentium-M by setting global floats I get the correct
>> > and expected values.
>>
>> VS7.1 running on Athlon64, see source in previous post.
>>
>>
>> thanks,
>>
>>
>>
>> Andras