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

RE: [GD-Windows] BitBlt() syncing to VBL

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

At 10:45 AM 1/15/2002, Jon Watte wrote:

>For what it's worth, when I was doing Mac programming, the Apple line
>was always:
>
>       "You should assume that CopyBits() is written by super intelligent
>        space aliens and will always perform optimally."

Sadly, CopyBits() is _much_ slower than a memcpy() buried in a for loop. So 
much for super intelligent space aliens :P

Tom

RE: [GD-Windows] BitBlt() syncing to VBL

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

For what it's worth, when I was doing Mac programming, the Apple line 
was always:

      "You should assume that CopyBits() is written by super intelligent 
       space aliens and will always perform optimally."

Cheers,

			/ h+

> I'm either doing something terribly wrong on the Windows side, or the
> Mac has some kind of mad, stupid Altivec optimized memcpy()/CopyBits().

RE: [GD-Windows] BitBlt() syncing to VBL

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

> A lot of what you're describing is surprising.  When I was 
> doing Mac stuff PCI video was the high end and NuBus was more 
> common, so that's a ways away from your G4 - but I never had 
> an app that ran faster on the Mac than the PC.

Well, Macs have gotten out of the Stone Age and are somewhere in the
Iron Age, so they at least have AGP now =)

> Also, what you say about DDraw blits seems strange.

Well, it was a bit of an unfair comparison.  With DDraw I was always
assuming that the source surface had transparency, even if it didn't, so
I'm sure it was going through a slower path than necessary.  With my GDI
blitter, I have separate opaque and transparent blitters.
 
> You also don't mention if you're page flipping, which would 
> obviously lock you to the refresh rate.

Nope.  This is on OS X using off-screen Gworlds and CopyBits().  This is
pretty much the MacOS equivalent to DIBSections and BitBlt().  In fact,
I should have even WORSE performance under OS X because I'm actually
triple buffering -- my blit goes into the window's off-screen
backbuffer, which is then blitted by the OS later.  Under Windows I'm
just going straight from DIB section to the Window's front buffer (in
theory).

My guess is that there's still some VBL action going on somewhere (note:
the Mac also VBLs, even though I'm getting 125fps, but the triple
buffering is probably accelerating things by allowing multiple blits in
a single refresh?), since I'm locked very close to my monitor's
ostensible frame rate.

I've tried disabling all the various "sync" parameters in the driver
properties, but to no avail.

I do find this quite a bit odd simply because I was expecting to do a
lot of optimization work on the Mac since the Mac has a slower clock
speed and significantly less memory bandwidth.  My nearest guess is that
I'm either doing something terribly wrong on the Windows side, or the
Mac has some kind of mad, stupid Altivec optimized memcpy()/CopyBits().

-Brian

RE: [GD-Windows] BitBlt() syncing to VBL

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

A lot of what you're describing is surprising.  When I was doing Mac
stuff PCI video was the high end and NuBus was more common, so that's a
ways away from your G4 - but I never had an app that ran faster on the
Mac than the PC.

Also, what you say about DDraw blits seems strange.  Given that memcpy
blitters are so easy to write, don't you think that the DX team would
have used memcpy if it was dramatically faster? :)  I'm not saying
you're wrong, I haven't tested it myself, it just seems strange.

You also don't mention if you're page flipping, which would obviously
lock you to the refresh rate.  DrawSprocket and QuickDraw don't support
page flipping (this is on pre-OSX) so that could be letting your Mac app
run faster than your PC.  On OSX, I don't know what the state of affairs
is.

Sorry that none of that really helps your problem,

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Tuesday, January 15, 2002 8:13 AM
To: gam...@li...
Subject: [GD-Windows] BitBlt() syncing to VBL


My blitting code on a PowerMac G4/867 is running over 50% faster than on
a=20
PC of higher clock speed (and with a faster video card to boot).  It
feels=20
like it's syncing to VBL on the PC -- 75fps on a 76Hz LCD -- but I was=20
under the impression that GDI's BitBlt() doesn't sync to VBL.  Is this
not=20
the case?  I was getting the distinct feeling that it was syncing to VBL

using DDraw's Blt() function, which is one reason I switched to GDI (not
to=20
mention that blitting using memcpy() has proven to be light years faster

than using DDraw's blitters).

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] BitBlt() syncing to VBL

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

My blitting code on a PowerMac G4/867 is running over 50% faster than on a 
PC of higher clock speed (and with a faster video card to boot).  It feels 
like it's syncing to VBL on the PC -- 75fps on a 76Hz LCD -- but I was 
under the impression that GDI's BitBlt() doesn't sync to VBL.  Is this not 
the case?  I was getting the distinct feeling that it was syncing to VBL 
using DDraw's Blt() function, which is one reason I switched to GDI (not to 
mention that blitting using memcpy() has proven to be light years faster 
than using DDraw's blitters).

Brian

Re: [GD-Windows] XLATEOBJ_hGetColorTransform

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

Brian Hook wrote:
> e.g. 15, 16, 24 and 32-bit blitters would be reasonably easy to write,
> but it would add a considerable amount of ugliness to the code -- and
> that's assuming that I don't have to deal with different masks and
> offsets for RGB within a format.

unless you use Hermes (http://www.clanlib.org/hermes/index.html), that does
all the dirty work for you.
I haven't used it, but the having read the docs, it seems to be very easy to
use.



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



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

RE: [GD-Windows] XLATEOBJ_hGetColorTransform

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

Well, I didn't want to use DDBs because right now my blitter
architecture is structured to support 16-bit sprite->backbuffer blits
and a 16-to-N-bit backbuffer->frontbuffer blit.  I don't mind letting
Windows handle the color transform, I was just hoping that in the cases
where it WAS unity, that it would be fast.

The problem with DDBs is then I have to write a bunch of different
blitters for a bunch of different formats.  It may not be all that bad,
e.g. 15, 16, 24 and 32-bit blitters would be reasonably easy to write,
but it would add a considerable amount of ugliness to the code -- and
that's assuming that I don't have to deal with different masks and
offsets for RGB within a format.

Oh well, guess you can't have everything =)

Brian

> Have you tried using DDBs instead of DIBs? You should get 
> better performance that way because they should be stored in 
> a device friendly way. Might be worth doing a quick DDB v DIB 
> performance comparison. I'd certainly be interested in the result :)
> 
> Andrew Grant
> Hothouse Creations 

RE: [GD-Windows] XLATEOBJ_hGetColorTransform

[Andrew G. <And...@ho...>]

Have you tried using DDBs instead of DIBs? You should get better performance
that way because they should be stored in a device friendly way. Might be
worth doing a quick DDB v DIB performance comparison. I'd certainly be
interested in the result :)

Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 09 January 2002 02:55
> To: bri...@py...; 'Gamedevlists-Windows@Lists. Sourceforge.
> Net'
> Subject: [GD-Windows] XLATEOBJ_hGetColorTransform
> 
> 
> It looks like about 20% of my time is spent in BitBlt() via 
> DIBsections.
> Of that time, this funky call to XLATEOBJ_hGetColorTransform is
> consuming like 98% of the time.  I'm guessing from the name that it's
> doing a color transform from my DIB to the screen, however both are in
> 16-bit.  So I'm figuring one of two things is going on:
> 
> - BitBlt() doesn't detect the unity situation with DIB sections
> 
> - even though the DIB is 16-bits and the framebuffer is 
> 16-bits, they're
> both "different" 16-bits.  If this is the case, is there a 
> way to query
> for the native format to allow for a unity blit?
> 
> And just think, we were wondering if there was even going to 
> be traffic
> on a Windows list that didn't talk about DX =)
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

Re: [GD-Windows] XLATEOBJ_hGetColorTransform

[Kent Q. <ken...@co...>]

Did you ever try to write a bitblt operator? Back in the day, I used to
write video driver code. There are about a zillion cases. As I
understand it, BitBlt has a code generator writes code to do the
specific blt needed and then calls it.

I don't know for sure, but I'd guess that one of several things could be
going on here:

* GetColorTransform isn't really what's going on, that's just the name
your profiler is assigning to the generated code.
* GetColorTransform is the compiler that writes the blt, and the actual
blt operation takes almost no time.
* The fact that your read and write don't have the same alignment is
causing trouble.
* You're right, and you don't actually have the same 16-bit buffer
layout.

How 'bout doing trying it in 24-bit or 32-bit mode and profiling that to
see where the time is spent? It'd at least be one way to confirm or deny
your supposition.

       Kent


Brian Hook wrote:
> 
> It looks like about 20% of my time is spent in BitBlt() via DIBsections.
> Of that time, this funky call to XLATEOBJ_hGetColorTransform is
> consuming like 98% of the time.  I'm guessing from the name that it's
> doing a color transform from my DIB to the screen, however both are in
> 16-bit.  So I'm figuring one of two things is going on:
> 
> - BitBlt() doesn't detect the unity situation with DIB sections
> 
> - even though the DIB is 16-bits and the framebuffer is 16-bits, they're
> both "different" 16-bits.  If this is the case, is there a way to query
> for the native format to allow for a unity blit?

-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________

[GD-Windows] XLATEOBJ_hGetColorTransform

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

It looks like about 20% of my time is spent in BitBlt() via DIBsections.
Of that time, this funky call to XLATEOBJ_hGetColorTransform is
consuming like 98% of the time.  I'm guessing from the name that it's
doing a color transform from my DIB to the screen, however both are in
16-bit.  So I'm figuring one of two things is going on:

- BitBlt() doesn't detect the unity situation with DIB sections

- even though the DIB is 16-bits and the framebuffer is 16-bits, they're
both "different" 16-bits.  If this is the case, is there a way to query
for the native format to allow for a unity blit?

And just think, we were wondering if there was even going to be traffic
on a Windows list that didn't talk about DX =)

Brian

Re: [GD-Windows] Keyboard lag

[Pierre T. <p.t...@wa...>]

> You might want to try to disable the TranslateMessage call in your message
> loop (in case it exists), which seems to cause problems similiar to those
> you describe.

Eh ?!
I have a TranslateMessage indeed. Well, I had. I currently don't see the lag
anymore so maybe that was it (until it shows up again). In any case, thanks.

This gives birth to a new question anyway : is there a standard "best"
message loop for typical cases such as games or realtime 3D applications ?
Or : are there other things like that I should know ... ? It seems pretty
important to know TranslateMessage could yield problems, yet that's the
first time I read about it. (I'm admittedly not the Windows expert)

Pierre

RE: [GD-Windows] Keyboard lag

[Ron N. <Ron...@gm...>]

You might want to try to disable the TranslateMessage call in your message
loop (in case it exists), which seems to cause problems similiar to those
you describe.

-- Ron

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Tuesday, January 08, 2002 8:40 PM
> To: Pierre Terdiman; 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> Subject: RE: [GD-Windows] Keyboard lag
>
>
> I'm seeing the same (using WM_* for keyboard input).
>
> -- Daniel, Epic Games Inc.
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On
> Behalf Of Pierre
> Terdiman
> Sent: Tuesday, January 08, 2002 2:15 PM
> To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> Subject: [GD-Windows] Keyboard lag
>
>
> Hi everyone,
>
> When I keep a key pressed (e.g. pressing say "z" and keeping it
> down) my app
> starts "stuttering", as if there was a big lag in certain frames.
> It doesn't
> seem to always happen, and I'm not doing any special
> keyboard-related stuff,
> AFAIK.
>
> Any idea what the problem is and how I could fix it ?
>
> Thanks.
>
> P.
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

RE: [GD-Windows] Keyboard lag

[Daniel V. <vo...@ep...>]

I'm seeing the same (using WM_* for keyboard input).

-- Daniel, Epic Games Inc.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Pierre
Terdiman
Sent: Tuesday, January 08, 2002 2:15 PM
To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
Subject: [GD-Windows] Keyboard lag


Hi everyone,

When I keep a key pressed (e.g. pressing say "z" and keeping it down) my app
starts "stuttering", as if there was a big lag in certain frames. It doesn't
seem to always happen, and I'm not doing any special keyboard-related stuff,
AFAIK.

Any idea what the problem is and how I could fix it ?

Thanks.

P.

[GD-Windows] Keyboard lag

[Pierre T. <p.t...@wa...>]

RE: [GD-Windows] Profiling anomaliesHi everyone,

When I keep a key pressed (e.g. pressing say "z" and keeping it down) my =
app starts "stuttering", as if there was a big lag in certain frames. It =
doesn't seem to always happen, and I'm not doing any special =
keyboard-related stuff, AFAIK.

Any idea what the problem is and how I could fix it ?

Thanks.

P.

RE: [GD-Windows] Profiling anomalies

[Gareth L. <GL...@cl...>]

Brian.

Exi386InterlockedExchangeUlong would probably be called by
InterlockedInterchange(). I don't know if it is your code or other code (
STL uses it ) but since that basically locks other threads it could be what
is causing it ?

P.S. It might also be called from InterlockedIncrement() and
InterlockedDecrement() ?

Regards, Gareth Lewin

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 08 January 2002 02:45
> To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> Subject: [GD-Windows] Profiling anomalies
> 
> 
> I'm profiling our puzzle game to try to get an idea where 
> time is being
> spent, and so far I have two huge spikes in really bizarre functions:
> 
> Exi386InterlockedExchangeUlong
> EngComputeGlyphSet
> 
> This is during app loading time.  Now, my inclination is that 
> the debug
> symbols are whacked, but I just downloaded the latest retail 
> Win2K debug
> symbols from Microsoft.  Is there something else that might be amiss?
> I'm using VTune 5.
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] Profiling anomalies

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

I'm profiling our puzzle game to try to get an idea where time is being
spent, and so far I have two huge spikes in really bizarre functions:

Exi386InterlockedExchangeUlong
EngComputeGlyphSet

This is during app loading time.  Now, my inclination is that the debug
symbols are whacked, but I just downloaded the latest retail Win2K debug
symbols from Microsoft.  Is there something else that might be amiss?
I'm using VTune 5.

Brian

RE: [GD-Windows] Icon for game window

[Roland <ro...@wi...>]

Some more tips for icon handling:

Icons can store multiple resolutions of the image in one file. Usually
Windows finds the correct resolution to display, but sometimes this
fails: In my particular case it fails whenever one creates a MFC
dialog-based app. The wizard constructs code like this (in
CXYZDlg::OnInitDialog()):

	// Set the icon for this dialog.  The framework does this
automatically
	//  when the application's main window is not a dialog
	SetIcon(m_hIcon, TRUE);			// Set big icon
	SetIcon(m_hIcon, FALSE);		// Set small icon

The 'big icon' is displayed in the little ALT-TAB selection window.
The 'small icon' is painted in the title bar and in the task bar
entry.

The problem is that this call always loads the big resolution of the
icon. This looks good in the ALT-TAB case, but the title bar and task
bar icon is resized (instead of taking the nicer-looking smaller
resolution). My usual workaround is as follows:

    SetIcon(m_hIcon, TRUE);			// Set big icon
    SetIcon((HICON)
        LoadImage(
        AfxGetResourceHandle(),
        MAKEINTRESOURCE(IDR_MAINFRAME),
        IMAGE_ICON,
        16,
        16,
        LR_DEFAULTCOLOR), FALSE);		// Set small icon

and voila: the small icon looks clean and nifty...

Isn't directly related to your problem, though....


