Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  And so it begins.... ! (Sun makes play...)  (Read 9884 times)
0 Members and 1 Guest are viewing this topic.
Offline nickdotjava

Junior Member




I have fallen to the dark side.  I'm using DX9


« Reply #30 - Posted 2003-06-06 16:18:26 »

How about the ability to overload operators, like in C++?  That is the feature of C++ I miss the most.

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
Offline abies

Senior Member





« Reply #31 - Posted 2003-06-06 16:52:57 »

Quote
How about the ability to overload operators, like in C++?  That is the feature of C++ I miss the most.


There are two problems with operator overloading - syntax and value objects. You can have operator overloading with java by using one of variant java compilers - kiev for example (althrough it is a bit outdated, it still supports a lot of interesting possibilities, like mentioned operator overloading, multiple inheritance through delegation etc).

Real problem is cost associated with creating new object every time you use operator. It cannot be resolved without lightweight objects or really smart immutable object/escape analysis and until then, operator overloading will not be suitable for high-performance math - and IMHO, math is only area where you really need it.

Please check out
http://java.sun.com/people/jag/FP.html#overloading

Artur Biesiadowski
Offline vrm

Junior Member




where I should sign ?


« Reply #32 - Posted 2003-06-07 08:46:16 »

LWJGL in the Jre and swing/awt optional  Grin Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #33 - Posted 2003-06-07 13:34:48 »

Quote

I think I disagree with Cas' #4..  The rich set of APIs is part of what attacted me to Java.  If they aren't part of Java they won't get ported (because it won't be 'required').. if they don't get ported, there goes WORA.


Ditto; the fact that Java started off with "standard libraries" whereas C and C++ had to wait a looooong time before getting them has IMHO had a huge but subtle positive effect.

In fact, my only truly catastrophic problems with supporting java applications have always been caused by failure (of a JVM author) to do the standard libraries properly. One example is Apple (and a few other platforms) JVM's which only included parts of the standard libraries - in the end, I usually persuaded my employers to stop supporting Apple entirely, for the simple reason that the cost-benefit ratio was far far too high.

The other obvious example is the massively irritating state of Fullscreen mode. Releasing 1.4.x with the new fullscreen API, but without support on major platforms (unix, linux) must be having a bad effect. Just look at the number of people who state "I'm not doing a fullscreen version of my game/app because it doesn't work on all platforms". I'm not complaining - just trying to point out how much pain comes about when a "standard library" isn't actually a complete standard.

Quote

Extend WebStart to handle automatic installation of JRE subcomponents to the JREs that it is aware of.


This must surely be one of the most popular sensible suggestions. I just want to add that - if you follow this route - please be very careful to make it a VERY good packaging/deployment/versioning system. Linux, for example, is suffering hugely these days because of the widespread use of RPM, and the major failings in that deployment system.

I know from experience that a really good packaging system is much like a really good Data-Structures library - it takes a lot of thinking and planning to get just right, but the payback is felt again and again and again for many years to come. Positive or negative. These systems really need a lot of effort, and typically you can't make big changes later on if you realise you did something badly.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #34 - Posted 2003-06-07 13:42:54 »

Quote

So, what do you want to see fixed?


Authoritative, UP TO DATE, documentation (probably in the form of tutorials) on the subtle, low-level issues. The BufferStrategy documentation is a good start, but it doesn't go far enough. If you take those docs, add in everything that Jeff has said on JGO on that topic, add in the comments by the guy in the Java2D team about some of the experimental hardware support in 1.4.x, add in some of the comments by people on JGO, and you get the right level of docs.

The typical problem here is that if you are trying to use all the advanced graphics stuff "properly", it is very hard to get it right first time. There are so many subtleties (e.g. "this isn't implemented on linux yet") and unanswered questions (e.g. "can I use Swing and AWT components with fullscreen mode? Are the problems I'm seeing my fault, or because of some incompatibility?").

Obviously, we'll have all those SPECIFIC examples cleaned up pretty soon. However, with each new release and API, if you are pushing hard at the boundaries of what is included in Java (e.g. adding a full OpenGL pipeline in 1.5 from scratch), the same kinds of problems will recur. If the release notes for each version were about 10 times as detailed, this wouldn't be a problem. If the API documentation were perfect, this wouldn't be a problem.

