Jump to content
Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.
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.
Posted 16 February 2000 - 06:43 AM
Posted 16 February 2000 - 09:53 AM
Posted 16 February 2000 - 05:43 PM
Posted 16 February 2000 - 06:32 PM
Posted 17 February 2000 - 03:05 AM
Posted 17 February 2000 - 04:20 AM
Posted 17 February 2000 - 04:50 AM
Posted 17 February 2000 - 05:02 AM
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 ).
Posted 17 February 2000 - 05:24 AM
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.
Posted 17 February 2000 - 07:53 AM
Posted 17 February 2000 - 08:12 AM
Posted 18 February 2000 - 07:11 AM
Posted 22 February 2000 - 10:21 PM
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
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.