[java] How important is Platform Independence?
Things have been kind of slow on the board, so I thought I would throw out this for discussion if anyone is interested.
There are several instances where the performance and/or flexibility of games developed in Java could be improved by using some kind of platform dependant library such as Magician, WildTangent, or DirectX.
There are examples even within development still classified as ‘Pure Java''. For instance, using the platform dependant versions of JMF can substantially increase your performance in playing back media files, but only Linux, Windows, and Solaris versions are available.
Given this:
- How important is Platform Independence to your Java game development efforts?
- If platform independence is important to you, is Java code executed against platform specific versions of Java libraries sufficient?
- Is Sun’s concentration on OS portability a hindrance or help to the language’s use for client applications such as games and interactive multimedia?
February 16, 2001 03:49 PM
platform independance isn''t worth much at all, almost 0. The truth is that the number of gamers using the same operating system (windows) is quite nearly 100%, perhaps something like 99.9999%, with the only people using different operating systems being kids who can''t convince their parents to use windows. So we''ve got nearly 100% of the people all using the same platform. I think the answer is pretty obvious. If we could have some directX java thing it would be great and make java a very viable language, but Sun is evil and doesn''t care about game development one bit so I''m stuck having to learn how to combine the two instead of having it nicely intergrated.
Since you posted anonymously, I can insult you ... you are insane. 99.99% of gamers use Windows? Where do you get that figure? Do all of the users of MAC OS, BeOS, Linux, Unix, etc not count? I will admit that over 90% of all computer users have "access" to a Windows OS, but that does not mean they prefer to be forced to use it ... and in the case of MAC or console gamers, they cannot. I have worked programming Windows DirectX 6, and I liked it. Now I am employed programming for BeOS, and I like that too ... but I can tell you at our company (which creates consoles for movie post production) half of our employees don''t have a Windows OS installed, so they don''t get to join our afternoon Unreal Tournament break ... how much better it would be for them if they could ... and even for the rest of us, we mostly have to boot to Windows just for the game ... which is silly.
Anyway ... if your writing platform specific, runtime critical code (like blazing fast game engines) why would you want to use java? Game engines are typically written using a subset of C++ (meaning just like C programs, only organized into class libraries, with some use of interfaces and virtual functions).
I wish that we were at the point were platform independence was feasable, but that is not yet the case with cutting edge games. Computers are more than fast enough to handle an ftp client that is only 1/3 as efficient as it could be, but if the performance on Quake3 had to take even a 20% loss in the rendering code, it would become nearly unplayable on relatively powerful machines (machines without $200+ graphic accelerators can still only handle about 800x600 resolution with high detail).
Just look at the needs of your program ... if it''ll run on a Pentium 233 with 4MB graphic accelerator (say S3 virge) in 32 MB RAM ... then you can afford platform independence ... otherwise .. you will probably need platform specific code or libraries - so accept the inevitable and do what you gotta do.
Anyway ... if your writing platform specific, runtime critical code (like blazing fast game engines) why would you want to use java? Game engines are typically written using a subset of C++ (meaning just like C programs, only organized into class libraries, with some use of interfaces and virtual functions).
I wish that we were at the point were platform independence was feasable, but that is not yet the case with cutting edge games. Computers are more than fast enough to handle an ftp client that is only 1/3 as efficient as it could be, but if the performance on Quake3 had to take even a 20% loss in the rendering code, it would become nearly unplayable on relatively powerful machines (machines without $200+ graphic accelerators can still only handle about 800x600 resolution with high detail).
Just look at the needs of your program ... if it''ll run on a Pentium 233 with 4MB graphic accelerator (say S3 virge) in 32 MB RAM ... then you can afford platform independence ... otherwise .. you will probably need platform specific code or libraries - so accept the inevitable and do what you gotta do.
February 16, 2001 07:26 PM
yeah that''s my problem, I don''t think my game will run fast enough if I just go with straight java. So I''m going to switch out my graphics engine (and sound and input, etc..) for one that has native methods to call some C++ which will use directX. Fortunately I''ve designed it with the expectation that I will swap those parts out. I really wish I could just use directX from within java, but I can''t. As for at work, well I guess that is an issue I hadn''t thought of. I was thinking more about home users, who should have a windows computer if they want to play games, just like you have to buy a nintendo if you want to play mario. If people go for platform independance like you said things end up slower or it takes more work and most game companies can''t afford to make their game that much slower (which would decrease the number of people able to buy it), and most can''t afford to port because there is so little return.
OK, I have long opinion in this topic so here goes...
First, I think that full platforms independance is utopia for games. It could be cool, to be able to write your problem once and it would then run on both game consoles, on PCs and Linux. However, systems such as consoles have a widely different set of input/output devices than PC so in reality making such a full platform independance if utopia - it is good for net based operation where the environment is the same but for games, I think not. Users expect programs to be written specifically for their system - as a PC user I hate being forced to use a game pad... (And a side note to the first ano poster - console games represent the majority of the global sales within gaming so if you count consoles and Linux it is more likely you are down to about 50% using WIndows (I don''t have the exact figures). Oh and java *does* exist to the Sony playstation...)
The best we can hope for is to write so code that with a minimum of effort can be ported to other platforms for use there. Given this it means that we should try to isolate all platform dependent things in as few modules as possible to make it easy to port. Doing this in Java is easier than with say C++ because so much effort has been put into platform independance.
Given that platform dependance is present anyway, it is my argument that then we might as well use platform dependant libraries to speed things up - *if* we can isolate their use to a few modules. And if possible use of such libraries should be miimized elsewhere as it may cause more work when porting.
So in conclusion I think we should use platform dependant libraries in a controlled way.
Although Sun are making libraries such as JMF available and classify their use as pure Java, then this isn''t making the system platform dependant. All those optional packages (including pacakages such as Java3D) are not really platform dependant due to the fact that they have only been made available on a few platforms. The result is that for pure platform independance you are stuck with JDK 1.1 without using any extra libraries you can download from Sun - and with that package there is pretty strict limits to what is possible to do.
As some of you know I have written several platform dependent libraries myself for Windows. One that allows you to program native Windows applications (called JWindows) and one that allows the use of the Quake II-like engine 6DX from Eldermage (it is called 6DX for Java). So I am in strong favor of platform dependant libraries - without them no proper commercial non-applet games will ever see the light of day.
Jacob Marner
First, I think that full platforms independance is utopia for games. It could be cool, to be able to write your problem once and it would then run on both game consoles, on PCs and Linux. However, systems such as consoles have a widely different set of input/output devices than PC so in reality making such a full platform independance if utopia - it is good for net based operation where the environment is the same but for games, I think not. Users expect programs to be written specifically for their system - as a PC user I hate being forced to use a game pad... (And a side note to the first ano poster - console games represent the majority of the global sales within gaming so if you count consoles and Linux it is more likely you are down to about 50% using WIndows (I don''t have the exact figures). Oh and java *does* exist to the Sony playstation...)
The best we can hope for is to write so code that with a minimum of effort can be ported to other platforms for use there. Given this it means that we should try to isolate all platform dependent things in as few modules as possible to make it easy to port. Doing this in Java is easier than with say C++ because so much effort has been put into platform independance.
Given that platform dependance is present anyway, it is my argument that then we might as well use platform dependant libraries to speed things up - *if* we can isolate their use to a few modules. And if possible use of such libraries should be miimized elsewhere as it may cause more work when porting.
So in conclusion I think we should use platform dependant libraries in a controlled way.
Although Sun are making libraries such as JMF available and classify their use as pure Java, then this isn''t making the system platform dependant. All those optional packages (including pacakages such as Java3D) are not really platform dependant due to the fact that they have only been made available on a few platforms. The result is that for pure platform independance you are stuck with JDK 1.1 without using any extra libraries you can download from Sun - and with that package there is pretty strict limits to what is possible to do.
As some of you know I have written several platform dependent libraries myself for Windows. One that allows you to program native Windows applications (called JWindows) and one that allows the use of the Quake II-like engine 6DX from Eldermage (it is called 6DX for Java). So I am in strong favor of platform dependant libraries - without them no proper commercial non-applet games will ever see the light of day.
Jacob Marner
Jacob Marner, M.Sc.Console Programmer, Deadline Games
February 17, 2001 02:38 PM
Platform independence is good. I am typing this on a Linux system, and so the only games and stuff I can play over the web are Java ones which run in Netscape. The statement that 99.999% of users have windows is utter crap.
felonius wrote:
I really have to disagree with the statement that Java is easier to port to other platforms than say C++. Given the context of this discussion I can assume that you mean porting Java games is easier than porting C++ games. Unfortunately that would be an incorrect statement. While Java is a powerful, viable language, it does not have as wide acceptance or the flexibility that C++ has when used to develop games . In order to achieve maximum performance in Java, it is often necessary to use unportable libraries or, worse yet, unportable implementations of Java ( Microsoft''s Visual J++ anyone? )
The key to developing any portable application is to separate interface from implementation. The key programming patterns used to facilitate this are "Bridge", "Abstract Factory", "Prototype", and "Proxy" - just to name a few. By utilizing these patterns effectively the main engine of a game can be developed in pure C++ (no compiler extensions etc) and can be linked to interface classes. The implementations of the interface classes are provided in separate libraries, specifically optimized for a given platform.
Any how, my wife is nagging me to get going for dinner. So I''ll close this off ...
Don''t take this the wrong way, I''m not attacking Java - I''m just pointing out that it is a common misconception that Java is truly "Write once, run anywhere".
Dire Wolf
direwolf@digitalfiends.com
quote:
The best we can hope for is to write so code that with a minimum of effort can be ported to other platforms for use there. Given this it means that we should try to isolate all platform dependent things in as few modules as possible to make it easy to port. Doing this in Java is easier than with say C++ because so much effort has been put into platform independance.
I really have to disagree with the statement that Java is easier to port to other platforms than say C++. Given the context of this discussion I can assume that you mean porting Java games is easier than porting C++ games. Unfortunately that would be an incorrect statement. While Java is a powerful, viable language, it does not have as wide acceptance or the flexibility that C++ has when used to develop games . In order to achieve maximum performance in Java, it is often necessary to use unportable libraries or, worse yet, unportable implementations of Java ( Microsoft''s Visual J++ anyone? )
The key to developing any portable application is to separate interface from implementation. The key programming patterns used to facilitate this are "Bridge", "Abstract Factory", "Prototype", and "Proxy" - just to name a few. By utilizing these patterns effectively the main engine of a game can be developed in pure C++ (no compiler extensions etc) and can be linked to interface classes. The implementations of the interface classes are provided in separate libraries, specifically optimized for a given platform.
Any how, my wife is nagging me to get going for dinner. So I''ll close this off ...
Don''t take this the wrong way, I''m not attacking Java - I''m just pointing out that it is a common misconception that Java is truly "Write once, run anywhere".
Dire Wolf
direwolf@digitalfiends.com
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
www.digitalfiends.com
February 18, 2001 08:50 AM
Platform independance is very important to me. I regularly code on 3 different platforms, NT, Mac OS and EPOC. The thing with java is that you do have to debug on each platform to ensure it runs how it''s supposed to. A typical example is that threads do not behave the same on each platform, but often it can be as simple as ensuring different the different sized widgets all cooperate properly.
For me java is a blessing, I started out with a PC, but got pissed of with windows, but didn''t want linux, so I got me a mac. I could program on it straight away. Then when I wanted a laptop I wasn''t stuck with choosing some crappy intel, 2 hours battery life, slab. I got a netBook instead, with a very respectable 8 hours of battery life.
Anyway, the point I''m making is that although java is not perfect at providing platform independence it is not too bad at it. The largest problems are to do with ambiguities in the specifications of the JVM (like threading), but then you have similar problems with HTML and you can''t really say that is not platform independent.
For me java is a blessing, I started out with a PC, but got pissed of with windows, but didn''t want linux, so I got me a mac. I could program on it straight away. Then when I wanted a laptop I wasn''t stuck with choosing some crappy intel, 2 hours battery life, slab. I got a netBook instead, with a very respectable 8 hours of battery life.
Anyway, the point I''m making is that although java is not perfect at providing platform independence it is not too bad at it. The largest problems are to do with ambiguities in the specifications of the JVM (like threading), but then you have similar problems with HTML and you can''t really say that is not platform independent.
quote:
Original post by Dire.Wolf
I really have to disagree with the statement that Java is easier to port to other platforms than say C++. Given the context of this discussion I can assume that you mean porting Java games is easier than porting C++ games. Unfortunately that would be an incorrect statement. While Java is a powerful, viable language, it does not have as wide acceptance or the flexibility that C++ has when used to develop games . In order to achieve maximum performance in Java, it is often necessary to use unportable libraries or, worse yet, unportable implementations of Java ( Microsoft''s Visual J++ anyone? )
The key to developing any portable application is to separate interface from implementation. The key programming patterns used to facilitate this are "Bridge", "Abstract Factory", "Prototype", and "Proxy" - just to name a few. By utilizing these patterns effectively the main engine of a game can be developed in pure C++ (no compiler extensions etc) and can be linked to interface classes. The implementations of the interface classes are provided in separate libraries, specifically optimized for a given platform.
Hi Dire.Wolf,
I respect your argument and agree fully that when making portable code (for any language) seperating implementation and interface is very important. It is true, (and I myself has argued that) that writing games for Java needs unportable native libraries. But so do C++ games - they also use unportable libraries.
But my point is, that assuming that you use isolate all these unportable libraries behind a portable interface then it would be easier to port a Java version faster than a C++ version. This has not something to do with the libraries used (which in both cases must be completely rewritten for the new platform) but the portability of the language constrcuts themselves, for instance:
* No matter the platform the various primitive types are identical in java. This is not the case in C++.
* C/C++ compilers have many differences across platforms - java compilers don''t. Just look at many of the GNU sources you have with Linux and you will see that the code is springled with preprocessor defines to take care of variation between UNIX platforms. For a "portable" C/C++ developer it is a nightmare to stay compatible with all this compiler variations. This is much easier in Java.
But admitted, the language is not as important an issue here as the implementation/interface seperation - and with regard to this issue the advantage of Java over C++ might be deemed insignificant by some.
One point where C++ has the advantage here is that most unportable libraries today are available for C++, not Java. This means that adapting a unportable library to your engine on the new platform is less of a hassle with C++ than with Java.
In the end, I think we agree, but my point just needed a little clarification. Do we agree?
Jacob Marner
Jacob Marner, M.Sc.Console Programmer, Deadline Games
Oh, one thing I forgot. Dire.Wolf, you mention Microsoft J++ as an example of an unportable Java compiler. True,
However, this compiler does not confirm to the standard and is thereby by definition not a Java compiler. In other words, Microsoft has made some strange compiler for a java-like language but it is not Java (why do you think Sun is sueing Microsoft and making them change their implementation).
If we just stay clear of these non-working clones, then all is fine.
Firtunately these non-wroking clone compilers are rare and almost all compilers are standard conforming. With C++, it is different - actually I don''t know of any current Windows based compiler that is fully conforming on all issues as described in Stroustrup''s 3rd Edition. There might be one for UNIX, but gcc is certainly not standard conforming.
Note to all: Microsoft J++ is to be avoided!!!! I use Windows and Microsoft C++ a love both, but Microsoft J++ is a piece of junk that should never have existed. Over and out.
Jacob Marner
However, this compiler does not confirm to the standard and is thereby by definition not a Java compiler. In other words, Microsoft has made some strange compiler for a java-like language but it is not Java (why do you think Sun is sueing Microsoft and making them change their implementation).
If we just stay clear of these non-working clones, then all is fine.
Firtunately these non-wroking clone compilers are rare and almost all compilers are standard conforming. With C++, it is different - actually I don''t know of any current Windows based compiler that is fully conforming on all issues as described in Stroustrup''s 3rd Edition. There might be one for UNIX, but gcc is certainly not standard conforming.
Note to all: Microsoft J++ is to be avoided!!!! I use Windows and Microsoft C++ a love both, but Microsoft J++ is a piece of junk that should never have existed. Over and out.
Jacob Marner
Jacob Marner, M.Sc.Console Programmer, Deadline Games
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement