Jump to content

  • Log In with Google      Sign In   
  • Create Account


[java] Reinventing the Wheel, Anyone Interested?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 February 2000 - 06:43 AM

I've been aware of the problem with programming for different Java versions for quite a long time (I've followed Java from its first 1.0 alpha releases)... But just recently it hit me that I'm writing a game programming library that is supposed to allow you to program for different Java versions. That means that I should propably somehow offer a unified class library for all these different libraries, right? And after that came the obvious realization that one could actually make better (faster & less memory consuming) implementations of many of the default Java library classes. E.g. one article in Gamasutra website ponders around this subject: Dirty Java - Optimizing Pure Java. And lot of the statements made there are true: multithreading under Java games is overkill due to expensive synchronization, Unicode strings are huge and slower to process than the simple ASCII ones. So how about it, anyone interested in participating in this endeavour? We could make this library a separate package from my GameFrame library just to make it usable to larger audience, but I'd like to keep it open source so that anyone can go ahead and integrate it to their game or customize the thing to their hearts content... This project would go where no-one has ever gone and it would offer great opportunity to familiarize yourself with the dark side of Java programming: optimization. Which actually should happen before any code has been written I've got a few links (besides the one above) to sites offering Java optimization tips and tricks. I'll post them here if we get a big enough group behind this. Edited by - javanerd on 2/16/00 12:48:33 PM

Sponsor:

#2 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 February 2000 - 06:47 AM

Oops, I forgot to put the closing /A tag in the link above and the link got screwed... Here is the link again (hopefully this time it''ll work):

http://www.gamasutra.com/features/19990618/dirty_java_01.htm


#3 joeG   Members   -  Reputation: 172

Like
Likes
Like

Posted 16 February 2000 - 09:53 AM

Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).

#4 Jim_Ross   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 February 2000 - 05:43 PM

I''ll have to disagree with much of what was in that article, yes unicode is going to be a bit more cpu intensive to process, but the overhead in threads is far outweighed by the performance boost they give you. And there are unsynchronized data structures in java, you just have to use something besides Vector.

As for rewriting java source... not for me.

#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 16 February 2000 - 06:32 PM

Unicode strings are huge and slower to process than the simple ASCII ones.

I read somewhere that *they* will make dual ASCII/Unicode, but hell, i''m not sure if it was somewhere on "JavaMegaSpeedBoosterMCXIV the most reguested implementation to Java" web pages, there is many of them, too ;-)

#6 Captain Goatse   Banned   -  Reputation: 100

Like
Likes
Like

Posted 16 February 2000 - 06:33 PM

Hell, I always forget my name ;-()

#7 vince   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 03:05 AM

Unicode is not the real problem with Java strings. On most modern architectures, dealing with 16 bit characters instead of 8 bit characters is not going to break the bank.

The problem with Java strings is that they are immutable objects - every modification done to a Java String object causes a new instance of a String object to be created.

so for example the following line
String a = "one" + "two" + "three" + "four";

involves the creation of 7 string instances:
"one", "two", "three", "four", "onetwo", "onetwothree", "onetwothreefour"

But Sun has a solution in the JDK - the StringBuffer class. If you are doing heavy string manipulation, you should use the StringBuffer to store intermediate results. It''s syntax is not as convenient but it performs better.

The overhead of threads is more of a platform-specific and VM-specific kind of thing. There are different implementations (green/user and native), and each platform has its own overhead for thread creation.

Generally, the overhead of synchronization also depends on the VM''s implementation. Clever implementation of monitors can make the overhead of the noncontested case as little as one instruction.




-vince




#8 Jerry Lynn   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 04:20 AM

I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.

But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.

Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.

Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.

Just my humble opinion.


#9 Jim_Ross   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 04:50 AM

If you''re going to do it, I would suggest finding a site that is devoted to custom java implementations and post about it there. I''m not saying don''t post it here, I''m saying that it might help keep you motivated. Something like www.gnu.org or jfa.javalobby.com

#10 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 05:02 AM

quote:
Original post by joeG

Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).


"STL-like package"? Are you referring to the collections framework that is included with Java 2 or is there another package thingie I haven''t heard about?

Datastructures are a good starting point. I had in mind some of the classes in java.util and java.lang packages that are essential to game programmers, but have been changed between JDK 1.1 and 1.2.

#11 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 17 February 2000 - 05:24 AM

quote:
Original post by Jerry Lynn

I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.

But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.

Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.

Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.

Just my humble opinion.


Hmm, your message really gives me something to think about.
But if you look at the way the Java VM has changed during the last five years, it really hasn''t. SUN has kept it their goal to NOT change the VM if it isn''t mandatory. The bytecode is still the same, just some class file flags have been added, but even then backwards compatibility is preserved. So if I wrote my own set of classes from the ground up I think I could rest assured that they''d work on the future Java VM''s.

