gamedevlists-general — List for discussing general game development issues

[GD-General] Assertions, pre/post-conditions and call tracing

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

I've gotten into the habit of making tons of function pre-conditions and 
post-conditions that can optionally be compiled away.  This is a Eiffel 
habit picked up second-hand from a former coworker of mine.

In Eiffel, you can set up a bunch of safeguards to do basic sanity 
checking.  The safeguards are pre-conditions (validate state and parameters 
before a method/"feature" is executed); post-conditions (validate state and 
parameters after a "feature" is executed); and class-invariants (check the 
integrity of the object after ANY "feature" is executed).

Eiffel does this with "require" and "ensure" clauses that are analogous to 
assert() expressions in C++, but are a bit more readable.  In addition, the 
"ensure" clause is guaranteed to be evaluated no matter how the function is 
exited (so you don't have to do a "goto ensure" all over your code to make 
sure you exit out the same place).

I don't believe there's any clean way to do a class-invariant in C++, but I 
may be wrong on that count.  The closest thing I can think of is making 
each class declare an InvarianceChecker class that is instanced at the 
beginning of each method and whose constructor/destructor pair do verification.

Related to this is the ability to halt the debugger when a verification 
fails (which I assume can be done portably by * ( int * ) 0 = 0 ), and 
bring up a dialog box with A/R/F a la Microsoft.  Finally, having a stack 
trace available so that I can see what function call list was causing the 
problem would be nice.

I can do a lot of this with assert(), but I'm hoping there's a better way 
to do all this.  I'm sure there might be some magic with exception handling 
that could be done but, as usual, I fear anything new in C++ that might not 
be portable.

Anyway, I'm interested to hear what other types of infrastructure people 
have devised for this type of stuff.

-Brian

RE: [GD-General] Any suggestion on aircraft geometry modeling?

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

I'm pretty sure there was a discussion a while back about this sort of thing
with animated people - check the archives. We were discussing the best way
to bias the error metric (I think we all used QEM) for edges between two
vertices that were in different bones. My solution was brute-force - put the
model in every known frame of animation, find the error of that edge for
each frame, and take the worst.

There were various slightly cheaper methods discussed as well.

Tom Forsyth - Muckyfoot bloke.

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

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 15 January 2002 11:44
> To: gam...@li...
> Subject: RE: [GD-General] Any suggestion on aircraft geometry 
> modeling?
> 
> 
> The standard way, to the best of my knowledge, is to split 
> the object into
> its movable pieces, and LOD (however you wish) them independently.
> 
> I've considered a LOD system where lower LODs use a subset of 
> the vertices
> in the higher LODs, and you keep track of the duplicates, so 
> you can modify
> the various copies (and probably spread modification costs 
> over several
> frames), but never actually done it....
> 
> Note that I have no experience in aircraft in games :)
> 
> Jamie
> 
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Zhou Haidong
> Sent: 15 January 2002 07:00
> To: gam...@li...
> Subject: [GD-General] Any suggestion on aircraft geometry modeling?
> 
> 
> Hi,
> I'm using VIPM for my 3D aircraft geometry
> modeling. Everything worked fine until I wanted
> to make the elevators movable. Because for each
> aircraft model, there can be several instances,
> and their elevators will normally have different
> deflection.
> Any suggestion or material on how others
> do their aircraft geometry modeling and
> instancing?
> 
> Thanks in advance!
> 
> Zhou Haidong
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 

RE: [GD-General] Any suggestion on aircraft geometry modeling?

[Jamie F. <ja...@qu...>]

The standard way, to the best of my knowledge, is to split the object into
its movable pieces, and LOD (however you wish) them independently.

I've considered a LOD system where lower LODs use a subset of the vertices
in the higher LODs, and you keep track of the duplicates, so you can modify
the various copies (and probably spread modification costs over several
frames), but never actually done it....

Note that I have no experience in aircraft in games :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Zhou Haidong
Sent: 15 January 2002 07:00
To: gam...@li...
Subject: [GD-General] Any suggestion on aircraft geometry modeling?


Hi,
I'm using VIPM for my 3D aircraft geometry
modeling. Everything worked fine until I wanted
to make the elevators movable. Because for each
aircraft model, there can be several instances,
and their elevators will normally have different
deflection.
Any suggestion or material on how others
do their aircraft geometry modeling and
instancing?

