Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
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]
  ignore  |  Print  
  PS3 and GCJ  (Read 7490 times)
0 Members and 1 Guest are viewing this topic.
Offline danielmd3000

Senior Newbie





« Reply #30 - Posted 2005-11-30 02:53:17 »

[...]
That is why the idea of a VM is so good to me, and if there was faster hardware to make startup time (the areas where VMs still show disadvantages vs Native).
[...]

Startup time could be masked in this case. Eg you could start showing the loading screen and progress meters (as a static image) prior to actually starting the vm. Once the vm is loaded you can continue to draw it yourself. The felt startup time would be zero then. Wink

For Desktop java games i actually don't see a problem with the VM startup time, even Native games have load times...
What i really dislike is the 30sec that i have to wait to get NetBeans to start  Tongue
Offline danielmd3000

Senior Newbie





« Reply #31 - Posted 2005-11-30 03:02:50 »


I don't want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3.

Actually, you don't.  You just thought you did.  Cool

 I hope I've helped clear that misconception up.

JK

I have to agree with Jeff on this one,
You really don't want an AOT or a VM for that matter. Why? Because PS3 specs are never going to change that much, so to run an unnecessary layer of abstraction on top of an architecture that is never going to change does not make much sense performance wise, “cut the middle man”.

Traditional Game programming is all about knowing the design of the system and squeezing every ounce of performance out of the components (well in theory  Roll Eyes ), if you use a VM you need to have a complete compatibility and more than that optimization on all platforms, looking at the actual panorama of desktop VMs that is not the reality and IMHO it is an utopia.

So porting companies can rest assured that they will have loads of work porting from platform to platform, for the next decades.
Online princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2005-11-30 10:16:48 »

Traditional game development is f*cked. Budgets are wildly out of control and increasingly the industry is doing everything opposite to the way every other enterprise attempts to work.

For consoles to continue into the next decade they must consolidate on APIs such as OpenGL and DirectX and abstract away the funny to-the-metal features of the hardware. It is simply not going to be commercially viable to have to completely port games to different platforms.

The start of this trend can be seen with XBox, which shares its APIs with Windows. That one simple act of using DirectX as the core rendering library meant that simultaneously developers could get a huge headstart developing for the console and Microsoft were able to punt that console out fast and grow its numbers quickly.

A VM doesn't make a great deal of difference to the overall equation - it'll just slash a few percent off the overall schedule. But a common API without crazy hardware programming will have a significant impact on the business.

Sony ought to concentrate on getting OpenGL onto the PS3 rather than Java.

Cas Smiley

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

JGO Coder


Medals: 3
Projects: 1
Exp: 14 years


Luke...END OF LINE


« Reply #33 - Posted 2005-11-30 21:12:59 »


Sony ought to concentrate on getting OpenGL onto the PS3 rather than Java.

Cas Smiley

Correct me if I'm wrong, but OpenGL is the tech of choice for PS3.

-Chris

Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #34 - Posted 2005-11-30 21:24:22 »


Sony ought to concentrate on getting OpenGL onto the PS3 rather than Java.

Cas Smiley

Correct me if I'm wrong, but OpenGL is the tech of choice for PS3.

-Chris


That's what I have heard - or at least something "OpenGLish" - whatever that means

Online princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2005-11-30 22:51:05 »

This is what I've heard too but until I see it I don't believe it Smiley PS2 JVM *cough*

Cas Smiley

Offline danielmd3000

Senior Newbie





« Reply #36 - Posted 2005-11-30 23:29:14 »


Sony ought to concentrate on getting OpenGL onto the PS3 rather than Java.

Cas Smiley

Correct me if I'm wrong, but OpenGL is the tech of choice for PS3.

-Chris


The last information that i have is that PS3 will use OpenGL ES 2.0 with extension more info about it http://www.khronos.org/opengles/2_X/  with cg for shader (since it is an nVidia chip).

I know i had more information on that, but i guess i don't have it bookmarked  Huh
Offline Jeff

JGO Coder




Got any cats?


« Reply #37 - Posted 2005-11-30 23:39:29 »

