Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  What's the status of the JSR?  (Read 15792 times)
0 Members and 1 Guest are viewing this topic.
Offline augusto

Senior Newbie





« Posted 2002-10-17 20:50:59 »

I see that the JSR has been voted and approved (I think), but when will we see more details?

I think after you guys went to that game conference you were going to post more details or maybe even some early idea of an API.

Any new info? What's going on?
Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2002-10-17 21:18:43 »

Well, I still need to be careful what I say, guys.  Thre are confidentiality issues and I assume you want me to still be around  in the near future  Grin

We've got quite a few of the areas well defined now.  Currently some work is beign done on the physics APIs that looks very promising.

Hopefully we'll have a chance to say something more public in the not too distant future....

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 gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #2 - Posted 2002-10-18 00:29:11 »

:oPhysics APIs? Okay now you're scaring me. I thought the goal was to be something small, not all encompasing. Huh  

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline augusto

Senior Newbie





« Reply #3 - Posted 2002-10-18 00:49:03 »

You might want to take a quick peek at the JSR;

http://www.jcp.org/jsr/detail/134.jsp

The proposed specification is of a J2ME Profile that covers nine areas of game development:

1. 3D Modeling and Rendering for Games
2. 3D Physics Modeling for Games
3. 3D Character Animation for Games
4. 2D Rendering and Video Buffer Flipping for Games
5. Game Marshalling and Networked Communication
6. Streaming Media for Games
7. Sound for Games
8. Game Controllers
9. Hardware Access for Games
Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #4 - Posted 2002-10-18 06:22:14 »

Augusto,

As the owner of a company building a game, I had been tracking some of this, but for some reason, I have read JSR-134 many times and NEVER once did the "J2ME" part click until this morning.

What kind of an effect would that have on writing a game, do you think?  Actually, is there a Windows or Mac J2ME JVM?  If not, (and yes, I am inexperienced in the usages of profiles) could a profile be used using J2SE?

I especially liked the 2D and communications part.

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline augusto

Senior Newbie





« Reply #5 - Posted 2002-10-18 13:55:54 »

Quote
Augusto,

As the owner of a company building a game, I had been tracking some of this, but for some reason, I have read JSR-134 many times and NEVER once did the "J2ME" part click until this morning.


I also "missed" the J2ME part when I read about this before, guess I wasn't paying much attention.

J2ME is also mentioned prominetly in the JavaOne slides for this topic;

http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1243.pdf

(requires registration)


Quote

What kind of an effect would that have on writing a game, do you think?  Actually, is there a Windows or Mac J2ME JVM?  If not, (and yes, I am inexperienced in the usages of profiles) could a profile be used using J2SE?

I especially liked the 2D and communications part.


Well hopefully Jeff can explain that, but from what I can undestand, this stuff should work on a J2SE VM, as J2SE is a superset of J2ME.

http://wireless.java.sun.com/midp/articles/api/
Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2002-10-18 22:06:59 »

Oh boy, a question  I can actually answer without violating my confedentiality agreements.

The JGP (JSR134) is a profile.  This means that is a subset of existing APIs and/or new APIs that, together, define a complete and legally detributable Java Platform.  So, for instance, if the JGp didn't include java.sql* in its description, a JGP distribution woudl nto have to include java.sql.* classes.

Now a profile is only legal in J2ME, thus the JGP is a J2ME spec.  This does not however mean that its intended for cell phones. J2ME ius a very wide catagory.  If you look at the JSR you wil lsee it targets the very high end of J2ME-- modern game consoles and maybe some very high end set top boxes.  Its is a CDC, not CLDC, profile which means it requries a full Java2VM (but not JDK class libraries.)

You will ALSO notice that there is some ervbage in there referring to desktop systems (PCs, Macs).  Thsi is an unusual effort  in that it is intended to streatch into areas that ae traditionally J2SE territory.  Whether that is accomplished by a J2ME on those paltforms, or by a "compatability set" of libraries that are added to J2SE to make it a JSR134 super-set is soemthing thats still undecided.