Thanks in advance!

Zhou Haidong


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

[GD-General] Any suggestion on aircraft geometry modeling?

[Zhou H. <ha...@ep...>]

Hi,
I'm using VIPM for my 3D aircraft geometry
modeling. Everything worked fine until I wanted
to make the elevators movable. Because for each
aircraft model, there can be several instances,
and their elevators will normally have different
deflection.
Any suggestion or material on how others
do their aircraft geometry modeling and
instancing?

Thanks in advance!

Zhou Haidong

RE: resource construction WAS: [GD-General] longjmp for C++

[Matt D. <ma...@co...>]

-- Let me know when this winds back to longjmp. :)



Really the only way to do it class-safe is with C++ exceptions.  But this
has two major drawbacks.  Firstly, your classes need to be stack
instantiations rather than have them created on the heap.  Your classes
should destruct properly then.  Secondly, having an exception handler at
such a high-level (i.e. somewhere around the main loop) adds overhead that
filters into the lower-level functions.  If you can live with that, thats
fine.

The only alternative is to have code that tracks what resources you have so
you can 'delete' them in one foul swoop (direct X resources, memory heaps
etc) then resort to your C-style longjmp.



There's nothing wrong in using HeapCreate, HeapDestroy etc. in your own
memory allocation routines.  Just use the HeapAlloc function inplace of the
alloc or new call (whatever creates your user-defined 'heap') so that
HeapDestroy can still be useful.


Cheers,


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com

RE: [GD-General] Practical Game Structure.

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

Common's headers should be included over and over again.  Common the =
static library should only be included in the final application or in =
the DLLs.  I'm guessing that you're linking the common library into =
every library project and ending up with lots of copies of it in your =
final application.

If you include Common the static lib in other static libs - say Video =
and Resource Manager - and then include Video and RM in your final =
application, when the linker goes looking for functions inside Common it =
can pull them from either Video or RM, and so it complains to you.

Don't forget that a static library is not a stand-alone piece of code - =
functions in Video will ultimately need to execute functions inside =
Common, but that will only happen once everything is linked together =
into an app or DLL.=20

Hope this helps,

--brian

-----Original Message-----
From:	Chris Brodie [mailto:Chr...@ma...]
Sent:	Sun 1/13/2002 3:14 PM
To:	'gam...@li...'
Cc:=09
Subject:	[GD-General] Practical Game Structure.

In the beginning of my current project I attempted to create structure =
within my project by using static libs. However as the project grew and =
the number of static libs grew my grand plan of structure has become a =
bit wobbly.

For example:

OpenGL Renderer is dependent on Common, Graphics and Renderer. Graphics =
is dependent on Common. Renderer is dependent on Application, Graphics, =
Video and Resource Manager. Application, Video and Resource Manager are =
all dependent on Common. Common includes things like expat and zlib + =
~50 other classes.

From this you can assume that just about everything uses common. The =
problem is that since common is included and included again and again I =
seem to be getting linker warnings about multiply defined symbols. I've =
been looking for an answer to this for months, not because I get a few =
warnings and it looks messy, rather I get 4000 warnings and it takes a =
-long- time for them to be displayed, long enough that it's probably =
doubling my build time.

Originally I went with this structure to reduce the amount of unused =
code that gets linked to all my DLL's (one for each renderer, mixer, =
input system etc).

I'm happy to hear from anyone who can either suggest a better structure =
or knows how to turn a linker warning off. I'm using  .NET but this =
problem was with me under VC6 too.

Many thanks

Chris


NOTICE
This e-mail and any attachments are confidential and may contain =
copyright material of Macquarie Bank or third parties. If you are not =
the intended recipient of this email you should not read, print, =
re-transmit, store or act in reliance on this e-mail or any attachments, =
and should destroy all copies of them. Macquarie Bank does not guarantee =
the integrity of any emails or any attached files. The views or opinions =
expressed are the author's own and may not reflect the views or opinions =
of Macquarie Bank.=20


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

Re: [GD-General] Practical Game Structure.

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

We use a similar structure, where different libraries are dependent on
each other, especially including util.

But I consider a multiple definition warning to be an error and
eliminate it. We don't have this problem. Just because a library is
dependent on another library doesn't mean that the code gets included
multiple times. 

I'm guessing that you're defining objects in include files instead of in
code.

