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

RE: [GD-Windows] VC++ lag

[Neil S. <ne...@st...>]

> Poor you, Visual Assist is teh bawmb

Especially when combined with Workspace Whiz. :)

Actually, Pierre, with Workspace Whiz, you probably wouldn't care about
maintaining open files any more, because it lets you find any file very
quickly. You have to see it to believe it...

- Neil.


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Re: [GD-Windows] VC++ lag

[Mickael P. <mpo...@ed...>]

>> Do you have workspaces that contains a lot of subprojects, with the
>> mainproject having all other projects considered as dependancies of
>> the main ?
>
> Yes.

Ok.

Each time I have a workspace with this kind of situation the first build of
the complex project after loading visual is always slow. It seems that
visual check each file date of each subtarget to see if it must be rebuilt,
and it takes an insane amount of time for some strange reason I didn't
understand :)

Try to add a new "hello world" project in your workspace. Save the workspace
and quit visual.

Reload visual, select the "hello world" as active project, build. It should
start instantaneously.

Quit and reload, select your complex main target, and build. It should take
forever before starting building.

    Mickael Pointier

RE: [GD-Windows] VC++ lag

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

> > Delete your .opt file, normally solves that. It's checking for
> dependancies
> > and something go screwed up ( I guess )
> 
> Sigh.... Unfortunately I'd like to keep that one alive, as it's where
> currently open files are stored (I think). I like to keep 
> some files open
> from day to day (the files I'm currently working on). Anyway 
> I guess I'll
> give it a try.

Don't delete it every day, just when you have problems :)

> >Do you use VisualAssist, or anyother kind of VC++ pluggin ?
> 
> No.

Poor you, Visual Assist is teh bawmb

> 
> >Do you have workspaces that contains a lot of subprojects, with the
> >mainproject having all other projects considered as 
> dependancies of the
> main
> >?
> 
> Yes.
> 

Will be slow.

Re: [GD-Windows] VC++ lag

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

> Delete your .opt file, normally solves that. It's checking for
dependancies
> and something go screwed up ( I guess )

Sigh.... Unfortunately I'd like to keep that one alive, as it's where
currently open files are stored (I think). I like to keep some files open
from day to day (the files I'm currently working on). Anyway I guess I'll
give it a try.

>The .ncb file is another pest.

No problem with those as I delete them frequently (each time I make a
backup, to save some space)

>Do you use VisualAssist, or anyother kind of VC++ pluggin ?

No.

>Do you have workspaces that contains a lot of subprojects, with the
>mainproject having all other projects considered as dependancies of the
main
>?

Yes.


Pierre

Re: [GD-Windows] VC++ lag

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

The screwed up .opt is definitely guilty for the long delays before
compilation.

Neil Stewart wrote:
> Actually, thinking about it, isn't it the .ncb that causes both these
> problems? I haven't used VC6 for a few months now, so I'm not
> absolutely sure.

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] VC++ lag

[Mickael P. <mpo...@ed...>]

> Is there any particular reason why VC++ should lag like hell before
> starting compiling ? The scenario is :
> - W2K / VC++ 6 / SP5 / brand new machine
> - I press F5 or F7 to compile
> - Between 30 and 60 seconds later compilation actually starts
> (before, VC++ just doesn't respond)

Do you use VisualAssist, or anyother kind of VC++ pluggin ?
Do you have workspaces that contains a lot of subprojects, with the
mainproject having all other projects considered as dependancies of the main
?

    Mickael Pointier

RE: [GD-Windows] VC++ lag

[Neil S. <ne...@st...>]

Actually, thinking about it, isn't it the .ncb that causes both these
problems? I haven't used VC6 for a few months now, so I'm not absolutely
sure.

- Neil.


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Neil Stewart
Sent: 12 June 2003 14:20
To: gam...@li...
Subject: RE: [GD-Windows] VC++ lag


There is usually still a lag even with no .opt file (checking
dependencies as Gareth says), but it's nowhere near as bad as it is when
the .opt file gets into that 'treacle' state. On occasion, I've seen it
actually take so long that it was faster to quit devstudio, delete the
.opt and start again.

The .ncb file is another pest. When it gets in a mess, you might get a
warning about missing ClassWizard information every time you load the
workspace. Deleting it also fixes the problem.

- Neil.



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

RE: [GD-Windows] VC++ lag

[Neil S. <ne...@st...>]

There is usually still a lag even with no .opt file (checking
dependencies as Gareth says), but it's nowhere near as bad as it is when
the .opt file gets into that 'treacle' state. On occasion, I've seen it
actually take so long that it was faster to quit devstudio, delete the
.opt and start again.

The .ncb file is another pest. When it gets in a mess, you might get a
warning about missing ClassWizard information every time you load the
workspace. Deleting it also fixes the problem.

- Neil.


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Gareth Lewin
Sent: 12 June 2003 14:05
To: gam...@li...
Subject: RE: [GD-Windows] VC++ lag


Delete your .opt file, normally solves that. It's checking for
dependancies and something go screwed up ( I guess )



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

RE: [GD-Windows] VC++ lag

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

Delete your .opt file, normally solves that. It's checking for dependancies
and something go screwed up ( I guess )

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 12 June 2003 23:04
> To: gam...@li...
> Subject: [GD-Windows] VC++ lag
> 
> 
> Hi,
> 
> Is there any particular reason why VC++ should lag like hell 
> before starting
> compiling ? The scenario is :
> - W2K / VC++ 6 / SP5 / brand new machine
> - I press F5 or F7 to compile
> - Between 30 and 60 seconds later compilation actually starts 
> (before, VC++
> just doesn't respond)
> 
> It doesn't happen all the time. This is extremely annoying, 
> especially when
> it stops 1 second after compilation has started, to report a 
> missing ";"
> .......
> 
> Another question while I'm at it :
> 
> I use a "subst" command to create a virtual drive where my 
> project lies, say
> "Y:". This maps a real location somewhere on the D: drive (at 
> work), or
> somewhere on C: (at home). Using a virtual drive allows me to use some
> hardcoded paths in various places.
> 
> Usually, when I select a file in VC++ (the source tree on the 
> left), it
> opens "Y:\SomeDir\SomeFile.cpp", which is what I want. 
> However, *sometimes*
> it decides to open "C:\RealLocation\SomeDir\SomeFile.cpp" 
> instead, i.e. it
> uses the real path. The trouble is, of course, when I use the backuped
> project on the other machine, it doesn't find the file 
> anymore (since it's
> now on D:), and the usual message box pops up to say that VC 
> has been unable
> to re-open some of the project files.
> 
> I'd like to know why it sometimes feels like using the real path names
> instead of subst'ed ones.
> 
> Pierre
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] VC++ lag

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

Hi,

Is there any particular reason why VC++ should lag like hell before starting
compiling ? The scenario is :
- W2K / VC++ 6 / SP5 / brand new machine
- I press F5 or F7 to compile
- Between 30 and 60 seconds later compilation actually starts (before, VC++
just doesn't respond)

It doesn't happen all the time. This is extremely annoying, especially when
it stops 1 second after compilation has started, to report a missing ";"
.......

Another question while I'm at it :

I use a "subst" command to create a virtual drive where my project lies, say
"Y:". This maps a real location somewhere on the D: drive (at work), or
somewhere on C: (at home). Using a virtual drive allows me to use some
hardcoded paths in various places.

Usually, when I select a file in VC++ (the source tree on the left), it
opens "Y:\SomeDir\SomeFile.cpp", which is what I want. However, *sometimes*
it decides to open "C:\RealLocation\SomeDir\SomeFile.cpp" instead, i.e. it
uses the real path. The trouble is, of course, when I use the backuped
project on the other machine, it doesn't find the file anymore (since it's
now on D:), and the usual message box pops up to say that VC has been unable
to re-open some of the project files.

I'd like to know why it sometimes feels like using the real path names
instead of subst'ed ones.

Pierre

RE: [GD-Windows] windows message on ALT-TAB

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

> Please forgive me if I'm being obvious, but everyone knows about the 
> Spy++ tool, right?  It answers questions like this very effectively.

Didn't know about it before - thanks for the pointer!

-- Daniel, Epic Games Inc.

Re: [GD-Windows] windows message on ALT-TAB

[brian s. <pud...@po...>]

Please forgive me if I'm being obvious, but everyone knows about the 
Spy++ tool, right?  It answers questions like this very effectively.

--brian

On Monday, June 9, 2003, at 09:55  PM, Daniel Vogel wrote:

>> WM_ACTIVATEAPP/WM_ACTIVATE ?
>
> Ah, thanks - that did the trick.
>
> -- Daniel, Epic Games Inc.

RE: [GD-Windows] windows message on ALT-TAB

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

> WM_ACTIVATEAPP/WM_ACTIVATE ?

Ah, thanks - that did the trick.

-- Daniel, Epic Games Inc.

RE: [GD-Windows] windows message on ALT-TAB

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

WM_ACTIVATEAPP/WM_ACTIVATE ?

I'm not sure if you're just looking to see if something else is about to
become the topmost window,  in which case WM_ACTIVATEAPP is all you need, or
if you specifically want to know if your window was minimised by an alt+tab
keypress.

If the later, out of curioisty,  is there a reason you're interested in how
it was deactivated? 

Unfortunately although there's a way to tell how a window was activated (e.g
by mouse, keyboard, or SetActiveWindow) there's no way to tell how one is
being deactivated unless you monitor keypresses before hand as you suggest.
Also even though in WinMe/2K and higher SetForegroundWindow doesn't
generally allow windows of a different thread to bring themselves to the
top, there's still ways your applicaton can unexpectedly find itself
becoming deacticated without any user input.


Andy @
Climax Brighton



> -----Original Message-----
> From: Daniel Vogel [mailto:vo...@ep...]
> Sent: Monday, June 09, 2003 4:59 PM
> To: gam...@li...
> Subject: [GD-Windows] windows message on ALT-TAB
> 
> 
> Is there a windows message I get when a user ALT-TAB's out of 
> my fullscreen
> application? I get a WM_SYSCOMMAND/ SC_KEYMENU but was hoping 
> for a more
> general "you just got minimized because someone ALT-TAB'ed away/ ..."
> message without having to manually check for the ALT-TAB combo.
> 
> Thanks,
> 
> -- Daniel, Epic Games Inc.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of 
> TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] windows message on ALT-TAB

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

