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

Re: [GD-Windows] Release build confusion

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

I believe that unless you tell it not to, the debugger fills 
newly-allocated memory with zeros. You may be counting on that behavior 
somewhere. Check your initializations, particularly of pointers; you may 
assume they're zero if they haven't yet been assigned.

    Kent



Chris Raine wrote:

>Hi, 
>
>I have a problem with our release builds which is driving me nuts for a
>couple of days now. If we start our release build from within the Visual
>Studio debugger, everything works fine, yet if we start our release
>build outside of Visual Studio, it either crashes or displays weird
>render artifacts. The debug build works in the IDE as well as outside. 
>
>  
>

[GD-Windows] Release build confusion

[Chris R. <c....@gm...>]

Hi, 

I have a problem with our release builds which is driving me nuts for a
couple of days now. If we start our release build from within the Visual
Studio debugger, everything works fine, yet if we start our release
build outside of Visual Studio, it either crashes or displays weird
render artifacts. The debug build works in the IDE as well as outside. 

My current assumption is that we trash the stack somewhere early in our
initialization code, for changing the default values of the stackreserve
and stackcommit  linker-options can influence the reproduceability of
the crashes. The callstack in case of a crash either is complete garbage
(jumps wildly around in all code) or crashes in areas in which we
already spent excessive time to make (hopefully) bug-free. 

My question is, how does the Visual Studio debugger interfere with the
release build and either prevent (or swallow) errors that lead to
crashes outside of the IDE? If my assumption about stack corruption is
correct, I would like to know if there are any systematic methods of
tracking down such a bug I do not know of? 

I am currently replacing all error-prone code (c-style string functions
e.g strcat() with strncat()) with safer versions and inserting
bounds-checks, as well as commenting out blocks of code and rebuilding
in the hope of finding the spot where we corrupt either the stack or the
heap. But till the present day - no bug found. 

regards, 
Chris Raine

RE: [GD-Windows] Terminating a program

[George G. <ge...@ba...>]

> > resources allocated and configured by drivers are beyond the direct 
> > control of the kernel, and as such can very often be left in
unstable 
> > states when an app is terminated.
> 
> This should simply not be true.

Ah, many things in life "should" not be true, but unfortunately are.

> The reason that you have to do this (and we do when we terminate 
> normally) is because of bugs in the implementation of the drivers. 
> Sadly, such bugs are so common, that they contribute to the 
> perception that Windows is unstable and computers just crash all the 
> time. 

Exactly, and of course in a user's eyes a driver bug = a bug in the app
that was using the driver.  (Mind you, this falsehood isn't helped any
by new software that mucks about with drivers and the O/S as part of
their lame copy protection schemes, but that is ENTIRELY a different
topic...)

Video and Sound driver bugs (such as terminate/cleanup bugs) are just SO
common that, for all intents and purposes, the termination issues have
to be assumed to be the "status quo" and apps have to try to work around
them.  As such, no good app should, if it can at all help it, exit
without closing down its video, sound and network APIs.  To do so is
inviting stability issues from faulty (and very common) drivers.

-- George.

- George Geczy
- Lead Programmer, BattleGoat Studios
- www.supremeruler2010.com
- "Designing the Next Generation of Intelligent Strategy Games"

Re: [GD-Windows] Terminating a program

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

> While letting the OS (XP, 2000 or NT) clean up the process is generally
> quick, there are dangers with device states, as in your example with the
> sound.  While the OS can enforce its own issues relatively well (memory
> heap, file handles, GDI handles, etc), resources allocated and
> configured by drivers are beyond the direct control of the kernel, and
> as such can very often be left in unstable states when an app is
> terminated.

This should simply not be true. The interface between the kernel and a 
device is, at its core, simple:

- open device
- close device
- read device
- write device
- control device

A device doesn't have to know whether "close" is because the application 
called close explicitly, or whether the kernel called close because it 
had to remove all device handles that belonged to a dying process.

However, in the Windows device model (especially the older models), 
there were reasons to go outside this basic model, and even within the 
basic model, a driver may have bugs (such as sequencing bugs) that make 
it not work right.

It's been my experience that a prime cause of bugs are all the "extras" 
that an OEM wants to add to their device: decoration of sound output; 
special throughput statistics windows for network cards; that kind of thing.

> my own experience is that it is very wise to clean up your devices
> before you close - for example, properly de-allocate and shut down
> DirectX or OpenGL, DirectSound/DirectShow, network resources, etc.  Not
> doing so could certainly leave some PC's in a less than stable state.

The reason that you have to do this (and we do when we terminate 
normally) is because of bugs in the implementation of the drivers. 
Sadly, such bugs are so common, that they contribute to the perception 
that Windows is unstable and computers just crash all the time. Grandma 
really won't have a good computer until the pace of hardware evolution 
slows down enough to let the drivers mature. This, in turn, is caused by 
the "good enough" rule -- if you're going for "perfect" then your 
competitors will ship six months before you do, as well as be cheaper, 
so as a hardware vendor, you're highly motivated to ship as soon as you 
have something that might work for a few minutes after boot.


Cheers,

			/ h+


-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

RE: [GD-Windows] Terminating a program

[George G. <ge...@ba...>]

While letting the OS (XP, 2000 or NT) clean up the process is generally
quick, there are dangers with device states, as in your example with the
sound.  While the OS can enforce its own issues relatively well (memory
heap, file handles, GDI handles, etc), resources allocated and
configured by drivers are beyond the direct control of the kernel, and
as such can very often be left in unstable states when an app is
terminated.

While I'm sure that programming instructors everywhere will grimace in
pain, not cleaning up your memory allocations is acceptable in the
manner that Jon suggested (ie, faster to let the OS do it than to walk
through pages and pages of memory freeing all the small bits).  However,
my own experience is that it is very wise to clean up your devices
before you close - for example, properly de-allocate and shut down
DirectX or OpenGL, DirectSound/DirectShow, network resources, etc.  Not
doing so could certainly leave some PC's in a less than stable state.

-- George.

- George Geczy
- Lead Programmer, BattleGoat Studios
- www.supremeruler2010.com
- "Designing the Next Generation of Intelligent Strategy Games"


> Is it that true ?
> 
> We have an game demo here on a PC that uses large
> sound buffers.
> When we kill the app using the task manager, and
> launch once again the application, the framerate
> become really slow, and we can't get any good
> framerate but by booting the PC.

[...]

> > If you're on NT-based Windows, just killing the
> > process will work. It's
> > a real OS with a real kernel, so all resources will
> > be magically 
> > released (barring any driver bugs, of course).(*)

Re: [GD-Windows] Terminating a program

[brian s. <bri...@gm...>]

Like I said, you have plenty of other options for IPC. Named event, create =
a=20
pipe, etc. But since his code was already using messages, switching to a=20
custom message seemed it would be fastest for Eero to implement.

--brian

On 8/1/05, Root, Konstantin <kr...@fu...> wrote:
>=20
> Why not just create named event that will be set by terminator program
> and checked by your full screen application?
>=20
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> epa...@ko...
> Sent: Sunday, July 31, 2005 8:02 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Terminating a program
>=20
> brian sharon wrote:
>=20
> > Sounds like you might be better off not using WM_CLOSE, since the OS
> is going to complain if you ignore it for too long. But you have plenty
>=20
> of other options if you want to handle communications between two apps
> you control. Easiest thing is to use RegisterWindowMessage() to get a
> unique message value for your own custom quit message, and then the
> child application could post WM_CLOSE to itself whenever it receives
> that custom quit message from the launcher app.
> >
>=20
>=20
> Results from this seem very promising. I did add TerminateProcess as the
> fallback, but so far (after doing one fix to the graphical program), I
> have not yet seen it triggered.
>=20
> (I have previously terminated programs on this setup (Nvidia +
> WindowsXP) and I have not noticed any ill effects)
>=20
> Thanks for your and Jon's comments
>=20
>=20
> Eero
>=20
> PS. I first sent this using wrong address, moderator please kill
> that message...
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> 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
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> 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] Terminating a program

[Emmanuel A. <e_a...@ya...>]

Is it that true ?