But rest assured, our goals include JGP compliant programs running on the desktop.

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 jack

Senior Newbie




I love YaBB 1G - SP1!


« Reply #7 - Posted 2002-10-19 06:20:46 »

Smiley
Hello friends,

I can't find much info regarding the JGP in java.sun.com. So
please give me answer to the following questions.

1. Does the JGP makes the current full screen api in jdk 1.4
obsolete ?

2. Is the intention of JGP a full multimedia api like directx ?  

3. How is it related to various java editions (j2me,j2se). Does
it have a seperate gaming VM ?
Offline eternal_blue

Junior Newbie




I love YaBB 1G - SP1!


« Reply #8 - Posted 2002-10-19 08:51:52 »

JGP Canceled?
Offline ChrisM

JGO Coder


Medals: 3
Projects: 1
Exp: 14 years


Luke...END OF LINE


« Reply #9 - Posted 2002-10-19 14:08:28 »

The white paper that was distributed at the GameDevelopers conference will be available in the documentation section of the new site.  You will be able to get it next week.

-Chris

P.S.  No, JGP not canceled Smiley

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

Junior Member




"C8 H10 N4 O2"


« Reply #10 - Posted 2002-10-19 15:50:02 »

Jeff, thanks for the answer... but I'm still trying to wrap my head around this "profile" thing.  

Is what you are saying that I will be able to use the full J2SE set for writing my game, along with the classes for JGP, if I choose to?  Or am I FORCED to use J2ME and the JGP profile?

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline jack

Senior Newbie




I love YaBB 1G - SP1!


« Reply #11 - Posted 2002-10-20 03:16:53 »

Wink
When can we start programming using the JGP.
When will it be released for developers ?
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #12 - Posted 2002-10-20 23:32:03 »

J2ME CDC and CLDC define a minimum specification of the capabilities that a type of device must have. CLDC is geared towards palms, phones and the like. CDC is geared towards more capable boxes such as consoles and PCs.

Once you get back the capabilities you come to the profiles. The profiles for all practical purposes define the software requirements that the device must support - or in another way, it defines the APIs that must be available. There is in fact a Personal Basis profile which is pretty much a redefinition of what J2SE is - just without the bloat.

When talking about cell phones and such you're talking about CLDC and MIDP... very very limited stuff, though nonetheless pretty cool. MIDP revolves around the KVM (for all practical purposes). The KVM is an absurdly low memory requirement JVM... and it *still* can do a lot. MIDP doesn't have anywhere near the API set available in J2SE, no crypto, no JDBC, no XML parsing, no JNI, no specialized classloaders, etc. I'm a fond fan of MIDP, but MIDP has its faults and as it sits today would never work for PC games or console game .. but would possibly work on a gameboy advance if someone did the port.

So from what the JSR says and from what is clear about the architure of J2ME and its profile/unit based design - you will be able to depend on a machine running with certain requirements and resolutions. Additionally you will have a hard defined API that you can use that must be present on anything that wants to call itself JGP compliant. This doesn't mean you can't have additional .jar files to do other functions - just means that you will have some already defined APIs for (apparently) doing everything you need for game programming.

Personally I think these additions (like a physics API) should have never been defined as part of the profile because physics is a very genre specific thing, but because a profile is a standard API - you will get the JGP implementation whether you want to use it or not. Should have just been an extension IMHO. Unless, of course, the JGP is somehow violating the contract of J2ME contexts and profiles Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #13 - Posted 2002-10-20 23:33:16 »

In any event, J2ME is good stuff... I only hope that with things like the Personal Basis profile and the like, that J2SE dies a rapid death and that everything becomes a J2ME profile... as it should be.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #14 - Posted 2002-10-22 02:26:32 »

J2SE die?  That seems rather harsh..  But I get your point - it is a bit bloated.. I would like to see more partitioning into 'standard extensions'... But currently the standard extensions don't get the support they deserve..  most are still not available as auto-downloads for Java Web Start for instance.. a HUGE oversight IMHO.

