gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] MFC and libc linker error

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Thanks, that is the ticket.  I forgot to look in MSDN.

Jake

-----Original Message-----
From: Joscha Metze [mailto:jo...@re...]
Sent: 30 April 2002 16:20
To: gam...@li...
Subject: Re: [GD-Windows] MFC and libc linker error


Hi Jacob,
you have to use the /nodefaultlib linker param.
You have to specify the lib you don't want to include. In your case 
it should be libcmtd. There is a different combination for each 
mfc/threading/debug combination. Look up in the msdn library for more 
information. There is a whole section about this problem.
Hope this helps
Joscha

Jacob wrote:
>>Developing simple MFC app and it is all going fine, just added a 
>>load of our
>>common source files into the project and now getting the following 
>>errors.

>>nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
>>new(unsigned int)" (??2@YAPAXI@Z) already defined in 
>>LIBCMTD.lib(new.obj)

>>nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator 
>>delete(void
>>*)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)

>>Now I have no idea why MSVC can't sort out which new to use, I 
>>don't think I
>>am explictly telling it to use the libc version ?

>>I have had this before but can't remember how I fixed it.  The last 
>>time it
>>happened I deleted all the source files and then added them in 1 by 
>>1 and it
>>all worked.  I have tried doing that this time but to no avail.




_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

[GD-Windows] memory allocation routine with alignment

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Is there a windows equivalent for GCC memalign() which is like malloc but
you can speficy the byte alignment you want for the ptr e.g. memalign( 64,
1000 ); will return a ptr which is 1000 bytes long and starts on a 64-byte
boundary.

Cheers

Jake

Re: [GD-Windows] MFC and libc linker error

[Joscha M. <jo...@re...>]

Hi Jacob,
you have to use the /nodefaultlib linker param.
You have to specify the lib you don't want to include. In your=
 case 
it should be libcmtd. There is a different combination for each 
mfc/threading/debug combination. Look up in the msdn library for=
 more 
information. There is a whole section about this problem.
Hope this helps
Joscha

Jacob wrote:
>>Developing simple MFC app and it is all going fine, just added=
 a 
>>load of our
>>common source files into the project and now getting the=
 following 
>>errors.

>>nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl=
 operator
>>new(unsigned int)" (??2@YAPAXI@Z) already defined in 
>>LIBCMTD.lib(new.obj)

>>nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator=
 
>>delete(void
>>*)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)

>>Now I have no idea why MSVC can't sort out which new to use, I=
 
>>don't think I
>>am explictly telling it to use the libc version ?

>>I have had this before but can't remember how I fixed it.  The=
 last 
>>time it
>>happened I deleted all the source files and then added them in=
 1 by 
>>1 and it
>>all worked.  I have tried doing that this time but to no=
 avail.

[GD-Windows] MFC and libc linker error

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

Developing simple MFC app and it is all going fine, just added a load of our
common source files into the project and now getting the following errors.

nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMTD.lib(new.obj)

nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void
*)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)

Now I have no idea why MSVC can't sort out which new to use, I don't think I
am explictly telling it to use the libc version ?

I have had this before but can't remember how I fixed it.  The last time it
happened I deleted all the source files and then added them in 1 by 1 and it
all worked.  I have tried doing that this time but to no avail.

Any suggestions ?

Cheers

Jake

RE: [GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

At 09:36 AM 4/28/2002 -0700, Jon Watte wrote:
>Yeah, that'd do it. If you count it, you're running with only a single
>buffer, if this is what you're doing.

Yeah, that was part of me being lazy and tired -- I didn't run through 
simulation steps.

> > Changing it to this fixed it:
> >
> > waveOutWrite( nextBuffer );
> > fillBuffer( completedBuffer );
> > waveOutWrite( completedBuffer ); //keep the chain going
>
>This can't possibly work right, as you enqueue two buffers for each
>buffer played. I think you actually mean something else, such as
>just calling fillBuffer() and waveOutWrite().

Actually, using your nomenclature, where "nextBuffer" indicates the 
"nextBuffer to be filled", I was doing this:

waveOutWrite( ( nextBuffer + 1 ) % 3 );
fillBuffer( nextBuffer );
waveOutWrite( nextBuffer );
nextBuffer = ( nextBuffer + 1 ) % 3;

And you're right, it didn't make sense -- it WORKED, but only because 
waveOutWrite is friendly when you send it a buffer it can't use.  In the 
case of the first completion, nextBuffer+1 would have pointed to a 
previously INQUEUED buffer, generating an error (which would be silent if 
the return values weren't checked...fwiw, the return value was '33', which 
isn't an MMSYSERR_xxxx).

So basically that first waveOutWrite() wasn't doing anything -- in fact, it 
was a legacy of my initial implementation where I always tried to have a 
premixed buffer waiting to go next.  That is, the completion routine was 
expecting to dispatch _immediately_ to avoid any hiccups, it originally 
didn't have any other buffers queued waiting to go.

That's the problem with long debugging sessions -- you start getting old 
code interfering with new code, but you're so tired and pissed you're 
scared to change stuff that seemingly works =)

>setup:
>   memset( buffers[0], QUIET, SIZE );
>   memset( buffers[1], QUIET, SIZE );
>   memset( buffers[2], QUIET, SIZE );
>   prepareBuffer( 0 );
>   prepareBuffer( 1 );
>   prepareBuffer( 2 );
>   nextBuffer = 0;

That's exactly what I was doing.

>start:
>   queueBuffer( 0 );
>   queueBuffer( 1 );
>   queueBuffer( 2 );

Ayup.

>completion:
>   fillBuffer( nextBuffer );
>   queueBuffer( nextBuffer );
>   nextBuffer = (nextBuffer + 1) % 3;

Yup.

The above is pretty much identical to the code I have now, but with my last 
e-mail I had a spurious queueBuffer((nextBuffer+1)%3) before I did the fill 
buffer.

Brian

RE: [GD-Windows] Streaming WAVE audio

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

> I was counting on/assuming that the "waveOutWrite( nextBuffer )" would 
> eventually dispatch a buffer that was filled NUM_BUFFERS-1 notifications 
> ago, which apparently wasn't the case.

Yeah, that'd do it. If you count it, you're running with only a single 
buffer, if this is what you're doing.

> Changing it to this fixed it:
> 
> waveOutWrite( nextBuffer );
> fillBuffer( completedBuffer );
> waveOutWrite( completedBuffer ); //keep the chain going

This can't possibly work right, as you enqueue two buffers for each 
buffer played. I think you actually mean something else, such as 
just calling fillBuffer() and waveOutWrite().

For the benefit of other readers of this thread, I've always found 
this logic to be the most robust when playing audio:

unsigned char buffers[3][SIZE];
int nextBuffer;

setup:
  memset( buffers[0], QUIET, SIZE );
  memset( buffers[1], QUIET, SIZE );
  memset( buffers[2], QUIET, SIZE );
  prepareBuffer( 0 );
  prepareBuffer( 1 );
  prepareBuffer( 2 );
  nextBuffer = 0;

start:
  queueBuffer( 0 );
  queueBuffer( 1 );
  queueBuffer( 2 );

completion:
  fillBuffer( nextBuffer );
  queueBuffer( nextBuffer );
  nextBuffer = (nextBuffer + 1) % 3;


If there's a chance that you will lose completion events, then you 
can turn completion into a while loop:

completion_with_misses:
  while( bufferDone( nextBuffer ) ) {
    fillBuffer( nextBuffer );
    queueBuffer( nextBuffer );
    nextBuffer = (nextBuffer + 1) % 3;
  }


Note that this mechanism scales very well to different number of 
buffers, and the code is very clean and decision-free, which is 
always a plus. This structure will work fine with double-buffering 
(only two buffers) assuming the buffers are big enough for the 
inherent scheduling jitter of your platform (missing a single 
buffer in double-buffering means you'll probably hear it).


Cheers,

				/ h+

RE: [GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

Woo-hoo, found it!  And, of course, it was stupid programmer 
syndrome.  Specifically, I wasn't dispatching a buffer after filling it, 
instead I was waiting for it to get dispatched "when necessary".

My WOM_DONE handler was doing this:

waveOutWrite( nextBuffer );
fillBuffer( completedBuffer );

Changing it to this fixed it:

waveOutWrite( nextBuffer );
fillBuffer( completedBuffer );
waveOutWrite( completedBuffer ); //keep the chain going

I was counting on/assuming that the "waveOutWrite( nextBuffer )" would 
eventually dispatch a buffer that was filled NUM_BUFFERS-1 notifications 
ago, which apparently wasn't the case.

Or maybe something else was wrong, but this fixes it for now.  Seat of the 
pants, baby!

Brian

RE: [GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

At 04:31 PM 4/27/2002 -0700, Brian Hook wrote:
>This is an i815 board (my Win2K box), so I'm assuming that Intel's drivers 
>don't suck that bad.

Just to verify, this also occurred on a system with a different processor 
(Athlon), OS (WinXP) and sound card (Echo Mia), so it's probably not a 
driver thing.  I'm pretty sure it's a programmer thing.

Since it sounds like I'm doing everything right, I'm going to assume that 
it's just Stupid Programmer Syndrome and I'll try to figure it out from there.

Thanks!

Brian

RE: [GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

At 04:07 PM 4/27/2002 -0700, Jon Watte wrote:
>I suppose you mean CALLBACK_THREAD when you're actually using a
>thread.

Correct.

>Have you tried CALLBACK_EVENT and WaitForSingleObject as
>an alternative, btw?

Not yet, but I was hoping to avoid getting that desperate.

>Poor drivers?

This is an i815 board (my Win2K box), so I'm assuming that Intel's drivers 
don't suck that bad.

>Another thing to try is to use at least three buffers, possibly four,

I'm actually using three buffers right now, to no avail.  I fill and write 
them out when I start up to get the chain going, then when dealing with 
WOM_DONE I refill buffers that are WHDR_DONE and dispatch buffers that 
aren't (and which have presumably been filled previously).

>buffers powers of two in size, to work around some classes of bugs.

Did that, no difference.

>You also should not prepare a header more than once; prepare all the
>headers on start-up, then call waveOutWrite() in a cyclic fashion.

Yep, that's what I do.  They're all pointing to the same buffers through 
their lives:

GLOBAL char buffer[ 3 ][ 1024 ];

header[ 0 ].lpData = buffer[ 0 ];
header[ 0 ].dwLength = sizeof( buffer[ 0 ] );
waveOutPrepareHeader( ... );
//etc. etc.

>Another thing to look for is internal logic errors where you play
>the "wrong" buffer, and/or get out of sync if you miss one buffer.

That's what I'm thinking it is, but so far I don't see it.  It's probably a 
stupid bug on my part, unfortunately the tried-and-true "find the bug after 
sending an e-mail asking for help" trick didn't work this time =)

When processing WOM_DONE I do a bunch of sanity checks, including verifying 
that the buffer I'm writing is the next one that needs to be written; that 
the buffer I'm filling isn't INQUEUE; that the buffer I'm filling is 
DONE.  Should be pretty simple and straightforward.

>Last, you can poll the WHDR_DONE bit in the headers for the buffers,
>rather than relying on a callback to fill the buffers. This lets you
>use a model slightly closer to that of DirectSound.

Yes, I could do that, and I may once I get REAL desperate. I could poll the 
WHDR_DONE in a separate thread a la my DSound buffering version and go with 
that, but I have a feeling if I implement it that way that things won't 
actually get any better, I'll just have shifted around the problem.

Thanks!

Brian

RE: [GD-Windows] Streaming WAVE audio

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

> CALLBACK_FUNCTION

I suppose you mean CALLBACK_THREAD when you're actually using a 
thread. Have you tried CALLBACK_EVENT and WaitForSingleObject as 
an alternative, btw?

> Any suggestions on what else to look for that could be causing problems?

Poor drivers?

Having had access to WinCE drivers as "reference code" when writing 
device drivers, I'm underwhelmed by some of the vendors' approaches 
to quality. Others do OK.

Another thing to try is to use at least three buffers, possibly four, 
because some drivers may have implementation issues with you handing 
it "only" one fresh buffer of advance queue. Also try to make the 
buffers powers of two in size, to work around some classes of bugs.

You also should not prepare a header more than once; prepare all the 
headers on start-up, then call waveOutWrite() in a cyclic fashion. 
You're probably already doing this right. It may be that preparing 
a header that has already been prepared is not the efficient no-op 
you'd want it to be.

Another thing to look for is internal logic errors where you play 
the "wrong" buffer, and/or get out of sync if you miss one buffer. 
The safest and most predictable way to do this is to always copy data 
from the mixer function, and fill all buffers with zero before you 
start the device, rather than trying to pre-fill buffers with data. 
While this will result in a startup latency equal to the steady-state 
latency and some people think this is a draw-back, I think it's the 
right thing to do.

Last, you can poll the WHDR_DONE bit in the headers for the buffers, 
rather than relying on a callback to fill the buffers. This lets you 
use a model slightly closer to that of DirectSound.

Let us know when you find out what it is!

Cheers,

				/ h+

[GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

Yes, it's me with a remedial, way-back, old-school question.  However, this 
is because I'm working on WinCE 3.0 (my God, all those WinCE docs that show 
up in MSDN searches now MEAN something!).

Since WinCE/PPC2K lack Direct Sound, I have to do my own audio mixing into 
wave buffers.  Conceptually, this is simple, although some of the 
implementation details were a bit tough to find out (specifically, using a 
thread instead of a callback).

In a nutshell, I'm doing this in the straightforward fashion you'd expect, 
double buffering two audio buffers that are filled periodically.

fill( buffer[ 0 ] );
fill( buffer[ 1  ] );

Under Win32's waveOut interface, you can specify a thread to handle 
messages indicating WOM_DONE, WOM_OPEN, WOM_CLOSE.  This is pretty easy, 
you just CreateThread() and pass the identifier and CALLBACK_FUNCTION to 
waveOut Open.

That much works.

The thread function basically does this:

while ( GetMessage( ... )
{
    if ( msg == WOM_DONE )
    {
       waveOutWrite( nextBuffer );
       fill( bufferThatJustEnded );
    }
}

The above works as well, in that it doesn't crash =)

That's all a streaming WAVE audio subsystem should really need to do.  Of 
course, I do the necessary waveOutPrepareHeader, etc.

I'm doing this in 8-bit, mono, 11KHz format, and the device definitely 
supports it.  In fact, I have this code running on Win2000 just so that I 
can make sure it works on a desktop before moving to a PDA.

So the problem is that I'm getting dropouts and stuttering, echoing, and a 
host of other bad things.  I boosted the thread's priority to highest, and 
I also set my buffers to some arbitrarily huge sizes to see if it was 
underruns to no avail.  I check all the return values.

Everything looks fine.  I timed calls to WOM_DONE handling, and the delta 
times are the expected buffer sizes.  The mixing code is the same for OS X 
and DirectSound and works as expected.  Each buffer is 150ms, more than 
enough time to mix in some stuff (especially on a P3/1000).

So I'm at a loss what else could be causing problems.  Originally I was 
using a CALLBACK_FUNCTION, but that's somewhat problematic for other 
reasons (you can't call waveOutXXX functions within the callback, since 
that can cause a deadlock).

Any suggestions on what else to look for that could be causing problems?

Brian

RE: [GD-Windows] forcing value to bool 'true' or 'false' (perform ance warning)

[Tom F. <to...@mu...>]

You're surely not going to tell me that

bool b = i != 0;

doesn't involve a conditional.


Anyway, I remember somebody coming up with this:

bool b = ((unsigned int)(a|-a))>>31;

Whether in practice it's faster or not, I don't know, but there's no
conditional jumps required.


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Tom Hubina [mailto:to...@3d...]
> Sent: 23 April 2002 02:22
> To: gam...@li...
> Subject: Re: [GD-Windows] forcing value to bool 'true' or 'false'
> (performance warning)
> 
> 
> At 06:04 PM 4/22/2002, Rich wrote:
> >Well, the compiler will generate code to convert an int (4 
> bytes) to a
> >bool (usually 1 byte), whether or not it matters for performance is
> >dubious.
> >
> >You can eliminate the warning by doing 'bool p = i ? true : false;'
> 
> Icky. You don't need conditionals for this.
> 
> When I convert between int and bool I've been using the 
> following to get 
> rid of the warning:
> 
> bool p = i != 0;
> 
> or in the case of Win32 API stuff:
> 
> bool p = i != FALSE;
> 
> In any case ... the performance issue for most cases is 
> probably minimal. I 
> would only be concerned if I was doing it inside a tight loop 
> that got 
> called a lot and was actually showing up as a spike when 
> profiling. When in 
> doubt, check the assembly.
> 
> Tom
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

Re: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Rich <leg...@xm...>]

In article <5.1...@ma...>,
    Tom Hubina <to...@3d...>  writes:

> You don't need conditionals for this.

I didn't assert anything of the sort.

I simply said you can eliminate the warning that way.

I did not say it was the only way to eliminate the warning.

I did not say it was the best way to eliminate the warning.

I simply said it was -a- way.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

Re: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Rich <leg...@xm...>]

In article <HEE...@mi...>,
    "Jon Watte" <hp...@mi...>  writes:

> The re-write you propose will generate 
> a branch, which will not predict well, which is a REALLY bad thing.

Nonsense.  Nothing can universally be declared bad.

"Bad things" can only be measured in context.  You won't know if this
is good or bad (or even significant) until you profile your app and
determine that this is the limiting factor.  I'm highly dubious that
it ever will be -the- limiting factor, but even if it ever is, you
can't say that until you measure it and determine that to be the
case.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Brian S. <bs...@mi...>]

The compiler generated version doesn't cause a branch (this is VC 7):

752:          int a =3D 1000;
0003A370   mov         dword ptr [a],3E8h
753:          bool b =3D a;
0003A377   cmp         dword ptr [a],0
0003A37B   setne       al
0003A37E   mov         byte ptr [b],al

But it is using a register so that doesn't do the optimizer any favors.

--brian

> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...]=20
> Sent: Monday, April 22, 2002 6:16 PM
> To: Rich; gam...@li...
> Subject: RE: [GD-Windows] forcing value to bool 'true' or=20
> 'false' (performance warning)=20
>=20
>=20
>=20
> It's more than that. The problem is that any bytes in the int must=20
> count towards a "true" value. The re-write you propose will generate=20
> a branch, which will not predict well, which is a REALLY bad thing.
>=20
> Perhaps MSVC7 generates CMOV for this; I've never gotten MSVC 6 to=20
> do it unfortunately :-( Another branchless alternative (assuming=20
> they're OK with any non-0 value for "true" inside a bool, which may=20
> not be true) is to do some shifts and ors.
>=20
>   int i; bool b;
>=20
>   unsigned short temp16 =3D (i>>16) | i;
>   *(unsigned char *)&b =3D (temp16>>8) | temp16; // horrible!
>=20
> Cheers,
>=20
> 				/ h+
>=20
> > Well, the compiler will generate code to convert an int (4=20
> bytes) to a
> > bool (usually 1 byte), whether or not it matters for performance is
> > dubious.
> >=20
> > You can eliminate the warning by doing 'bool p =3D i ? true : =
false;'
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

Re: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Tom H. <to...@3d...>]

At 06:04 PM 4/22/2002, Rich wrote:
>Well, the compiler will generate code to convert an int (4 bytes) to a
>bool (usually 1 byte), whether or not it matters for performance is
>dubious.
>
>You can eliminate the warning by doing 'bool p = i ? true : false;'

Icky. You don't need conditionals for this.

When I convert between int and bool I've been using the following to get 
rid of the warning:

bool p = i != 0;

or in the case of Win32 API stuff:

bool p = i != FALSE;

In any case ... the performance issue for most cases is probably minimal. I 
would only be concerned if I was doing it inside a tight loop that got 
called a lot and was actually showing up as a spike when profiling. When in 
doubt, check the assembly.

Tom

RE: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Brian S. <bs...@mi...>]

If you look at the disassembly you'll see it's a little bit more than
that, it also has to clamp any integer to the value of "true", which is
1 in the VC++ implementation.  Essentially, it does implicitly what your
"?" expression does explicitly.

--brian

> -----Original Message-----
> From: Rich [mailto:leg...@xm...]=20
> Sent: Monday, April 22, 2002 6:04 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] forcing value to bool 'true' or=20
> 'false' (performance warning)=20
>=20
>=20
>=20
> In article <000901c1ea5a$ca4377e0$dc56533e@aurora>,
>     =3D?iso-8859-1?Q?Ignacio_Casta=3DF1o?=3D <cas...@ya...>  =
writes:
>=20
> > does somebody knows why msvc complains about a performance=20
> warning when
> > converting an integer into a bool value? Is there really=20
> any performance
> > hit?
>=20
> Well, the compiler will generate code to convert an int (4 bytes) to a
> bool (usually 1 byte), whether or not it matters for performance is
> dubious.
>=20
> You can eliminate the warning by doing 'bool p =3D i ? true : false;'
> --=20
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     izfree: Open source tools for Windows Installer
>             <http://izfree.sourceforge.net>
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