If you have something like this:

	//-----idnumber.h------
	class IdNumber
	{
	public:
	  static int id = 1;
	};
	
change it to this:

	//-----idnumber.h------
	class IdNumber
	{
	public:
	  static int id;
	};
	
	//-----idnumber.cpp------
	#include <util/IdNumber.h>
	
	int IdNumber::id = 1;

You *don't* want that definition to show up more than once when you
link.

	Kent


Chris Brodie wrote:
> 
> In the beginning of my current project I attempted to create structure within my project by using static libs. However as the project grew and the number of static libs grew my grand plan of structure has become a bit wobbly.
> 
> For example:
> 
> OpenGL Renderer is dependent on Common, Graphics and Renderer. Graphics is dependent on Common. Renderer is dependent on Application, Graphics, Video and Resource Manager. Application, Video and Resource Manager are all dependent on Common. Common includes things like expat and zlib + ~50 other classes.
> 
> >From this you can assume that just about everything uses common. The problem is that since common is included and included again and again I seem to be getting linker warnings about multiply defined symbols. I've been looking for an answer to this for months, not because I get a few warnings and it looks messy, rather I get 4000 warnings and it takes a -long- time for them to be displayed, long enough that it's probably doubling my build time.
> 
> Originally I went with this structure to reduce the amount of unused code that gets linked to all my DLL's (one for each renderer, mixer, input system etc).
> 
> I'm happy to hear from anyone who can either suggest a better structure or knows how to turn a linker warning off. I'm using  .NET but this problem was with me under VC6 too.
> 
> Many thanks
> 
> Chris
> 
> NOTICE
> This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

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

[GD-General] Practical Game Structure.

[Chris B. <Chr...@ma...>]

In the beginning of my current project I attempted to create structure within my project by using static libs. However as the project grew and the number of static libs grew my grand plan of structure has become a bit wobbly.

For example:

OpenGL Renderer is dependent on Common, Graphics and Renderer. Graphics is dependent on Common. Renderer is dependent on Application, Graphics, Video and Resource Manager. Application, Video and Resource Manager are all dependent on Common. Common includes things like expat and zlib + ~50 other classes.

From this you can assume that just about everything uses common. The problem is that since common is included and included again and again I seem to be getting linker warnings about multiply defined symbols. I've been looking for an answer to this for months, not because I get a few warnings and it looks messy, rather I get 4000 warnings and it takes a -long- time for them to be displayed, long enough that it's probably doubling my build time.

Originally I went with this structure to reduce the amount of unused code that gets linked to all my DLL's (one for each renderer, mixer, input system etc).

I'm happy to hear from anyone who can either suggest a better structure or knows how to turn a linker warning off. I'm using  .NET but this problem was with me under VC6 too.

Many thanks

Chris


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

resource construction WAS: [GD-General] longjmp for C++

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

-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...] 
Sent: Friday, January 11, 2002 2:22 AM
To: cor...@sp...; Gam...@li...
Subject: Re: [GD-General] longjmp for C++

performs a resource allocation upon construction or initialization, is
also
responsible for releasing said resource upon destruction / shutdown.

discipline and identify ownership of resources, whether they be
individual
memory blocks, entire heaps or D3D textures.

-- I would highly suggest against having resources as small and low
level as individual D3D texture (which already has its construction and
deletion) to be responsible for its construction and initialization.

-- Things as large as level should be able to construct and destroy
itself. But things as small as textures, you would in effect be making
them a 1-layer wrapper. This is highly inefficient.

-- The interesting thing about "levels" is that there are in fact 2
methods that are distinct: "construction" and "restoration."

-- Not only should level be able to construct / destroy as you had
suggested. But it should be capable of releasing (device dependent
resources) as much as possible, but not so "destroyed" that it cannot
"restore" (but not a full construct) with the start of a new device
state.

-- As with many things in programming, there is moderation to all. And
too fine a granularity in class automated construction and deletion
("point", "polygon") adds unnecessary overhead to 3D engines.

-- Restarting levels is very simple, very easy. It really isn't as
complicated as most of the suggestions here so far.
 
-- This is indeed straying very far from whether there is a class-safe
equivalent of longjmp for C++ classes. :)

-- I really think there is very little (possibly none) to add to the
pretty simple subject of restarting a level; so I would leave the rest
of this "new" topic up to the rest of you who still would like to
discuss it.