We have an game demo here on a PC that uses large
sound buffers.
When we kill the app using the task manager, and
launch once again the application, the framerate
become really slow, and we can't get any good
framerate but by booting the PC.

Launching with no sound (or without those big buffers)
behave correctly, so it seems related to sound.

So I came to the conclusion that sound memory wasn't
correctly released when killing the app.
Is it a driver bug ? 
And I though I had some similar issues with graphics (
but, speaking of it, maybe it was on W98 ).

Emmanuel

Ps : And for the original question, I would also use a
specific message in order to tell the application to
shut down properly...



--- Jon Watte <hp...@mi...> a écrit :

> 
> If you're on NT-based Windows, just killing the
> process will work. It's 
> a real OS with a real kernel, so all resources will
> be magically 
> released (barring any driver bugs, of course).(*)
> 
> If you want this on Win98 or WinME, you're screwed,
> though. Similarly, 
> if there's any state you might want to re-use (such
> as files being 
> written to at any point in your program), there's no
> guarantee of their 
> consistency.
> 
> Cheers,
> 
> 			/ h+
> 
> 
> (*) This is why I usually advocate implementing
> "quit" as "exit(0)" 
> rather than fully releasing everything, because to
> release everything, 
> you have to walk through it, probably paging in a
> bunch of cruft just to 
> tell the runtime library you don't need it. I hate
> applications that 
> take 20 seconds to quit. The kernel can do a much
> better job of just 
> making it go away on quit than you can.
> 
> 
> epa...@ko... wrote:
> > I have divided my system to a launcher program and
> the actual (full 
> > screen) graphics application.
> > 
> > In some cases the laucher needs to terminate the
> graphics application.
> > 
> > I have been trying
> >       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
> >              SMTO_NORMAL,
> >              10000,
> >              &res);
> > 
> > and
> > 
> >           PostMessage(hwnd, WM_CLOSE, 0, 0) ;
> > 
> > 
> > but neither of these is fully reliable. In some
> cases
> > I get the Windows "End Program" dialogue on screen
> asking
> > the user if the program should really be
> terminated.
> > 
> > That is not ok for me.
> > 
> > Actually I don't really care if the program gets
> its chance of
> > getting cleanly shut down, but it is very much
> necessary that the
> > OpenGL (Nvidia) and sound drivers (Creative) are
> not left in a
> > corrupt state. And Windows (XP) itself must be
> able to get
> > all resources back etc.
> > 
> > Any ideas how to do this?
> > 
> >         Eero
> > 
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> > from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> > informative Webcasts and more! Get everything you
> need to get up to
> > speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> >
>
http://sourceforge.net/mailarchive/forum.php?forum_id=555
> > 
> > 
> 
> -- 
> -- The early bird gets the worm, but the second
> mouse gets the cheese.
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
>
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
>
http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

RE: [GD-Windows] Terminating a program

[Root, K. <kr...@fu...>]

Why not just create named event that will be set by terminator program
and checked by your full screen application?

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
epa...@ko...
Sent: Sunday, July 31, 2005 8:02 PM
To: gam...@li...
Subject: Re: [GD-Windows] Terminating a program

brian sharon wrote:

 > Sounds like you might be better off not using WM_CLOSE, since the OS=20
is going to complain if you ignore it for too long.  But you have plenty

of other options if you want to handle communications between two apps=20
you control.  Easiest thing is to use RegisterWindowMessage() to get a=20
unique message value for your own custom quit message, and then the=20
child application could post WM_CLOSE to itself whenever it receives=20
that custom quit message from the launcher app.
 >


Results from this seem very promising. I did add TerminateProcess as the
fallback, but so far (after doing one fix to the graphical program), I
have not yet seen it triggered.

(I have previously terminated programs on this setup (Nvidia +
WindowsXP) and I have not noticed any ill effects)

     Thanks for your and Jon's comments


             Eero

PS. I first sent this using wrong address, moderator please kill
that message...



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
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] Terminating a program

[<epa...@ko...>]

brian sharon wrote:

 > Sounds like you might be better off not using WM_CLOSE, since the OS 
