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

[GD-Windows] FPU registers in __asm blocks

[Grisha S. <_g...@tu...>]

Why I can't use FPU registers in __asm blocks in Visual C++
(v6.0+SP5)? When
I write something like:

void AxisAngle2quat( quat dest, const vect3 axis, const
float angle )
{
     static float real05 = 0.5f;
     float sine, cosine;
     __asm fld dword ptr angle
     __asm fmul dword ptr real05
     __asm fsincos
     __asm fstp dword ptr cosine
     __asm fstp dword ptr sine
     dest[X] = axis[X]*sine;
     dest[Y] = axis[Y]*sine;
     dest[Z] = axis[Z]*sine;
     dest[W] = cosine;
}
all works fine, but if I try

void AxisAngle2quat( quat dest, const vect3 axis, const
float angle )
{
    static float real05 = 0.5f;
    __asm
    {
        fld dword ptr angle
        fmul dword ptr real05
        fsincos
        mov ecx, dword ptr axis
        mov edx, dword ptr dest
        fstp dword ptr [edx+12]
        fld dword ptr [ecx]
        fmul st(1)
        fstp dword ptr [edx]
        fld dword ptr [ecx+4]
        fmul st(1)
        fstp dword ptr [edx+4]
        fld dword ptr [ecx+8]
        fmul st(1)
        fstp dword ptr [edx+8]
    }
}
I will get 'error C2415: improper operand type' on every
'fmul st(1)'.

Re: [GD-Windows] Process communication

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

Seems to me you're confusing two problems here:

a) Keeping a centralized set of assets everyone can use for development
b) Building the asset set for the game use

A system that's tuned for use by the game is probably going to be a mess
trying to update it during development, and vice-versa.

I suggest you make two systems -- one that's easy to maintain, and one
that's fast and compact for the game. Make the game software capable of
using both.

What we did (using Quake I's rudimentary but adequate-at-the-time .pak
file format) was make our game read all pakfiles AND the local
filesystem for all assets. The most recent version of the asset found
was used. It meant you could replace an asset simply by dropping a copy
into the local filesystem.

In your case, you're looking to use a networked system. What I'd do is
have your server keep a master directory that contains pointers to the
most current version of stuff, some of which will be in the master
archive file. Every night when no one's around, rebuild the master
archive from the most current assets. During the day, when someone
updates an asset, you just change the pointer in the directory.

If you need to make a local copy of the archive, you either have to wait
for it to build you a complete local copy, or you replicate the
directory functionality on the local machine.

I hope I haven't misunderstood your problem.

	Kent


David Hunt wrote:
> 
> Thanks Jon (*2;-)
> 
>     I'll look at DCOM. I'm not so much interested in managing multiple
> resources or versioning, we find Sourcesafe adequate for that. I'm more
> interested in developing a single monolihic (.wad) style file format
> Gigabytes large containing all final/production binary assets of the game.
> 
>     In order to keep this database safe and allow timely shared access to it
> I want to route all access to it through a server application (rather than
> treating it as one big shared file on our network).
> 
>     I also need to understand the file format from within the game which
> WILL just treat it as a big file (the game won't be a client, it will use a
> local copy).
> 
>     This isn't a massive versioning exercise - all I want is a high capacity
> pipe between myself and another application on another machine on our
> intranet.
> 
> David Hunt
> 
> ----- Original Message -----
> From: "Jon Watte" <hp...@mi...>
> To: "David Hunt" <da...@em...>;
> <gam...@li...>
> Sent: Monday, March 04, 2002 5:50 PM
> Subject: RE: [GD-Windows] Process communication
> 
> >
> > The official solution is DCOM. Unfortunately, that's about as far
> > from designed-for-games as you can come. In games, the real-time
> > nature of a message ("I want it now") is much more important than
> > something like "reliable, in-sequence delivery". This means that
> > any RPC-like mechanism is doomed to failure, except for non-time-
> > critical operations. Of course, those, you'd like to take care of
> > before the game even starts, using some protocol like rsync.
> >
> > In your problem description, it was somewhat un-clear whether you
> > were looking for a workflow/verioning system for in-house
> > development and release management, or a run-time remote data
> > management system. If what you meant was the former, I would
> > suggest Perforce because of it's fast and flexible revision
> > management, or possibly CVS because it's reliable and cheap.
> >
> > Cheers,
> >
> > / h+
> >
> > >     What mechanisms should I be looking at in Windows for remote
> > > inter-object communication?
> >
> >
> >
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

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