Is there a windows message I get when a user ALT-TAB's out of my fullscreen
application? I get a WM_SYSCOMMAND/ SC_KEYMENU but was hoping for a more
general "you just got minimized because someone ALT-TAB'ed away/ ..."
message without having to manually check for the ALT-TAB combo.

Thanks,

-- Daniel, Epic Games Inc.

Re: [GD-Windows] WM_SYSCOMMAND documentation question

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

In article <JDE...@ep...>,
    "Daniel Vogel" <vo...@ep...>  writes:

> The D3D sample applications return 1 in response to WM_SYSCOMMAND to prevent
> certain events from interfering with the app being fullscreen though I can't
> find any documention why 1 is returned. The MSDN docs state that 0 should be
> returned if the application handles WM_SYSCOMMAND so I'm wondering where the
> return value of 1 is documented.

I think Brian's analysis is correct.  From "Win32 Programming" by
Rector & Newcomer, pg. 904:

    "If you add your own menu items to the systme menu and, therefore,
    intercept the WM_SYSCOMMAND message, you must make sure you pass
    all unprocessed messages to the DefWindowProc function.  If you
    don't, the standard menu commands will be effectively disabled.
    They will look active to the user, but selecting them will have no
    effect."
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

Re: [GD-Windows] WM_SYSCOMMAND documentation question

