hey there guys i am new to this forum, but im not new to java allthought im new to LWJGL, my question is bascily ... how would i load and draw a image in LWJGL ? i am not using slick and i am not going to use it either umm that really sums it all up, thanks

hey there guys i am new to this forum, but im not new to java allthought im new to LWJGL, my question is bascily ... how would i load and draw a image in LWJGL ? i am not using slick and i am not going to use it either umm that really sums it all up, thanks

Slick, or Slick-Utils? Slick-Utils really is the best way to load a image, and the license isn't hindering if you wanna sell your product at all, so that's the only thing I can recommend.

You need to convert the image for OpenGL, basically. You have to split it up in its RGB(A) components and put that in a buffer then. After that you have to flip the buffer so that it is readable for OpenGL.

yea as i am new to LWJGL and i know java pretty well i like to make my own algorithms and such i don't really have any reason other than that, im not hating on slick tho its a great engine and i have used it b4 i just want to see how i would do without it

hey there guys i am new to this forum, but im not new to java allthought im new to LWJGL, my question is bascily ... how would i load and draw a image in LWJGL ? i am not using slick and i am not going to use it either umm that really sums it all up, thanks

Slick, or Slick-Utils? Slick-Utils really is the best way to load a image, and the license isn't hindering if you wanna sell your product at all, so that's the only thing I can recommend.

2004 called, they want their texture loader back.

@Xenon: Giovanni's link should be all you need. If you don't understand something in it, you probably need to read up more on the basics of LWJGL.

Yep, glTexImage2D operates on the last texture bound, which is global state. After the first thousand times you cringe at how ugly that sort of thing is, you get used to it. Welcome to OpenGL. You think that kind of thing is awful in Java, try dealing with it in a pure functional language sometime.

I couldnt write it myself. I was raised in OOP.This whole static notion - I like to use it when appropriate, but OpenGL is crazy.

glTexImage2D pushes the data in the GPU somehow - but you still have to keep track of it... there is no Texture object which you can now use.

o_O

Better give up then? I mean, the integer texture ID you already have binded is just impossible to encapsulate in your own Texture object, along with all the relevant texture data like width, height and color channels, all of which are actually even queryable from OpenGL but a bit slow? Maybe you could encapsulate the texture ID in an Integer in proper OOP spirit?

... which makes it (in addition to helping you understand OpenGL textures, Cero ) the perfect introduction to handling data for OpenGL with buffers which is also very practical for VBOs or any kind of batched rendering.

Well its all interesting; but I never started learning OpenGL really, because I dont even want to use it directly... way too low level for me.It's one of these legacy technology, terribly designed by todays standards, that have to be used on a low level, behind the scenes; but you guys do that, and I just use the TextureLoaders and whatnot =D

libgdx uses (for most but not all backends, eg for GWT different shenanigans are involved) stb_image by Sean Barrett. It's fast, C (so works on desktop/Android), and decodes into a format suitable for OpenGL. There is a thin native layer over the stb_image stuff called gdx2d for working with the decoded image data, drawing primitives, blending, etc. This is all hidden by the Pixmap class, which has a Java API for manipulating the data and provides a ByteBuffer containing the pixels. Textures can be created with this ByteBuffer, though most often a Texture is created from a file and a Pixmap is used under the covers.

But yeah, with only LWJGL you need to decode an image to bytes OpenGL can use, which can be nontrivial depending on the image format. Often, on the desktop, AWT is used to do the decoding. I believe this is what the slick-utils does.

Well its all interesting; but I never started learning OpenGL really, because I dont even want to use it directly... way too low level for me.It's one of these legacy technology, terribly designed by todays standards, that have to be used on a low level, behind the scenes; but you guys do that, and I just use the TextureLoaders and whatnot =D

I dont hate it, its just...If I didnt want to make games actually, then fiddling around with it would be fun I guess.Well the fact that its horribly designed still stands of course.Maybe OpenGL 3+ is better, but of course I wont use it until its available on like 90%+ pcs...

Slick-Util uses Matthias' PNGDecoder, Kev's TGA decoder, and AWT for other formats. The decoders are acceptable -- it's the texture loader that makes SlickUtil a "bad" and outdated library. It doesn't support or include things you'd want to use in a modern OpenGL game -- like automatic mipmapping, non-power-of-two sizes, wrap modes, compressed textures, custom internal formats, multiple texture targets (cube maps, 1D/3D textures, arrays) etc. As far as texture loaders go, it's really just the bare minimum, and not something any serious OpenGL user should rely on.

A better texture library would support the features I mentioned earlier, as well as decoding without the need for AWT. LibGDX is pretty close, although because of its Android focus it doesn't seem too serious about DXTn texture compression or 1D/3D/arrays/etc. I have my own WIP texture library (using Matthias' decoders) that tries to include many of these features, as well as a simple DDS decoder. It might help for inspiration in your own texture loaders:https://github.com/mattdesl/slim/tree/master/slim/src/slim/texture

It mostly used to lower the amount of VRAM needed when lots of textures need to be in memory at the same time. It can also actually improve performance if your program is very limited by memory bandwidth since it trades processing power for less memory.

It's really easy to use I think, you should just change the internal texture format when allocating the texture:

If you already have compressed texture data on your disk which uses one of the compression algorithms OpenGL supports, you can load the already compressed data with glCompressedTexImage2D(), which looks works identically to glTexImage() but expects compressed data.

The different S3TC algorithms compress 4x4 blocks of pixels to either 64 bits or 128 bits. I don't know about the quality but expect to take a pretty big hit there considering the huge compression ratio. Since the algorithms work on 4x4 blocks of pixels it might be a good idea to at least keep texture dimensions to multiples of 4. The spec says that the padding pixels are undefined, which might screw up linear filtering even with clamping since it technically isn't the texture edge, but this is just a speculation.

BPTC is a newer compression mode which uses slightly more memory but has much better quality. However, it's only implemented by OGL3 GPUs, but since those GPUs generally have more memory than GPUs that don't support it it might be a good idea to choose the most advanced compression algorithm available since it's literally only a single changed parameter to glTexImage2D().

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