RE: [GD-Windows] Process communication

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

>     I'll look at DCOM. I'm not so much interested in managing multiple
> resources or versioning, we find Sourcesafe adequate for that. I'm more

To each his own, I guess :-)

> interested in developing a single monolihic (.wad) style file format
> Gigabytes large containing all final/production binary assets of the game.

You might want to make part of your build process be to re-generate
the wad file(s) from sources, with actual dependency maps. That way,
you have full control of what goes into it, and it's never fragmented
or out of date. You could do it on each client as part of make; the
only cost is extra disk space and sync time. Of course, with SourceSafe,
that might become a problem.

>     This isn't a massive versioning exercise - all I want is a
> high capacity
> pipe between myself and another application on another machine on our
> intranet.

I see. Basically, the remote-ness only comes into play in the development
environment, and it's there because you want one master machine that
stores and keeps assets, rather than having the assets and file building
go through source control to the clients.

Anything works, there. You might consider just banging something out with
raw sockets. Or you could use Apache with a plug-in and wrap it all in
HTTP. Or you could use network mounts and proper file locking. I'd prefer
either of these solutions to having to write and use something RPC-like
(such as DCOM). Yes, I'm no great RPC fan :-)

Cheers,

			/ h+

Re: [GD-Windows] Process communication

[David H. <da...@em...>]

Thanks Jon (*2;-)

    I'll look at DCOM. I'm not so much interested in managing multiple
resources or versioning, we find Sourcesafe adequate for that. I'm more
interested in developing a single monolihic (.wad) style file format
Gigabytes large containing all final/production binary assets of the game.

    In order to keep this database safe and allow timely shared access to it
I want to route all access to it through a server application (rather than
treating it as one big shared file on our network).

    I also need to understand the file format from within the game which
WILL just treat it as a big file (the game won't be a client, it will use a
local copy).

    This isn't a massive versioning exercise - all I want is a high capacity
pipe between myself and another application on another machine on our
intranet.


David Hunt

----- Original Message -----
From: "Jon Watte" <hp...@mi...>
To: "David Hunt" <da...@em...>;
<gam...@li...>
Sent: Monday, March 04, 2002 5:50 PM
Subject: RE: [GD-Windows] Process communication


>
> The official solution is DCOM. Unfortunately, that's about as far
> from designed-for-games as you can come. In games, the real-time
> nature of a message ("I want it now") is much more important than
> something like "reliable, in-sequence delivery". This means that
> any RPC-like mechanism is doomed to failure, except for non-time-
> critical operations. Of course, those, you'd like to take care of
> before the game even starts, using some protocol like rsync.
>
> In your problem description, it was somewhat un-clear whether you
> were looking for a workflow/verioning system for in-house
> development and release management, or a run-time remote data
> management system. If what you meant was the former, I would
> suggest Perforce because of it's fast and flexible revision
> management, or possibly CVS because it's reliable and cheap.
>
> Cheers,
>
> / h+
>
> >     What mechanisms should I be looking at in Windows for remote
> > inter-object communication?
>
>
>

RE: [GD-Windows] Process communication

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

The official solution is DCOM. Unfortunately, that's about as far 
from designed-for-games as you can come. In games, the real-time 
nature of a message ("I want it now") is much more important than 
something like "reliable, in-sequence delivery". This means that 
any RPC-like mechanism is doomed to failure, except for non-time-
critical operations. Of course, those, you'd like to take care of 
before the game even starts, using some protocol like rsync.