The idea of these replacement classes would be to make the game programmer free of the runtime JDK version problems. Of course that would mean settling to some subset of the JDK classes, but that is to be expected. What this would mean is that the programmer wouldn''t have to worry about the tiny (and oh so annoying) differences between the JDK classes.

The idea behind GameFrame (as it is provided) is to offer easy access to game programming and to enhance the experience under some runtimes. That means I''m targetting the hobbyists, beginners and the like that don''t want to spend half a year just making some graphics engine to work. And believe me as a hobbyist myself, half a year is quite a short time for this kind of thing and you need one more half-a-year to make sound work both under JDK 1.1 and JDK 1.2. Many of my own projects have ended prematurely just because I got fed up with making the low level things to work. The only reason GameFrame exists is that I haven''t been aiming at making a game, but a library and I''ve had my previous source codes to draw upon. Trying to reach both targets (game+engine) is too heavy requirement for many. Doing a game is difficult task in itself (idea development, planning, graphics, sounds, logic etc.).

If someone wants to use GameFrame with e.g. Magician or Java 3D they can do that if they just get inside the source code, but that really requires a whole different level of knowledge. As is required by the aforementioned APIs anyhow. It would be next to impossible to implement as flexible game library that one could use it with everything under the sun (no pun intended ).

#12 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 05:26 AM

Oops, my turn to forget my name. Arch@on you''re not alone with this

#13 joeG   Members   -  Reputation: 172

Like
Likes
Like

Posted 17 February 2000 - 07:53 AM

Yeah, that's what I meant: "collections" Okay, so you want JDK-cross compatability, right? If the amount of dependencies of these collections classes is minimal (i.e. helper classes, inner classes, etc...), than it should be easy to just include those classes in your distribution, allowing you to use what has already been made. But say that the extra dependency classes will make the distribution too large. Then I guess I'd understand the need to redo the wheel.

BTW I am still interested in the project ('course I don't want to spend too much time on it either )

JoeG

Edited by - joeG on 2/17/00 1:55:35 PM

#14 Jerry Lynn   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 February 2000 - 08:12 AM

The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM

#15 Wrathnut   Members   -  Reputation: 345

Like
Likes
Like

Posted 18 February 2000 - 04:38 AM

Hey JavaNerd, I am just a newbie, but I like the sounds of your project. I don''t know if there really is anything I can do but if I can help you I''d be glad to.



-The beatings will continue until morale improves!

#16 joeG   Members   -  Reputation: 172

Like
Likes
Like

Posted 18 February 2000 - 07:11 AM

Just e-mail me if you are going to do this project.

BTW I already have some Java data structure classes based on the publisher Bailey's Java book. Can't think of its name right now. Vector, Queue, Stack, Binary Tree. They are all structured together very nicely. I think the best part of the project will be figuring out how all these 'different' classes will work together: i.e. some generic interfaces and classes.

Keep all of us informed,

JoeG

Edited by - joeG on 2/18/00 1:11:48 PM

#17 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 09:00 PM

Great! It''s good to know there are some interested persons out there. I''ll have to delay the startup to next weekend, but I''ll inform you then (via eMail).

#18 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 10:21 PM

quote:
Original post by Jerry Lynn
The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM

Yep, you definitely sound a "bit" pessimistic but then again I''m often a "bit" too optimistic.

But I''ve just got to say that many of the classes I''m talking about are not interdependent. E.g. Vector and Properties are quite stand alone classes. Vector uses arrays internally which in my opinion might not be the fastest choise (because array access is so slow under Java). Properties has changed inbetween JDK versions annoingly. These are just two classes, but they are good examples of what is has gone wrong IMHO with Java. It has grown to be a Jack Of All Trades and thus many of it''s classes aren''t that usable for game programming or aren''t usable for multi JDK (1.1 - 1.2 - 1.3) programming.

I chose the "black box" approach as it really is the only way to approach making of several implementations of the same thing. So my game programming library doesn''t allow the user to subclass the concrete implementations. Heck, the user doesn''t even know which implementation the application is going to use at runtime. But that is just the beauty of it, you can have several (even native) implementations specific to different platforms and get the benefits of increased speed or fullscreen graphics etc.

The original reason why I started with all these different implementations was that I just wanted to have fullscreen graphics and ended up doing an Asteroids emulator that used different sound & graphics engines under JavaSoft JDK 1.1 and Microsoft Java 3.0. Then Java 2 came around and I noticed that the sound API had been changed (from the application point of view) and I had to implement a sound engine for that also. And so I noticed that maybe I should do all this stuff in some generic way and publish it as a simple 2D game programming library for the masses.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS