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

Re: [GD-Windows] Windows paints my window!

[Javier A. <ja...@py...>]

[I moved most of this stuff to the DXList]

Rich <leg...@xm...> wrote:


>> There is an issue between some drivers and the D3D runtime which
>> will cause D3D to return invalid pointers when you lock resources.
>> This is apparently not fixable in the drivers, so it has to be
>> worked around in the app.

> the workaround was to be more picky about when and where you call into
> Windows.

So, bottom line: should PeekMessage() be called or shouldn't it while
loading video resources? We're going to try commenting it out (since the
window white effect was successfully removed by the hollow brush) and see if
it happens less often.

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] Windows paints my window!

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

In article <9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> There is an issue between some drivers and the D3D runtime which will cause
> D3D to return invalid pointers when you lock resources.  This is apparently
> not fixable in the drivers, so it has to be worked around in the app.  We
> see this a lot filling dynamic vertex buffers.  You can use IsBadWritePtr()
> or some other exception handling technique to deal with this.  Hopefully DX9
> will fix this.

I thought this was discussed on the DirectXDev list a while back --
the workaround was to be more picky about when and where you call into
Windows.
-- 
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] Windows paints my window!

[Grills, J. <jg...@so...>]

There is an issue between some drivers and the D3D runtime which will cause
D3D to return invalid pointers when you lock resources.  This is apparently
not fixable in the drivers, so it has to be worked around in the app.  We
see this a lot filling dynamic vertex buffers.  You can use IsBadWritePtr()
or some other exception handling technique to deal with this.  Hopefully DX9
will fix this.

j

-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: Wednesday, September 11, 2002 5:02 AM
To: gam...@li...
Subject: Re: [GD-Windows] Windows paints my window!


Brian Sharon <bs...@mi...> wrote:

> Who said you have to actually process the messages? :)  From MSDN:
> IsHungAppWindow
[...]
> Call PeekMessage when you update your progress bars and all should be
> well.  --brian

Thanks guys, with either the hollow brush thing or the PeekMessage trick,
the window is now fine.

However, when we put PeekMessage inside our KeepAlive call (which we call
frequently from various load functions), we got a nasty DirectX crash if we
Alt-Tab repeatedly. Until now we had only been able to generate this crash
in convoluted Ctrl-Alt-Del sequences... it bombs in the middle of a vertex
buffer refill: Device was ok, Lock() call was ok, the vertex buffer memory
was accesible, but somewhere in the middle of the vertex buffer fill loop,
the vertex buffer memory is lost and the rep movsd crashes halfway.

I was under the impression that the only way to lose the device when
fullscreen was either by Ctrl-Alt-Del (which has special considerations and
doesn't take away locked memory), or by actually processing messages and
letting your app be deactivated. We PeekMessage with PM_NOREMOVE during
load, don't actually process messages, and most certainly don't call that
function inside the vertex buffer fill loops, so AFAIK the only effect this
PeekMessage should have is to let windows know we're not dead.

Will cross-post this to the DirectXDEV list and see what people think.

[ Note: funny thing, the crash showed up when I was using Photoshop, had the
color picker dialog up, and tried to set the game to fullscreen 640x480
resolution. For some reason, Photoshop's color picker will not let any other
app go fullscreen 640x480 (any other resolution is fine). You can try it
with the DX samples. Bummer. ]

  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
In remembrance
www.osdn.com/911/
_______________________________________________
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] DShow / DMusic and MP3

[Javier A. <ja...@py...>]

Nicolas Romantzoff <nic...@fr...> wrote:

> I'll probably try to make .ogg files supported, but i'm really asked
> to support .mp3 unfortunately :)
>
> And the same question (DShow-only, DShow->DMusic, own->DMusic)
> applies to .ogg files as well...

The answer to your original question in what relates to Ogg-Vorbis is,
external decoder that sends sample stream to DSound (DMusic?).

When we were originally using MP3 we had DShow decode the stream into a
filter buffer, which we would read and send to DSound. Wasn't very pretty,
but then, nothing DShow-related is.

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] DShow / DMusic and MP3