roland, fighting-for-nice-icons


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On
> Behalf Of
> Brian Hook
> Sent: Monday, January 07, 2002 9:51 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] Icon for game window
>
>
> A-ha!  I was doing that, however I botched up the call to
> LoadIcon by
> passing NULL as the first parameter instead of hInstance.  Doh.
>
> Thanks!
>
> Brian
>
>
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...] On
> > Behalf Of Andrew Grant
> > Sent: Monday, January 07, 2002 9:45 AM
> > To: gam...@li...
> > Subject: RE: [GD-Windows] Icon for game window
> >
> >
> > set WNDCLASS.hIcon before you register the class for your
> main window.
> >
> > Andrew Grant
> > Hothouse Creations
> >
> >
> >
> > > -----Original Message-----
> > > From: Brian Hook [mailto:bri...@py...]
> > > Sent: 07 January 2002 17:34
> > > To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> > > Subject: [GD-Windows] Icon for game window
> > >
> > >
> > > What magical bit of tomfoolery do I need to do to have my
> > > application's
> > > icon show up in the caption bar?  I'm already using
> > LoadIcon() to load
> > > the correct icon, and it shows up correctly in Explorer
> > when browsing
> > > directories, just not in the caption.
> > >
> > > Thanks,
> > >
> > > Brian
> > >
> > >
> > > _______________________________________________
> > > Gamedevlists-windows mailing list
> > > Gam...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > >
> >
> >
> > This email is covered by the following disclaimer, please
> > read before accepting this email.
> http://www.hothouse.org/disclaimer/
> >
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] Suspending execution

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

> Adding the WaitMessage like you say works great - except in 
> network games - but then pause is an issue anyway :-)

Right =)

> One other thing you may want to add is detect if you are the 
> foreground app and if you are not, add a Sleep(50) before the 
> peekmessage loop - I find this makes using debuggers or alt 
> tabbing much much more responsive (esp. on single processor machines).

Good idea, I'll look at that.

> I don't get mouse move messages all the time - maybe you have 
> a jittery mouse?

It's an MS optical mouse, but if it was jittery, I'd expect it to show
me different cursor positions.  Unless the driver is sending out
messages when it sees movement, even if the movement isn't large enough
to warrant a new message.

Brian

RE: [GD-Windows] Suspending execution

[Andy G. <an...@mi...>]

Adding the WaitMessage like you say works great - except in network
games - but then pause is an issue anyway :-)

One other thing you may want to add is detect if you are the foreground
app and if you are not, add a Sleep(50) before the peekmessage loop - I
find this makes using debuggers or alt tabbing much much more responsive
(esp. on single processor machines).

I don't get mouse move messages all the time - maybe you have a jittery
mouse?

Andy Glaister.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Monday, January 07, 2002 11:16 AM
To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
Subject: [GD-Windows] Suspending execution


Okay, next question up.  My current game is doing the traditional "run
as fast as you can" model of execution, which eats CPU like mad stupid
crazy.  The traditional loop is:

while ( PeekMessage( ... ) )
{
    if ( GetMessage( ... ) )=20
    {=20
        Translate/DispatchMessage( ... );
    }
    else
    {
        //app quit
    }
}

To avoid hammering the CPU, I'm thinking of slightly changing it to:

if ( bPaused )
{
   WaitMessage();
}

//do regular loop here

Are there any hidden gotchas with WaitMessage()?

One other thing I've noticed is that I'm constantly getting WM_MOUSEMOVE
messages even if the mouse isn't moving (confirmed with Spy++).  I
assume this is expected behaviour?

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] Suspending execution

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

Okay, next question up.  My current game is doing the traditional "run
as fast as you can" model of execution, which eats CPU like mad stupid
crazy.  The traditional loop is:

while ( PeekMessage( ... ) )
{
    if ( GetMessage( ... ) ) 
    { 
        Translate/DispatchMessage( ... );
    }
    else
    {
        //app quit
    }
}

To avoid hammering the CPU, I'm thinking of slightly changing it to:

if ( bPaused )
{
   WaitMessage();
}

//do regular loop here

Are there any hidden gotchas with WaitMessage()?

One other thing I've noticed is that I'm constantly getting WM_MOUSEMOVE
messages even if the mouse isn't moving (confirmed with Spy++).  I
assume this is expected behaviour?

Brian

RE: [GD-Windows] TryEnterCriticalSection

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

Thought this might be interesting:

http://www.cs.rochester.edu/u/michael/PODC96.html

Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue
Algorithms

Abstract
Drawing ideas from previous authors, we present a new non-blocking
concurrent queue algorithm and a new two-lock queue algorithm in which
one enqueue and one dequeue can proceed concurrently. Both algorithms
are simple, fast, and practical; we were surprised not to find them in
the literature. Experiments on a 12-node SGI Challenge multiprocessor
indicate that the new non-blocking queue consistently outperforms the
best known alternatives; it is the clear algorithm of choice for
machines that provide a universal atomic primitive (e.g.
compare-and-swap or load-linked/store-conditional). The two-lock
concurrent queue outperforms a single lock when several processes are
competing simultaneously for access; it appears to be the algorithm of
choice for busy queues on machines with non-universal atomic primitives
(e.g. test-and-set). Since much of the motivation for non-blocking
algorithms is rooted in their immunity to large, unpredictable delays in
process execution, we report experimental results both for systems with
dedicated processors and for systems with several processes
multiprogrammed on each processor.

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, January 03, 2002 11:18 AM
To: gam...@li...
Subject: [GD-Windows] TryEnterCriticalSection

It looks like TryEnterCriticalSection is only available on >=3D NT4 (and
according to the docs, it's not available on Win9x at all).  To get
around this I'm thinking that I could switch to using a mutex and
WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
heavier weight than critical sections (I'm not sure how bad this is in
practice though).

Any opinions, comments or shared experiences with this?

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: MSDN (was RE: [GD-Windows] Icon for game window)

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

As much as I love MSDN, one thing about it that's really annoying is
that you don't know what data it's going to overwrite.  Since I'm
dependent on DX3 documentation right now, if I install the latest MSDN
I'm fearful that all my glorious DX3 docs will get hosed by DX8.1.

Brian

> If you install the MSDN that ships with Visual Studio, you 
> can set your search scope permanently to a more reasonable 
> subset...though of course it is sad not to have ready access 
> to those BackOffice SDK pages...

MSDN (was RE: [GD-Windows] Icon for game window)

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

The good news is you can go to "Advanced search" and set your search
scope to exclude all the extraneous junk.

The bad news is that it doesn't remember your last scope setting, and
setting the scope might take longer than just scanning through the crap.

If you install the MSDN that ships with Visual Studio, you can set your
search scope permanently to a more reasonable subset...though of course
it is sad not to have ready access to those BackOffice SDK pages...

--brian

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Monday, January 07, 2002 10:07 AM
To: bri...@py...; Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: RE: [GD-Windows] Icon for game window


> Thanks for the tip on searching MSDN, however, as you noted, the WinCE
> references and technical articles from Win3.0 are a bit much =3D)

I've come to read the URLs directly, as they list the platform=20
type in there. As long as the real hit is on the first page I'm=20
usually doing OK :-)

> However, more important, I thought I WAS doing the right thing with
the
> WNDCLASS structure, which is why I ended up asking this list (i.e. the

Yes, I saw that: our messages crossed in the mail. My apologies.

Cheers,

			/ h+


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] Icon for game window

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

> Thanks for the tip on searching MSDN, however, as you noted, the WinCE
> references and technical articles from Win3.0 are a bit much =)

I've come to read the URLs directly, as they list the platform 
type in there. As long as the real hit is on the first page I'm 
usually doing OK :-)

> However, more important, I thought I WAS doing the right thing with the
> WNDCLASS structure, which is why I ended up asking this list (i.e. the

Yes, I saw that: our messages crossed in the mail. My apologies.

Cheers,

			/ h+

RE: [GD-Windows] Icon for game window

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

Jon,

Thanks for the tip on searching MSDN, however, as you noted, the WinCE
references and technical articles from Win3.0 are a bit much =)
However, more important, I thought I WAS doing the right thing with the
WNDCLASS structure, which is why I ended up asking this list (i.e. the
icon was showing up fine on the desktop just not in the titlebar, so I
had assumed that the two were different, when in fact I should have more
correctly assumed I was a dork and getting something wrong =) ).

As I said in the other e-mail, I was botching the call to LoadIcon(), so
the problem was further upstream than I had expected.

Thanks again,

Brian