In your problem description, it was somewhat un-clear whether you 
were looking for a workflow/verioning system for in-house 
development and release management, or a run-time remote data 
management system. If what you meant was the former, I would 
suggest Perforce because of it's fast and flexible revision 
management, or possibly CVS because it's reliable and cheap.

Cheers,

			/ h+

>     What mechanisms should I be looking at in Windows for remote
> inter-object communication?

[GD-Windows] Process communication

[David H. <da...@em...>]

Very soon I'm going to be moving our currently very messy data storage
scheme consisting of hundreds of seperate sound/texture/binary files into a
properly managed data solution (ugh I've already started talking MS
techno-babble - I'll be using words like "leverage" and calling all our
projects solutions soon).

So...
    Our shiny new system needs to be client server based. All
artists/content providers compile their data into a single large database
residing on a seperate machine (or locally for debug purposes). Obviously to
manage all this more than blind file sharing is needed - I don't want to
have to wait 10 minutes whilst artist A copies his data over and keeps the
file locked. I need to send my data to a server application that controls
database access in a fair/interleaved monolithic timely safe fashion. The
server needs to be able to defrag the database in its spare time and clients
need to be able to browse it quickly, detemine changes and synchronise data
that has changed locally.

    The data storage format has to be understandable by the game and cross
platform so SQL or whatever probably isn't on the cards (I think?).

    I want this to run on win 98 machines up - but I suppose at a pinch we
could set the bar at ME/NT.

    What mechanisms should I be looking at in Windows for remote
inter-object communication?


David Hunt (Empire Interactive)

RE: [GD-Windows] Beep error on exit

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

> From: Brian Hook [mailto:bri...@py...]
> Sent: Thursday, February 21, 2002 9:43 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] Beep error on exit
>=20
> At 09:40 PM 2/21/2002 -0800, Brian Sharon wrote:
> >Who/what is firing the beep off?  Just wondering...
>=20
> No clue.  When I run in Debug Mode under MSVC and quit the app, I get
the
> beep.  If I run in Release Mode, no beep.  I've seen this before,
usually
> something "Bad" is happening somewhere and the message beep is telling
me
> about it, but there's no way to trap it.

Maybe you have static object destructors doing something bogus?  Don't
forget you can keep stepping for quite awhile past the end of main(),
there's a bunch of code still left to execute at that point.

In this case I'm not sure SetUnhandledExceptionFilter is going to help
you, it doesn't sound like you have an actual exception/access violation
going on - or you'd already be dropping into the debugger.  Sorry :(.
You could try setting a breakpoint on MessageBeep(), assuming that's
what triggers the sound.

Good luck,

--b.

RE: [GD-Windows] Beep error on exit

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

At 09:40 PM 2/21/2002 -0800, Brian Sharon wrote:
>Who/what is firing the beep off?  Just wondering...

No clue.  When I run in Debug Mode under MSVC and quit the app, I get the 
beep.  If I run in Release Mode, no beep.  I've seen this before, usually 
something "Bad" is happening somewhere and the message beep is telling me 
about it, but there's no way to trap it.

>Check out SetUnhandledExceptionFilter().

Thanks, I'll check that out!

Brian

RE: [GD-Windows] Beep error on exit

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

> When my app exits under the debugger, I hear the "Error beep" in the
> background, but I don't see any complaints in the debugger output, nor
> do any asserts fire.  Putting a breakpoint at the last line of main()
I
> don't get any beep errors either.

Who/what is firing the beep off?  Just wondering...

> Is there a simple, slick way to put in a handler to get called when
any
> type of error crops up, that way stuff that is "broken but magically
> fixed because the app's exiting anyway" can get fixed correctly on my
> part.

Check out SetUnhandledExceptionFilter().

--brian

[GD-Windows] Beep error on exit

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

When my app exits under the debugger, I hear the "Error beep" in the
background, but I don't see any complaints in the debugger output, nor
do any asserts fire.  Putting a breakpoint at the last line of main() I
don't get any beep errors either.