[Nicolas R. <nic...@fr...>]

Thanks...

I'll probably try to make .ogg files supported, but i'm really asked to support .mp3
unfortunately :)

And the same question (DShow-only, DShow->DMusic, own->DMusic) applies to .ogg files as
well...


Nicolas Romantzoff


>> I'm trying to implement mp3 support for background music in our
>> engine (for now only midi and dmus were supported), was wondering
>> what you guys feel more comfortable with:
>
>We're using Ogg-Vorbis and are _extremely_ pleased with it.
>
>  Javier Arevalo
>  Pyro Studios

RE: [GD-Windows] DShow / DMusic and MP3

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

And there's none of the vagueness regarding licensing issues.

Andy @ 
Climax Brighton 



-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: 11 September 2002 12:58
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: Re: [GD-Windows] DShow / DMusic and MP3


Nicolas Romantzoff <nic...@fr...> wrote:

> I'm trying to implement mp3 support for background music in our
> engine (for now only midi and dmus were supported), was wondering
> what you guys feel more comfortable with:

We're using Ogg-Vorbis and are _extremely_ pleased with it.

  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
In remembrance
www.osdn.com/911/
_______________________________________________
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] DShow / DMusic and MP3

[Javier A. <ja...@py...>]

Nicolas Romantzoff <nic...@fr...> wrote:

> I'm trying to implement mp3 support for background music in our
> engine (for now only midi and dmus were supported), was wondering
> what you guys feel more comfortable with:

We're using Ogg-Vorbis and are _extremely_ pleased with it.

  Javier Arevalo
  Pyro Studios

[GD-Windows] DShow / DMusic and MP3

[Nicolas R. <nic...@fr...>]

Hi !

I'm trying to implement mp3 support for background music in our engine (for
now only midi and dmus were supported), was wondering what you guys feel
more comfortable with:

1- Entirely going through DShow (using default audio output).

2- Using DShow for mp3 streaming/reading/decoding, using a in-house
audio-renderer for interaction with DMusic/DSound

3- Using a custom mp3 decoder, using DMusic only for rendering.

(knowing that DMusic is used for 3D sound in parallel).



__________________________________________________________________
Nicolas Romantzoff
ICQ#: 1182420
      Current ICQ status:
+  More ways to contact me
__________________________________________________________________

Re: [GD-Windows] Windows paints my window!

[Javier A. <ja...@py...>]

Brian Sharon <bs...@mi...> wrote:

> Who said you have to actually process the messages? :)  From MSDN:
> IsHungAppWindow
[...]
> Call PeekMessage when you update your progress bars and all should be
> well.  --brian

Thanks guys, with either the hollow brush thing or the PeekMessage trick,
the window is now fine.

However, when we put PeekMessage inside our KeepAlive call (which we call
frequently from various load functions), we got a nasty DirectX crash if we
Alt-Tab repeatedly. Until now we had only been able to generate this crash
in convoluted Ctrl-Alt-Del sequences... it bombs in the middle of a vertex
buffer refill: Device was ok, Lock() call was ok, the vertex buffer memory
was accesible, but somewhere in the middle of the vertex buffer fill loop,
the vertex buffer memory is lost and the rep movsd crashes halfway.

I was under the impression that the only way to lose the device when
fullscreen was either by Ctrl-Alt-Del (which has special considerations and
doesn't take away locked memory), or by actually processing messages and
letting your app be deactivated. We PeekMessage with PM_NOREMOVE during
load, don't actually process messages, and most certainly don't call that
function inside the vertex buffer fill loops, so AFAIK the only effect this
PeekMessage should have is to let windows know we're not dead.

Will cross-post this to the DirectXDEV list and see what people think.

[ Note: funny thing, the crash showed up when I was using Photoshop, had the
color picker dialog up, and tried to set the game to fullscreen 640x480
resolution. For some reason, Photoshop's color picker will not let any other
app go fullscreen 640x480 (any other resolution is fine). You can try it
with the DX samples. Bummer. ]

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Windows paints my window!

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

Who said you have to actually process the messages? :)  From MSDN:

	IsHungAppWindow
	You call the IsHungAppWindow function to determine if=20
	Windows considers that a specified application is not=20
	responding, or "hung". An application is considered to=20
	be not responding if it is not waiting for input, is=20
	not in startup processing, and has not called PeekMessage=20
	within the internal timeout period of 5 seconds.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/=
