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

Re: [GD-Windows] Resource conditions in Visual Studio

[Rik H. <ri...@sy...>]

You should be able to just add #ifdef's to the .rc file in your project
(they are just text files) to comment stuff out for some builds, though I
have never tried this myself.

The resource compiler uses a different set of defines to your c++ compiler.
You can set which constants to set when the resource compiler is run in the
Resources tab of the project settings dialog.

Not sure why you would want to bother though. It will only save you a few
bytes and it probably won't effect the size of the exe at all, as padding
will probably result in it staying the same size.

Rik Heywood

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Sunday, November 18, 2001 3:23 AM
Subject: [GD-Windows] Resource conditions in Visual Studio


> I have some dialog boxes that are only required in the demo build of one
> of our games (registration).  According to the (thin) docs, I can set a
> "Condition" for resources to be included in the final EXE.  Simple
> enough.  Their example lists "NDEBUG" as a sample.
>
> Okay, so I give it a shot.  No go, it's not included.  I have a compiler
> constant TEST_BUILD defined in the project settings.  Then I set the
> "Condition" property for a dialog to "TEST_BUILD".  It no likey, doesn't
> include it.  You can't put in comparisons either, e.g. "TEST_BUILD==1"
> is a syntax error.
>
> Any ideas what kind of mystical kung fu is required to make this work?
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

RE: [GD-Windows] Resource conditions in Visual Studio

[Seungrog, O. <emp...@75...>]

Maybe you can have a look at "Resources" tab in Project Settings.

Seungrog, Oh

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Brian Hook
> Sent: Sunday, November 18, 2001 12:24 PM
> To: gam...@li...
> Subject: [GD-Windows] Resource conditions in Visual Studio
> 
> 
> I have some dialog boxes that are only required in the demo 
> build of one
> of our games (registration).  According to the (thin) docs, I 
> can set a
> "Condition" for resources to be included in the final EXE.  Simple
> enough.  Their example lists "NDEBUG" as a sample.
> 
> Okay, so I give it a shot.  No go, it's not included.  I have 
> a compiler
> constant TEST_BUILD defined in the project settings.  Then I set the
> "Condition" property for a dialog to "TEST_BUILD".  It no 
> likey, doesn't
> include it.  You can't put in comparisons either, e.g. "TEST_BUILD==1"
> is a syntax error.
> 
> Any ideas what kind of mystical kung fu is required to make this work?
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] Resource conditions in Visual Studio

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

I have some dialog boxes that are only required in the demo build of one
of our games (registration).  According to the (thin) docs, I can set a
"Condition" for resources to be included in the final EXE.  Simple
enough.  Their example lists "NDEBUG" as a sample.

Okay, so I give it a shot.  No go, it's not included.  I have a compiler
constant TEST_BUILD defined in the project settings.  Then I set the
"Condition" property for a dialog to "TEST_BUILD".  It no likey, doesn't
include it.  You can't put in comparisons either, e.g. "TEST_BUILD==1"
is a syntax error.

Any ideas what kind of mystical kung fu is required to make this work?

Brian

RE: [GD-Windows] SoftICE for debugging?

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

Another bad point is that the interface is seriously crufty. :-)

