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?

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

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

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

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

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.

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.

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.

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.

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.

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"?

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org