is going to complain if you ignore it for too long.  But you have plenty 
of other options if you want to handle communications between two apps 
you control.  Easiest thing is to use RegisterWindowMessage() to get a 
unique message value for your own custom quit message, and then the 
child application could post WM_CLOSE to itself whenever it receives 
that custom quit message from the launcher app.
 >


Results from this seem very promising. I did add TerminateProcess as the
fallback, but so far (after doing one fix to the graphical program), I
have not yet seen it triggered.

(I have previously terminated programs on this setup (Nvidia +
WindowsXP) and I have not noticed any ill effects)

     Thanks for your and Jon's comments


             Eero

PS. I first sent this using wrong address, moderator please kill
that message...

Re: [GD-Windows] Terminating a program

[brian s. <bri...@gm...>]

On 7/30/05, epa...@ko... <epa...@ko...> wrote:
>=20
> Is there a way of delivering WM_CLOSE so that the dialog box does not
> appear even if the application does not respond? With this I would
> probably solve 95% of my current problem cases. (And could concentrate
> my debugging effort to the remaining 5%)


Sounds like you might be better off not using WM_CLOSE, since the OS is=20
going to complain if you ignore it for too long. But you have plenty of=20
other options if you want to handle communications between two apps you=20
control. Easiest thing is to use RegisterWindowMessage() to get a unique=20
message value for your own custom quit message, and then the child=20
application could post WM_CLOSE to itself whenever it receives that custom=
=20
quit message from the launcher app.

--brian

Re: [GD-Windows] Terminating a program

[<epa...@ko...>]

brian sharon wrote:

> Windows pops up that dialog box because your graphics application isn't 
> processing messages, so Windows considers the app to be hung.  You 
> should figure out why that's happening, and fix the bugs in your 
> graphics app so that it can actually process messages and shutdown cleanly.
> 


Probably true. Actually I suspect that I have two kinds of problems
here. The other is that the shutdown request can happen already at the
application startup time. I do poll the windows messages now and then
also during that time, but the application might be in an library
reading an index from a large zip resource file or something like that
which takes some time. The other problem is that sometimes this happens
during the normal run time, might be some kind of transient dead lock
with the networking code (and Visual Studio debugger is not too helpful
here)


Is there a way of delivering WM_CLOSE so that the dialog box does not
appear even if the application does not respond? With this I would
probably solve 95% of my current problem cases. (And could concentrate
my debugging effort to the remaining 5%)

-------

Regarding the message from Jon Watte:

I would probably use the TerminateProcess as my fall back as described
on: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q178893

(and if I cannot get WM_CLOSE to behave, I will end up testing what
are the real ill effects of TerminateProcess with WindowsXP...)



		Eero

Re: [GD-Windows] Terminating a program

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

If you're on NT-based Windows, just killing the process will work. It's 
a real OS with a real kernel, so all resources will be magically 
released (barring any driver bugs, of course).(*)

If you want this on Win98 or WinME, you're screwed, though. Similarly, 
if there's any state you might want to re-use (such as files being 
written to at any point in your program), there's no guarantee of their 
consistency.

Cheers,

			/ h+


(*) This is why I usually advocate implementing "quit" as "exit(0)" 
rather than fully releasing everything, because to release everything, 
you have to walk through it, probably paging in a bunch of cruft just to 
tell the runtime library you don't need it. I hate applications that 
take 20 seconds to quit. The kernel can do a much better job of just 
making it go away on quit than you can.


epa...@ko... wrote:
> I have divided my system to a launcher program and the actual (full 
> screen) graphics application.
> 
> In some cases the laucher needs to terminate the graphics application.
> 
> I have been trying
>       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
>              SMTO_NORMAL,
>              10000,
>              &res);
> 
> and
> 
>           PostMessage(hwnd, WM_CLOSE, 0, 0) ;
> 
> 
> but neither of these is fully reliable. In some cases
> I get the Windows "End Program" dialogue on screen asking
> the user if the program should really be terminated.
> 
> That is not ok for me.
> 
> Actually I don't really care if the program gets its chance of
> getting cleanly shut down, but it is very much necessary that the
> OpenGL (Nvidia) and sound drivers (Creative) are not left in a
> corrupt state. And Windows (XP) itself must be able to get
> all resources back etc.
> 
> Any ideas how to do this?
> 
>         Eero
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 
> 

