Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  What's got your Goat today?  (Read 3367 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2003-11-04 20:34:47 »

A subtle offshoot of the "game genres and Java thread":

What right now is Java doing to hinder your game development / deployment? (And of course, what might you want to remedy the situation)

Cas Smiley

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #1 - Posted 2003-11-04 20:41:57 »

It keeps inciting people to develop new projects, which I get envolved in at the cost of my own project Smiley

To remedy the situation I suggest removing the cumbersome brain-> keyboard -> computer link and just go brain -> computer. This would enable me to work faster. An extension to JInput maybe? oh, poo, thats another one of the projects I'm envolved in isn't it, doh!

what was that?, you wanted a serious thread?

oops

Smiley

Endolf

Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #2 - Posted 2003-11-04 21:47:18 »

Quite frankly it's my free time, or lack of it, that hinders my leisure development.  Java the language is powerful enough to express anything I need, Java the platform is nicely rolling out o'er the Internet, and LWJGL provides plenty of OpenGL to keep me happy.  If J2EE weren't such a damn fine set of APIs I wouldn't be busy using it to pay the bills, so I guess that's the only "failing" in Java I can point to!  I haven't had the opportunity to turn on my gaming/development machine for quite some time now.  Hell, it's not been plugged in since mid-September.

That said, I think it's crazy that we have three very powerful APIs being actively developed on this board (JoGL, Xith3D and LWJGL) and there is zero code overlap between them.  Hands up who's written a TGA loader in the last six months?  BMP?  PNG?  How about the various 3D file formats?

I've always said that LWJGL needs a standard (and versioned Wink) library to allow people to write interoperable code - currently any two LWJGL applications will have no code overlap but an awful lot of functionality overlap - but this is even more important when you look at the three APIs together.

So please, is there any reason why we couldn't agree on a single "Image" object that people can write loaders for?  A single format for holding vertex data, texture coordinates etc?  A single vector library?  I know there can be no one-size-fits-all format, but at least provide a common data model people can use to load their custom models.  Instead of every man and his dog writing a X3D loader, let's do it properly once as opposed to hacking it up hundreds of times.

I just see the same chaos that's currently slowing the Blender community down - they are resolutely sticking to a C-land memory dump for a scene file format.  Noone else can read .blend files as there is no spec for them, and it changes format with every new binary release anyway.  You have to get data out using Python scripts, and everyone - absolutely everyone - writes their own.  Result?  Everyones' loaders have missing functionality and most of them export to some made-up ASCII data format.  So people don't use Blender to create assets. :-/

Interoperability - it's a very, very good thing.

Hellomynameis Charlie Dobbie.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2003-11-04 23:10:06 »

Quote
So please, is there any reason why we couldn't agree on a single "Image" object that people can write loaders for?  A single format for holding vertex data, texture coordinates etc?  A single vector library?  I know there can be no one-size-fits-all format, but at least provide a common data model people can use to load their custom models.  Instead of every man and his dog writing a X3D loader, let's do it properly once as opposed to hacking it up hundreds of times.


I don't mind too much about writing different texture loaders for different APIs, what with core java libraries able to load .gif, .jpeg and .png with a single line of code its not a major issue, simply one of converting to a library specific format (although this is a step that should be hidden).

More annoying is writing specific vector math and geometric routines everytime. I've managed to recycle a vector math implementation from LWJGL to Jogl without too much trouble, but should i really have to myself?

Even more annoying is writing primative intersection routines again and again. Sure something like circle-circle intersection is pretty trivial, and so is AABB-AAB tests, but getting these generic primitive types to test for intersection against each other is an unnessisary pain. And thats even before i've got into convex hull vs. convex hull tests (needed for my current project, and still not implemented robustly).

At first I started coding these in a generic way, yet eventually this started hindering development too much (dupication of code etc.). Had these been in a library i would probably have done some kind of aggrigation method instead of extending the existing class.

I'm still interested in doing a generic (ie API independant) geometric math library, including primative intersection etc., however i'm no math wiz - i barely get by on my own. IMHO its the last big problem facing indie java game developers.

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

JGO Coder




Got any cats?


« Reply #4 - Posted 2003-11-04 23:15:11 »

Okay,  I'll give you mine.

Platform Ubiquity.