RE: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

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

It's more than that. The problem is that any bytes in the int must 
count towards a "true" value. The re-write you propose will generate 
a branch, which will not predict well, which is a REALLY bad thing.

Perhaps MSVC7 generates CMOV for this; I've never gotten MSVC 6 to 
do it unfortunately :-( Another branchless alternative (assuming 
they're OK with any non-0 value for "true" inside a bool, which may 
not be true) is to do some shifts and ors.

  int i; bool b;

  unsigned short temp16 = (i>>16) | i;
  *(unsigned char *)&b = (temp16>>8) | temp16; // horrible!

Cheers,

				/ h+

> Well, the compiler will generate code to convert an int (4 bytes) to a
> bool (usually 1 byte), whether or not it matters for performance is
> dubious.
> 
> You can eliminate the warning by doing 'bool p = i ? true : false;'

Re: [GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[Rich <leg...@xm...>]

In article <000901c1ea5a$ca4377e0$dc56533e@aurora>,
    =?iso-8859-1?Q?Ignacio_Casta=F1o?= <cas...@ya...>  writes:

> does somebody knows why msvc complains about a performance warning when
> converting an integer into a bool value? Is there really any performance
> hit?

Well, the compiler will generate code to convert an int (4 bytes) to a
bool (usually 1 byte), whether or not it matters for performance is
dubious.

You can eliminate the warning by doing 'bool p = i ? true : false;'
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

[GD-Windows] forcing value to bool 'true' or 'false' (performance warning)

[<cas...@ya...>]

Hi,
does somebody knows why msvc complains about a performance warning when
converting an integer into a bool value? Is there really any performance
hit?

Thanks in advance,

Ignacio Castaño
ca...@as...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [GD-Windows] CreateFont question

[Brian H. <bri...@py...>]

At 11:28 AM 4/19/2002 +0100, Andrew Grant wrote:
>This value is retrieved via GetDeviceCaps(LOGPIXELSY), so infact it's you 
>yourself who is scaling your font up, not Windows :)

Well, that'll teach me to cut and paste the sample code from MSDN =)

I'll give that a whack and go with it. Thanks!

Brian

Re: [GD-Windows] CreateFont question

[Andrew G. <ag...@cl...>]

Brian,

I had the same problem a few years ago. by default Windows defines a logical
screen inch as 96 pixels high, with large fonts this is 120 pixels. Also in
Win98 and later the user is capable of specifying other values via control
panel which can be even be < 96 or > 120.

This value is retrieved via GetDeviceCaps(LOGPIXELSY), so infact it's you
yourself who is scaling your font up, not Windows :)