-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

Re: [GD-Windows] Terminating a program

[brian s. <bri...@gm...>]

On 7/29/05, epa...@ko... <epa...@ko...> wrote:
>=20
> I have divided my system to a launcher program and the actual (full
> screen) graphics application.
>=20
> In some cases the laucher needs to terminate the graphics application.
>=20
> I have been trying
> SendMessageTimeout(hwnd,WM_CLOSE,0,0,
> SMTO_NORMAL,
> 10000,
> &res);
>=20
> and
>=20
> PostMessage(hwnd, WM_CLOSE, 0, 0) ;
>=20
>=20
> but neither of these is fully reliable. In some cases
> I get the Windows "End Program" dialogue on screen asking
> the user if the program should really be terminated.


Windows pops up that dialog box because your graphics application isn't=20
processing messages, so Windows considers the app to be hung. You should=20
figure out why that's happening, and fix the bugs in your graphics app so=
=20
that it can actually process messages and shutdown cleanly.

That is not ok for me.
>=20
> Actually I don't really care if the program gets its chance of
> getting cleanly shut down, but it is very much necessary that the
> OpenGL (Nvidia) and sound drivers (Creative) are not left in a
> corrupt state. And Windows (XP) itself must be able to get
> all resources back etc.
>=20
> Any ideas how to do this?


Once you learn that there's a function called TerminateProcess() you may=20
think it's just what you need, but that is a very bad way to shut down an=
=20
application, and it is likely to leave drivers in a corrupt state.

--brian

[GD-Windows] Terminating a program

[<epa...@ko...>]

I have divided my system to a launcher program and the actual (full 
screen) graphics application.

In some cases the laucher needs to terminate the graphics application.

I have been trying
       SendMessageTimeout(hwnd,WM_CLOSE,0,0,
			 SMTO_NORMAL,
			 10000,
			 &res);

and

           PostMessage(hwnd, WM_CLOSE, 0, 0) ;


but neither of these is fully reliable. In some cases
I get the Windows "End Program" dialogue on screen asking
the user if the program should really be terminated.

That is not ok for me.

Actually I don't really care if the program gets its chance of
getting cleanly shut down, but it is very much necessary that the
OpenGL (Nvidia) and sound drivers (Creative) are not left in a
corrupt state. And Windows (XP) itself must be able to get
all resources back etc.

Any ideas how to do this?

		Eero

Re: [GD-Windows] MAX Crashes During Batch

[yogiwp <yo...@gm...>]

Good idea! I think I can do something similar.

In our case, max is started in 'silent' mode causing it to not show any dialog box
(apparently including errors boxes). This is necessary because otherwise it will
show dialogs about missing texture etc. and stops the build.

So what I'll try is monitor max' window caption, and if it doesn't change after a
while I know max is stuck.

Thanks all.


----- Original Message ----- 
From: "Martin Slater" <ms...@he...>

> > I'm clueless on how to 'detect' max crashes. And I'm not even sure if this
> > is a good idea. Anyone?
> 
> In the past I've had a little util that sits doing a FindWindow on the 
> error dialog box title every second or so then just take the resulting 
> HWND and do SendMessage(hwnd, WM_CLOSE) to it.
> 
> Martin

Re: [GD-Windows] MAX Crashes During Batch

[Martin S. <ms...@he...>]

> I'm clueless on how to 'detect' max crashes. And I'm not even sure if this
> is a good idea. Anyone?

In the past I've had a little util that sits doing a FindWindow on the 
error dialog box title every second or so then just take the resulting 
HWND and do SendMessage(hwnd, WM_CLOSE) to it.

Martin


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.1.0 - Release Date: 27/05/2005

Re: [GD-Windows] MAX Crashes During Batch

[yogiwp <yo...@gm...>]

Well, unfortunately it's kinda late for this project to switch into such process.