Is there a simple, slick way to put in a handler to get called when any
type of error crops up, that way stuff that is "broken but magically
fixed because the app's exiting anyway" can get fixed correctly on my
part.

Thanks,

Brian

[GD-Windows] distorted dialogs

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

Hi,
does somebody knows how to control the exact size of the fonts in order to
avoid the distortion of the dialogs? It happens with many programs when
using 120dpi fonts for example and  I don't want my apps look that bad.

Thanks in advance,


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



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

RE: [GD-Windows] SM_SLOWMACHINE

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

> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: Tuesday, December 25, 2001 9:13 PM
>=20
> Just out of pure curiosity, what the hell is that function exactly
doing
> to
> tell between a slow and a not-slow machine ?
>=20
> BOOL Res =3D GetSystemMetrics(SM_SLOWMACHINE);
>=20
> I find that one rather amusing :)
>=20

I was going through old email today and saw this, which got me wondering
all over again.  What the hell *is* a slow machine?  So I asked.  The
short version is it's a really, really, really slow machine.  The email
thread follows:

-----Original Message-----
From: Brian Sharon=20
Sent: Wednesday, February 20, 2002 5:37 PM
Subject: SM_SLOWMACHINE
Importance: Low
=20
What the heck does GetSystemMetrics(SM_SLOWMACHINE) check for?  Standard
mode vs. 386 enhanced?  Wow, just typing those words took me back to a
horrible place.  Or is it something more relevant?
=20
No, I'm not planning on using this.  Just curious.
=20
--brian

-----Original Message-----
From: Jon Wiswall=20
Sent: Wednesday, February 20, 2002 5:47 PM
Subject: RE: SM_SLOWMACHINE

The MSDN 8-ball brought up Q131259, which details how it can be used to
detect unaccelerated video cards, low memory (< 5mb) and low CPU (=3D=3D
386) machines.
=20
Good luck getting XP to run on such a machine.

-----Original Message-----
From: Ken Wickes=20
Sent: Wednesday, February 20, 2002 5:56 PM
Subject: RE: SM_SLOWMACHINE

I can find no mention of it in the NT source, I suspect all NT machines
are fast machines.  . =20
=20
Thanks for reminding me of the old windows modes.  May you be cursed to
maintaining the SDK docs for GlobalWire(). =20
=20

RE: [GD-Windows] Stopping a thread cleanly

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

> Function calls have nothing do with it.  "Assume aliasing across
> function calls" is a separate setting.
> 
> This program has an aliasing problem, yet thread 2 has no function calls
> in it.  See for yourself:

The difference in this program would be that I would no think the 
compiler incorrect to put the values in registers, thus you'd have 
to use the "volatile" qualifier. However, the compiler cannot 
correctly make any guesses about whether something on the other end 
of a pointer changes when you call a function with separate linkage 
(i e, in a separate translation unit).

Basically, my view is that the standard does not require the compiler 
to be thread, or signal, aware in its code generation, but it DOES 
require it to be conservative on aliasing. It's already the case 
that compilers generate thread-unsafe code for some constructs, such 
as initialization of statics with function scope.

Then, what specific compilers do with specific options, is another 
question (and ultimately, quite relevant :-)

Cheers,

			/ h+

RE: [GD-Windows] Stopping a thread cleanly

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

Function calls have nothing do with it.  "Assume aliasing across
function calls" is a separate setting.

This program has an aliasing problem, yet thread 2 has no function calls
in it.  See for yourself:

#include <windows.h>
#include <stdio.h>

int gTrueCount, gFalseCount;

DWORD WINAPI ThreadProc(LPVOID param)
{
	bool * fooPtr =3D (bool *)param;
	while (1)
	{
		if (*fooPtr)
		{
            gTrueCount++;
		}
		else
		{
            gFalseCount++;
		}
	}
}