Use 96 rather than the value from GetDeviceCaps, this should give you a
consistent font size no matter what size fonts the user has set.


Andrew Grant -
Climax Brighton 


----- Original Message ----- 
From: "Brian Hook" <bri...@py...>
To: "'GDWindows'" <gam...@li...>
Sent: Friday, April 19, 2002 12:18 AM
Subject: [GD-Windows] CreateFont question


> I'm using CreateFont() to make a font for high scores, statistics, etc.
> I'm doing a pretty vanilla call:
> 
>     hFont = CreateFont( -MulDiv( kiPointSize, GetDeviceCaps( hDC,
> LOGPIXELSY ), 72 ),// nHeight
>                        0,
> // nWidth
>                        0,
> // nEscapement
>                        0,
> // nOrientation
>                        FW_BOLD,
> // fnWeight
>                        FALSE,
> // fdwItalic
>                        FALSE,
> // fdwUnderline
>                        FALSE,
> // fdwStrikeout
>                        OEM_CHARSET,
> // fdwCharSet
>                        OUT_DEFAULT_PRECIS,
> // fdwOutputPrecision
>                        CLIP_DEFAULT_PRECIS,
> // fdwClipPrecision
>                        DEFAULT_QUALITY,
> // fdwQuality
>                        FF_MODERN | FIXED_PITCH,
> // fdwPitchAndFamily
>                        NULL );
> // typeface name
> 
> The problem is that on systems where the user has selected "Big Fonts",
> I always get vastly oversized fonts that don't fit in my various text
> boxes.  Anyone have suggestions on what to do in such cases?
> 
> The obvious alternative is to do my own font handling, but for various
> reasons I'd prefer to avoid that (specifically, internationalization
> issues).
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] CreateFont question

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