Which brings me to my somewhat on-topic questions...
It seems there are similarities between 'standard extensions' and J2ME 'profiles'.  Could someone clarify exactly where each fits? How they differ? How they are similar?  How would JGP on a PC/Mac be implemented?  Could it be implemented as a standard extension on J2SE?  Or must there be a lightweight runtime for the desktop - a J2ME implementation of PC/Mac?


Scott

Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2002-10-22 06:56:38 »

It strikes me that there should have simply been a raw JVM at the baseline with java.lang in it and nothing else, and *everything* should have been an extension optionally downloaded from the JVM vendor. Now that's what I'd call J2ME. If I ruled the world.

It would help, too, if the JVM binaries were a little smaller. I noticed that it's creeping up and up in size. But then, quite a few of the .dlls in there are to support Java APIs anyway.

But mostly it would help if it were on a coverdisk somewhere Grin

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2002-10-22 17:39:46 »

Quote
Smiley
Hello friends,

I can't find much info regarding the JGP in java.sun.com. So
please give me answer to the following questions.

1. Does the JGP makes the current full screen api in jdk 1.4
obsolete ?


I'm afraid that would get into details that not onyl aren't currently discussable, but until there has been a community review aren't even final.  I think I cna say however that we ar trying very hard to nopt reinvent the wheel.

Quote


2. Is the intention of JGP a full multimedia api like directx ?  


I'd say a full game programming API (or rather set of APIs) like DirectX,  but the answer is yes.

Quote

3. How is it related to various java editions (j2me,j2se). Does
it have a seperate gaming VM ?


See my discussion above about profiles and the intent to have compatability inot the J2SE space.  I think I fully addressed this already. If not, tell me whats missing.

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 Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2002-10-22 17:42:03 »

Quote
Jsonally I think these additions (like a physics API) should have never been defined as part of the profile because physics is a very genre specific thing, but because a profile is a standard API - you will get the JGP implementation whether you want to use it or not. Should have just been an extension IMHO. Unless, of course, the JGP is somehow violating the contract of J2ME contexts and profiles Smiley


Thanks for the summation greg and good job.

As for physics we are trying very hard to give you the common tools without imposing a specific game model on you.

When we hit review you can tell me how well/poorly you thin kwe've accomplished that Smiley

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 gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #18 - Posted 2002-10-23 00:38:42 »

Which brings me to my somewhat on-topic questions...
It seems there are similarities between 'standard extensions' and J2ME 'profiles'.  Could someone clarify exactly where each fits? How they differ? How they are similar?  How would JGP on a PC/Mac be implemented?  Could it be implemented as a standard extension on J2SE?  Or must there be a lightweight runtime for the desktop - a J2ME implementation of PC/Mac?



For the sake of discussion I will try to describe how this would most likely work (though only the Sun folks could say for sure). So you have this thing called the Connected Device Configuration (CDC). Basically it would say things like the device must have at a miminum a certain amount of ram and rom. Note true physical storage is never mentioned as the interface to persistence is a little bit more abstract in J2ME (which as it works out is a very good thing). The CDC is a bit different from the Connected Limited Device Configuration in that you can assume a less limited connection to the network. So in terms of a PC or Mac, the CDC would really just say that in order for your machine to cut the mustard, you must have a certain amount of RAM. No biggie, any PC out there will fit the bill.