-- Let me know when this winds back to longjmp. :)

RE: [GD-General] longjmp for C++

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

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Gareth Lewin
Sent: Thursday, January 10, 2002 1:22 PM
To: cor...@sp...; Gam...@li...
Subject: RE: [GD-General] longjmp for C++

Hi, 
Sorry to jump in so late, but couldn't you just run your game app again
? Split your app into 2, one for the menus, one for the game, and to
restart you can have the game spawn the game again and then exit. (
Maybe has a sleep call at the start just to make sure your other game
instance is dead )

-- Gareth,

-- Way too much overhead for starting a new level.
-- The other suggestion of only a 2nd thread would be smaller, but still
unnecessary overhead.

-- A simple release old level and restore new level works just fine.

-- Just one app, just its thread and a few threads like rendering.

-- And it manages to release very cleanly.

-- And Release + Restore is really a preferable as implementation over
having 2 executables, or even 2 threads.

RE: [GD-General] longjmp for C++

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

Hi,

Sorry to jump in so late, but couldn't you just run your game app again ?
Split your app into 2, one for the menus, one for the game, and to restart
you can have the game spawn the game again and then exit. ( Maybe has a
sleep call at the start just to make sure your other game instance is dead )

> -----Original Message-----
> From: Corrinne Yu [mailto:cor...@sp...]
> Sent: 10 January 2002 17:50
> To: Gam...@li...
> Subject: RE: [GD-General] longjmp for C++
> 
> 
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Matt Davies
> Sent: Thursday, January 10, 2002 6:24 AM
> To: cor...@sp...; Gam...@li...
> Subject: RE: [GD-General] longjmp for C++
> 
> Under Windows, you can use the API calls HeapCreate, HeapDestroy,
> HeapAlloc
> 
> -- We do our own heaps so it is even easier. :) Doing our own 
> memory is
> also better for cross platform reasons.
> 
> As for DirectX, shutting it down should clear all resources associated
> with
> a device driver, shouldn't it?
> 
> -- :D Ha! (To be fair it does a good job of cleaning as much 
> as it can.)
> 
> -- Actually, it is still important for you to manually clean 
> and release
> your resources before shutting down the device. In execution, various
> minor undesirable things happen if your own code does not clean it all
> up before shutting down devices.
> 
> -- Another thing is that strangely enough things like destroying the
> entire device in DX is an asynchronous operation, when it would make
> sense for that to be synchronous, or a flag to define it to be
> synchronous. Or even better, it would be good to also have a global
> TestDeviceState to check its destruction process in this 
> case, as you no
> longer have the object (pointer), but you know for a split 
> nanosecond or
> so after destruction, DX is still out there doing something.
> 
> -- Thus if you actually leave resource releasing to Direct X during
> shutdown, or if you have a huge number of resources that is of the
> managed pool (which DX allocates system copies that it needs 
> to clean),
> there can be an unknowable time lapse after you called 
> destruction, and
> then when it is all actually destroyed.
> 
> HANDLE Spawn (const char* commandLine, const char* params,
> 	const char* directory)
> 
> -- Thanks, though the "specifiable pristine state" (not a real reboot)
> is what we are looking for (very close to longjump).  We don't
> necessarily want to actually reboot, but jump to a precise 
> state that we
> set somewhere in the game execution (which is in fact way after the
> process reboot).
> 
> -- The question is really more out of curiosity. Release and Restore
> works just fine and probably would remain the solution. 
> 
> P.S. The platform specific-ness of this is making this veering off of
> the "General" Topic, so perhaps we should move it elsewhere 
> where it is
> more specific to the API's and platforms.
> 
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 

RE: [GD-General] longjmp for C++

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

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Matt Davies
Sent: Thursday, January 10, 2002 6:24 AM
To: cor...@sp...; Gam...@li...
Subject: RE: [GD-General] longjmp for C++

Under Windows, you can use the API calls HeapCreate, HeapDestroy,
HeapAlloc

-- We do our own heaps so it is even easier. :) Doing our own memory is
also better for cross platform reasons.

As for DirectX, shutting it down should clear all resources associated
with
a device driver, shouldn't it?

-- :D Ha! (To be fair it does a good job of cleaning as much as it can.)

-- Actually, it is still important for you to manually clean and release
your resources before shutting down the device. In execution, various
minor undesirable things happen if your own code does not clean it all
up before shutting down devices.