One thing that works is to decide on the max size you want (height 
and width) for the text, and then create the font using various 
sizes, using binary search to find the font size that best fills 
the area in question. 

The text you want to display could be some well-known string, so 
you know what'll happen for a number of common easily testable 
fonts, and at least have some hope of having a readable screen 
when a user prefers Atlantis Parade Demi Black and enters her name 
in Kanji or something.

Cheers,

				/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, April 18, 2002 4:19 PM
> To: 'GDWindows'
> Subject: [GD-Windows] CreateFont question
> 
> 
> I'm using CreateFont() to make a font for high scores, statistics, etc.
> I'm doing a pretty vanilla call:
> 
>     hFont = CreateFont( -MulDiv( kiPointSize, GetDeviceCaps( hDC,
> LOGPIXELSY ), 72 ),// nHeight
>                        0,
> // nWidth
>                        0,
> // nEscapement
>                        0,
> // nOrientation
>                        FW_BOLD,
> // fnWeight
>                        FALSE,
> // fdwItalic
>                        FALSE,
> // fdwUnderline
>                        FALSE,
> // fdwStrikeout
>                        OEM_CHARSET,
> // fdwCharSet
>                        OUT_DEFAULT_PRECIS,
> // fdwOutputPrecision
>                        CLIP_DEFAULT_PRECIS,
> // fdwClipPrecision
>                        DEFAULT_QUALITY,
> // fdwQuality
>                        FF_MODERN | FIXED_PITCH,
> // fdwPitchAndFamily
>                        NULL );
> // typeface name
> 
> The problem is that on systems where the user has selected "Big Fonts",
> I always get vastly oversized fonts that don't fit in my various text
> boxes.  Anyone have suggestions on what to do in such cases?
> 
> The obvious alternative is to do my own font handling, but for various
> reasons I'd prefer to avoid that (specifically, internationalization
> issues).
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] CreateFont question