int main(int argc, char **argv)
{
    gTrueCount =3D 0;
    gFalseCount =3D 0;
    bool foo =3D true;
    CreateThread(NULL, 0, ThreadProc, &foo, 0, NULL);
    while (1)
    {
        foo =3D !foo;
        printf("True count: %d False count: %d\n", gTrueCount,
gFalseCount);
        ::Sleep(1000);
    }
    return 0;
}

> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...]
> Sent: Monday, February 18, 2002 10:56 AM
> To: Brian Sharon; bri...@py...; gamedevlists-
> wi...@li...
> Subject: RE: [GD-Windows] Stopping a thread cleanly
>=20
>=20
> It only needs to assume this if you're calling any other function
> from within that loop. Of course, Sleep(), or WaitForSingleObject(),
> or pretty much anything else you might want to do in the loop does
> count as a function call (as long as it doesn't get inlined) but
> I thought I'd mention it.
>=20
> volatile is your friend when you're using a shared-memory thread
> communication model.
>=20
> Cheers,
>=20
> 				/ h+
>=20
> > The compiler should always reload it unless you've specified "assume
no
> > aliasing" (which is not the default, even in optimized builds).
Since
> > it's not a local variable, it has to assume that pData->bKill can be
> > changed every time through the loop.
>=20

Re: [GD-Windows] Mind numbing GetOpenFileName Problem

[Paul C. <pa...@pa...>]

Brian: Cheers that seems to have helped, e.g. it stopped crashing and then I
also noticed (eventually) I hadn't set ofn.hInstance which seemed to finally
fixed things.

Tom: Very wierd, mine took an extra 20 minutes here. Go figure. Perhaps I
should have set the priority button in outlook :D

----- Original Message -----
From: "Brian Sharon" <bs...@mi...>
To: "Paul Crowder" <pa...@pa...>;
<gam...@li...>
Sent: Monday, February 18, 2002 4:58 PM
Subject: RE: [GD-Windows] Mind numbing GetOpenFileName Problem


Have you tried inserting:

> OPENFILENAME ofn;

ZeroMemory(&ofn, sizeof(ofn));

> ofn.lStructSize = sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =

unless you're sure you're setting every field, you should probably get
in the habit of doing that...

--brian

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

RE: [GD-Windows] Stopping a thread cleanly

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

It only needs to assume this if you're calling any other function 
from within that loop. Of course, Sleep(), or WaitForSingleObject(), 
or pretty much anything else you might want to do in the loop does 
count as a function call (as long as it doesn't get inlined) but 
I thought I'd mention it.

volatile is your friend when you're using a shared-memory thread 
communication model.

Cheers,

				/ h+

> The compiler should always reload it unless you've specified "assume no
> aliasing" (which is not the default, even in optimized builds).  Since
> it's not a local variable, it has to assume that pData->bKill can be
> changed every time through the loop.

RE: [GD-Windows] Mind numbing GetOpenFileName Problem

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

> > OPENFILENAME ofn;
> 
> ZeroMemory(&ofn, sizeof(ofn));

I second this advice; never forget it!

> > ofn.lStructSize = sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =
> 
> unless you're sure you're setting every field, you should probably get
> in the habit of doing that...

After reading on MSDN, I believe that OPENFILENAME_SIZE_VERSION_400 
is a (constant) int. sizeof( int ) is 4. You probably want to drop 
the "sizeof" in this piece of code.

Cheers,

			/ h+


PS: if you had stepped through the offending data set-up in the 
debugger, or just inspected it right before you called Windows, 
you might have caught it more quickly.

Re: [GD-Windows] Mind numbing GetOpenFileName Problem

[Andrew G. <an...@ra...>]

Why are you defining the Windows version? Just miss these out and use
sizeof(OPENFILENAME). This is from one of my tools;

char szFileName[256] = {0};        // make sure this is null terminated or
windows barfs
	char szInitialDir[256];

 // Display the OpenFileName dialog. Then, try to load the specified file
    OPENFILENAME ofn = { sizeof(OPENFILENAME), NULL, NULL,
                        _T(".IMF Files (.x)\0*.imf\0\0"),
                        NULL, 0, 1, szFileName, 256, NULL, 0,
                        szInitialDir, _T("Open Mesh File"),
                        OFN_FILEMUSTEXIST, 0, 1, NULL, 0, NULL, NULL };

   if( TRUE == GetOpenFileName( &ofn ) )
    {


// andrew

----- Original Message -----
From: "Paul Crowder" <pa...@pa...>
To: <gam...@li...>
Sent: Friday, February 15, 2002 11:01 PM
Subject: [GD-Windows] Mind numbing GetOpenFileName Problem


> All I want is an open file dialog box, but no, windows has to cause me
> problems.  Ok, its probably a silly mistake but here goes.
> I'm compiling with both these flags set:
> #define _WIN32_WINNT 0x500
> #define WINVER 0x500
>
> to try and get various things (mousewheel, ...) to co-operate.  The
problem
> comes when I try and open a file dialog.  The code is below.  The
>
> sticking point appears to be the ofn.lStructSize line.  When set using the
> VERSION_400 flag is fails gracefully with CDERR_STRUCTSIZE.  If I use
>
> sizeof( OPENFILENAME ) it just crashes in the kernel on GetOpenFileName.
> This should be really simple to get up and running, but I don't know how
>
> get out of this hole I seem to have dug.  With no error message, useful or
> otherwise, I'm a bit stuck.
>
> (I apologise for the crap formatting but outlook express has decided to
put
> double carriage returns everywhere - go figure).
>
> cheers
>
> Paul
>
> char inputfile[256], outputfile[256], filename[256];
> char initdir[] = "d:\\Projects\\Clearday\\Data/0";
> char title[] = "Select file to process/0";
>
>
> OPENFILENAME ofn;
> ofn.lStructSize = sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =
> izeof( OPENFILENAME );
> ofn.hwndOwner = hWnd;
> char *filter = "Max ASE files/0*.ASE/0/0";
> ofn.lpstrFilter = NULL;
> ofn.lpstrCustomFilter = NULL;
> ofn.lpstrFile = inputfile;
> ofn.nMaxFile = 256;
> ofn.lpstrFileTitle = filename;
> ofn.nMaxFileTitle = 256;
> ofn.lpstrInitialDir = NULL;
> ofn.lpstrTitle = NULL;
> ofn.Flags = ( OFN_ENABLESIZING | OFN_FILEMUSTEXIST );
>
> if( GetOpenFileName( &ofn )!=0 )
> {
>     _world.PreProcess( type, inputfile, outputfile );
> }
> else
> {
>     DWORD err = CommDlgExtendedError();
>     if( err == CDERR_STRUCTSIZE )
>     {
>         int a = 1;
>     }
> }
>
>
> _______________________________________________
> 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] Stopping a thread cleanly

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

> > In this case the compiler could put bExit in a register due
> > to optimisation which obviously isn't good.
>=20
> This is actually why this came up.  When I looked at my original code,
> it was basically doing this:
>=20
> while ( 1 )
> {
> ...
> if ( pData->bKill )
>   break;
> ...
> }
>=20
> I was more than a little concerned that the compiler wasn't reloading
> pData->bKill in some instances, because there were sections of code
> where no function calls were occurring but bKill was being checked
> multiple times.
>=20

The compiler should always reload it unless you've specified "assume no
aliasing" (which is not the default, even in optimized builds).  Since
it's not a local variable, it has to assume that pData->bKill can be
changed every time through the loop.

--brian

RE: [GD-Windows] Mind numbing GetOpenFileName Problem

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

Have you tried inserting:

> OPENFILENAME ofn;

ZeroMemory(&ofn, sizeof(ofn));

> ofn.lStructSize =3D sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =3D

unless you're sure you're setting every field, you should probably get
in the habit of doing that...

--brian

[GD-Windows] Mind numbing GetOpenFileName Problem

[Paul C. <pa...@pa...>]

All I want is an open file dialog box, but no, windows has to cause me
problems.  Ok, its probably a silly mistake but here goes.
I'm compiling with both these flags set:
#define _WIN32_WINNT 0x500
#define WINVER 0x500

to try and get various things (mousewheel, ...) to co-operate.  The problem
comes when I try and open a file dialog.  The code is below.  The

sticking point appears to be the ofn.lStructSize line.  When set using the
VERSION_400 flag is fails gracefully with CDERR_STRUCTSIZE.  If I use

sizeof( OPENFILENAME ) it just crashes in the kernel on GetOpenFileName.
This should be really simple to get up and running, but I don't know how

get out of this hole I seem to have dug.  With no error message, useful or
otherwise, I'm a bit stuck.

(I apologise for the crap formatting but outlook express has decided to put
double carriage returns everywhere - go figure).

cheers

Paul

char inputfile[256], outputfile[256], filename[256];
char initdir[] = "d:\\Projects\\Clearday\\Data/0";
char title[] = "Select file to process/0";


OPENFILENAME ofn;
ofn.lStructSize = sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =
izeof( OPENFILENAME );
ofn.hwndOwner = hWnd;
char *filter = "Max ASE files/0*.ASE/0/0";
ofn.lpstrFilter = NULL;
ofn.lpstrCustomFilter = NULL;
ofn.lpstrFile = inputfile;
ofn.nMaxFile = 256;
ofn.lpstrFileTitle = filename;
ofn.nMaxFileTitle = 256;
ofn.lpstrInitialDir = NULL;
ofn.lpstrTitle = NULL;
ofn.Flags = ( OFN_ENABLESIZING | OFN_FILEMUSTEXIST );

if( GetOpenFileName( &ofn )!=0 )
{
    _world.PreProcess( type, inputfile, outputfile );
}
else
{
    DWORD err = CommDlgExtendedError();
    if( err == CDERR_STRUCTSIZE )
    {
        int a = 1;
    }
}

[GD-Windows] Fw: Mind numbing GetOpenFileName Problem

[Paul C. <pa...@pa...>]

Original message is below, the first attempt didn't seem to get through? Are
the lists shut down at weekends?

----- Original Message -----
From: "Paul Crowder" <pa...@pa...>
To: <gam...@li...>
Sent: Friday, February 15, 2002 11:01 PM
Subject: Mind numbing GetOpenFileName Problem


> All I want is an open file dialog box, but no, windows has to cause me
> problems.  Ok, its probably a silly mistake but here goes.
> I'm compiling with both these flags set:
> #define _WIN32_WINNT 0x500
> #define WINVER 0x500
>
> to try and get various things (mousewheel, ...) to co-operate.  The
problem
> comes when I try and open a file dialog.  The code is below.  The
>
> sticking point appears to be the ofn.lStructSize line.  When set using the
> VERSION_400 flag is fails gracefully with CDERR_STRUCTSIZE.  If I use
>
> sizeof( OPENFILENAME ) it just crashes in the kernel on GetOpenFileName.
> This should be really simple to get up and running, but I don't know how
>
> get out of this hole I seem to have dug.  With no error message, useful or
> otherwise, I'm a bit stuck.
>
> (I apologise for the crap formatting but outlook express has decided to
put
> double carriage returns everywhere - go figure).
>
> cheers
>
> Paul
>
> char inputfile[256], outputfile[256], filename[256];
> char initdir[] = "d:\\Projects\\Clearday\\Data/0";
> char title[] = "Select file to process/0";
>
>
> OPENFILENAME ofn;
> ofn.lStructSize = sizeof( OPENFILENAME_SIZE_VERSION_400 );  // =
> izeof( OPENFILENAME );
> ofn.hwndOwner = hWnd;
> char *filter = "Max ASE files/0*.ASE/0/0";
> ofn.lpstrFilter = NULL;
> ofn.lpstrCustomFilter = NULL;
> ofn.lpstrFile = inputfile;
> ofn.nMaxFile = 256;
> ofn.lpstrFileTitle = filename;
> ofn.nMaxFileTitle = 256;
> ofn.lpstrInitialDir = NULL;
> ofn.lpstrTitle = NULL;
> ofn.Flags = ( OFN_ENABLESIZING | OFN_FILEMUSTEXIST );
>
> if( GetOpenFileName( &ofn )!=0 )
> {
>     _world.PreProcess( type, inputfile, outputfile );
> }
> else
> {
>     DWORD err = CommDlgExtendedError();
>     if( err == CDERR_STRUCTSIZE )
>     {
>         int a = 1;
>     }
> }
>

RE: [GD-Windows] Stopping a thread cleanly

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

> I don't see why a critical section would be necessary in that loop. 

It's a guard around the shared data accessed in DoWork().

> There's no shared state going on between the player and the killer, 
> except for the event, which is protected enough without the critical 
> section.

Actually, there is shared state -- in this case, they're both trying to
dork with an LPDIRECTSOUNDBUFFER.  The killer immediately releases it
when the thread is done.  I could have the thread do this, but sometimes
I just want to stop the thread without releasing the buffer.
 
> Anyway, the problem with this is that you delay shut-down (while 
> spinning, waiting for that global) for whatever your sleep time is. 

Which is why I'm WFSO now instead of just a pure sleep.

> DirectSound supports playback notifier events, so you can set an 
> event, say, every 100 milliseconds played, and use this event to 
> wake up and fill the buffer.

Except those don't work all the time.  Way back when, Candy Cruncher
used notifications, until I started getting E_NOINTERFACE failures on
some older drivers and sound cards.  Getting rid of those made my audio
a lot more robust.

> Regarding declaring members or globals "volatile" when they're shared 
> between threads: that's what the keyword is for, so I don't see how 
> that is considered ugly (assuming you need that semantic)?

I was originally going to declare the _class_ as volatile, which
suddenly breaks a lot of things (respecing volatile is much like
respecing const -- it ain't plug and play).  But just specing that one
member would have worked (and is all that's necessary).

Brian

RE: [GD-Windows] Stopping a thread cleanly

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

> Actually, I'm not giving it instructions -- it's completely autonomous
> based on the parameter passed to it which is a pointer to the shared
> data it needs to operate on.  It doesn't have any communication

I don't see why a critical section would be necessary in that loop. 
There's no shared state going on between the player and the killer, 
except for the event, which is protected enough without the critical 
section.

Anyway, the problem with this is that you delay shut-down (while 
spinning, waiting for that global) for whatever your sleep time is. 
DirectSound supports playback notifier events, so you can set an 
event, say, every 100 milliseconds played, and use this event to 
wake up and fill the buffer. Or you can use your "shutdown" event 
with an appropriate time-out as your sleep thing, if you're OK 
with polling.

playerThread:

for(;;) {
  if( WaitForSingleObject( event, POLL_INTERVAL ) == WAIT_TIMEOUT ) {
    break;
  }
  lock buffer, read disk, unlock buffer
}

stopper:

  SetEvent( event );
  WaitForSingleObject( playerThread, INFINITE );


Regarding declaring members or globals "volatile" when they're shared 
between threads: that's what the keyword is for, so I don't see how 
that is considered ugly (assuming you need that semantic)?

Cheers,

			/ h+

RE: [GD-Windows] Stopping a thread cleanly

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

> In this case the compiler could put bExit in a register due 
> to optimisation which obviously isn't good. 

This is actually why this came up.  When I looked at my original code,
it was basically doing this:

while ( 1 )
{
...
if ( pData->bKill )
  break;
...
}

I was more than a little concerned that the compiler wasn't reloading
pData->bKill in some instances, because there were sections of code
where no function calls were occurring but bKill was being checked
multiple times.

I was going to do the knee jerk thing of specing it as volatile, but
decided to go with WFSO instead.

Brian