Is this API for me?

[DarkMortar]

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.

[oNyx]

-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.

[Eliwood]

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.

http://slick.cokeandcode.com/

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

[princec]

I just had this strange urge to say LWJGL FTW!!!!

Cas

[Kova]

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.

[Orangy Tang]

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).

[kappa]

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.

Only problem with LWJGL is that API is relatively new and there aren't much tutorials, documentation sucks also.

LWJGL's API is older than JOGL's.

[Eliwood]

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.

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.

[DarkMortar]

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 1280*1024 fullscreen. The minmum my game will allow is 1024*768 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).

[oNyx]

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.
[...]

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.

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

[Orangy Tang]

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.

[DarkMortar]

But TGA does not carry transparency data?

[oNyx]

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

[DarkMortar]

ok, i guess it has transparency so its better?

http://www.ilixis.com/developer/tga.html

[Kova]

it is raw data... it's better (faster) for loading as nothing gets decompressed.

[Riven]

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.

[Kova]

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.

[Eliwood]

Of course, then comes DXTn, and then all of that goes out the window.

[Kova]

Of course, then comes DXTn, and then all of that goes out the window.

not until someone says something about it...

[quixote_arg]

One big pro of JOGL is that you don't need to sign the jar if you are making an Applet

[oNyx]

not until someone says something about it...

http://en.wikipedia.org/wiki/S3_Texture_Compression

Loads faster than anything else and it uses less vram (1/4 or 1/6).

The downside is that it's lossy and not suited for every kind of image.

[Orangy Tang]

http://en.wikipedia.org/wiki/S3_Texture_Compression

Loads faster than anything else and it uses less vram (1/4 or 1/6).

The downside is that it's lossy and not suited for every kind of image.

Aye, dxtn is great for texturing in a3d world, where you can get double texture resolution for the same memory. However for 2D where you want 1:1 pixel mappings dxtn just ends up reducing your image quality IMHO.

[Eliwood]

Aye, dxtn is great for texturing in a3d world, where you can get double texture resolution for the same memory. However for 2D where you want 1:1 pixel mappings dxtn just ends up reducing your image quality IMHO.

I beg to differ here. Everything I do is 2D, and I haven't noticed any noticeable quality loss, nor have my users either. Of course, it depends in the nature of the images, but for what I've used so far, it's done great. Usually, when I hear lossy, I think JPG, but this uses something completely different which seems to work out a lot better.

Take the following image, blown up to 100%. Is there a difference in the leaf? Yes, if you look hard enough. Would you notice it in game with all the action? Unlikely unless you linger around still for a long time. I leave you to decide which one is the original and which is the compressed.

[oNyx]

For pixelart it's certainly bad. But generally I'm rather impressed with the quality. Even vector stuff looks good for the most part. If you zoom in you'll see lots of color errors at the antialiased edges, but at 100% it looks fine (even at 640x480 on a 19" CRT). The reason for that is that brightness is more important than color. ClearType for example exploits the same weakness of the human eye.

[Evil-Devil]

If DXTn is not suiteable, i suggest to use RLE compressed TGAs. Works really fine for me and saves much more space than PNG ^^

[oNyx]

If DXTn is not suiteable, i suggest to use RLE compressed TGAs. Works really fine for me and saves much more space than PNG ^^

Ehm... RLE is inferior to Deflate.

[Evil-Devil]

Sure it is, but why not using all features when using tga? Most ppl will deflate it anyway, regardless to the original fileformat size.

[Juriy]

I'm also evaluating OpenGL APIs for game development.

I got strange symptoms while running LWJGL demos from the site.

After WebStart loads my CPU load jumps up to 100% and stays there no matter how simple the scene is. I've tried running demos at different workstations - all shows the same effect. Am I missing something or 100% load is another "price for crosspatform"?

[oNyx]

You can lower the cpu usage with throtteling. Without any throtteling even while(true); will result in 100% usage.

However, 100% usage isn't really all that unusual for games.

[princec]

Yup, what oNyx said. Where possible, one can throttle frames rendered to the monitor refresh rate; but if you're just interested in getting fillrate/throughput performance figures, one runs without throttling to see what the maximum possible FPS is. Like most of the demos.

Cas