[Brian H. <bri...@py...>]

I'm using CreateFont() to make a font for high scores, statistics, etc.
I'm doing a pretty vanilla call:

    hFont = CreateFont( -MulDiv( kiPointSize, GetDeviceCaps( hDC,
LOGPIXELSY ), 72 ),// nHeight
                       0,
// nWidth
                       0,
// nEscapement
                       0,
// nOrientation
                       FW_BOLD,
// fnWeight
                       FALSE,
// fdwItalic
                       FALSE,
// fdwUnderline
                       FALSE,
// fdwStrikeout
                       OEM_CHARSET,
// fdwCharSet
                       OUT_DEFAULT_PRECIS,
// fdwOutputPrecision
                       CLIP_DEFAULT_PRECIS,
// fdwClipPrecision
                       DEFAULT_QUALITY,
// fdwQuality
                       FF_MODERN | FIXED_PITCH,
// fdwPitchAndFamily
                       NULL );
// typeface name

The problem is that on systems where the user has selected "Big Fonts",
I always get vastly oversized fonts that don't fit in my various text
boxes.  Anyone have suggestions on what to do in such cases?

The obvious alternative is to do my own font handling, but for various
reasons I'd prefer to avoid that (specifically, internationalization
issues).

Brian

RE: [GD-Windows] ADSL firewall networking problems

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