Next we come over to the profile is what JGP is (Java Gaming Profile). The profile further specifies the capabilities the device hust have, including resolution and bit depth as well as the input devices. The Personal profile requires that a machine have 2.5MB ROM and 1MB RAM. I would guess that the JGP will have much larger requirements than this. So now your device will be checked to see if it has these requirements (note that this is *machine specific implementation stuff* just like a JVM). Okay so now your specialized JVM (and I will guess that the JGP would use a more upgraded version of the KVM and not subject us to the pain and unpredictability that is the standard JVM and all its hotspot madness  Grin

Next will come a set of APIs. This of this part as redefining Java all over again because while there may be similar APIs in J2SE - or the same package structure anyways, you would use a different bootclasspath to signify a different set of core classes and behaviors. Thus while you may be using java.lang.String - what is being used and compiled under the covers is actually a different implementation of String specifically for this profile. Writing an entire profile (as these folks have done) is a non-trivial excerise.

So in a sense your standard extensions may or may not even be compatible with the JGP depending on how its implemented (probably not - to engineer out much of what we don't want would require some core changes to some fundamental APIs).

JGP would be implemted as a JVM (maybe the standard one, maybe the KVM, maybe something new altogether) and a .jar file that would describe is API.

Could it be implemented as a standard extension to J2SE? NO! If it were a standard extension to J2SE is would most definitely not be anything near what you'd achieve with J2ME. What you'd have is just an API in a jar and all the bloat and nastiness of J2SE coming along for the ride. Thing of J2ME as a 'second chance at doing the client side cleaner.' You wouldn't want this as a standard extension, it would defeat the whole point of doing it in the first place. In reality a standard extension version of the JGP is pretty much what Java3D provides.

Must there be a lightweight runtime for PC/MAC - yes. Unless the Sun folks cheat and repackage the standard JVM (which would be a mistake IMO... the kVM is more than capable for our tasks) - we should be looking at something that  sits on top of the kVM. However it has been said that it also rides on top of the CDC so that almost lends itself to be a much larger JVM like that of J2SE - unfortunately. What's really needed is a specialized JVM to handle gaming tasks. The other good thing would be that the kVM 's source is readily available allowing any random joe to port the core of JGP to another platform in relatively short time (the kVM is fairly standard C code).


So I've somewhat entered the realm of speculation to cover what I think they'll do, but of course I'm looking at the ideal situation - and I don't have to base my view on a timetable or budget (specifically with respect to modifying the KVM).

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #19 - Posted 2002-10-23 00:46:15 »

It strikes me that there should have simply been a raw JVM at the baseline with java.lang in it and nothing else, and *everything* should have been an extension optionally downloaded from the JVM vendor. Now that's what I'd call J2ME. If I ruled the world.


You should take a look at what J2ME provides. J2ME doesn't specify that any particular API set be available. In fact there is nothing stopping you from defining some random profile that only has that functionality provided! When I first looked at the MIDP API and looked at the API for the lightweight java gaming library I thought that outside of a few areas they are fairly equivalent and trying to accomplish the same thing. While LWJGL provides a lot more functionality (and in a way is a lot heavier that MIDP), LWJGL could quite easily be adapted to being a profile that sat on top of the KVM... kinda.... since you'd also have to modify the KVM to handle the same NIO buffer structure you want to pass to OpenGL.

Take a look for yourself and you'll see why I consider J2ME (MIDP) the last saving grace/chance for client side Java. Sun would do well to replace applets with Midlets as soon as possible. It not only would give them a cleaner (and greatly more uptodate) programming model, but it would also allow phone developers to take their wares back and forth to the PC public.

The network layer is a work of clean engineering with a focus on simplicity... as is the record store (though not quite as clean). All in all I think the MIDP is excellent.... missing some absolutely critical features through which Microsoft will rape them if they don't release them soon (sitting at CNN I have the fortune/misfortune of seeing lots of goodies coming down the pipe), but excellent nontheless.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #20 - Posted 2002-10-25 01:55:00 »

The KVM is optimized mainly for space is it not?  While consoles would benfit from this.. we still need speed.  HotSpot is optimized for speed.
In general I don't see the need for a specifc game VM, so long as there are two things available.  1) Hires timing facilities, 2) predicable GC pauses.
It would be great if instead of Thread.sleep(x); we had gc(x) - a request to garbage collect for x milliseconds.  and some way of falling back to Sleep if the collector couldn't use all that time for something useful.

When I asked if JGP could be implemented as an extension I was getting at the points you brought up:  The PC alreadys meets the JGP hardware specs and therefore you are left with APIs.  I had not considered that the VM itself would have different constraints, I guess that part could come as an improvement to the existing J2SE VM though.

The bit I'm trying to get at is that the J2ME and the Profile can't be distributed with every game anyway - at least not without making the games hardware specific and throwing away a lot of the reason to use Java.  And on the PC/Mac side of things it MAY be confusing to need several different flavours of Java.  That is, telling the user that having the J2SE JRE is not enough, you need the J2ME JRE for platform X plus the JGP..
How would such a thing be delivered?  The ultimate goal being to grab a "JGP compatible" game off the shelf and run it on any system that runs the JGP.  How will the JGP get on to the PC/Mac/X-Box/PlayStation/GameSphere/whatever?  Am I right in assuming that it makes no sense to distribute it with the game itself?
Is there a good enough reason for hardware companies to put such a thing on the machine to begin with in the case of consoles?  (Much like you see with mobile phones now.)  I don't think the console Mfg's will be ready to do something like that for a long time.  

Java really needs to prove itself as a cutting edge game platform before that will happen.  And we all know the difficulties involved with that.  Java lags the cutting edge - it almost has to.  First the new capabilities are added to the hardware (graphics card) then the native code has to be written to exploit those capabilities, then someone has to make a Java binding - preferably a standard one like Java3D... there is a built-in lag to Java supporting the 'latest' gaming hardware. [man, this is really getting off-topic]  So I'm missing how Java is going to get to the consoles.  JGP makes sense to me as a standard extension only in the sense that getting it to PCs should be much easier that way.

Offline Jeff

JGO Coder




Got any cats?


« Reply #21 - Posted 2002-10-25 20:24:58 »

2 Quick comments:

(1) KVM is an implementation, others are possible, but yes its intended for a tiny space.
(2) J2ME is much bigger Category then just KVM/CLDC, it includes CVM type VMs and its profiles, as well as JavaCard on the other end.

(I think I already disucssed where JSR134 fits in above.)

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 gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #22 - Posted 2002-10-26 01:49:10 »

Well in reality there isn't much stopping Java from getting to consoles. The issue is purely a business one, not a technical one. For example it would take the better part of the weekend to port the KVM to a gameboy advance using the Nintendo GBA Developers Kit. The question then becomes 'then what?'

As such the only companies that would partake in such a port would be Sun or Nintendo. Nintendo has shown that it doesn't really have the desire - and Sun doesn't yet appear to have the motivation and as such while the JSR will be the greatest thing to ever happen to Java from a gaming perspective - that doesn't mean that we will get console capability... Sun would have to go to these console boys and present a good business case to get the JVM in the tool chain (that's really all they have to do, because Sun can say whatever they want - if you don't build a game with an 'accepted' tool or technology - you won't be on a console).

Once its in the tool chain and developers can choose to use or not use it (won't be in this generation - that's for sure), then you may see people adopt it... though most game developers are very C/C++ centric and most of the ones that I know who've been doing it for 5+ years simply aren't interested in doing Java development. The rest simply don't see the point.

Even those who I've shown pixel shaded Cg goodness running from Java just really think of it as nothing more than a novelty. At most they are interested in building scripting engines in Java - but don't see the point of doing much else.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2002-10-26 07:58:28 »

That's because there simply isn't a point.
For a game developer to give up C++ or even C (s)he has to give up these things:

- access to any API or hardware they feel like using
- performance
- most of the canny knowledge they've acquired in another language
- several useful features in the other languages that aren't available in Java through bloody mindedness

The notional gain is one of productivity but if you're writing a game for a console you're pretty much on the bleeding edge of technology already and need to wring what you can out of them: so you will tend to spend more time coding around the limitations of Java and less time writing straight to the hardware.

The biggest killer will be performance and memory overheads. It's just simply not possible to get away with Jeode-style performance on an iPaq when you see how incredible the games are on it written in C++. Insignia have been working on that ARM JVM for a good while now and its performance is staggeringly poor. A PS2 has roughly the same poke as an iPaq but I can't see any half-playable games appearing on it with current state-of-the-art JVM technology. Quite apart from the fact the APIs will almost certainly be inadequate to extract the specific performance and features out of a PS2.

Then there's still that myth that you could write a game in Java on PS2 and just run it unchanged on GC or XBox. Apart from the fact that XBox is sooo unlikely to get a JVM on it for general use, the graphics technology is so radically different to a PS2 you'd be pretty crazy to think you could shrinkwrap the hardware under one generic API. In the end you'd have to re-write most of the code that took care of the graphics. I've already got this problem under Win32 just trying to write code to ATI or Nvidia as they've got some pretty radically different ways of optimising rendering.

As the game code is likely to be written in very generic looking C++ I'd hardly say that portability of the logic would raise its ugly head. But in the end the gulf in performance and technique will not be bridged by a clever API. It'll just boil down to one big, long, debugging and optimising and rewriting session and there goes your productivity, and all in the face of massive risk.

I may have ranted about this on the old boards but I feel like having another one Tongue

Cas Smiley

Offline sonicviz

Senior Newbie





« Reply #24 - Posted 2002-10-27 23:45:59 »

Sad...but true.

If you are serious about gamedev (which means minimising risk at all levels) why would you even bother with Java when there are already a number of high-end cross platform engines available...intrinsicAlchemy, renderware, NDL etc.

Even excellent mid-range "dirty Java" solutions such as Wildtangent now have some uncertainty due to the Microsoft/Sun JVM fiasco. Though to their credit WT seem to be committed to Java (http://devforum.wildtangent.com/cgi-bin/ib3/ikonboard.cgi?s=3dbca20724ccffff;act=ST;f=1;t=884) as their main language, though they support a lot more.

To my mind WT are showing the best and most intelligent use of Java for gaming...use it at the application level (much easier to use than C/C++) and leave the grunt work to faster native code. There are enough problems optimising the application level when developing a complex game without having to worry about low level Java efficiency.

Do you want to make games, or do you want to make game engines?

FYI...intent JVM (www.tao-group.com) has serious speed advantages over insiginia.
Offline Jeff

JGO Coder




Got any cats?


« Reply #25 - Posted 2002-10-28 03:26:38 »

There is actually a JSr that defines much of this.  (68 I believe but thats from memory.)

Basically a profile can include "building blocks".  A standard extension can be considered a "building block."

Clear as mud?

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
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2002-10-28 10:31:01 »

It has occurred to me that a Profile might not be complete without some indication of its minimum performance.

To this end you'd need some kind of nontrivial benchmark application. Bit of a problem. At least in the PC world you can vaguely state that you need an 8Mb 3D card, 32Mb of RAM and a 400Mhz processor and be reasonably confident about the performance of the game.

How might a Profile have a minimum performance rating associated with it? SPECjvm? Suggestions?

Cas Smiley

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #27 - Posted 2002-10-30 17:11:39 »

Yeah, I tried to touch on building blocks in my other posts. Basically building blocks makes it possible to break all of the Java functionality into a bunch of standard extensions and then define some arbitrary profiles that include only certain bits of Java - and that RULES! When that happens I see J2SE as either reinventing itself or becoming nothing more than a system that includes every building block.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #28 - Posted 2002-10-31 07:40:19 »

Hm, how about a J2SE JVM distro which includes the bare minimum of classes to be able to start a JVM and begin loading the rest of the classes it needs from a "provider" (ie. Sun), one by one, and storing them?

You could version each class individually and provide detailed version dependencies. Then the "provider server" would automatically be able to keep your JRE core code completely up-to-date on a micro level and the initial download hit would be very small indeed.

Cas Smiley

Offline rgeimer

Senior Newbie





« Reply #29 - Posted 2002-10-31 19:46:01 »

I thought you were knocking this idea on "the old board" because it required web access after the initial install. Did you change your mind about that?   Wink
Pages: [1] 2 3
  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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (39 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!