Actually, i''d like to say something about portable libraries. Being both a Java and a Linux developer, i know a little about this stuff. Writing a C or C++ game that is portable is not much more work than writing any game as long as you set out with portibility in mind. Generally, the installer and QA type stuff are the only things that require a seperate effort for each platform.
SDL (http://www.libsdl.org) is a good example of a library for C that allows platform independent development. ClanLib (http://www.clanlib.org) is another example of a platform independent library, this one for the more object oriented bunch. Of these two i suggest SDL, myself, though it doesn''t really fit in perfectly with the object oriented paradigm. Still, it would make perfect sense to me for someone to make a Java port of it, and i''m sure you''d be well recieved. There have been ports to MANY other languages already.
Technically, you''d still have platform dependent Java, but it''d be much better than just DirectX support. SDL supports Windows, Linux, MacOS <10, MacOSX, FreeBSD, BeOS, and possibly Solaris and IRIX, though i''m not sure about those two.
-ben.c
[java] How important is Platform Independence?
Jerry got the ball rolling, now let me continue.
Platform independence is a nice bonus to me and I have my library that I can use to access the platform dependant features transparently. And I agree with Shelrem, you can achieve platform indepency also via C/C++ if you use the appropriate library. The most important thing for me in Java (when compared to C/C++) is the less hairy syntax and the lesser errors/line ratio I get when writing code. I''m a hobbyist game writer and call me funny, but on my free time I don''t like to tackle any more difficulties with the programming than I have to. I just want to get an idea, plan a couple of pretty diagrams on paper and be done with it on the implementation side. Of course I enjoy taking up a challenge every now and then, but that is purely voluntary.
I don''t think Sun''s concentration on OS portability is that much of a hindrance for game writing in pure Java. The hindrance comes from their focus on "serious" application development. Most of the Java library components have been written to accommodate all sorts of different application requirements, but not too many of them are suitable for game development. E.g. sound support has been and for the most part still is an achilles heel.
The announcement of VolatileBitmaps (bitmaps that are stored in video memory and that can be drawn with HW acceleration) in JDK 1.4 is good news for us, but this again raises the (IMHO) true culprit of Java: Cross JDK compatibility.
The deprecation mechanism is a better way to remove old functionality instead of just chopping old features from the library immediately in newer versions. But it doesn''t remove the problem that the library is still changing. And by now we have quite a variety of JDK''s 1.0, 1.1, 1.2, 1.3 and soon 1.4. It used to be enough to write your game in 1.1 and it would work practically in all of the JVM''s, but when JDK 1.4 arrives it will most likely be in some ways incompatible with 1.1. And this incompatibility will be difficult to handle as it might come up even in the simplest of tasks like when trying to save the Properties object (save() in pre JDK 1.2 vs. store() in post JDK 1.2). Not to mention the sound support fiasco: first in JDK 1.1 you had only the unofficial "hacked" sound support, but it allowed quite easily you to write support for any audio format you liked and even do some streaming. Then in JDK 1.2 they "removed" the hack and offered the "official" way of loading only WAV and MIDI files. Then in JDK 1.3 they introduced a completely new way of handling sound. And how many games have you seen that don''t use sound? Not that many I guess.
This problem becomes even more difficult to handle if you are trying to write Applets as there has been rumours about Microsoft removing Java support altogether from the next IE version. Say what you like about Microsoft''s take on Java, but at least it offered decent multimedia API''s in the form of DirectX without the need to get your hands dirty with C/C++ (of course it is debatable which is the dirtiest C/C++ or COM/ActiveX).
What do you think? Is cross JDK compatibility a real problem or am I just seeing things?
Platform independence is a nice bonus to me and I have my library that I can use to access the platform dependant features transparently. And I agree with Shelrem, you can achieve platform indepency also via C/C++ if you use the appropriate library. The most important thing for me in Java (when compared to C/C++) is the less hairy syntax and the lesser errors/line ratio I get when writing code. I''m a hobbyist game writer and call me funny, but on my free time I don''t like to tackle any more difficulties with the programming than I have to. I just want to get an idea, plan a couple of pretty diagrams on paper and be done with it on the implementation side. Of course I enjoy taking up a challenge every now and then, but that is purely voluntary.
I don''t think Sun''s concentration on OS portability is that much of a hindrance for game writing in pure Java. The hindrance comes from their focus on "serious" application development. Most of the Java library components have been written to accommodate all sorts of different application requirements, but not too many of them are suitable for game development. E.g. sound support has been and for the most part still is an achilles heel.
The announcement of VolatileBitmaps (bitmaps that are stored in video memory and that can be drawn with HW acceleration) in JDK 1.4 is good news for us, but this again raises the (IMHO) true culprit of Java: Cross JDK compatibility.
The deprecation mechanism is a better way to remove old functionality instead of just chopping old features from the library immediately in newer versions. But it doesn''t remove the problem that the library is still changing. And by now we have quite a variety of JDK''s 1.0, 1.1, 1.2, 1.3 and soon 1.4. It used to be enough to write your game in 1.1 and it would work practically in all of the JVM''s, but when JDK 1.4 arrives it will most likely be in some ways incompatible with 1.1. And this incompatibility will be difficult to handle as it might come up even in the simplest of tasks like when trying to save the Properties object (save() in pre JDK 1.2 vs. store() in post JDK 1.2). Not to mention the sound support fiasco: first in JDK 1.1 you had only the unofficial "hacked" sound support, but it allowed quite easily you to write support for any audio format you liked and even do some streaming. Then in JDK 1.2 they "removed" the hack and offered the "official" way of loading only WAV and MIDI files. Then in JDK 1.3 they introduced a completely new way of handling sound. And how many games have you seen that don''t use sound? Not that many I guess.
This problem becomes even more difficult to handle if you are trying to write Applets as there has been rumours about Microsoft removing Java support altogether from the next IE version. Say what you like about Microsoft''s take on Java, but at least it offered decent multimedia API''s in the form of DirectX without the need to get your hands dirty with C/C++ (of course it is debatable which is the dirtiest C/C++ or COM/ActiveX).
What do you think? Is cross JDK compatibility a real problem or am I just seeing things?
I just want to state that using Visual J++ doesn''t have to mean platform dependance 
''''2+2=5 for extremely large values of 2.''''
''''2+2=5 for extremely large values of 2.''''
I have to agree with Fovster, just using Visual J++ does not mean
platform dependence on windows.. As long as you do not use any
of the microsoft specfic libraries it will be still be pure java.
War doesn''t determine who is right, war determines who is left.
platform dependence on windows.. As long as you do not use any
of the microsoft specfic libraries it will be still be pure java.
War doesn''t determine who is right, war determines who is left.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