> What kind of firewalling/NAT/proxies are typical with ADSL
> providers? ADSL is not offered in our corner of Europe
> and thus it caught us entirely by surprise.

Many ADSL set-ups use NAT. Problems with NAT come when you 
need to send packets "in" to the user, who are not "replies" 
to packets going "out" from the user. This may be information 
you already know, but it bears repeating:

If you have this situation:

Server <---> NAT <---> User

NAT is the gateway for the User. The User creates and binds 
a socket, which gets a local port number Pu on the User machine 
with address Au. He then uses this socket to sendto() some 
remote port number Ps.

NAT will re-write the "source" address/port field to some 
NAT-local port Pn, and using the external NAT gateway address 
An. NAT remembers the tuple Pn->Au/Pu.

The Server gets a packet, and looks at the recvfrom() address 
to figure out the return address: the server sees An/Pn. 
Server figures out what data to send to the User, and sends it 
back to An/Pn.

NAT box sees a packet arriving at Pn, and looks up Pn in his 
translation table. If found, he forwards it to Au/Pu, re-writing 
the "destination" header, and the User sees the packet as if 
nothing had happened.


The problem comes if you send or use IP addresses or ports that 
are not part of the headers that get correctly re-written by 
NAT. If you have a field in your packet that says "IP address" 
or "IP port", then your protocol is fundamentally broken from 
the point of view of NAT. Some famous fundamentally broken 
protocols include FTP and H.320, so you'd be in good company :-) 
Part of NAT friendly protocol design is to only use the addresses 
as seen by sendto() and recvfrom(), and not put addressing data 
in your data packet.

If you're using peer-to-peer networking, it gets even more 
exciting, because some "server" may tell a "user" about some 
other "user" he's supposed to communicate to. This counts as 
"IP/port" data which is part of your packet, and thus won't get 
properly re-written by NAT.

As you can see, nobody who "listens" for "remote" connections, as 
opposed to "initiating" them, can sit behind NAT, unless you make 
the NAT explicitly aware of this port and forwards the port 
traffic to some specific listener inside the translated network.

If you're trying to get peer-to-peer working when both peers are 
behind one NAT box each, and the NAT boxes don't support custom 
port forwarding (or the users don't set it up) you're never going 
to get it to work, unless you use some external third server 
which sends what amounts to properly forged packets to introduce 
the two sites to each other. Most hosting/service providers don't 
take kindly to you doing IP forgery, so I'd be hesitant to base a 
business on being able to do that.


Cheers,

			/ h+