W
inUI/WindowsUserInterface/Windowing/Windows/WindowReference/WindowFuncti
ons/IsHungAppWindow.asp

Call PeekMessage when you update your progress bars and all should be
well.  --brian

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]=20
> Sent: Monday, September 09, 2002 1:17 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Windows paints my window!
>=20
>=20
> Tom Forsyth <to...@mu...> wrote:
>=20
> >> I thought that setting the hbrBackground of the
> >> WNDCLASS struct to NULL was enough to prevent this
> >
> > IIRC, you need to set it to a transparent brush, not just to NULL.
>=20
> I didn't find explicit mentions of a transparent brush, but I guess
> BS_HOLLOW will do:
>=20
>   LOGBRUSH lb =3D { BS_HOLLOW };
>   wcex.hbrBackground =3D (HBRUSH)CreateBrushIndirect(&lb);
>=20
> Hopefully this will do the trick.
>=20
> > But beware of other nasty things that happen when you neglect your
> > message
> > pump. It might be an idea to call the message pump regularly during
> > the
> > loading process. You can also draw progress bars, etc at the same
> > time - keeps both Windows and the user from worrying.
>=20
> Yeah we have a progress bar but we don't call the message=20
> pump, just update
> the screen. I'm concerned about letting messages interfere=20
> with the loading
> process. We support surface/vb loss & restoration allright,=20
> as well as all
> incarnations of Ctrl-Alt-Del we have figured out (we only got=20
> one rare case
> where the three-finger salute will BSOD Win2k), plus mission=20
> loading with
> the device lost (app minimized). However, I wonder how stable=20
> can I get this
> thing if I allow a device loss in the middle of reloading=20
> surfaces & such
> (easy to get into reentrancy trouble I guess).
>=20
> Thanks, I'll post if / when this is solved.
>=20
>   Javier Arevalo
>   Pyro Studios

Re: [GD-Windows] Windows paints my window!

[Javier A. <ja...@py...>]

Tom Forsyth <to...@mu...> wrote:

>> I thought that setting the hbrBackground of the
>> WNDCLASS struct to NULL was enough to prevent this
>
> IIRC, you need to set it to a transparent brush, not just to NULL.

I didn't find explicit mentions of a transparent brush, but I guess
BS_HOLLOW will do:

  LOGBRUSH lb = { BS_HOLLOW };
  wcex.hbrBackground = (HBRUSH)CreateBrushIndirect(&lb);

Hopefully this will do the trick.

> But beware of other nasty things that happen when you neglect your
> message
> pump. It might be an idea to call the message pump regularly during
> the
> loading process. You can also draw progress bars, etc at the same
> time - keeps both Windows and the user from worrying.

Yeah we have a progress bar but we don't call the message pump, just update
the screen. I'm concerned about letting messages interfere with the loading
process. We support surface/vb loss & restoration allright, as well as all
incarnations of Ctrl-Alt-Del we have figured out (we only got one rare case
where the three-finger salute will BSOD Win2k), plus mission loading with
the device lost (app minimized). However, I wonder how stable can I get this
thing if I allow a device loss in the middle of reloading surfaces & such
(easy to get into reentrancy trouble I guess).

Thanks, I'll post if / when this is solved.

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] Windows paints my window!

[Javier A. <ja...@py...>]

Ignacio Castaño <cas...@ya...> wrote:

> Are you returning TRUE to the WM_ERASEBKGND message?

This is in our windowproc:

case WM_PAINT:
  {
    PAINTSTRUCT paint;
    BeginPaint((HWND)hWnd, &paint);
    EndPaint((HWND)hWnd, &paint);
    return 0L;
  }

case WM_ERASEBKGND:
  return 1L;

And this is our window class setup:

 wcex.cbSize = sizeof(WNDCLASSEX);
 wcex.style   = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS;
 wcex.lpfnWndProc = (WNDPROC)WindowProc;
 wcex.cbClsExtra  = 0;
 wcex.cbWndExtra  = 0;
 wcex.hInstance  = (HINSTANCE)m_hInstance;
 wcex.hIcon    = LoadIcon((HINSTANCE)m_hInstance, "PRAETORIANS");
 wcex.hCursor   = LoadCursor(NULL, IDC_ARROW);
 wcex.hbrBackground = NULL;
 wcex.lpszMenuName = NULL;
 wcex.lpszClassName = "Ventana";
 wcex.hIconSm  = LoadIcon(wcex.hInstance, "SMALL.ICO");
 RegisterClassEx(&wcex);

> Javier Arevalo wrote:
>> Hi!
>>
>> During long load times (not so long actually, but hey) Windows
>> sometimes seems to decide that the game's window needs repainting
>> and erasing. The app is not responding to messages because it's busy
>> loading stuff. I thought that setting the hbrBackground of the
>> WNDCLASS struct  to NULL was enough to prevent this, but it still
>> paints the window white. This only happens when the game runs in
>> fullscreen mode, never in the windowed mode we use for development.
>> Even funnier is that it only started happening a few days ago, but
>> we have been unable to find any changes we might have done to the
>> Window or DirectX handling code for the past _months_.
>>
>> Any ideas where to look at? Even the slightest trace of a pointer
>> will be greatly appreciated.
>>
>> Thanks,
>>   Javier Arevalo
>>   Pyro Studios
>
>
> _______________________________________________________________
> Copa del Mundo de la FIFA 2002
> El único lugar de Internet con vídeos de los 64 partidos.
> ¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555


  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Windows paints my window!

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

> I thought that setting the hbrBackground of the
> WNDCLASS struct to NULL was enough to prevent this

IIRC, you need to set it to a transparent brush, not just to NULL.

But beware of other nasty things that happen when you neglect your =
message
pump. It might be an idea to call the message pump regularly during the
loading process. You can also draw progress bars, etc at the same time =
-
keeps both Windows and the user from worrying.


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: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 09 September 2002 18:10
> To: gam...@li...
> Subject: Re: [GD-Windows] Windows paints my window!
>=20
>=20
> Hi,
> Are you returning TRUE to the WM_ERASEBKGND message?
>=20
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
> Javier Arevalo wrote:
> > Hi!
> >
> > During long load times (not so long actually, but hey)=20
> Windows sometimes
> > seems to decide that the game's window needs repainting and=20
> erasing. The
> app
> > is not responding to messages because it's busy loading=20
> stuff. I thought
> > that setting the hbrBackground of the WNDCLASS struct  to=20
> NULL was enough
> to
> > prevent this, but it still paints the window white. This=20
> only happens when
> > the game runs in fullscreen mode, never in the windowed=20
> mode we use for
> > development. Even funnier is that it only started happening=20
> a few days
> ago,
> > but we have been unable to find any changes we might have=20
> done to the
> Window
> > or DirectX handling code for the past _months_.
> >
> > Any ideas where to look at? Even the slightest trace of a=20
> pointer will be
> > greatly appreciated.
> >
> > Thanks,
> >   Javier Arevalo
> >   Pyro Studios
>=20
>=20
> _______________________________________________________________
> Copa del Mundo de la FIFA 2002
> El =FAnico lugar de Internet con v=EDdeos de los 64 partidos.=20
> =A1Ap=FAntante ya! en http://fifaworldcup.yahoo.com/fc/es/
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> 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] Windows paints my window!

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

