I’ve been wondering which is the ‘best’ API for me. I am choosing between this (LWJGL) and JOGL.
I want to write a 2d using this, and I will not need swing, or do I? I do not need to make swing interfaces at least.
The real question is, which is faster, and I am going to use the API for a pretty complex/large 2d rpg with tile maps,
a lot if tile rendering with .png’s. LWJGL has a sound api built-in and it doesn’t use swing which is a plus. And which is more 2D friendly?
Thank you.
-The speed is about the same.
-Rendering a some tile map isn’t much of an issue. It’s only a fart of geometry and the overdraw is low, too.
-2d stuff is about the same… they are both opengl bindings after all.
-Instead of PNGs you should use something raw. PNG uses Deflate… so does Zip/Jar. Applying the same compression algorithm twice rarely helps.
edit: I forgot… take a look at both apis and pick the one you like more.
If you go the route of LWJGL, you might want to take a look at Slick. You’ll find it very useful in getting a 2D game going.
I just had this strange urge to say LWJGL FTW!!!
Cas 
I was wondering same thing about 2 weeks ago… I searched through forums and from what I see LWJGL is better API for making games. It has OpenAL included, easy Keyboard and Mouse manipulation and some other stuff, like #lwjgl , … while JOGL is plain opengl binding as I understood. Only problem with LWJGL is that API is relatively new and there aren’t much tutorials, documentation sucks also.
Remember if you use Jogl then you have to use the JRE fullscreen exclusive mode for fullscreen display, which is buggy as hell and doesn’t work on linux (it barely works on WinXP last time I tried it).
i picked LWJGL as it has all the stuff needed for gaming, OpenGL, OpenAL, JInput, Keyboard, Mouse, all in one nice api. As well as the best IRC room at #lwjgl where the support is second to none.
LWJGL’s API is older than JOGL’s.
The documentation is sparse, but the API is so closely tied to the real thing that it works out, even for someone who’s barely bad any OpenGL exposure till now. I can just look any old OGL examples (like the NeHe ones) and adapt accordingly.
You say I should not use .png’s for tiles on a 2d map? Why not? PNG has transparency information, which I need for tile blending etc.
While, .BMP is huge in file size and I say its good for backgrounds or 3d games. Yeah .png has only 16-bit color but I guess its enough for 80x80 px tiles.
One of my major internal debates going on, is what tile size should I use. I want to support both window and full screen modes for any supported resolution.
I persoanilly would play on 12801024 fullscreen. The minmum my game will allow is 1024768 window or full screen (nothing lowers), because the player is going to need space to see ahead in the rpg.
Ok, I do have a tile map renderer that I made for Java2D, I will port it to LWJGL, and I have ran my program through various tile sizes. I am deciding between:
100x100 px
80x80 px
or something like that.
There are advantages to both larger and smaller tiles.
First of all, I notice my speed increases (fps) is I use larger tiles, because there is less to loop through on-screen.
However, large tiles provide more limited terrain showing. Like you wont see as much of a lake or something.
But smaller tiles, show more terrain, and its details, yet the stuff closer will be less detailed.
Larger Tiles (100x100+)
Provide better texture quality.
More up-close detail, more detailed grass/detail objects.
Actual map will have more running distance.
Improves fps a little bit.
Smaller Tiles (Less than 80x800)
More visible land on screen, better gameplay.
Terrain is more visible, more pleasing.
Things like lakes, trees, and environment are more obvious, may be more immersive.
Less ‘wasted’ off-screen parts of tiles rendered.
The size of the tiles will not affect the way I place housing, or objects etc. My houses, and characters will be similar size.
The size of the land matters, because it will show terrain. Like I could use 256x256 tiles, but that is stupid, because then my lake would have transitions that are retarded, and very boxy.
Each square of land will contain a certain amount of resources, etc, so keep that in mind also.
My collision detection has nothing to do with the tiles at all, my objects and house images etc will be the ones you collide with, not tiles.
The tiles you collide with will be the water blending/walls.
My map editor will let you place terrain, in a tile-based fashion. Yet, when you place housing, details like grass/shrub/trees, or weapon pickups, those items will be placed exactly where you click on the map (objects DO NOT bind themselves to tiles).
I said “something raw” and not BMP. Btw PNG supports up to 16bit… PER CHANNEL. With RGBA that would be 64bit.
TGA for example is fine for 24 or 32 bit.
Inside a compressed Jar TGAs end up at about the same size as PNGs. Because Zip uses Deflate and PNG also uses Deflate.
Choice of tile size is always a bit tricky - it’s one of those annoying decisions that you have to make up front and it a bit of a pain to change later (sure you can make your code reasonably size-agnostic, but if you change you’ll likely have to chuck out a decent chunk of art and levels).
I’ve always found 32x32 a good size, but thats usually for smaller resolutions (640x480, 800x600). For those resolutions 64x64 might be more appropriate. Personally I’d probably do a quick mockup at the target resolution (drawn without any tile size in mind), then see what kind of tile size it would chop up nicest into.
But TGA does not carry transparency data?
“TGA for example is fine for 24 or 32 bit.”
I wonder what that 4th channel is used for… o_O
it is raw data… it’s better (faster) for loading as nothing gets decompressed.
There was an interesting benchmark on this forum comparing loadingtimes between TGA (raw) and PNG (gz).
Turned out they were equally fast, because the decompression-time for PNG was roughly the same as the additional IO time required for the bigger TGA.
then I stay with png
If they are equally fast then PNG is better, displayable on web browsers and higher maximum quality of the picture (right?).
Thank you Riven.
Of course, then comes DXTn, and then all of that goes out the window. 
not until someone says something about it…
One big pro of JOGL is that you don’t need to sign the jar if you are making an Applet