I really was hoping for 'hacks' to get around this. Max crashes should not
stop the build.
One idea is to 'detect' if max hangs and kill it, continue the build, and then
repeat the build (because different build runs crash on different file).

I'm clueless on how to 'detect' max crashes. And I'm not even sure if this
is a good idea. Anyone?

Thanks.


----- Original Message ----- 
From: "Jon Watte" <hp...@mi...>
> 
> The file that the artists produce and check into the build is not the 
> .max file; it's a rich, exported format that captures whatever we will 
> need. The real asset build then builds from this intermediate format to 
> an actual optimized format.
> 
> The artists still revision control their .max files, but they do that on 
> a server they organize however they want, without any 
> engineering-imposed structure. The intermediate files, however, have 
> that structure.
> 
> Cheers,
> 
> / h+

Re: [GD-Windows] MAX Crashes During Batch

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

The file that the artists produce and check into the build is not the 
.max file; it's a rich, exported format that captures whatever we will 
need. The real asset build then builds from this intermediate format to 
an actual optimized format.

The artists still revision control their .max files, but they do that on 
a server they organize however they want, without any 
engineering-imposed structure. The intermediate files, however, have 
that structure.

Cheers,

			/ h+


yogiwp wrote:
> Hi,
> 
> I wonder how people deal with 3dsmax export crashes during
> batch data build? It happens randomly and it's not the exporter's
> fault. Reseting the scene before loading new file helps to reduce
> crashes a bit, but not completely.
> 
> Thanks in advance.
> 
> 
> Yogi Wahyu Prasidha
> www.inspiritarena.com

[GD-Windows] MAX Crashes During Batch

[yogiwp <yo...@gm...>]

Hi,

I wonder how people deal with 3dsmax export crashes during
batch data build? It happens randomly and it's not the exporter's
fault. Reseting the scene before loading new file helps to reduce
crashes a bit, but not completely.

Thanks in advance.


Yogi Wahyu Prasidha
www.inspiritarena.com

RE: [GD-Windows] Makefile woes

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

> Obviously the mkdir needs to become md, but it seems to me that the
brackets
> and the or'ing are using the shell to test for the directory? I don't know
> shell commands at all and it's frustrating trying to figure out this
stuff.


Learning make is like learning any other language; you can't expect
to go from newbie to proficient in a single week of work. If you don't
know make syntax, and don't know UNIX command line shells, you may want
to ask yourself why you're trying to use make syntax and UNIX command
line shells to accomplish whatever your task is. Does someone else in
your organization require it? If so, use them as a learning resource.

There are some resources you need. The first one is a reference to the
BASH shell and the typical UNIX command-line utitilies (such as '['
which is an alias for 'test'). Because you're using Cygwin, you have
access to mkdir, test, cp, sed, and the other commands; you should use
them if you're using the Cygwin make.

If you want a reference manual for GNU make, try an online copy, such
as http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_toc.html