But despite all that, it is still an awesome bit of kit, and it is well
worth taking the time to learn it. The actual debugging capabilities (i.e.
not the UI) are far better than VC6 and so on, and of course it's a lot more
powerful, since it's a kernel-level debugger.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Roland [mailto:ro...@wi...]
> Sent: 12 November 2001 23:25
> To: gam...@li...
> Subject: RE: [GD-Windows] SoftICE for debugging?
> 
> 
> I highly recommend running SoftICE on any development machine. It has
> helped track down countless bugs. Most people in our team use a second
> (monochrome) monitor on our development machines and have SoftICE's
> output redirected there. I guess this setup would be helpful for
> anybody developing fullscreen 3D stuff (apart from having two 'real'
> monitors). Otherwise SoftICE's takes over the video memory and
> displays its output in the middle of the graphics/Windows screen. I
> don't know how reliable this would work in different/fullscreen 3D
> video modes.
> 
> My favourite properties of SoftICE are:
> * it catches *every* OutputDebugString(). I've seen the MSDev output
> window 'drop' some debug output, if you output too much data. SoftICE
> will slow down the application, but it will show every TRACE() call.
> * You can download debug symbols and do Source Level debugging on
> anything (not limited to drivers), watch local/global variables
> (presented with correct type info), inspect memory etc. etc.
> * You can catch almost any exception and once you've catched it, you
> can do stack traces and single steps to pin down the problem.
> * [driver developers only]: If you're into driver development, you can
> debug drivers as soon as the machine loads them (even before you get
> any UI).
> 
> Things that aren't that good:
> * Some games will refuse to run, if you have SoftICE running
> (copy-protection).
> * If you have lot's of OutputDebugStrings() in some drivers, it will
> severely slow down your machine (I had once a driver for a network
> card which printed a line for every packet received -> unusable
> because of this)
> * It takes a bit of preparation before you can debug something inside
> SoftICE's. It's not that quick Compile/Run/Breakpoint cycle you might
> be used to from MSDev.
> 
> hope this helps
> roland
> 
> 
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On
> > Behalf Of
> > Jon Watte
> > Sent: Friday, November 09, 2001 3:03 PM
> > To: Gamedevlists-Windows@Lists. Sourceforge. Net
> > Subject: [GD-Windows] SoftICE for debugging?
> >
> >
> >
> > I'm having these problems with Windows 98 machines
> > spuriously crashing
> > once in a blue moon. Often, the machine is not reachable
> > through the
> > devices plugged in (keyboard, mouse, network card) so it
> > looks like a
> > hard "kernel hang". Of course, these are not repeatable,
> > and will only
> > happen on one machine out of 20 when running testing for
> > three hours.
> > Anything else would make it too easy :-)
> >
> > What kinds of tools have y'all had success with (or not) in this
> > sitation? The product appears to run fine on Win2k/XP. I've
> > been hearing
> > about SoftICE but haven't used it personally (and haven't
> > seen it used
> > for the last three years or so). I believe it's a debugger
> > used mostly
> > for driver debugging, but would it allow me to examine
> > machine state
> > under these conditions?
> >
> > Anything else you can recommend?
> >
> > Cheers,
> >
> > 			/ h+

RE: [GD-Windows] SoftICE for debugging?

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

I highly recommend running SoftICE on any development machine. It has
helped track down countless bugs. Most people in our team use a second
(monochrome) monitor on our development machines and have SoftICE's
output redirected there. I guess this setup would be helpful for
anybody developing fullscreen 3D stuff (apart from having two 'real'
monitors). Otherwise SoftICE's takes over the video memory and
displays its output in the middle of the graphics/Windows screen. I
don't know how reliable this would work in different/fullscreen 3D
video modes.

My favourite properties of SoftICE are:
* it catches *every* OutputDebugString(). I've seen the MSDev output
window 'drop' some debug output, if you output too much data. SoftICE
will slow down the application, but it will show every TRACE() call.
* You can download debug symbols and do Source Level debugging on
anything (not limited to drivers), watch local/global variables
(presented with correct type info), inspect memory etc. etc.
* You can catch almost any exception and once you've catched it, you
can do stack traces and single steps to pin down the problem.
* [driver developers only]: If you're into driver development, you can
debug drivers as soon as the machine loads them (even before you get
any UI).

Things that aren't that good:
* Some games will refuse to run, if you have SoftICE running
(copy-protection).
* If you have lot's of OutputDebugStrings() in some drivers, it will
severely slow down your machine (I had once a driver for a network
card which printed a line for every packet received -> unusable
because of this)
* It takes a bit of preparation before you can debug something inside
SoftICE's. It's not that quick Compile/Run/Breakpoint cycle you might
be used to from MSDev.

hope this helps
roland


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On
> Behalf Of
> Jon Watte
> Sent: Friday, November 09, 2001 3:03 PM
> To: Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: [GD-Windows] SoftICE for debugging?
>
>
>
> I'm having these problems with Windows 98 machines
> spuriously crashing
> once in a blue moon. Often, the machine is not reachable
> through the
> devices plugged in (keyboard, mouse, network card) so it
> looks like a
> hard "kernel hang". Of course, these are not repeatable,
> and will only
> happen on one machine out of 20 when running testing for
> three hours.
> Anything else would make it too easy :-)
>
> What kinds of tools have y'all had success with (or not) in this
> sitation? The product appears to run fine on Win2k/XP. I've
> been hearing
> about SoftICE but haven't used it personally (and haven't
> seen it used
> for the last three years or so). I believe it's a debugger
> used mostly
> for driver debugging, but would it allow me to examine
> machine state
> under these conditions?
>
> Anything else you can recommend?
>
> Cheers,
>
> 			/ h+
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] SoftICE for debugging?

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