> In article <006001c25820$2a348d00$ab02000a@mcaf.local>,
>     "Javier Arevalo" <ja...@py...>  writes:
>=20
> > Any ideas where to look at? Even the slightest trace of a=20
> pointer will be
> > greatly appreciated.
>=20
> I thought there was a message you had to handle by returning TRUE (or
> FALSE, can't remember) to tell windows not to repaint your background.
> Check the DirectXDev archives, I know this has come up there before.
>=20
> I think it was WM_ERASEBKGND

It is, but Jare said he's not pumping messages when this happens.  And
if you aren't pumping messages, then I know some versions of the OS will
decide you're "hung" and erase your window (signified by the "Not
Responding" added to the title bar of your window).  I didn't think it
happened to full-screen apps, but I don't know that for certain.

Does it only happen at startup, or anytime during the game?  Could it be
prompted by some other window trying to come to the foreground, like
ICQ/AIM/MSN?  What OS versions do you see it on?

--brian

RE: [GD-Windows] Windows paints my window!

[Steve L. <st...@mi...>]

This has always been the case.  You must pump messages, USER will paint
your client area white if you don't.

The following is purely a theory about the behaviour change. When
fullscreeen, previously you might have switched to the non-GDI surface,
so when windows paints it white you wouldn't see it.  Maybe now you have
flipped to the surface that GDI knows about and you're seeing the white
paint.

Cheers,
	Steve

Steve Lacey
- Chief Code Wrangler
- ironWorks Entertainment


-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]=20
Sent: Monday, September 09, 2002 9:44 AM
To: GDWindows
Subject: [GD-Windows] Windows paints my window!

Hi!

During long load times (not so long actually, but hey) Windows sometimes
seems to decide that the game's window needs repainting and erasing. The
app
is not responding to messages because it's busy loading stuff. I thought
that setting the hbrBackground of the WNDCLASS struct  to NULL was
enough to
prevent this, but it still paints the window white. This only happens
when
the game runs in fullscreen mode, never in the windowed mode we use for
development. Even funnier is that it only started happening a few days
ago,
but we have been unable to find any changes we might have done to the
Window
or DirectX handling code for the past _months_.

Any ideas where to look at? Even the slightest trace of a pointer will
be
greatly appreciated.

Thanks,
  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

Re: [GD-Windows] Windows paints my window!

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

In article <006001c25820$2a348d00$ab02000a@mcaf.local>,
    "Javier Arevalo" <ja...@py...>  writes:

> Any ideas where to look at? Even the slightest trace of a pointer will be
> greatly appreciated.

I thought there was a message you had to handle by returning TRUE (or
FALSE, can't remember) to tell windows not to repaint your background.
Check the DirectXDev archives, I know this has come up there before.

I think it was WM_ERASEBKGND
-- 
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] Windows paints my window!

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

Hi,
Are you returning TRUE to the WM_ERASEBKGND message?


Ignacio Castaño
cas...@ya...


Javier Arevalo wrote:
> Hi!
>
> During long load times (not so long actually, but hey) Windows sometimes
> seems to decide that the game's window needs repainting and erasing. The
app
> is not responding to messages because it's busy loading stuff. I thought
> that setting the hbrBackground of the WNDCLASS struct  to NULL was enough
to
> prevent this, but it still paints the window white. This only happens when
> the game runs in fullscreen mode, never in the windowed mode we use for
> development. Even funnier is that it only started happening a few days
ago,
> but we have been unable to find any changes we might have done to the
Window
> or DirectX handling code for the past _months_.
>
> Any ideas where to look at? Even the slightest trace of a pointer will be
> greatly appreciated.
>
> Thanks,
>   Javier Arevalo
>   Pyro Studios


_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

[GD-Windows] Windows paints my window!

[Javier A. <ja...@py...>]

Hi!

During long load times (not so long actually, but hey) Windows sometimes
seems to decide that the game's window needs repainting and erasing. The app
is not responding to messages because it's busy loading stuff. I thought
that setting the hbrBackground of the WNDCLASS struct  to NULL was enough to
prevent this, but it still paints the window white. This only happens when
the game runs in fullscreen mode, never in the windowed mode we use for
development. Even funnier is that it only started happening a few days ago,
but we have been unable to find any changes we might have done to the Window
or DirectX handling code for the past _months_.

Any ideas where to look at? Even the slightest trace of a pointer will be
greatly appreciated.

Thanks,
  Javier Arevalo
  Pyro Studios

RE: Re:[GD-Windows] Windows in .NET :(

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

From my POV mainly the XBox SDK and the MSDN library. Already the last
version of MSDN that plugs into dev studio is last october or something.
From October the XDK will only support VC7 which is going to be a massive
pain, and probably result in every team here who works on cross platform
products having to upgrade due to the VC6 & VC7 workspaces not being
compatible, another dubious move really.


Andy @ 
Climax Brighton 



-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: 08 September 2002 15:47
To: gam...@li...
Subject: Re: Re:[GD-Windows] Windows in .NET :(


Andrew Grant <ag...@cl...> wrote:

> I wish that was viable, unfortunately though Microsoft as usual are
> doing all they can to "encourage" developers to upgrade by already
> cutting VC6 support from some products.

Yeah that kind of behaviour is to be expected from Microsoft. What lack of
support are you referring to specifically? Which products? For me, as long
as VTune and DirectX work with VC6 I see no major development troubles.

Luckily for us, we're finishing our current game around the time a more
stable version of .NET comes out.

  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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: Re:[GD-Windows] Windows in .NET :(

[Javier A. <ja...@py...>]

Andrew Grant <ag...@cl...> wrote:

> I wish that was viable, unfortunately though Microsoft as usual are
> doing all they can to "encourage" developers to upgrade by already
> cutting VC6 support from some products.

Yeah that kind of behaviour is to be expected from Microsoft. What lack of
support are you referring to specifically? Which products? For me, as long
as VTune and DirectX work with VC6 I see no major development troubles.

Luckily for us, we're finishing our current game around the time a more
stable version of .NET comes out.

  Javier Arevalo
  Pyro Studios

RE: Re:[GD-Windows] Windows in .NET :(

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

I wish that was viable, unfortunately though Microsoft as usual are doing
all they can to "encourage" developers to upgrade by already cutting VC6
support from some products.

Andy @ 
Climax Brighton 



-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: 07 September 2002 12:20
To: gam...@li...
Subject: Re: Re:[GD-Windows] Windows in .NET :(


If you're doing non-.NET C++ projects then it's definitely a good idea to
stick with VC6 (that's what I do) and wait for future, more refined versions
of the new environment. But it doesn't hurt to play with it on the side
(.NET forms are _cool_, MFC be gone for good!) to minimize the future
transition.

  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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: Re:[GD-Windows] Windows in .NET :(

[Javier A. <ja...@py...>]

Joe Collins <jo...@mu...> wrote:

> Well adding an empty wndproc wasn't enough. I had to set the cursor
> and icon as well. Looks like
> it still complains about an invalid menu handler but it doesn't crash
> anymore :)

Clearing all fields to zero is definitely a good idea. You don't want to
have a random window proc, a random icon handle or such stuff in your window
class.

For a dummy window, ::DefWindowProc() as the window proc should be good
enough, but quite frankly, I have never done that myself (even for the
dumbest of hello world apps I at least add a check for ESC). I have no clue
if a NULL WndProc is supposed to work.

> I guess .NET is a bit pickier than vc6 libs.

Uninitialized variables are always broken no matter the compiler. It's just
that sometimes they happen to not blow up in your face. :)

> As far as .NET being horribly broken... well one could argue that the
> change from workspaces
> to solutions is broken. It definately does not behave the same as vc6
> workspaces. ;)

I don't particularly care about solutions vs. workspaces, but I definitely
agree that many tasks in the new IDE are much more cumbersome than in VC6:

 - They require more mouse clicks for just about everything,
 - Some hotkeys like Alt-F7 are now context-dependent,
 - The advanced editor mode has a tendency to start eating your source code
away.

If you're doing non-.NET C++ projects then it's definitely a good idea to
stick with VC6 (that's what I do) and wait for future, more refined versions
of the new environment. But it doesn't hurt to play with it on the side
(.NET forms are _cool_, MFC be gone for good!) to minimize the future
transition.

  Javier Arevalo
  Pyro Studios

Re:[GD-Windows] Windows in .NET :(

[Joe C. <jo...@mu...>]

  Hmm...

Well adding an empty wndproc wasn't enough. I had to set the cursor and 
icon as well. Looks like
it still complains about an invalid menu handler but it doesn't crash 
anymore :)

The window is only used to get the wgl extensions.  Basically create a 
fake window,
get the wgl extensions and then destroy the window. I guess .NET is a 
bit pickier than
vc6 libs.

As far as .NET being horribly broken... well one could argue that the 
change from workspaces
to solutions is broken. It definately does not behave the same as vc6 
workspaces. ;)

Thanks,

-Joe

Javier Arevalo wrote:

Brian Sharon <bs...@mi...> wrote:

>(cc'ing the Windows list and removing the general list)
>
>You haven't specified a WNDPROC for your window class.  That might be
>one lame reason.
>

That would definitely hurt a lot. :)

In case oyu wonder if .NET is horribly broken or something, we compiled the
full Praetorians source code in both managed and non-managed modes with
VS.NET. We had to make five or six syntax changes, we were hit by one code
generation bug regarding float constants, and we were appalled by the
trouble that managed C++ has with virtual function calls (fixed in the next
version I believe). Other than that, the entire game ran just fine.

>>-----Original Message-----
>>From: Joe Collins [mailto:jo...@mu...]
>>

>>On a side note, I have previously tried to get the mousewheel
>>working in my code. But
>>I get a compile error when I try to use WM_MOUSEWHEEL - undefined
>>
>>There seems to be some magic defines you need to set to get this to
>>compile... Something to do with
>>#define _WIN32_WINNT 0x0400
>>#define _WIN32_WINDOWS 0x500
>>

The mousewheel was not available in windows 95, therefore if you want to use
it you must specify that you won't be supporting Win98. All this is
explained in the MSDN help entry for WM_MOUSEWHEEL. We simply defined them
ourselves to avoid messing with equally obscure include-control macros:

#ifndef WM_MOUSEWHEEL
#define WM_MOUSEWHEEL 0x020A
#endif

#ifndef MSH_MOUSEWHEEL
#define MSH_MOUSEWHEEL 0xC7B1
#endif

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Windows in .NET :(

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

Zero-filling structs that you pass in to Win32 calls is an excellent
habit.  But for this case, the size param is only present in WNDCLASSEX
(used with RegisterClassEx).  --b.

> -----Original Message-----
> From: Ben Carter [mailto:be...@gu...]=20
> Sent: Friday, September 06, 2002 11:34 AM
> To: GDWindows
> Subject: Re: [GD-Windows] Windows in .NET :(
>=20
>  I'm working from memory here, but don't you have to set the size
> parameter of the WNDCLASS structure, and zero out all the unused
> members?

Re: [GD-Windows] Windows in .NET :(

[Javier A. <ja...@py...>]

Brian Sharon <bs...@mi...> wrote:

> (cc'ing the Windows list and removing the general list)
>
> You haven't specified a WNDPROC for your window class.  That might be
> one lame reason.

That would definitely hurt a lot. :)

In case oyu wonder if .NET is horribly broken or something, we compiled the
full Praetorians source code in both managed and non-managed modes with
VS.NET. We had to make five or six syntax changes, we were hit by one code
generation bug regarding float constants, and we were appalled by the
trouble that managed C++ has with virtual function calls (fixed in the next
version I believe). Other than that, the entire game ran just fine.

>> -----Original Message-----
>> From: Joe Collins [mailto:jo...@mu...]

>> On a side note, I have previously tried to get the mousewheel
>> working in my code. But
>> I get a compile error when I try to use WM_MOUSEWHEEL - undefined
>>
>> There seems to be some magic defines you need to set to get this to
>> compile... Something to do with
>> #define _WIN32_WINNT 0x0400
>> #define _WIN32_WINDOWS 0x500

The mousewheel was not available in windows 95, therefore if you want to use
it you must specify that you won't be supporting Win98. All this is
explained in the MSDN help entry for WM_MOUSEWHEEL. We simply defined them
ourselves to avoid messing with equally obscure include-control macros:

#ifndef WM_MOUSEWHEEL
#define WM_MOUSEWHEEL 0x020A
#endif

#ifndef MSH_MOUSEWHEEL
#define MSH_MOUSEWHEEL 0xC7B1
#endif

  Javier Arevalo
  Pyro Studios