[brian s. <pud...@po...>]

My take would be: they're not actually handling the message (hence a 
non-zero return) and they don't want it to go to DefWindowProc (hence 
the immediate return).  Where the 1 comes from, I have no idea.  But if 
they returned 0, it would be read by the OS as "I've handled the 
message, you are now clear to turn off the monitor power/size the 
window" and they probably don't want to deal with those messages in a 
simple sample app.  They'd rather just eat them up and ignore them.

You, as a creator of a real application, probably *should* deal with 
those messages properly and return 0.

--brian

On Monday, June 9, 2003, at 08:22  AM, Daniel Vogel wrote:

> The D3D sample applications return 1 in response to WM_SYSCOMMAND to 
> prevent
> certain events from interfering with the app being fullscreen though I 
> can't
> find any documention why 1 is returned. The MSDN docs state that 0 
> should be
> returned if the application handles WM_SYSCOMMAND so I'm wondering 
> where the
> return value of 1 is documented.
>
> case WM_SYSCOMMAND:
> 	// Prevent moving/sizing and power loss in fullscreen mode
> 	switch( wParam )
> 	{
> 		case SC_MOVE:
> 		case SC_SIZE:
> 		case SC_MAXIMIZE:
> 		case SC_KEYMENU:
> 		case SC_MONITORPOWER:
> 			if( false == m_bWindowed )
> 				return 1;
> 			break;
> 	}
> 	break;
>
>
> Thanks,
>
> -- Daniel, Epic Games Inc.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The 
> best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>

[GD-Windows] WM_SYSCOMMAND documentation question

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

The D3D sample applications return 1 in response to WM_SYSCOMMAND to prevent
certain events from interfering with the app being fullscreen though I can't
find any documention why 1 is returned. The MSDN docs state that 0 should be
returned if the application handles WM_SYSCOMMAND so I'm wondering where the
return value of 1 is documented.

case WM_SYSCOMMAND:
	// Prevent moving/sizing and power loss in fullscreen mode
	switch( wParam )
	{
		case SC_MOVE:
		case SC_SIZE:
		case SC_MAXIMIZE:
		case SC_KEYMENU:
		case SC_MONITORPOWER:
			if( false == m_bWindowed )
				return 1;
			break;
	}
	break;


Thanks,

-- Daniel, Epic Games Inc.

RE: [GD-Windows] Input thread

[Ivan-Assen I. <as...@ha...>]

> If you use windows messages for mouse stuff, it's also a good 
> idea to capture the mouse when you receive a mouse down. In a 
> full screen app the mouse is always over the window, but if 
> you support windowed mode (you do, right? Debugging), you 
> could receive a BUTTONDOWN but not the corresponding BUTTONUP 
> because the mouse has moved outside the window (the window is 
> still in focus). Also remember that SetCapture() and 
> ReleaseCapture() are not refcounted, so multiple simultaneous 
> button presses need special care.

Also remember that in multimon configuration your application might
have stretched itself to the entire primary screen, but still the mouse
can be able to escape to other monitors... we had such a problem
with Celtic Kings. (Sadly, this didn't convince management to
install a second monitor on every programmer's desk :-)

I also second the DirectInput suggestion. If you want to access the
keyboard as an assortment of buttons (vs. a text-input device), 
the DirectInput API is very straightforward.

regards,
Assen

Re: [GD-Windows] Input thread

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

Pierre Terdiman wrote:

>> Windows messages can be lost if your window lose the focus. You
>> should handle the WM_ACTIVATE message: if your window lose the focus
>> you should stop every activity in your program (so in your example
>> send a stop event to the character)
>
> Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
> mandatory with GetAsyncKeyState ...

If you use windows messages for mouse stuff, it's also a good idea to
capture the mouse when you receive a mouse down. In a full screen app the
mouse is always over the window, but if you support windowed mode (you do,
right? Debugging), you could receive a BUTTONDOWN but not the corresponding
BUTTONUP because the mouse has moved outside the window (the window is still
in focus). Also remember that SetCapture() and ReleaseCapture() are not
refcounted, so multiple simultaneous button presses need special care.

Another more hackish option is, right after processing all pending windows
messages, scan the input (mouse & keyboard) to update for any potentially
lost or mishandled messages.

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Input thread

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

That's the easiest solution? 

Dude you really need to give DInput a shot sometime :)


> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...] 
> Sent: 05 June 2003 14:25
> To: gam...@li...
> Subject: Re: [GD-Windows] Input thread
> 
> 
> Ok, I just rewrote it using vanilla Windows messages and it 
> seems to work well indeed.
> 
> I think I found my former bug :
> 
> - The GetAsyncKeyState() version is testing mouse buttons as well.
> - To get back to Windows messages, I first record inputs in 
> the event proc (keys, mouse messages like WM_LBUTTONDOWN, etc).
> - Then when the character / scene gets updated, I fire all 
> recorded events at the state machine and let it do its job.
> 
> When I did that, it mostly worked but some combos were a lot 
> more difficult to make. Which is probably why I discarded Win 
> events at first.
> 
> But Win events had nothing wrong, I just forgot to -also- 
> record double-click messages (WM_LBUTTONDBLCLK, etc) as if 
> they were normal clicks. Which makes the difference when a 
> particular combo requires rapid clicking...
> 
> 
> Anyway, short story : it seems to work with standard Win 
> events so far, which is the easiest solution I could have 
> wanted, so everything's fine. [Until next bug pops up]
> 
> Thanks for the help.
> 
> - Pierre
> 

Re: [GD-Windows] Input thread

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

Ok, I just rewrote it using vanilla Windows messages and it seems to work
well indeed.

I think I found my former bug :

- The GetAsyncKeyState() version is testing mouse buttons as well.
- To get back to Windows messages, I first record inputs in the event proc
(keys, mouse messages like WM_LBUTTONDOWN, etc).
- Then when the character / scene gets updated, I fire all recorded events
at the state machine and let it do its job.

When I did that, it mostly worked but some combos were a lot more difficult
to make. Which is probably why I discarded Win events at first.

But Win events had nothing wrong, I just forgot to -also- record
double-click messages (WM_LBUTTONDBLCLK, etc) as if they were normal clicks.
Which makes the difference when a particular combo requires rapid
clicking...


Anyway, short story : it seems to work with standard Win events so far,
which is the easiest solution I could have wanted, so everything's fine.
[Until next bug pops up]

Thanks for the help.

- Pierre

Re: [GD-Windows] Input thread

[Gabor <ts...@co...>]

It's okay. In this case key messages have to work perfectly. Another
solution can be that you use DirectInput in which you can create such a
keybuffer which receives messages even if your application is in the
background. I am sure you will prefer the first solution ;)

Gabor

> Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
> mandatory with GetAsyncKeyState ...

Re: [GD-Windows] Input thread

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

> Windows messages can be lost if your window lose the focus. You should
> handle the WM_ACTIVATE message: if your window lose the focus you should
> stop every activity in your program (so in your example send a stop event
to
> the character)
> A program is losing focus for example if you are using Alt+Tab to switch
> between tasks.

Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
mandatory with GetAsyncKeyState ...

Pierre

Re: [GD-Windows] Input thread

[Gabor <ts...@co...>]

Windows messages can be lost if your window lose the focus. You should
handle the WM_ACTIVATE message: if your window lose the focus you should
stop every activity in your program (so in your example send a stop event to
the character)
A program is losing focus for example if you are using Alt+Tab to switch
between tasks.

Hope this helps,
  Gabor

> Honestly, I don't know. It's been a long time now, but one year ago (or
> maybe two) I was using Windows messages in that part of the code, and IIRC
I
> ran into some problems of lost messages. Typically, the "key up" event
> sometimes was never caught, so for example :
> - on key down, I was sending a message to a state machine, that eventually
> made the character walk
> - key up event was missed
> - the character kept walking forever