I'm having these problems with Windows 98 machines spuriously crashing 
once in a blue moon. Often, the machine is not reachable through the 
devices plugged in (keyboard, mouse, network card) so it looks like a 
hard "kernel hang". Of course, these are not repeatable, and will only 
happen on one machine out of 20 when running testing for three hours. 
Anything else would make it too easy :-)

What kinds of tools have y'all had success with (or not) in this 
sitation? The product appears to run fine on Win2k/XP. I've been hearing 
about SoftICE but haven't used it personally (and haven't seen it used 
for the last three years or so). I believe it's a debugger used mostly 
for driver debugging, but would it allow me to examine machine state 
under these conditions?

Anything else you can recommend?

Cheers,

			/ h+

Re: [GD-Windows] IsIconic() vs. trapping window messages

[Corrinne Y. <cor...@sp...>]

You definitely want to still hook into
WM_SIZE where wParam == SIZE_MAXHIDE.

You are not minimized, but some other window is covering yours, because they
are maximized.






----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Friday, November 09, 2001 2:34 PM
Subject: [GD-Windows] IsIconic() vs. trapping window messages


> I've seen two different ways of detecting minimized state.  The first is
> the standard trapping of WM_MOVE, WM_SIZE, WM_ACTIVATE, etc. messages.
> However, I've seen other code that uses IsIconic(HWND).  The latter
> obviously can't provide you the state change detection, but assuming you
> don't need to capture a change in state but only need to know if you're
> iconic or not, is there any place where IsIconic() will fail?
>
> For example, a game might only need to know if it's active or not, and
> whether to render.  Activation can be handled through the usual
> suspects, and the render loop could just do:
>
> if ( active && !IsIconic( hwnd ) )
>    render();
>
> ...instead of all the cruft that normally goes into the WndProc.
>
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

[GD-Windows] IsIconic() vs. trapping window messages

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

I've seen two different ways of detecting minimized state.  The first is
the standard trapping of WM_MOVE, WM_SIZE, WM_ACTIVATE, etc. messages.
However, I've seen other code that uses IsIconic(HWND).  The latter
obviously can't provide you the state change detection, but assuming you
don't need to capture a change in state but only need to know if you're
iconic or not, is there any place where IsIconic() will fail?

For example, a game might only need to know if it's active or not, and
whether to render.  Activation can be handled through the usual
suspects, and the render loop could just do:

if ( active && !IsIconic( hwnd ) )
   render();

...instead of all the cruft that normally goes into the WndProc.

RE: [GD-Windows] Linker hell

[Colin F. <cp...@ea...>]

November 7th, 2001
Wednesday

----- Original Message ----- 
From: "Brian Hook" <bri...@py...>
> Thanks to everyone for their suggestions.  I did a DUMPBIN /ALL on some
> of the problematic OBJ files to find out that they were STILL linking to
> MSVCRTD.LIB (!).  Grrr.  As it turns out, you can specify the linkage
> PER FILE (not just per project).  So even if all your projects are set
> to, say, Multithreaded Debug, a file within a project might be set to
> Multithreaded Debug DLL (which is what happened in this case).  Once
> that was found and I fixed the two files that were set this way (no idea
> how they got that way), all problems went away.

I guess if you do incremental builds, and you changed
the build setting from single-threaded to 
multi-threaded, then the only files to experience
the new settings would be files built after
the settings change.  If none of the files upon
which a source file depends is modified, and
you rarely do a clean build, the stale object
file could stick around!

Maybe changing the setting regarding which
version of the C run-time library to use
should bring up a dialog box that warns
you that a clean rebuild is necessary,
and offers to delete all object files
immediately! :-)

--- Colin

RE: [GD-Windows] Linker hell

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

Thanks to everyone for their suggestions.  I did a DUMPBIN /ALL on some
of the problematic OBJ files to find out that they were STILL linking to
MSVCRTD.LIB (!).  Grrr.  As it turns out, you can specify the linkage
PER FILE (not just per project).  So even if all your projects are set
to, say, Multithreaded Debug, a file within a project might be set to
Multithreaded Debug DLL (which is what happened in this case).  Once
that was found and I fixed the two files that were set this way (no idea
how they got that way), all problems went away.

*sigh*

Thanks,

Brian

Re: [GD-Windows] Linker hell

[Corrinne Y. <cor...@sp...>]

Ah, the old linking game!

What libs are you linking with?  Have you turned up the link debug spew
(Project->Link->Customize->Print progress messages) to see what code is
referencing the DLL runtime?

Also remember that a line like this in your codebase:

#pragma comment(lib, "libname")

can pull things into your link line unexpectedly.

-- Oh, goodness, forgot those as well! Those are pain in the a**.

-- It would be nice to be just in one place, all libs are linked, and no
where else. One can dream.

-- Well, I am just glad mine is linking and running now, and I had past the
point in my code to have to add more libs (all the major libs are already
inside), condolences to all of you who have to hunt those down. :(

RE: [GD-Windows] Linker hell

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

Ah, the old linking game!

What libs are you linking with?  Have you turned up the link debug spew
(Project->Link->Customize->Print progress messages) to see what code is
referencing the DLL runtime?

Also remember that a line like this in your codebase:

	#pragma comment(lib, "libname")=20

can pull things into your link line unexpectedly.

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Wednesday, November 07, 2001 11:18 AM
To: gam...@li...
Subject: [GD-Windows] Linker hell

So I'm trying to build a fairly large project, statically linked (no
DLLs), and so far I'm in hell.

First pass: Select all projects and use "Multithreaded Debug" library.
I get conflicts with MSVCRTD.DLL, even though it's not being explicitly
referenced by anything.  I do a DUMPBIN on the modules in question, and
they show they're that their defaultlib is MSVCRTD.LIB even though the
project is showing them as using Multithreaded Debug (LIBCMTD.LIB).
What the hell?

Second pass: Select "No default libraries" and manually specify
LIBCMTD.LIB in the libraries list.  Conflicts go away, but now I get:

LINK : warning LNK4049: locally defined symbol "_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free" imported
LINK : warning LNK4049: locally defined symbol "_memmove" imported
LINK : warning LNK4049: locally defined symbol "_realloc" imported
ogg_static_local.lib(framing.obj) : error LNK2001: unresolved external
symbol __imp__memchr
vorbis_static_d.lib(info.obj) : error LNK2001: unresolved external
symbol _strdup

I'm not using the Ogg Vorbis libs directly, I'm actually compiling the
source files.

What's particularly disturbing is that suddenly it can't find strdup()
or memchr() just because I changed libs?!

Any ideas?

Brian



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

Re: [GD-Windows] Linker hell

[Rik H. <ri...@sy...>]

It is possible the Ogg stuff is forcing the inclusion of a static library
from the source, via pragmas.

Rik Heywood,


----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Wednesday, November 07, 2001 7:18 PM
Subject: [GD-Windows] Linker hell


> So I'm trying to build a fairly large project, statically linked (no
> DLLs), and so far I'm in hell.
>
> First pass: Select all projects and use "Multithreaded Debug" library.
> I get conflicts with MSVCRTD.DLL, even though it's not being explicitly
> referenced by anything.  I do a DUMPBIN on the modules in question, and
> they show they're that their defaultlib is MSVCRTD.LIB even though the
> project is showing them as using Multithreaded Debug (LIBCMTD.LIB).
> What the hell?
>
> Second pass: Select "No default libraries" and manually specify
> LIBCMTD.LIB in the libraries list.  Conflicts go away, but now I get:
>
> LINK : warning LNK4049: locally defined symbol "_malloc" imported
> LINK : warning LNK4049: locally defined symbol "_free" imported
> LINK : warning LNK4049: locally defined symbol "_memmove" imported
> LINK : warning LNK4049: locally defined symbol "_realloc" imported
> ogg_static_local.lib(framing.obj) : error LNK2001: unresolved external
> symbol __imp__memchr
> vorbis_static_d.lib(info.obj) : error LNK2001: unresolved external
> symbol _strdup
>
> I'm not using the Ogg Vorbis libs directly, I'm actually compiling the
> source files.
>
> What's particularly disturbing is that suddenly it can't find strdup()
> or memchr() just because I changed libs?!
>
> Any ideas?
>
> Brian
>
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

Re: [GD-Windows] Linker hell

[Corrinne Y. <cor...@sp...>]

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Wednesday, November 07, 2001 1:18 PM
Subject: [GD-Windows] Linker hell


> Any ideas?
>
> Brian

-- I hope at best the following ideas help you. And at worst you are not mad
I suggest them.

-- Edit the Text File of the project whenever adding files and changing
linkages. I may get flamed by MS people for this, but I just don't trust the
Menu interface, and that is not very well designed right now.

-- There are multiple places inside the menuing system to add remove change
and modify which files are linked and not linked, and if one is removed in
one place, not in another place, then it is not properly removed or added.
It would be good if there is only one place to do all that in the menu.

-- Back to editing the text file. That is kind of cool too as it also allow
me arrange some folders alphabetically. (Not as anal nor as tedious as it
sounds, if you insert as you add one at a time.) When I add or remove
something in the text file, then I know for sure which is added and which is
not added.

-- I link to the following: winmm.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib odbc32.lib odbccp32.lib. Yes, I am using dynamic .dll so that I
have the best chance of running on windows versions. (Doing a lot of
CoCreateInstance stuff on all the interfaces, querying for the function
entry points before using them, etc.)

-- Then in another separate folder, I link to my D3D and DX libs. Another
good thing about editing the text file directly, is that that stuff can be
organized.

-- As for string functions, I don't use the C lib ones at all. The ones you
mention isn't bad.

-- But vsprintf and sscanf type functions, if you look at the
implementations, is tremendously dangerous (in terms of going off writing
past the safe locked memory). If you roll a few of the C string funcs you do
use, then it may make it easier to solve linkage problems.

-- So the short summary is, edit the text file directly to add and remove
libs, and to read the libs by opening them. You can see which functions are
inside and not inside a lib, by reading them directly inside the binary
reader of Visual Developer.

-- To help track down your problem, you may also want to explicitly link to
a direct copy (i.e., not use the file path) of each of your libs, so you
know the exact content of what you are linking.

-- Hope any of the above suggestions can help you resolve your linkage.

[GD-Windows] Linker hell

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

So I'm trying to build a fairly large project, statically linked (no
DLLs), and so far I'm in hell.

First pass: Select all projects and use "Multithreaded Debug" library.
I get conflicts with MSVCRTD.DLL, even though it's not being explicitly
referenced by anything.  I do a DUMPBIN on the modules in question, and
they show they're that their defaultlib is MSVCRTD.LIB even though the
project is showing them as using Multithreaded Debug (LIBCMTD.LIB).
What the hell?

Second pass: Select "No default libraries" and manually specify
LIBCMTD.LIB in the libraries list.  Conflicts go away, but now I get:

LINK : warning LNK4049: locally defined symbol "_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free" imported
LINK : warning LNK4049: locally defined symbol "_memmove" imported
LINK : warning LNK4049: locally defined symbol "_realloc" imported
ogg_static_local.lib(framing.obj) : error LNK2001: unresolved external
symbol __imp__memchr
vorbis_static_d.lib(info.obj) : error LNK2001: unresolved external
symbol _strdup

I'm not using the Ogg Vorbis libs directly, I'm actually compiling the
source files.

What's particularly disturbing is that suddenly it can't find strdup()
or memchr() just because I changed libs?!

Any ideas?

Brian

[GD-Windows] MFC Book

[Michael F. <Mi...@fa...>]

Hi all,

not strictly gamedev related but i'm looking for a good
MFC book so if anyone can recommend a book i would be
really happy ... it also helps to know the bad books ;-)
(think a lot of you guys use MFC for tools?)

TIA,

Michael Flad

--
Fantastic Realms Interactive GmbH - Germany
Phone: +49 (0)7121 / 947 999 0
Fax:   +49 (0)7121 / 947 999 9

Re: [GD-Windows] Changing window flags

[Corrinne Y. <cor...@sp...>]

Brian,

The way to change windows flag in runtime is:

SetWindowLong  ( hwnd, GWL_STYLE, flag );
or
SetWindowLong ( hwnd, GWL_EXSTYLE, flag );

Hope this helps.

Corrinne Yu



----- Original Message ----- 
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, November 05, 2001 9:26 PM
Subject: [GD-Windows] Changing window flags


> My app can currently run in a window or fullscreen.  When fullscreen I
> use WS_POPUP and TOPMOST, but when running windowed I use
> WS_OVERLAPPEDWINDOW.  Currently when I toggle between windowed and
> fullscreen I'm not destroying and recreating the window, primarily
> because other components unrelated to graphics (DirectSound) would also
> need to be destroyed and recreated.
> 
> But because my window styles are set at window creation time, things
> look funky when I go windowed->fullscreen (I have a bordered fullscreen
> window) or vice versa (borderless window).  Is there a better way to fix
> this than just to destroy and recreate my window and all HWND dependent
> subsystems every time I change modes?
> 
> Brian

RE: [GD-Windows] Changing window flags

[Wayne C. <wc...@re...>]

> But because my window styles are set at window creation time, things
> look funky when I go windowed->fullscreen (I have a bordered 
> fullscreen
> window) or vice versa (borderless window).  Is there a better 
> way to fix
> this than just to destroy and recreate my window and all HWND 
> dependent
> subsystems every time I change modes?

Can you use SetWindowPos() when switching to windowed mode, and then
resetting them back when going fullscreen, and modifying the style with
SetWindowLong() for any other changes?

ie.

void OnWindowed( HWND hWnd )
{
	SetWindowPos( hWnd, HWND_NOTOPMOST, 0, 0, 256, 256, 0 );
}

void OnFullscreen( HWND hWnd )
{
	SetWindowPos( hWnd, HWND_TOPMOST, 0, 0, screenwidth, screenheight, 0
);
}


Wayne
-Virus scanned and cleared ok

[GD-Windows] Changing window flags

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

My app can currently run in a window or fullscreen.  When fullscreen I
use WS_POPUP and TOPMOST, but when running windowed I use
WS_OVERLAPPEDWINDOW.  Currently when I toggle between windowed and
fullscreen I'm not destroying and recreating the window, primarily
because other components unrelated to graphics (DirectSound) would also
need to be destroyed and recreated.

But because my window styles are set at window creation time, things
look funky when I go windowed->fullscreen (I have a bordered fullscreen
window) or vice versa (borderless window).  Is there a better way to fix
this than just to destroy and recreate my window and all HWND dependent
subsystems every time I change modes?

Brian

RE: [GD-Windows] Latency of wavOutWrite vs. DSound

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

It's been my experience that PlaySound() goes through the file system 
in a synchronous kind of way, so not only do you pay the cost of opening 
and parsing the file ; you also suffer the event loop hit of being 
blocked waiting for all that (including loading the entire sound into 
memory).

Also, PlaySound() only plays one sound at a time, because it needs a 
WAV device, which only allows a single stream. Some hardware actually 
publishes more than one WAV device, but that's the minority. I'm assuming 
you'd want to do something basic like keeping a stream of buffers going 
and mix into that stream as sound events start happening. Perhaps even 
that is overkill for whatever you're doing.

If you're writing a card game, and you know you'll be installed on a 
hard disk that's never spun down, and the sounds are small, and there is 
no background music, PlaySound() may be good enough. Depends on what your 
requirements for "latency" really are.

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Monday, November 05, 2001 10:24 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] Latency of wavOutWrite vs. DSound
> 
> 
> 
> 
> > -----Original Message-----
> > From: Jon Watte [mailto:hp...@mi...] 
> > > Is there a significant difference between PlaySound( resource ) vs. 
> > > waveOutWrite?
> > 
> > Yes.
> 
> Can you elaborate?  I assume you mean that PlaySound has significantly
> worse latency?
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

RE: [GD-Windows] Latency of wavOutWrite vs. DSound

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

> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...] 
> > Is there a significant difference between PlaySound( resource ) vs. 
> > waveOutWrite?
> 
> Yes.

Can you elaborate?  I assume you mean that PlaySound has significantly
worse latency?

Brian

RE: [GD-Windows] Latency of wavOutWrite vs. DSound

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