We need to be careful when we talk to seperate J2SE and J2ME as tpoday theya re very doifferent beasts.

Furthermore you need to destinguish between J2ME/CDC and J2ME/CLDC.  What you really are talking about is J2ME/CLDC.

(Technically, J2ME/CLDC isn't even Java by the Java VM spec as floating point i opstional in J2ME but required by the JVM spec.)

The initial crop of J2ME/CLDC devices were probably the worst possible environment to try to run Java code.  No memory, slow processors, highly inconsistant hardwware.  Ina  very real sense, no J2ME/CLDC program COULD be :"signficantly complex" and thus frankly it brought all of the potnetial weaknesses of Java to the fore while removing most fo its benefits.

What J2ME  people generally see still lags behind the desktop badly in Java technology HOWEVER this is changing as those devices grow into the more capable CDC profile. which is much closer to true desktop Java.

CDC or CLDC that's just the profile,

Incorrect.  CDC or CLDC is the J2ME family, literally the definition of the VM.  Profiles live above that.  MIDP for instance, is a profile. CDC is designed for very very resource constrained dveices and thus is a minimal VM.  CLDC is designed for the next wrung up and thus is a much more complex and faster VM ebcause the resources are available to create such.

J2SE is designed for top end devices where the resources are availabel to do a maximally compelx and maximally fast VM.


Quote
the VM implementations are always going to differ

Your point?  As long as they all meet a common specification, the implementation details should be fairly irellevent.

Quote
CLDC is here to stay for a long time.... and even wend CDC devices start to overtake, that will only bring more fragmentation to the market, so basically you end up programming like a low-level programmer

In what way?

Today much of J2ME is written like C code because of space considerations.  Thats really the only reason.

Quote
(the fragmentation problem is never going to go away)

This is an assertion not an argument.

Quote
for much worse performance,

EDIT: This line deleted because it failed the "punk-bastard test."

We see no such performacne penalties on the larger machines.  As the phone gets larger it will inherit all the performance tricks that larger platforms use today.

I already know of one manufacturer that is in planning for a phone with PSP level capabilities.  Thats more the enough to run a version of hotspot.  Our CDC VM today gets 85% of the performance of Hotspot and will run in mid range devices such as you will see in your pocket VERY soon.

Quote
the java high level abstraction brings nothing of value,

Pardon, but then what are you doing here?

Most everyon here doing serious games has seen great improvements in their productivity and code correctness in moving to Java.  Thats why we're here.  As I say, why are you?

Im about ready to classify this whole thing as "troll bait" and move on.

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 danielmd3000

Senior Newbie





« Reply #38 - Posted 2005-12-01 00:52:04 »

Ok let's get things clear Jeff, by the way i don't get all this forum aggressive behavior, but it is the nature of the beast...

I called it CDC/CDLC profile because  you called it a profile "...grow into the more capable CDC profile. which is much closer to true desktop Java." i thought you understood what i meant, as i understood what you meant by those words it would have been very easy for me to simply say INCORRECT the CDC is not a profile (but i believe that would have been a trolish thing to do since a VM alone cannot be used to run applications), anyone can go to http://java.sun.com/j2me/index.jsp and read all the wonderful definitions for the acronyms that we use:

The Connected Device Configuration (CDC), developed within the Java Community Process (JCP), is a framework for using Java technology to build and deliver applications that can be shared across a range of network-connected consumer and embedded devices, including smart communicators, high-end personal digital assistants (PDAs), and set-top boxes
http://java.sun.com/products/cdc/index.jsp

I work in the J2ME space for the past year, so i am pretty familiar with all the definitions and really don't like to spend my days telling people that oh that is not a profile that is a framework, that is a profile, that not all phones have the same abilities, what JSR are, that phones can use the KVM or Hotspot, etc... i usually refer them to some nice webpages like this one: http://java.sun.com/products/cldc/faqs.html

About platform fragmentation i am only too familiar with it, and that is why i stated that the fragmentation problem is not going away just because phone makers will ship more capable phones in fact with so many extensions and abilities it is only going to get worse and companies like http://www.tirawireless.com/default.htm are here to stay and no amount of memory in phones is going to change that.

"Today much of J2ME is written like C code because of space considerations.  Thats really the only reason.", now this is a statement form someone that clearly does not code in the J2ME world,  space is a problem, but only one of the many, device capabilities/abilities, device differences (screen size, keypad, etc...).

There are already phones capable of playstation+ level from sonyEricsson and others, that use optional JSR184, OpenGL ES from companies like MascotCapsule or Hybrid, there are even phones that have hardware acceleration i don't see your point, the fact is that a GBA system is much less powerful than the current generation of phones but you can do allot more (games can perform better) with it that you can with a mobile phone, at least using only the MIDP profiles (1.0,2.0 gamecanvas etc...) so there is a performance problem that you cannot get around since you have to code for the java platform (this has been discussed by John Carmak on his blog http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates).

"Pardon, but then what are you doing here?" Well i am here to discuss this is a forum is it not? I am not here to be a Fan boy of Sun or Java for that matter, i am here to participate

My only point in my previous post was to say that there is always going to be tweaking to do because of all these extensions and optional packages the first generation of phones used the MIDP1.0 profile and that brought extensions from nokia, and many others it was insufficient, the second generation with MIDP2.0 (gamecanvas, etc...) was still not sufficient, CDC devices that have the personal profile, foundation profile, personal basis profile... blah blah blah are still insufficient, manufacturers are now used to breaking standards and creating extensions (so basically what we have now, and will continue to have is a similar situation to the Microsoft JVM vs Sun JVM on the desktop) and this is BAD, Sun should provide more than CDC hotspot and RI they should do what they did on the desktop space a JRE so that we have on the ME space what we have on the SE desktop space, that is where java brought value, it is not bringing that to the Mobile space and it is going to hurt developers on the long term.

"Im about ready to classify this whole thing as "troll bait" and move on" you are free to do so, i will do the same.
Offline zero

Junior Devvie





« Reply #39 - Posted 2005-12-01 02:16:21 »

Correct me if I'm wrong, but OpenGL is the tech of choice for PS3.

Quote from: opengl.org
Sony confirms PlayStation 3 to use OpenGL ES
July 25, 2005  At Sony Computer Entertainment's PlayStation meeting the company president showed off the development kit hardware and confirmed and the choice of OpenGL ES as the graphics API in order to facilitate rapid developer adoption and content creation. The Sony Playstation 3 will be using OpenGL ES for the 3D graphics API, NVIDIA's Cg shader language and tools (CG compiler, FX composer, ShaderPerf and PerHUD), and the development tools will also incorporate support for the COLLADA format for art asset interchange so that developers can share interactive 3D art among multiple platforms. This also opens the possibility that after the PS3's launch, the platform could be opened to general development to anyone, not just game developers. (In marked contrast to Xbox).




I don't want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3.

Actually, you don't.  You just thought you did.  Cool

I hope I've helped clear that misconception up.

I hope so.  Roll Eyes From your statement the memory consumption is higher than for a C++ applciation, because Java uses late binding.  That makes sense, but I believe an AOT (like JET) should not produce that much different codepaths due to optimization for different hardware since the one in a console should always the same - don't know how much this saves. Futher, the mentioned total memory consumption, e.g. that meassured by the mentioned benchmark, hasn't anything todo with the program itself but with run-time functionality, Java provides. What excactly do you mean by 'run-time functionality'? From the language point of view or has this something todo with the provided packages (awt,..). If the latter is the case, fine a java 'console edition' without them would be the solution (such LWJGL), but if not: how to reduce the total memory consumed ?


.. This means that most dispatach points cannot be inlined because you cannot gaurantee one and only one destination. Hostspot does what we call "agressive inlining."  If, at run time, there is one and only one class loaded that can meet the target rquirements we go ahead and inline it.  We then watch what is loaded and, should another be loaded that can meet the requirements we back out the inlining.
That's very interesting, indeed I don't know that much about how the JRE can inline code. Unfortunately, I don't understand how to determine a state, from which on only one destination is possible. You said if 'there is one and only one class loaded that can meet the target rquirements'. Are target requirements the Type of the reference point to an Object ? (Number n = new Interger(0); <- in that case 'Number')


Does the mean an immutable array will never be inlined ? Take the following case:

1  
2  
AnyClass[] array = ..;
List<AnyClass> constArray = Collections.unmodifiableList(Arrays.asList(array));


constArray.get(0) -> Collections.UnmodifiableList.get(0) -> Arrays.ArrayList.get(0) -> array[0]

if that canot be inlined, because two classes with the List Interface are loaded: Collections.UnmodifiableList and Arrays.ArrayList. Thus it probably cannot be optimized, right?


Now, I really hope I understand something wrong  Sad

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

JGO Coder




Got any cats?


« Reply #40 - Posted 2005-12-01 22:57:39 »

Ok let's get things clear Jeff, by the way i don't get all this forum aggressive behavior, but it is the nature of the beast...

Non-factual assertions generate assertive responses.

Questions and a willngness to learn generate non assertive responses.

Quote
I called it CDC/CDLC profile because  you called it a profile "...grow into the more capable CDC profile. which is much closer to true desktop Java."

A full definition of a J2ME profile is a VM definition (CDC/CLDC) and a sofwtare spec (eg MIDP, PBP.)  Thsoe specs are referred to as Profiles in official J2ME termi nology.  (The P at the end of both in fact stands for PROFILE).

A Profile however always defines a specific VM underneath it as part of its spec.  Thus when someon says "MIDP" they are implying CLDC.  When someone says "PBP" they are implying CDC.

Quote
i thought you understood what i meant, as i understood what you meant by those words it would have been very easy for me to simply say INCORRECT the CDC is not a profile

And you woudl have been wrong because you misunderstood the meanings of the words.

The statemenbt "a CDC profile" is perfectly correct,.  PBP *IS* a CDC PROFILE.  So for that matter is PP.    They are Profiles defined ontop of CDC.  MIDP *IS* a CLDC profile, it is a profile defined ontop of CLDC.

This does NOT mean that CDC or MIDP alone are profiles.  They aren't..

Is that clear enough?

Quote
anyone can go to http://java.sun.com/j2me/index.jsp and read all the wonderful definitions for the acronyms that we use:

The Connected Device Configuration (CDC), developed within the Java Community Process (JCP), is a framework for using Java technology to build and deliver applications that can be shared across a range of network-connected consumer and embedded devices, including smart communicators, high-end personal digital assistants (PDAs), and set-top boxes
http://java.sun.com/products/cdc/index.jsp

And not a profile.  Thank you for making my point for me.

Quote
i usually refer them to some nice webpages like this one: http://java.sun.com/products/cldc/faqs.html

And i usually try to explain to them where they are wrong and play RTFM only as a last resort.  Since you have the FM links I guess here I won't need to.

Since we're throwing around credentials, I workd on J2Se 1.3 and then did a year in Sun's J2ME group.  I led a J2ME JSR effort. Im still at Sun doing Java related technologies. Can we stop with that silliness now?

Quote
About platform fragmentation i am only too familiar with it, and that is why i stated that the fragmentation problem is not going away just because phone makers will ship more capable phones in fact with so many extensions and abilities it is only going to get worse and companies like http://www.tirawireless.com/default.htm are here to stay and no amount of memory in phones is going to change that.

Well thats a more complete statement. Not encessarily 100% correct, but more complete.

Go look at the JSRs in progress,.  There is a major effort by the phone comapneis right now to build a rich standard.  the options, such as 3D support are also being standardized (eg the OpenglES JSR ongoing right now.)

Will they all be idnentical? No.  Will they converge to be more similar? Likely as the marekt matures.  The same thing happened in PCs if you are old enough to remember that.  More importantly as the phones become more sophisticated and more powerful compute devices hiding the differences will becoem more possible.

A Mac is'nt much like a PC hardware-wise, but somehow, they can run the same games if written in J2SE.  I suggest you ruminate on that some.

Quote
"Today much of J2ME is written like C code because of space considerations.  Thats really the only reason.", now this is a statement form someone that clearly does not code in the J2ME world,  space is a problem, but only one of the many, device capabilities/abilities, device differences (screen size, keypad, etc...).

This does not lead to C like code as I am defining it . Perhapse I should have been more sepcific and said "structured code in a small number of classes."

The rest are porting issues. Not unimportant buit not causes of un OO programs.

Quote

around since you have to code for the java platform (this has been discussed by John Carmak on his blog http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates).

Yup and he is wrong.  Why he is wrong has been gone over here many times and I don't feel like rehashing it but it comes down to the fact that is he is ignorant of any Java technolgoy but CLDC/MIDP and thus cannot see where it is headed.

And you ignored all my attempts to explain the same to you.

GO write BREW.  Its clearly what you want to do.


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 danielmd3000

Senior Newbie





« Reply #41 - Posted 2005-12-02 01:36:26 »

You just don't make any sense, btw i also code in Brew (got a problem with it?)

I am just to good damn old/tired/bored  for all this fanboy crap, ignore me i will ignore you and we both can live happy.
Offline Jeff

JGO Coder




Got any cats?


« Reply #42 - Posted 2005-12-02 20:33:09 »

You just don't make any sense, btw i also code in Brew (got a problem with it?)

"I must confess, a man hears what he wants to hear and disregards the rest."
Paul Simon, The Boxer

Come on back when you are willing and ready to learn.





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 Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #43 - Posted 2005-12-02 20:56:03 »

To Jeff and Daniel - I am hung like a horse so nahh nahh nahh Cheesy

Seriously guys - I think the converersation has gone beyond logic and degraded into an old fashioned pissing match -  Perhaps it's time to either get back on topic or close the thread.

Offline ChrisM

JGO Coder


Medals: 3
Projects: 1
Exp: 14 years


Luke...END OF LINE


« Reply #44 - Posted 2005-12-02 21:02:28 »


Quote

around since you have to code for the java platform (this has been discussed by John Carmak on his blog http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates).

Yup and he is wrong.  Why he is wrong has been gone over here many times and I don't feel like rehashing it but it comes down to the fact that is he is ignorant of any Java technolgoy but CLDC/MIDP and thus cannot see where it is headed.


I will only comment on this piece of the conversation.  For all the ranting that John made about Java, you will notice that the DOOM RPG was programmed and delivered to the market  on J2ME and BREW. Apparently, it WAS good enough for him to use.....

http://www.doomrpg.com/n.x/Doom%20RPG/Home/Screenshots

-Chris

Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #45 - Posted 2005-12-02 21:08:37 »

If I had the time I would love to take the Q3 code and convert it to Java just to show JC and the other doubters, that Java is more then ready for prime time games.  The Q3 engine is old now, but that makes the comparison even more valid, because the newer engines rely much more on the video card for the latest and greatest effects and less so the CPU (relative to todays hardware).

Offline Jeff

JGO Coder




Got any cats?


« Reply #46 - Posted 2005-12-02 21:14:48 »

To Jeff and Daniel - I am hung like a horse so nahh nahh nahh Cheesy

Seriously guys - I think the converersation has gone beyond logic and degraded into an old fashioned pissing match -  Perhaps it's time to either get back on topic or close the thread.

Thanks V but, baring any more pissing at me, I'm done.

Oh and I'm happy for you, more so for your wife/girlfriend Cool




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 #47 - Posted 2005-12-04 04:51:47 »

SO here in excrutiaitng detail is the right answers to all the definitional issues that came up in this thread.

(And off its parent page iare all the right answers to the performance issues that came up.)

Go. Read. Enjoy.  Learn

http://wiki.java.net/bin/view/Games/JeffOnJava

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
Pages: 1 [2]
  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.

PocketCrafter7 (11 views)
2014-11-28 16:25:35

PocketCrafter7 (6 views)
2014-11-28 16:25:09

PocketCrafter7 (6 views)
2014-11-28 16:24:29

toopeicgaming1999 (73 views)
2014-11-26 15:22:04

toopeicgaming1999 (63 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16
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!