The move to JOGL

Java 2D
#21

[quote]Just in case anyone is interested, I’ve moved my stuff over into JOGL from Java2D. Its here,

http://www.cokeandcode.com/astroprime

I’ve actually put together an abstraction layer which can be implemented in Java2D or JOGL, so hopefully I can always swap back if needs be :wink:

Kev
[/quote]
I’m totally new to JOGL, buy I’m interested in alternatives to Java2D.

Are you using hardware rotations in your game?

If yes, how do you replace them if you have to turn back to Java2D?

Rotations with this library are sluggish. So I don’t think there’s a real way to turn back…

Maybe I’m wrong.

#22

I use hardware rotations. I wrap up JOGL in a layer so that I can replace it with Java2D later. Rotatations in Java2D are pretty damn awful, true, but apparantly its being reimplemented ontop of OpenGL. When/If that happens I’ll switch back.

HTH

Kev

#23

Kev can you explain the theory behind wrapping JOGL in a layer so as to be able to switch between Java2D and JOGL. What does that mean exactly and how does it work?

#24

Well, I only really tell you the way I’m doing it, not sure if it could be improved or can even be considered right… but hey.

I have a central interface called a “GameFrame”. GameFrame displays a window to be drawn into. It also supports the creation of resources like Sprites and BitmapFonts. These also have interfaces “Sprite” and “BitmapFont”. GameFrame also has a callback interface for draw, allowing you to plug in a drawing object. So I have a bunch of interfaces describing all my graphics objects.

Now I implement two versions of GameFrame called JoglGameFrame and J2DGameFrame. When a start my game I instance one of these two classes but I maintain it as a references to the interface “GameFrame”. Then when I want to load a sprite I can call getSprite() on my game frame which will return me an object conforming to the Sprite interface. The sprite that is returned could be implemented in J2D or Jogl, my program doesn’t know. At this point it doesn’t matter.

Finally, in my draw() routine, I call sprite.draw(). Draw is implemented different by the J2D and Jogl versions. Logically, one draws it in J2D and one draws it in Jogl.

So, to swap between the two rendering methods, I have to change one like at the start of my code, a create an appropriate GameFrame.

If you want to see, I can post the code somewhere tonight, but its pretty simple stuff really.

Kev

PS. Damn this forum could do with a UML tool :slight_smile:

#25

Right, I was going to try and document this stuff, but since I’m not going to have time, here’s my abstraction code. The Java2D section is massively under developed since I gave up early on. The Jogl version is what I’m currently using for my game…

http://www.newdawnsoftware.com/astroprime/test/mook-stuff.zip

Kev

#26

[quote]Damn it, my problem is I don’t have anyway of testing the red box thing relyably.

Kev
[/quote]
I do though, I’ve got plenty of machines willing to spit out red boxes at me. I’ll test this out tonight and see what’s up.

#27

If you want to test for the red box thing, it’d be best to try:

http://www.newdawnsoftware.com/astroprime/test/JoglModeTest.zip

But its failed generally on some systems…

Kev

#28

I’m at work right now so I only played with it a bit, but did find one mode that caused the red box syndrome

Trying option :17
GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false
, DepthBits: 16, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum:
0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ]

surprisingly a lot of modes seem to work just fine on this machine, a dell with an Intel 82815 onboard graphics chip with 4mb ram, running default drivers. My laptop will be the true test though.

Anything allocating something other than 8 bits per component (ie 5 or 3) just results in a blank white screen.

This seems to be the best mode I’m capable of…

Trying option :2
GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: false,
DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum:
16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ]

#29

Yep, concurs with what I’ve found so far. The red textures seem to be occuring with the lack of a Accum settings.

Kev