> I'm working on a small title that needs to run across as wide a range of
> Win32 platforms as possible.  I know that the non-DX audio capabilities
> such as wavOutWrite have higher latencies than using DirectSound, but
> has anyone quantified the difference?  Is it high enough to be
> aggravating in a game that isn't an action game?

The weird thing is that the wavOut API, as designed, could achieve very
low latencies, if only the Windows scheduler would cooperate, and drivers
were well written. I've found that there are a few issues with getting low
latencies on wavOut:

-) some kernels (especially NT 4 I believe) implement it poorly
-) some hardware or drivers make assumptions about minimum block sizes
-) some systems (especially Win95 and original Win98) may not schedule you
   as often as you'd wish

The problem is that most modern cards and systems would have no problem
with you writing 1024 frame buffers at 44.1kHz/16bit/2ch (~23 milliseconds),
but there are some oddball cases that need about 300 milliseconds to work
right. Of course, 300 milliseconds get to the point where buffers are too
big for some hardware so you'd have to split the amount of data you want to
write up into several smaller buffers.

Perhaps you could profile the system, and do double-buffering with 23 ms
buffers on high-end "modern" systems, 69 ms buffers on less "modern" systems
and have a "alternate sound" checkbox which doubled the amount of buffering,
to use in troubleshooting cases. (Note that with 23 ms buffers, your
perceived
latency is twice that, or up to 46 milliseconds; still OK for games).

> Is there a significant difference between PlaySound( resource ) vs.
> waveOutWrite?

Yes.

Cheers,

			/ h+

Re: [GD-Windows] Latency of wavOutWrite vs. DSound

[Corrinne Y. <cor...@sp...>]

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Saturday, November 03, 2001 7:53 PM
Subject: [GD-Windows] Latency of wavOutWrite vs. DSound


> I'm working on a small title that needs to run across as wide a range of
> Win32 platforms as possible.  I know that the non-DX audio capabilities
> such as wavOutWrite have higher latencies than using DirectSound, but
> has anyone quantified the difference?  Is it high enough to be
> aggravating in a game that isn't an action game?

-- Old DSound (using it only as a way to write out to a simple sound output
buffer) is available on a lot of systems, and if not, can be provided free
with your application. I had done code on some games that were pretty old
that did not use any D3D (and didn't use OpenGL) and only used DSound.

-- Using simple old DSound doesn't lock you out of too many legacy Win32
platforms. And when I didn't use DSound back then, I used those famous 3rd
party audio libs, which didn't cost too much to license either. (in exchange
for sound board compatibility, and decent audio performance, and a more
practical API interface)

-- And when I didn't use the 3rd party audio libs, I programmed the
interrupts directly for a handful of audio chips. It wasn't that bad as
audio cards were trying to converge towards the Adlib / Soundblaster
cloneing process anyway. I don't suspect interrupt programming is too bad
now (though hadn't done it for a while) since most of those bargain non
Creative chips probably just emulate old Adlib or old Soundblaster
interfaces on some level.

[GD-Windows] Latency of wavOutWrite vs. DSound

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

I'm working on a small title that needs to run across as wide a range of
Win32 platforms as possible.  I know that the non-DX audio capabilities
such as wavOutWrite have higher latencies than using DirectSound, but
has anyone quantified the difference?  Is it high enough to be
aggravating in a game that isn't an action game?

Is there a significant difference between PlaySound( resource ) vs.
waveOutWrite?

Thanks,

Brian

[GD-Windows] Foregroundness

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

I'm having some problems with forcing my app to the foreground. We currently
show a splash screen at startup and defer going fullscreen till almost
everything is loaded so there is enough time for a user to click on other
windows to continue browsing or whatever (especially in debug builds ;)). I
don't want to change this behaviour at all and using the below code to
obtain foregroundness works except if the app that currently has the focus/
is the foreground app is 'cmd'. Is there a way to make it work even in this
case?

HWND hWndForeground = ::GetForegroundWindow();
AttachThreadInput(GetWindowThreadProcessId(hWndForeground, NULL),
GetCurrentThreadId(), true);
SetForegroundWindow( Window->hWnd );
AttachThreadInput(GetWindowThreadProcessId(hWndForeground, NULL),
GetCurrentThreadId(), false);

- Daniel Vogel, Programmer, Epic Games Inc.