-- Another thing is that strangely enough things like destroying the
entire device in DX is an asynchronous operation, when it would make
sense for that to be synchronous, or a flag to define it to be
synchronous. Or even better, it would be good to also have a global
TestDeviceState to check its destruction process in this case, as you no
longer have the object (pointer), but you know for a split nanosecond or
so after destruction, DX is still out there doing something.

-- Thus if you actually leave resource releasing to Direct X during
shutdown, or if you have a huge number of resources that is of the
managed pool (which DX allocates system copies that it needs to clean),
there can be an unknowable time lapse after you called destruction, and
then when it is all actually destroyed.

HANDLE Spawn (const char* commandLine, const char* params,
	const char* directory)

-- Thanks, though the "specifiable pristine state" (not a real reboot)
is what we are looking for (very close to longjump).  We don't
necessarily want to actually reboot, but jump to a precise state that we
set somewhere in the game execution (which is in fact way after the
process reboot).

-- The question is really more out of curiosity. Release and Restore
works just fine and probably would remain the solution. 

P.S. The platform specific-ness of this is making this veering off of
the "General" Topic, so perhaps we should move it elsewhere where it is
more specific to the API's and platforms.

RE: [GD-General] longjmp for C++

[Matt D. <ma...@co...>]

Hi,

Under Windows, you can use the API calls HeapCreate, HeapDestroy, HeapAlloc
etc for you memory needs.  HeapDestroy will remove the heap, clear any RAM
pages and so forth.  Overload your new, new[], delete and delete[] to use
the Win32 API Heap functions and you can clear memory up easily.

As for DirectX, shutting it down should clear all resources associated with
a device driver, shouldn't it?

Alternatively, you can shut things down as normal and at the end of your
call do something like:

	if (doReset) Spawn(filename,params,directory);

Where Spawn() is:

HANDLE Spawn (const char* commandLine, const char* params,
	const char* directory)
{
	SHELLEXECUTEINFO shellInfo;

	ZeroMemory(&shellInfo,sizeof(SHELLEXECUTEINFO);
	shellInfo.cbSize = sizeof(SHELLEXECUTEINFO);
	shellInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
	shellInfo.lpFile = commandLine;
	shellInfo.lpParameters = params;
	shellInfo.nShow = SW_SHOWNORMAL;
	shellInfo.lpDirectory = directory;

	if (ShellExecuteEx(&shellInfo)) return NULL;

	return shellInfo.hProcess;
}


This will spawn another process which is your game.  Which is, in effect,
rebooting your game.


Hope that helps.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Corrinne Yu
Sent: 09 January 2002 21:12
To: Gam...@li...
Subject: RE: [GD-General] longjmp for C++



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Daniel Vogel
Sent: Wednesday, January 09, 2002 1:12 PM
To: Thatcher Ulrich; Gam...@li...
Subject: RE: [GD-General] longjmp for C++

What Secret Level did for the DreamCast version of Unreal Tournament was
reloading the section of the executable that contains the global
variables
and resetting the heap for level changes. On PS2 and XBox we simply
"reboot". Of course this is all console stuff ;)

-- Rebooting is the type of behavior I have in mind (which is currently
implemented by release and reload). I just wondered if anyone knows of
something that simple on the PC. (Not a real reboot of course, just
something that restores environment to a specifiable equally pristine
state.)
-- As for textures and all the device driver interface nastiness, it may
be helpful for some degenerate situations to completely shutdown all of
Direct X to do as clean a clear as possible. It is still not completely
clean, but it really helps the device drivers to re-compact things like
texture memory with a full rebuild of devices and reload of current used
textures. For in between, there are a few DX calls that compact and
reset, but not always very well. Of course, these degenerate situations
don't arise until running lots and lots of resources for a very long
time.



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

RE: [GD-General] longjmp for C++

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

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Daniel Vogel
Sent: Wednesday, January 09, 2002 1:12 PM
To: Thatcher Ulrich; Gam...@li...
Subject: RE: [GD-General] longjmp for C++

What Secret Level did for the DreamCast version of Unreal Tournament was
reloading the section of the executable that contains the global
variables
and resetting the heap for level changes. On PS2 and XBox we simply
"reboot". Of course this is all console stuff ;)