We've done a fine job I think, finally, of covering all the desktop issues for j2SE. Now J2SE has to go where its never gone before.

(1) Consoles.  We need a Playstation VM.  I'd liek to see an XBox VM though i realize that might be harder to make happen as its arguably not in MSFTS interest-- at least not until there is a killer game on the PS that requires it to port.

(2) Portables.  IMPO J2ME was, at best, a bad compromise due to extreme limitatiosn of the low end of the marekt.  Those limitations though are going away.  A modern VM with a subset of the J2SE libs and our game extensions aught to be possible in the near future if not immediately.


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
Offline William

Junior Devvie




No Exit


« Reply #5 - Posted 2003-11-05 12:42:38 »

The lack of producitivity solutions (like 3D-exporters for multi-textured lightmapped models, plugs to physics engines, interactive music components etc.) used to be my main goat while I was developing game-like applications in an environment where all the professional content tools were available. However, I guess the overall issue is that Java game development for the PC does not appear to be done in such an environment.

While Java's productivity is great for indies, an indie developer would have to be damn good/lucky to get enough online sales to justify the purchase of an application like Maya (100 Alien Flux) or Pro Tools (500 Alien Flux). It would sure be nice if one could make a living doing game development in Java without having to raise the cash to start a new studio or go develop for mobile phones. Maybe a game-optimized JVM for consoles is the solution, I don't know.
Offline thinker

Senior Newbie




null


« Reply #6 - Posted 2003-11-05 14:32:46 »

Quote
Maybe a game-optimized JVM for consoles is the solution, I don't know.


Heckya.. if we had a PS2 VM with interfaces to the PS2 libs that would change *everything*

Right now Java is limited from the major game market that is consoles..

....
thinker
Offline Jens

Senior Devvie




Java for games!


« Reply #7 - Posted 2003-11-05 15:47:24 »

Quote
Hands up who's written a TGA loader in the last six months?  BMP?  PNG?  How about the various 3D file formats?


For Xith3D there exists the xith-tk (tk=toolkit) project, which will hopefully host various loaders for different 3D formats in the future. Of course this is doesn't necessarily help Jogl or LWJGL.

Quote
So please, is there any reason why we couldn't agree on a single "Image" object that people can write loaders for?  A single format for holding vertex data, texture coordinates etc?  A single vector library?


There are opensource implementations of the vector library of Java3D (if that's what you need).

I don't know if the comparision of Xith3D, Jogl and LWJGL is valid. Currently Xith3D uses Jogl, but if any of the LWJGL gurus would like to implement just about a dozen classes (not much compared to the size of Xith3D) it would happily work on top of LWJGL. In fact I'd like the freedom to choose between these two APIs as a base. :-)

Of course your points are still valid, but I don't know how the projects could share code and find a common denominator. What can be reached is that each API can have a code repository and that existing code can be ported to other APIs.

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #8 - Posted 2003-11-05 18:38:17 »

Quote
For Xith3D there exists the xith-tk (tk=toolkit) project, which will hopefully host various loaders for different 3D formats in the future. Of course this is doesn't necessarily help Jogl or LWJGL.

Well, if it's written in an API-agnostic fashion with no reliance on Xith3D, it should be usuable from LWJGL and JoGL as well.  But that's not going to happen, is it? Lips Sealed

On the image-format side, there's been at least two different libraries produced for LWJGL.  Many people have written their own, and I'm sure there are versions for GL4Java and Magician if we look closely enough.  Xith-tk will probably add another one.

Quote
I don't know if the comparision of Xith3D, Jogl and LWJGL is valid. Currently Xith3D uses Jogl, but if any of the LWJGL gurus would like to implement just about a dozen classes (not much compared to the size of Xith3D) it would happily work on top of LWJGL. In fact I'd like the freedom to choose between these two APIs as a base. :-)

But that only helps people who use Xith3D - they are then able to use all the Xith-tk utilities, but what about those who are writing straight to LWJGL and JoGL?  On the porting side, I looked at it a short while ago, but realised that Xith3D doesn't run on my only currently available graphics hardware, so the idea was dropped... Sad

Quote
Of course your points are still valid, but I don't know how the projects could share code and find a common denominator. What can be reached is that each API can have a code repository and that existing code can be ported to other APIs.

Ah, but there's no standard toolkit library for either LWJGL or JoGL, so everyone would just be porting the code to their own system, which doesn't solve anything.