But we live in the real world, so I'd be happy with a subsection of JGO which was just an up-to-date FAQ on these gotchas. Searching JGO forums, and reading hundreds of posts to find a gotcha (the only way I currently know of dealing with these problems!) everytime you THINK you may have found one is far too time consuming.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #35 - Posted 2003-06-07 13:44:37 »

Quote
How about the ability to overload operators, like in C++?  That is the feature of C++ I miss the most.


I'm not trying to be facetious, but "just because you miss it, isn't a reason for porting it".

There are damn fine reasons not to have operator overloading (and, of course, good reasons for having it - although I've been convinced over the years that the former outweigh the latter).

...but if you've got a really good reason for having it, then illuminate us (unless you were  just trolling Wink)

Number one reason for not having it:

  Code maintenance often becomes much more expensive, because you have a much poorer concept of what, precisely, is happening when you read the code.

This is strongly related to some of the good reasons for doing away with header files and compile-time includes: reading and comprehending source code quickly becomes an exercise in remembering things, or fast-switching between lots of source files, just to read one of them; encapsulation typically flies out the window, and most of the advantages that go with it.

Blah blah blah...good programmers don't make these mistakes...blah blah. But that's what they said about BCPL, and typeless languages.  I haven't yet met the developer who would prefer NOT to have a compiler which was able to automatically catch programming errors (apart from Martin Richards, who is still in love with BCPL, all these years later Sad ).

[forgive the gross generalizations, in an attempt not to wander too far off topic, and into the wastelands where the Trolls live...]

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #36 - Posted 2003-06-07 14:51:43 »

Overloading operators can be a nightmare for maintenance, since you loose consistancy when reading code, however the same can be said when you start getting badly named methods, or methods that have subtle but vital side effects which arn't immediatly obvious when looking at the method signiture.

Just because some people can abuse overloading, doesnt justify their total removal. I can write bad code with or without this feature Wink

Likewise, what about this:
1  
2  
3  
String head = "Some text";
String tail = "more text";
String list = head + tail;


So, what is that except operator overloading? I doubt you'll see people complaining about the readability with this (especially vs. the fully expanded form generated with chained string buffers). This is clearly a special case, and so breaks consistancy. </devils advocate>

I don't particularly mind either way, but whatever the decision is, make it consistant!

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #37 - Posted 2003-06-07 15:08:33 »

Quote

Likewise, what about this:
1  
2  
3  
String head = "Some text";
String tail = "more text";
String list = head + tail;


So, what is that except operator overloading?


Indeed. I have a vague memory of finding a bug in someone's code for them, that was cause by the plus overload for String's, but I'm not sure; seems very unlikely Smiley.

EDIT: I remember now. Just irritating problems that prevent compilation....You cannot do:
1  
2  
3  
    int x, y;
    String s;
    System.out.println( "something: "+s+", and x+y"+ x+y );


You have to bracket the x+y, to make the compiler interpret that plus as an integer plus, rather than a String concatenate. Minor irritant.

I have also seen problems when the implicit call to ".toString()" doesn't happen. The call is normally triggered by the use of a non-String with a String-concatenate-plus, but if you pass an Object to a method that takes a String argument, the conversion doesn't take place. This is kind of weird for some people, because the get used to the fact that you can insert an Object where a String is expected, and that the implicit call will "just work".



However, I have seen MANY major bugs because of java's op-overloading for arithmetic on basic datatypes. The most common one is, of course, the difference between integer divide and double divide. It's rational to overload float and double divide to be the same, but I frequently see people doing something like:

1  
2  
   int x = 1; int y=2;
   double d = x / y;


and being screwed by the unexpected value of 0.0d. Sigh. And this is a trivial example that you can learn to avoid by rote...things can get much worse if you add general overloading.

(Of course, the actual code has the variables separated up much more, and it is less obvious what the problem was!).

What really really irritates me about this example is that javac will refuse to compile (which is a whole separate stupidity: compiler warning? yes please ... refuse to compile? Please, NO!) if it thinks I didn't actually want an automatic cast for this:

1  
    float f = f * Math.sqrt( f );


when I often do want the cast, but WILL NOT do the same behaviour for the painfully common accident I highlighted above.

Ditto the stupid stupid stupid bug whereby:
1  
2  
    Object i = null; // you HAVE to explicitly reference null, or it won't compile
   // do something with i


is forced upon you by the compiler because otherwise it refuses to compile because "i may not have been assigned to". What do I gain? If I try using it without assignment, I'm STILL going to get a NullPointerException; the only difference is that now I've had to write extra code....Sigh.

malloc will be first against the wall when the revolution comes...
Offline nickdotjava

Junior Member




I have fallen to the dark side. &nbsp;I'm using DX9


« Reply #38 - Posted 2003-06-07 16:00:04 »

Quote
There are damn fine reasons not to have operator overloading (and, of course, good reasons for having it - although I've been convinced over the years that the former outweigh the latter).

...but if you've got a really good reason for having it, then illuminate us (unless you were  just trolling )


I'm not trying to troll here.  I've just always found > or < more intuitive than a.compareTo(b).  For instance, I'm implementing the storage of the map in a rts game as a sparse matrix.  Since the elements are sorted in each LinkedList, it would be more intuitive to have > or <.  But no, no troll here.  I love Java.  I'm not going back to C++.   Cheesy

-Nick

"Oh ya, that's trivial.  I should have it done in an hour."
Offline Mark Thornton

Senior Member





« Reply #39 - Posted 2003-06-07 17:40:19 »

The solution to the problem with
1  
f = f*Math.sqrt(f)
 would be the addition of a full set of Math methods taking (and returning) float values. I gather this was omitted due to a defficiency in an early compiler (couldn't overload on float/double). There ought to be an RFE for this, but I can't find one.

As for operator overloading I think the only group with an undeniably strong claim are those using complex numbers and similar numerical types.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2003-06-07 18:10:58 »

And the rather large number of us using vector algebra.
But then I've always advocated alphanumeric syntax for operators, which solves the pain of bad syntax and unreadability and project differences at a stroke:

1  
a = a dot b;

and
1  
2  
if (a isGreaterThan b) {
}


Looks nice doesn't it?
All the advantages of C++ operator overloading... none of the disadvantages...

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #41 - Posted 2003-06-07 18:19:03 »

Quote
You have to bracket the x+y, to make the compiler interpret that plus as an integer plus, rather than a String concatenate. Minor irritant.


Well, that's just because the expression is evaluated in left-right order.  The String's + operator has the same precedence as the int's + operator, so you need to explicitly bracket things.

Quote
What really really irritates me about this example is that javac will refuse to compile (which is a whole separate stupidity: compiler warning? yes please ... refuse to compile? Please, NO!) if it thinks I didn't actually want an automatic cast for this:

1  
    float f = f * Math.sqrt( f );


when I often do want the cast, but WILL NOT do the same behaviour for the painfully common accident I highlighted above.


Well, it's all logical I'm afraid! Wink  In the sqrt expression, (float * double) is promoted to (double * double), which is evaluated.  It then tries (float = double), which fails to compile as it's a narrowing conversion.

In the integer divide expression, (int / int) is evaluated first (as an integer divide, as both operands are integers), then it attempts (double = int), promotes it to (double = double) via a widening conversion, which then works fine. Grin

N.B. Some languages get around this kind of problem by having a different operator for integer divides.


Quote
Ditto the stupid stupid stupid bug whereby:
1  
2  
    Object i = null; // you HAVE to explicitly reference null, or it won't compile
   // do something with i


is forced upon you by the compiler because otherwise it refuses to compile because "i may not have been assigned to". What do I gain? If I try using it without assignment, I'm STILL going to get a NullPointerException; the only difference is that now I've had to write extra code....Sigh.


Nope, not a bug - there's a big difference there.

Local variables are NOT implicitly initialised - you have to do it yourself.  (Member variables are automatically initialised at object creation.)  If you didn't explicitly assign a value to a local variable, you wouldn't get a NullPointerException, you'd get garbage - a reference pointing to some random bit of memory somewhere.  The Java compiler refuses to allow this to happen, so you have to initialise it.

And why doesn't Java implicitely initialise local variables?  It's to allow you to perform late-initialization of local final variables! Smiley

Hellomynameis Charlie Dobbie.
Offline abies

Senior Member





« Reply #42 - Posted 2003-06-07 18:26:02 »

Quote

And why doesn't Java implicitely initialise local variables?  It's to allow you to perform late-initialization of local final variables! Smiley


For me, main reason is to catch errors. Simple example:

String str1;
String str2;

if ( quiteOften ) {
   str1 = "AAA";
   str2 = "BBB";
} else {
   str1 = "XXX";
   str1 = "YYY";
}

This one is simple, but sometimes, with try/catch/finally etc, every help from compiler is useful in spotting such errors early.

Artur Biesiadowski
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #43 - Posted 2003-06-07 18:43:16 »

Quote

Well, it's all logical I'm afraid! Wink
...
N.B. Some languages get around this kind of problem by having a different operator for integer divides.


Grin. Yes, indeed it is. I only mentioned those issues because they tend to waste development time and/or be the source of additional bugs...

...And they are all due to operator overloading. Your N.B. summarises my point perfectly - if that operator were not overloaded, the problem would not occur. I'm just trying to illustrate that operator overloading already causes significant problems.

Quote

Nope, not a bug - there's a big difference there.

Local variables are NOT implicitly initialised - ... It's to allow you to perform late-initialization of local final variables! Smiley


Sorry, I shouldn't have said "bug" Smiley. And I forgot the reason that abies gave...I too use that behaviour, so perhaps it's just another case of "the cons are bad, but the pros are just good enough to tip the balance" Smiley.

I think I tend to forget the "lazy/final" reason because this kind of feature (something that enables late or delayed or selective initializations) is missing in some other places, so that you cannot in general assume java provides the mechanisms to do this.

For instance, the rule that you cannot delegate to another constructor EXCEPT in the first line of another constructor. The sensible version, that would fit nicely with the feature you've pointed out, is if it said "you may not make any method call/etc that has any effect on the object-under-construction prior to delegation".

I CAN execute statements before the delegated constructor call, since I can do things like:

1  
2  
3  
4  
   public constructor( Object obj )
   {
       this( "a string"+a+", "+obj.toString() );
   }


...but it won't compile if you move the toString() method call into a line earlier, and use a temporary variable.

I've wondered for years if there is any reason for this. I've written pseudo-code for a compiler that decides quite easily whether a pre-delegation method call is OK. I can't see a problem with it; doesn't mean there isn't one, of course Wink. I can't recall precisely what I wrote, but I seem to remember it did a check for things like whether you were assigning to a final variable, and made sure that final wasn't assigned to again in another constructor, etc. It wasn't difficult.

malloc will be first against the wall when the revolution comes...
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #44 - Posted 2003-06-07 22:29:07 »

Quote
I modelled a virtual world in Maya, built a new physical interface, scripted and recorded cutscenes and dialogue, wrote a 3D-engine etc. in just nine weeks, much thanks to all the  APIs provided by Sun and the Xj3D group.


Way out of topic for this thread - but we'd like to know what your project was and if you have a public page for it. We like to link to other sites that are successfully using Xj3D in their projects. PM me with the details if you don't mind us linking to it.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline William

Junior Member




No Exit


« Reply #45 - Posted 2003-06-07 22:54:34 »

Oh, the project is very public. It's called Nevermore and you can find a poster about it at http://www.saar.se/nevermore_poster.php (PDF-file) and more details about the project at http://www.saar.se.

I really just use Xj3D for loading static VRML models, but I can see it become a really important API in the future if Java3D manages to stay alive and AliasWavefront implements full support for X3D-export in Maya.
Offline Jeff

JGO Coder




Got any cats?


« Reply #46 - Posted 2003-06-08 07:42:07 »

Thanks guys!

We have a long way to go yet but yes this is what we've been bursting at the seems to tell you.  The client effort will all be discussed next week and yes we still see it as critical.

I should mention, since the press release didn't  (sticks tounge out at the "marketing guy who get HIS name mentioned")  I've got a new title too...

Jeff Kesselman
Architect, Game Technologies
Software Advanced Technology Group

I'm doing two things primarily right now.  The first is doing everything I can to make the transition of the tech we worked on in JSR-134 over to open-source smooth and fast.

The second is that I'm leading the effort at defining the software part of the Sun server solution set for MMOL games.  As some of you might remember I've had a long standing interest in back-end infrastructure for thsese kidsn of games.  DOn't betoo surpised to see some of the ideas we've discussed here in times past making it into that stack Wink

JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (12 views)
2014-07-29 18:09:19

Riven (9 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (26 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (40 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!