-- Rebooting is the type of behavior I have in mind (which is currently
implemented by release and reload). I just wondered if anyone knows of
something that simple on the PC. (Not a real reboot of course, just
something that restores environment to a specifiable equally pristine
state.)
-- As for textures and all the device driver interface nastiness, it may
be helpful for some degenerate situations to completely shutdown all of
Direct X to do as clean a clear as possible. It is still not completely
clean, but it really helps the device drivers to re-compact things like
texture memory with a full rebuild of devices and reload of current used
textures. For in between, there are a few DX calls that compact and
reset, but not always very well. Of course, these degenerate situations
don't arise until running lots and lots of resources for a very long
time.

RE: [GD-General] longjmp for C++

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

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Thatcher Ulrich
Sent: Wednesday, January 09, 2002 12:47 PM
To: Gam...@li...
Subject: Re: [GD-General] longjmp for C++

On Jan 09, 2002 at 12:31 -0600, Corrinne Yu wrote:
> Out of curiosity, what are you using longjmp/setjmp for?
> 
> -- Daniel, Epic Games Inc.
> 
> -- It can be a convenient/lazy :) way to restart a clean game.
> 
> -- You set jump after all the startup but before game specific code.
> Then when a game ends, you can just long jump back to the state after
> startup but before game code. You can use the same idea to rewind a
game
> (after game data loaded, but before any game play changes has
started).
> 
> -- Another way (which is the way it is done now) is to do a full
cleanup
> after game ends and manually restores state to start up but before
game
> data load.
> 
> -- The lazy jump way of restarting is only safe for a pure C app. Our
> code base has now a lot of C++ classes and need to have their objects
be
> destroyed and constructed properly. Long jump is not guaranteed to do
> that correctly.

Neither setjmp/longjmp nor exceptions are going to do anything for
your heap, though, correct?  Which seems like the much tougher issue.

-- Not if all your heaps are part of the environment context, even your
C++ ones.

P.S. It's funny the mail editor insists longjmp should be spelled
longhop. :)

RE: [GD-General] longjmp for C++

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

What Secret Level did for the DreamCast version of Unreal Tournament was
reloading the section of the executable that contains the global variables
and resetting the heap for level changes. On PS2 and XBox we simply
"reboot". Of course this is all console stuff ;)

If it's a PC game: not only do you have to worry about the memory you
allocate dynamically but also resources like textures, open files and
whatnot in the case where you can't guarantuee everything is completly
loaded after init (e.g. in a multiplayer game a player joins with a
different player skin).

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Thatcher Ulrich
> Sent: Wednesday, January 09, 2002 1:47 PM
> To: Gam...@li...
> Subject: Re: [GD-General] longjmp for C++
>
>
> On Jan 09, 2002 at 12:31 -0600, Corrinne Yu wrote:
> > Out of curiosity, what are you using longjmp/setjmp for?
> >
> > -- Daniel, Epic Games Inc.
> >
> > -- It can be a convenient/lazy :) way to restart a clean game.
> >
> > -- You set jump after all the startup but before game specific code.
> > Then when a game ends, you can just long jump back to the state after
> > startup but before game code. You can use the same idea to rewind a game
> > (after game data loaded, but before any game play changes has started).
> >
> > -- Another way (which is the way it is done now) is to do a full cleanup
> > after game ends and manually restores state to start up but before game
> > data load.
> >
> > -- The lazy jump way of restarting is only safe for a pure C app. Our
> > code base has now a lot of C++ classes and need to have their objects be
> > destroyed and constructed properly. Long jump is not guaranteed to do
> > that correctly.
>
> Neither setjmp/longjmp nor exceptions are going to do anything for
> your heap, though, correct?  Which seems like the much tougher issue.
>
> --
> Thatcher Ulrich <tu...@tu...>
> http://tulrich.com
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

Re: [GD-General] longjmp for C++

[Thatcher U. <tu...@tu...>]

On Jan 09, 2002 at 12:31 -0600, Corrinne Yu wrote:
> Out of curiosity, what are you using longjmp/setjmp for?
> 
> -- Daniel, Epic Games Inc.
> 
> -- It can be a convenient/lazy :) way to restart a clean game.
> 
> -- You set jump after all the startup but before game specific code.
> Then when a game ends, you can just long jump back to the state after
> startup but before game code. You can use the same idea to rewind a game
> (after game data loaded, but before any game play changes has started).
> 
> -- Another way (which is the way it is done now) is to do a full cleanup
> after game ends and manually restores state to start up but before game
> data load.
> 
> -- The lazy jump way of restarting is only safe for a pure C app. Our
> code base has now a lot of C++ classes and need to have their objects be
> destroyed and constructed properly. Long jump is not guaranteed to do
> that correctly.