Hellomynameis Charlie Dobbie.
Offline kevglass

« JGO Spiffy Duke »


Medals: 195
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #9 - Posted 2003-11-05 18:45:29 »

wrt model loaders, most people seem to write them to read the data file into an "API-agnostic" data format which is then rendered into the appropraite scenegraph/engine. I guess we're just in need of classes of Face/Mesh/Frame classes?

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2003-11-05 20:31:08 »

So, there's a general disgruntlement about APIs then -- but most of these APIs are reasonably trivial to implement or copy from other bits of API. Image loaders for example should be agnostic to any rendering API.

And not a lot of people know this but the reason 3dsmax is so difficult to import is because people try and import that dreadful ASE format. Tip: it's far, far, easier to write an XML file exporter in MaxScript...

What about aspects of the language? The IDEs? The JVM? Deployment?

You know my views on the language and JVM: the language needs mapped memory objects; and the JVM needs two-stage compilation.

Cas Smiley

Offline Java Cool Dude

Senior Devvie




Java forever


« Reply #11 - Posted 2003-11-05 21:02:17 »

Quote
Hands up who's written a TGA loader in the last six months?  BMP?  PNG?  How about the various 3D file formats?


I've written all of those Wink
GIF, PNG, JPG, BMP, TGA etc..
Loaders: Quake 3 loader and animator Smiley
PS: I've written them all for JoGL first, and then ported them to both Java3D and Xith3D.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #12 - Posted 2003-11-05 23:00:03 »

I don't understand why anyone would need to write 2D image loaders... all of the formats mentioned already have loaders.  Why is anyone doing this all over again???  What am I missing here?

The 3D formats are a different story - a scenegraph API or some sort of standard representation is needed first, right?  Xith3D has a few loaders now doesn't it?

Offline kevglass

« JGO Spiffy Duke »


Medals: 195
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #13 - Posted 2003-11-06 04:30:22 »

Quote

I don't understand why anyone would need to write 2D image loaders... all of the formats mentioned already have loaders.  Why is anyone doing this all over again  What am I missing here?


