gamedevlists-general

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

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

[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

[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

[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
>

[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] 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
>

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++

[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++

[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++

[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++

[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
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++

[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. :)