Neither setjmp/longjmp nor exceptions are going to do anything for
your heap, though, correct?  Which seems like the much tougher issue.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] longjmp for C++

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

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Daniel Vogel
Sent: Wednesday, January 09, 2002 11:50 AM
To: cor...@sp...; Gam...@li...
Subject: RE: [GD-General] longjmp for C++

On Windows you can use exceptions for almost all case where you'd want
to
use longjmp/ setjmp. On Linux you can't use exceptions that well but
longjmp/ setjmp are extremely slow there :(

Out of curiosity, what are you using longjmp/setjmp for?

-- Daniel, Epic Games Inc.

-- It can be a convenient/lazy :) way to restart a clean game.

-- You set jump after all the startup but before game specific code.
Then when a game ends, you can just long jump back to the state after
startup but before game code. You can use the same idea to rewind a game
(after game data loaded, but before any game play changes has started).

-- Another way (which is the way it is done now) is to do a full cleanup
after game ends and manually restores state to start up but before game
data load.

-- The lazy jump way of restarting is only safe for a pure C app. Our
code base has now a lot of C++ classes and need to have their objects be
destroyed and constructed properly. Long jump is not guaranteed to do
that correctly.

RE: [GD-General] longjmp for C++

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

On Windows you can use exceptions for almost all case where you'd want to
use longjmp/ setjmp. On Linux you can't use exceptions that well but
longjmp/ setjmp are extremely slow there :(

Out of curiosity, what are you using longjmp/setjmp for?

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Corrinne Yu
> Sent: Wednesday, January 09, 2002 12:33 PM
> To: Gam...@li...
> Subject: [GD-General] longjmp for C++
>
>
>
> What are class-safe equivalents for longjmp and setjmp type operation in
> C++ that correctly reconstruct all class objects?
>
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

[GD-General] longjmp for C++

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

What are class-safe equivalents for longjmp and setjmp type operation in
C++ that correctly reconstruct all class objects?

Re: [GD-General] Java bitching

[Joe <dar...@ya...>]

Try using Integer.byteValue() and see what you get :)

Seems like they should have returned a byte[] instead of a single byte...
but probably no one actually uses the Integer class other than for 
converting strings
to ints and perhaps as an int object container...

Colin Fahey wrote:

>>>>The problem here is that a byte in java is signed.
>>>>
>
>D'Oh!
>
>I guess I've been conditioned to think of "byte"s as
>8-bit values, not small signed integers.
>
>Since "char" in Java is a signed 16-bit integer, I
>guess they would have to make "byte" their signed
>8-bit integer.
>
>I'd rather that Java defined "byte" as "UN-signed 8-bit
>integer", and "char" as "8-bit signed integer", and
>"wchar" as "16-bit signed integer".  But everything in
>Java is signed, and Java is so wildly popular that
>redefining "byte" is impossible without the use of
>a time machine and brain-washing equipment...Set the
>coordinates to Sun's remote Java think-tank conference
>room -- date: the day they decided to call "byte"
>a signed 8-bit integer.  (Note to self: Bring the attache
>case of money, and bet on sporting events.  Meet up
>with the earlier "me" and tell him that 2001 is gonna
>suck.  Don't step on the Butterfly in Beijing, or you'll
>cause a catastrophic change in the Earth's climate,
>disrupt the timeline, and send the planet spiraling
>in to the Sun.)
>
>But, as it is, I'm *glad* the compiler is doing the
>"right thing".
>
>--- Colin
>
>
>
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

RE: [GD-General] Java bitching

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

>>>The problem here is that a byte in java is signed.

D'Oh!

I guess I've been conditioned to think of "byte"s as
8-bit values, not small signed integers.

Since "char" in Java is a signed 16-bit integer, I
guess they would have to make "byte" their signed
8-bit integer.