Yep, JAI does all that but it creates Images/BufferedImages. Jogl/LWJGL need a buffer of pixles formatted for OpenGL. This is why I wrote a texture loader that first loaded the image with normal Java stuff then converted the image into something that OpenGL could use. I only mention this to illustrate the loading of data into some API-agnostic format (considering we're in Java I though Image would count, but I suspect Cas would disagree) and then conversion to the appropriate rendering layer.

Quote

The 3D formats are a different story - a scenegraph API or some sort of standard representation is needed first, right?  Xith3D has a few loaders now doesn't it?


Scenegraph is going a bit far, just some standard classes for Face, Mesh and Frame wouldn't probably be enough. All add in some generic class for Materials. If everyone wrote loaders to build these classes then it would be far more trivial to display these models in different renderers.

Kev

Offline princec

« JGO Spiffy Duke »


Medals: 421
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2003-11-06 08:21:25 »

This stuff's just trivial details. What's fundamentally getting in your way?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #15 - Posted 2003-11-06 08:42:50 »

Quote
What's fundamentally getting in your way?

Time, but I doubt theres a software solution to that one Wink

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

Senior Devvie




Java for games!


« Reply #16 - Posted 2003-11-06 08:44:14 »

Quote
Well, if it's written in an API-agnostic fashion with no reliance on Xith3D, it should be usuable from LWJGL and JoGL as well.  But that's not going to happen, is it? Lips Sealed


I don't think this is currently possible. There is no common base to do this or am I missing the point?

Quote
On the image-format side, there's been at least two different libraries produced for LWJGL.  Many people have written their own, and I'm sure there are versions for GL4Java and Magician if we look closely enough.  Xith-tk will probably add another one.


This may be true, but it's still better to keep things in a central place for one API, so people can use what others have already done. Btw. xith-tk is more intended to be a loose collection of community efforts. Currently the Getting Started Guide (see signature) and the website xith.org is hosted there.

Quote
But that only helps people who use Xith3D - they are then able to use all the Xith-tk utilities, but what about those who are writing straight to LWJGL and JoGL?  On the porting side, I looked at it a short while ago, but realised that Xith3D doesn't run on my only currently available graphics hardware, so the idea was dropped... Sad


Are you talking about the OpenGL 1.2 restriction? In case of problems you can always drop me a private message. Smiley

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #17 - Posted 2003-11-06 10:41:23 »

Quote
I don't think this is currently possible. There is no common base to do this or am I missing the point?
Well, developing the common base is what's required - everything falls nicely into place after that.

Quote
Are you talking about the OpenGL 1.2 restriction?
That's the badger!  The only OpenGL hardware I currently have easy access to is 1.1 only.  But there are several other requirements in Xith3D (like assumed AWT integration) that will cause problems... but I'm sure it can be done.


Okay Cas, we'll leave third-party APIs aside then! Grin (But maybe we need a new thread to deal with them?)  Let's break it down:

1. Core APIs
Networking, security, threading, IO etc are all great.  Reflection is fantastically useful.  AWT/Swing are very well designed and very stable.  Java2D has a few bugs but is essentially feature-complete as far as I can see.

2. Language
Better primitives support would be handy - I understand why bytes are signed, but that doesn't stop the idea being non-sensical.  Fine, so all primitives are signed - give us easier ways to integrate with unsigned data then.  Allowing integer operations to operate on bytes without automatic widening conversions would be nice.  In fact, it'd be bloody marvellous.

I've often wondered about adding native binary support to the language, 0b1011 and all that, but I don't think it is useful enough to be worthwhile.  You can't express a signed byte as a binary string in any way that makes sense, anyway. *shrug*

I can't comment on structs, as I've not had any burning desire for them personally.  But I do appreciate their possibilities, which is why my three votes go towards them.  (Aside: coming up on nine months, 16th most-voted RFE, and still no Sun comment... Shocked)

Generics, autoboxing, static import, enumerations and covariant return types are all going to be very useful.  Metadata we've already got (ever heard of xdoclet?), and the "enhanced for loop" just looks ugly.

In short, the language could do with a few tweaks, but is currently excellent.  And 1.5 will be better.

3. IDEs
Eclipse has a few bugs that have cost me a couple of days' work in the past few weeks.  But on the whole I've got no problem with it - the productivity gain it provides is much much more than any set-back it could cause.  I'm happy with its rate of development at the moment.

4. JVM
Well, from the user's perspective "better performance" is always a nice thing.  Not having researched this, I couldn't say what's required - caching of compiled code, GC changes, more code analysis for a shorter warm-up time, meta-information to allow it to optimise more, or whatever.  I leave the technical details of the JVM to those in the know!

5. Application Deployment
I've not deployed any desktop apps on a large scale, so really can't comment here.  WebStart looks good for network distribution, as do executable JARs for hardcopy.  I've heard call for being able to configure the JVM more, and maybe a simple JNLP-generation tool wouldn't go amiss - probably already exists for most IDEs, come to think about it.

6. JVM Deployment
We all know this could do with a boost.  However, I'm not trying to sell anything commercially to an environment I don't utterly control already, so I've personally got no problems here.  YMMV.

7. Sun
It's no secret that most current Java development is in J2EE - Sun still seem to be coming to terms with the fact that there really could be a viable games/entertainment market here.  I can't imagine the problems the GTG people must go through every day!  I hope the good work we've seen so far continues.  *cheer*


Anything I've missed? Grin

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2003-11-07 13:15:30 »

Quote
This stuff's just trivial details. What's fundamentally getting in your way?

Cas Smiley


For freetime projects, the lack of 3D data structures really is fundamentally limiting. It makes "knocking up a new 3D app" or "playing about in any non-trivial way with JOGL" a mountain out of a molehill. I spend my working day worrying about data structures, and putting lots of effort into designing API's to be future proof. I don't have the energy to do that when I get home - especially not for something that has been (re-)invented a billion times already Sad.

For commercial work, the godawful documentation from Sun is the biggest single problem. On my team, no-one would get away with putting a class into the main build *FOR GOLD RELEASE* with API docs as bad as much of Swing (and elsewhere throughout the standard libs. I am the proud owner of an eventually-fixed JDK bug "You forgot to document the following 2 methods from Class X; there isn't even a comment, and the parameters are unnamed int's so you can't tell which one does what").

EDIT: can't recall the class, but I checked the regression at the time, and remember it also had no comment in the previous TWO major releases! That's a long time for it to go unnoticed...

Yeah, mistakenly adding a class/interface to the system during dev is one thing. Screwing up the docs and making the team look like incompetent novices who don't know anything about sofware engineering is entierly another Sad.

I would greatly appreciate @deprecation for the whole of Swing (like they did with AWT Smiley).

However, all that aside, with XML-parsing and Regexp's now in standard libs, AND the most excellent NIO, AND all the stuff in 1.5 that will kill a lot of boilerplate code, I'm pretty darned happy these days Smiley. Oh, and for completeness: the JVM's are excellent. I don't think we really say this often enough, but the current crop are really fantastic, and my appreciation flies out to those who have made them thus (having developed with 1.1.4, and even some 1.0.x, I'm very appreciative Smiley).

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

JGO Coder


Projects: 2


Fire at will


« Reply #19 - Posted 2003-11-08 05:19:32 »

One of the reasons why I really like java is that it has very well structured (and I thought in most cases is complete) documentation.

A big criticism I have with many other programming libraries and languages is the lack of documentation, or when it does exist, it is badly formatted and disorganised.  Take the MSDN for example (cd or web, take your pick) - what a mess!  The GTK and QT library docs I also found lacking.  Infact about the only decent and complete documentation I have found in the C/C++ world is for the ANSI C libraries.

In stark comparison, the Javadocs are normaly complete, lightweight (no stupid images to load if you are viewing them remotally) and well worded.  If you know the name of the class and method, then within seconds you can be looking at an explanation of what the class/method does.  If they fail then there is always the Sun tutes and the million other tid bits of info about java on the internet.

Will.

Offline Preston

Senior Devvie


Medals: 4



« Reply #20 - Posted 2003-11-08 06:37:49 »

Quote

What about aspects of the language? The IDEs? The JVM? Deployment?


I like Java very much. As a former C++ programmer I think the following:
1) Compilation of Java sources flys. :-)
2) JVM looks stable and smart today. The server VM better than the buggy client VM (Win32 I mean, like Jeff told us). Compared to the JVMs some years ago I think SUN has done a very good job.
3) IDEs: I've never seen more and better IDEs for any language than for Java - many of them are even free. Personally I love Borland's JBuilder.
4) Deployment I can't comment from a finished product point of view. Bundling a JAR file for my tester (hehe) with all exes (sorry ".class"es) and most of the graphic resources however is a matter of a click (or a one liner script if you do it manually). Very smart compared to the old Win32 installer way.