If you want an example of a set of simple make files that manage to
build a number of libraries and applications without recursively
invoking itself, and which also collects full dependencies automatically
(assuming you're using GCC), you can look at my sample here:
http://www.mindcontrol.org/~hplus/makesample.html


In conclusion: if you're doing this for your own edification, then keep
going. It might feel frustrating, but you ARE learning an entirely new
language; don't expect mastery in the first week. If you're doing this
for someone else, and that someone else expects you to master it in a
single week, then someone needs to adjust their expectations, or do it
themselves, or help you along (obviously, the latter would be best
overall).


Cheers,

			/ h+

Re: [GD-Windows] Makefile woes

[Martin S. <ms...@he...>]

><some makefile commands>
>echo "You got here"
><some more makefile commands>
>  
>
Shouldn't it be

@echo "you got here"

?

not that i've touched a makefile in over two years so.....

martin

Re: [GD-Windows] Makefile woes

[Daniel G. <dgl...@cr...>]

It's been more than 2 years since I had to maintain makefiles, so this 
is all coming from memory.

Brett Bibby wrote:

>1. I want to check for the existence of a directory, and if it doesn't exist
>create it.
>
>Most of the linux/unix examples do something like:
>
>.PHONY: $(SUBDIR)
>$(SUBDIR):
>	@[ -d $(SUBDIR) ] || mkdir -p $(SUBDIR)
>
>
>Obviously the mkdir needs to become md, but it seems to me that the brackets
>and the or'ing are using the shell to test for the directory? I don't know
>shell commands at all and it's frustrating trying to figure out this stuff.
>  
>
[ is a exe in unix, but more likely a shell builtin these days.  It 
might be a synonym for 'file'.  But it's using circuit evaluation to 
test if $(SUBDIR) exists, and if it doesn't then it creates the directory.

But if you're running under cygwin, you should have the unix shell, 
shouldn't you?  (And a version of the mkdir)

>2. I want to do some printf style debugging beyond the -d makefile switch.
>Something like:
>
><some makefile commands>
>echo "You got here"
><some more makefile commands>
>
>But this doesn't work. What is the way/format to output messages anywhere
>during the make build.
>  
>
Make builds dependencies.  You can only run commands as the result of 
make deciding it needs to build a dependency.

$(SUBDIR):
    @echo Creating dir $(SUBDIR)...
    @[ -d $(SUBDIR) ] || mkdir -p $(SUBDIR)
    @echo Done.

Doesn't really clarify anything, does it...

cheers
DanG

RE: [GD-Windows] Makefile woes

[Michael J. L. \(SPACES\) <ml...@mi...>]

How about:

	md $(SUBDIR) 2> nul

It will print an error to the null device (i.e., do nothing) if it
already exists, but so what?

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Brett Bibby
Sent: Tuesday, May 10, 2005 7:55 PM
To: Gam...@li...
Subject: [GD-Windows] Makefile woes

Any makefile experts that can spare a moment? Having problems with
makefiles
on Windows (using GNU make under Cygwin) and can't seem to figure it out
or
even how to google it.=20

If anybody can point me to a mailing list or forum that is more
appropriate,
please let me know. All the lists I found so far aren't helpful.

1. I want to check for the existence of a directory, and if it doesn't
exist
create it.

Most of the linux/unix examples do something like:

.PHONY: $(SUBDIR)
$(SUBDIR):
	@[ -d $(SUBDIR) ] || mkdir -p $(SUBDIR)


Obviously the mkdir needs to become md, but it seems to me that the
brackets
and the or'ing are using the shell to test for the directory? I don't
know
shell commands at all and it's frustrating trying to figure out this
stuff.

2. I want to do some printf style debugging beyond the -d makefile
switch.
Something like:

<some makefile commands>
echo "You got here"
<some more makefile commands>

But this doesn't work. What is the way/format to output messages
anywhere
during the make build?

Any help appreciated...

Mr.b



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

[GD-Windows] Makefile woes

[Brett B. <res...@ga...>]

Any makefile experts that can spare a moment? Having problems with makefiles
on Windows (using GNU make under Cygwin) and can't seem to figure it out or
even how to google it. 

If anybody can point me to a mailing list or forum that is more appropriate,
please let me know. All the lists I found so far aren't helpful.

1. I want to check for the existence of a directory, and if it doesn't exist
create it.

Most of the linux/unix examples do something like:

.PHONY: $(SUBDIR)
$(SUBDIR):
	@[ -d $(SUBDIR) ] || mkdir -p $(SUBDIR)


Obviously the mkdir needs to become md, but it seems to me that the brackets
and the or'ing are using the shell to test for the directory? I don't know
shell commands at all and it's frustrating trying to figure out this stuff.

2. I want to do some printf style debugging beyond the -d makefile switch.
Something like:

<some makefile commands>
echo "You got here"
<some more makefile commands>

But this doesn't work. What is the way/format to output messages anywhere
during the make build?

Any help appreciated...

Mr.b

RE: [GD-Windows] VC.NET 'Optimization'

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

> To be safe, as you said, the fibonacci() call would have to be made in a
> statement after the timer.Restart() but before the printf() containing
> the timer.GetElapsed();

This still doesn't fix the problem that, given that you pass a constant 
into fibonacci(), the compiler can statically evaluate the entire function 
and replace it with a literal value.

Cheers,

			/ h+