No C++ game that Java cannot do (Chris Melissinos)

General Discussions
#21

Java will flourish in the indie scene provided we get some help :wink: Hint hint.

Cas :slight_smile:

#22

[quote]Re: No C++ game that Java cannot do (Chris Melissinos)
[/quote]
This is blatantly false. There is one game that java will never be able to do. You know this game. Its a game that was once wildly popular with some software developers but greatly despised by others.

Yes, thats right, the old ‘Screw around with pointers until I want to pry my eyeballs out with a pen’ game well never come to the java platform.

:stuck_out_tongue:

#23

Is it necessary to embed JavaVM into the console ROM/EPROM?

Can it just be bootstrapped from the game DVD first. At least in windows javavm can be 100% zero distributed to clients. Setup.exe is not necessary procedure.

You can just copy your own installed JRE folder to cdrom, copy java app, create launchme.bat or use launcher.exe, create autorun.inf and thats it.

Consoles do require a taylored VM but then it can be distributed and launched entirely from the game dvd…right?

#24

Something like this?
import javax.playstation2.*
EE.Scratchpad.setBuffer(int[] sc1, 0);
EE.Scratchpad.setBuffer(int[] sc2, 4048);
int[] sc1 = new int[1024];
int[] sc2 = new int[1024];
Buffer rb = new RambusBuffer(3004048);
Rambus.setBuffer(rb, 0, 3004048);
//Buffer rb2 = new RambusBuffer(300*4048);
//Rambus.setAlignedBuffer(rb2, NEXT_FREE_SPACE);
int[] currentBuffer = sc1;
for(int step=0; step<quick; step++){
do some work
if((step%4048)==0){
Rambus.copyBuffer(currentBuffer, rb, step);
if(currentBuffer==sc1){currentBuffer=sc2;
}else{currentBuffer==sc1;}
if((step+1)>=quick){EE.waitOnReady(currentBuffer);}
}
}
currentBuffer = null; //it would be released with sc1 and sc2 anyway.
Unluckily for all Sony did a pretty high mess. One of a little problem is Rambus. Smart Java compiler in this case matter more than JVM on PS2.
(Async hardware momory releasing would be nice.)
A sidenote “class” EE doesn’t exist it’s just a mark for the compiler.
Of course no compiler exist.

#25

Could easily implement PS2 stuff as OpenGL extensions. Or even simply wrap it up completely in the OpenGL driver as a buffer object.

Cas :slight_smile:

#26

the2bears, I am always sarcastic, even now :o

#27

[quote]Java will flourish in the indie scene provided we get some help :wink: Hint hint.
[/quote]
I’d love to see Java flourish in the indie game scene…
And flourish in general for desktop apps/games.
Sigh.

#28

[quote]One of a little problem is Rambus. Smart Java compiler in this case matter more than JVM on PS2.
[/quote]
And if someone makes a native compiler, like gcj? Then we wouldn’t need a JVM in the console. (Of course we would need jogl, joal and jinput ports too). Maybe with this we can make games to current consoles, instead of waiting for the next generation?

#29

That above post was a source code for smart “native” compiler.

Of course you CAN’T have OpenGL, or such stuff on console, it would be slow.

#30

[quote][…]
Of course you CAN’T have OpenGL, or such stuff on console, it would be slow.
[/quote]
Nintendo’s GameCube is a console, too. ::slight_smile:

(Yes, they use OpenGL there)

#31

[quote](Of course we would need jogl, joal and jinput ports too). Maybe with this we can make games to current consoles, instead of waiting for the next generation?
[/quote]
Ehm - LWJGL would be a much better fit!

#32

Indeed. We designed LWJGL with the express intention of having it work on consoles and set-top boxes. The current generation of consoles are all easily able to use OpenGL if someone were to produce a driver (it’s been done for PS2 already).

Cas :slight_smile:

#33

Add to this the possibility that the PS3 could have OpenGL (ES?), too.

#34

Why?

#35

Having looked at both LWJGL and Jogl/Jinput I’m not entirely sure why you think that LWJGL would be a “much better” fit. In what ways?

#36

Because (at least) Jogl requires AWT to work - whereas LWJGL uses its own display architecture.
To get LWJGL running you basically need JNI & NIO and then you’re set to go.

#37

The amount of AWT required to run JOGL is just a graphics context - no more or less than LWJGL requires, surely?

#38

and the canvas & panel - and the fullscreen stuff? (which brings in the whole slew of awt stuff)

#39

Event handling, input etc. Then you need a sound architecture etc…

#40

yeah - but JInput & JOAL are independent (afaik) - so only jogl that is a problem.