What hinders...

a) I can't stand the need of dynamic casting (runtime casting) when you use collections. Mytype var = (Mytype) mycollection.get(n)
Because the type checking has to be done by the compiler. I wonder why such a safe and high level language like Java invented that at all years ago. I won't whine anymore because I see it's already being solved in 1.5 - can't wait!
b) Many PCs don't have a recent JVM. This could mean tricky situations when it comes to deploy a budget game (ie NOT on a CD, where it's no problem to bundle the JVM). However first I read that SUNs tries well to distribute a recent JVM via free CDs to users. Second more and more people have good access to the Internet so downloading 12 MB for the JRE is getting less and less of a problem.
c) Not enough spare time to program but that's off-topic.
Offline Jens

Senior Devvie




Java for games!


« Reply #21 - Posted 2003-11-08 07:14:37 »

Quote
That's the badger!  The only OpenGL hardware I currently have easy access to is 1.1 only.  But there are several other requirements in Xith3D (like assumed AWT integration) that will cause problems... but I'm sure it can be done.


You could start to write an LWJGL renderer for Xith3D, which runs with OpenGL 1.1.

Xith3D Getting Started Guide (PDF,HTML,Source)
Pages: [1]
  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.

trollwarrior1 (27 views)
2014-11-22 12:13:56

xFryIx (69 views)
2014-11-13 12:34:49

digdugdiggy (48 views)
2014-11-12 21:11:50

digdugdiggy (42 views)
2014-11-12 21:10:15

digdugdiggy (36 views)
2014-11-12 21:09:33

kovacsa (60 views)
2014-11-07 19:57:14

TehJavaDev (64 views)
2014-11-03 22:04:50

BurntPizza (62 views)
2014-11-03 18:54:52

moogie (77 views)
2014-11-03 06:22:04

CopyableCougar4 (77 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!