I'd rather that Java defined "byte" as "UN-signed 8-bit
integer", and "char" as "8-bit signed integer", and
"wchar" as "16-bit signed integer".  But everything in
Java is signed, and Java is so wildly popular that
redefining "byte" is impossible without the use of
a time machine and brain-washing equipment...Set the
coordinates to Sun's remote Java think-tank conference
room -- date: the day they decided to call "byte"
a signed 8-bit integer.  (Note to self: Bring the attache
case of money, and bet on sporting events.  Meet up
with the earlier "me" and tell him that 2001 is gonna
suck.  Don't step on the Butterfly in Beijing, or you'll
cause a catastrophic change in the Earth's climate,
disrupt the timeline, and send the planet spiraling
in to the Sun.)

But, as it is, I'm *glad* the compiler is doing the
"right thing".

--- Colin

RE: [GD-General] Java bitching

[Rob H. <ro...@ir...>]

The problem here is that a byte in java is signed.

//so this will compile
byte[] a = {0x7f, 0x01}

//whereas 0xff is bigger than 2^7-1(0x7f) so it requires an explicit cast
byte[] a = {(byte)0xff, 0x7f};

As one who has spent quite a bit of time over the last 4+ years programming
in java, most of Mr. Zawinski's complaints come from a lack of knowledge
about the language, but in all fairness he clarifies that at the beginning.
"Therefore, some of the following complaints might have been addressed in
later versions of the language, or they might have been misunderstandings on
my part."

Rob Hughes

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Friday, January 04, 2002 10:52 AM
To: Gam...@li...
Subject: RE: [GD-General] Java bitching


> Let me add a Java gripe!
>
> I was disappointed that something like
> the following Java code doesn't compile:
>
> // Loss of precision: int to byte
> byte [] a = { 0xff, 0x7f };
>
> Forcing me to do this:
>
> // Okay
> byte [] a = { (byte)0xff, (byte)0x7f };

Isn't that a compiler problem and not a language problem, or does the
language assume that bytes are characters?  If it's a compiler problem,
then I won't fault Java for it, but if it's a language thing -- um, ick.

I'm all for language purity, but when it interferes with actual,
practical getting work done (like Eiffel's lack of hex constants), then
I'm against it.  What I DON'T like are syntactic helpers that are purely
stylistic; however, this doesn't seem to be the case.

Brian


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

RE: [GD-General] Java bitching

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

> Let me add a Java gripe!
> 
> I was disappointed that something like
> the following Java code doesn't compile:
> 
> // Loss of precision: int to byte
> byte [] a = { 0xff, 0x7f };
> 
> Forcing me to do this:
> 
> // Okay
> byte [] a = { (byte)0xff, (byte)0x7f };

Isn't that a compiler problem and not a language problem, or does the
language assume that bytes are characters?  If it's a compiler problem,
then I won't fault Java for it, but if it's a language thing -- um, ick.

I'm all for language purity, but when it interferes with actual,
practical getting work done (like Eiffel's lack of hex constants), then
I'm against it.  What I DON'T like are syntactic helpers that are purely
stylistic; however, this doesn't seem to be the case.

Brian

Re: [GD-General] Java bitching

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

January 4th, 2002
Friday

>>>
http://www.jwz.org/doc/java.html
>>>
>>>Brian

Let me add a Java gripe!

I was disappointed that something like
the following Java code doesn't compile:

// Loss of precision: int to byte
byte [] a = { 0xff, 0x7f };

Forcing me to do this:

// Okay
byte [] a = { (byte)0xff, (byte)0x7f };

It just makes the code ugly when there
are, say, 1024 bytes in a table!
I think the Java compiler could postpone
deciding that hex literals in a byte
array are 'int', and go with the 
assumption that they're 'byte' until
an excessive value, like 0x100, is
encountered!  Why not?  Confusion? ;-)

Also, although I can see how having
signed integer types (char, short,
int, long) eliminates the wacky math
situations that can arise with
UN-signed types, I sometimes wish I
could use an unsigned integer type
in Java. I guess using 31 bits of "int"
is okay, and then you need to go to
"long" for 32 up to 63 unsigned bits.
But I was porting a table of 32-bit
unsigned int's from C to Java, and
having to do all operations in terms
of "long"'s seems like a waste.

I'll admit, the low-level bit madness
I am dealing with is probably not the
kind of computer science Java is 
promoting -- so I downgrade this "gripe"
to "tale of inconvenience".  I don't
want Sun's QA to enter another "Highest Priority"
entry in the Gripezilla or GripeTracker 
database on my account!

--- Colin