make a Porting: Java2D to JOGL

[alesky]

hi guys

i have a game implemented completely in Java2D,
i would like now study jogl and make a complete porting,

my game is a side scrolling shooter.
it is mainly based on  direct draw of the images using the primitive of java2D --> Graphics2D.drawImage
The engine is provided of functionality to modify color and transparent and rotation of the images,
finally i have final effect over the final image create drawing directly over it that allow my to make effect like darkness (used for example in the transition between the level etc..), send storm, rain etc....

now studding same tutorial of jogl I undestood that is completely based on a 3D concepts.
So to create a flat 2D word i have to:
A) create a 3D word with the  Z coordinate constant and use the Orthographic Projection
B) to print an image create a rectangle/square and load the image as a texture over it

is there another approach "more 2D" that this one, or this is the correct path that i have to follow to reach my target?
thanks guys


 

[ra4king]

That's the correct general gist of it, so you're fine!

[Mads]

Nope. Orthographic and textures on polygons is where it's at. It's not too hard if you're using immidiate mode to render. That's slower as well, but I can't imagine it being a problem if you're coming from Java2D.

Games published by our own members! Check 'em out!

[ClickerMonkey]

This might get flamed by JOGL lovers, but I would recommend going to LWJGL instead. I used to use JOGL but I always had non-GC pauses in my game and I could never figure out why... I switched to LWJGL and the pauses went away and my FPS was even up to 50% faster.

[Mads]

This might get flamed by JOGL lovers, but I would recommend going to LWJGL instead. I used to use JOGL but I always had non-GC pauses in my game and I could never figure out why... I switched to LWJGL and the pauses went away and my FPS was even up to 50% faster.

I prefer LWJGL too, but that's personal preference. I don't think we can reach an agreement on this, on JGO, and that's completely fine

[princec]

Even I wouldn't take that advice as gospel LWJGL is rarely more than a few % faster than JOGL, so it was likely you were just doing something slightly wrong with JOGL there.

Cas

[StrideColossus]

Nope. Orthographic and textures on polygons is where it's at. It's not too hard if you're using immidiate mode to render. That's slower as well, but I can't imagine it being a problem if you're coming from Java2D.

I'd recommend using immediate mode initially as well - it's deprecated in favour of more 'modern' techniques using VBOs, shaders, VAOs, etc.  but it is a much simpler learning curve, you can always refactor later if required.

Immediate mode is also considerably slower but I imagine that's less important than getting to grips with OpenGL for you right now.

[Mads]

Immediate mode is also considerably slower but I imagine that's less important than getting to grips with OpenGL for you right now.

How much, relative to "fancy" methods as well as Java2D? Do we have any charts?

[princec]

A couple of years ago... I was limited to about 1000-1500 sprites @ 60Hz using immediate mode rendering. Now I can do 25,000. Obviously just ballpark figures but you get the general gist.

You might think that 1000 sprites is a lot but we regularly use a couple of thousand in our games and they "look" quite "simple", no?

Cas

[20thCenturyBoy]

When you say "Immediate Mode" is that like the old NeHe tutorials on gamedev.net? Where you just define your vertices and output them?

Games published by our own members! Check 'em out!

[StrideColossus]

When you say "Immediate Mode" is that like the old NeHe tutorials on gamedev.net? Where you just define your vertices and output them?

Yes.

i.e. methods such as glBegin/End, glVertex, glNormal, glColor, etc.

[20thCenturyBoy]

i.e. methods such as glBegin/End, glVertex, glNormal, glColor, etc.

Ah the old Redbook OpenGL 1.1 style?

Is it really worth learning that stuff only to have to discard it when using "modern" shader techniques?

[princec]

Yes. Because it's easy and it works with fewer of those "my screen is just black" moments.

Cas

[StrideColossus]

Ah the old Redbook OpenGL 1.1 style?

Is it really worth learning that stuff only to have to discard it when using "modern" shader techniques?

I would suggest yes it's definitely still worth it.  Getting something up and running with the older APIs is much quicker and easier - most of hard work is done for you (e.g. gluLookAt to set up your projection, matrix management, etc) meaning you can focus on your particular game or application until you're comfortable with OpenGL.  Once you've reached that point then I suggest you have a look at re-implementing using vertex and index buffers, VAOs, shaders/GLSL, etc. because (trust me) there's a lot of stuff to get to grips with - even just to get your texture-on-a-quad - and you won't have 'wasted' much (if any) effort should you decide to switch to the non-deprecated (i.e. core profile) API.

However I'm thinking from the perspective of someone who's implementing an OpenGL app from the 'ground up' (which is my personal interest), as an alternative you might want to investigate using a higher-level library/engine such as libgdx* which builds on top of an OpenGL library (such as LWJGL) and provides a much richer API, there are plenty of tutorials and links in this and other forums.  Guess it depends on your particular interests.

* EDIT: Actually a better suggestion might be Slick since I believe it's specifically orientated towards 2D OpenGL, not my sphere of knowledge but might be worth checking out?  http://www.slick2d.org/