Big picture: I'm in the process of getting more acquainted with LWJGL. My hope is that by using it as a means of accessing OpenGL, I can improve the efficiency of my game's graphics, leaving more cpu available for audio processing.

Immediate question:Most of my images are procedurally generated. So far, all the tools and tutorials I've run across for displaying images assumes that a resource originates from a file. Can someone point me to the operation, or a tutorial for using a Java BufferedImage as a starting point for a Texture? I'm assuming I just overlooked this, or haven't run across the right tutorial yet.

Thought occurs to me as I write: I recall reading about stippling lines, and that there is also 2D stippling. Is that the route one takes? In other words, should I look at converting my graphic data to stippling data format?

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

@davedes - This is a cool tutorial, lots of great info in it! I've been making use of your Tutorials and of lwjgl-basics. Thanks for writing all this and making it available. It just wasn't aimed at this specific question, since that example loads a png instead of making use of an existing BufferedImage.

@RobinB - Awesome! It will take me a bit to make time and digest what you wrote, but I should be able to jump in and see what I can make of it before the weekend.

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

@davedes - This is a cool tutorial, lots of great info in it! I've been making use of your Tutorials and of lwjgl-basics. Thanks for writing all this and making it available. It just wasn't aimed at this specific question, since that example loads a png instead of making use of an existing BufferedImage.

@RobinB - Awesome! It will take me a bit to make time and digest what you wrote, but I should be able to jump in and see what I can make of it before the weekend.

Got it from the LWJGL demo and adjusted it a bit.Just copy / paste for usage, and find out later what it does

//in Photoshop, we included a small white box at the bottom right of our font sheet//we will use this to draw lines and rectangles within the same batch as our textrect = newTextureRegion(fontTex, fontTex.getWidth()-2, fontTex.getHeight()-2, 1, 1);

font = newBitmapFont(Util.getResource("res/ptsans.fnt"), fontTex);

Perhaps there is a problem with the font? When I tried to run "FontTest.java" from the same package, I get this error:

1

java.io.IOException: dataforlineHeightiscorrupt/missing:

I don't know much about fonts, but here is what comes up when I do a text display of the font file you supply with the project (limited to first five lines):

@davedes - This is a cool tutorial, lots of great info in it! I've been making use of your Tutorials and of lwjgl-basics. Thanks for writing all this and making it available. It just wasn't aimed at this specific question, since that example loads a png instead of making use of an existing BufferedImage.

Hopefully the knowledge from the tutorial will help you to upload generic byte data. There is no need for a BufferedImage (unless you also plan to display the image with Java2D). It just causes another step of copying pixel data.

Instead, you should upload the data directly to the texture as a ByteBuffer (or you can implement IntBuffer). lwjgl-basics includes a utility for this:

I forked "lwjgl-basics" to my account in github, then cloned that to my c: (windows xp OS), then made the clone the source of the Eclipse project (Juno).

afaik, I didn't open up any files except in the context of eclipse, and certainly didn't edit any of the resources. All resources bear the same creation and modification date (presumably the clone time).

I looked at the .fnt file in Notepad, and there is no blank line at the start. The text is as I showed earlier.

I'll put a copy of the files I feel might be dubious on the following URL, if you want to check them for corruption.

I included the two .png files because they aren't 'normal' images. Maybe they are correct. Here's what displays for ptsans_00.png (hard to see the white chars over the grey background):

Are these files okay? If it is a matter of decoding the .fnt file correctly...Microsoft OS "properties" just says "Opens with: Unknown application" -- no info as to char encoding. Is there a setting in Eclipse I can report back to you on how the file is being read?

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

Not sure why it is happening, I will have to look into it. In the mean time, you don't need any fonts to work with procedural Textures (or shaders for that matter) so you can just run the tests that don't include bitmap fonts.

@davedes -- Am curious what you uncover! I just did a test that confirms the crash is on the font, not the png's that come in the try--catch before the font call.

Unfortunately, my computer doesn't support shaders, so the program won't run anyway, even if we get the font file read. In fact, it seems all your tutorials and programs in lwjgl-basic require shaders. Dang. I won't be upgrading my graphics for a few months probably.

Meanwhile, just saw that the "red book" has a later chapter that discusses Images in some detail. That will hopefully give additional background that will help. Did a review of ByteBuffer today, too. I have a lot of background to fill in.

Onward...

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

The code I posted is a "software shader" -- so it should work. It just changes byte data and uploads it to a texture every frame. It will at least get you introduced to the concept of fragment shaders -- i.e. per-pixel operations -- even though it isn't in GLSL.

Also, just curious what computer and GL version are you are running? Lwjgl-basics should be compatible with GL 2.0.

My old computer also seems to insist on ATI graphic cards. We tried putting in a PCI board, a GeForce something with OpenGL 4.2, and no go. The only ATI board for sale at the shop where I usually go was $120, and "only" supported OpengGL 3.2.

At the time, I decided not to get it, figuring I'd wait to get a wholly new computer rather than spend a significant fraction on a somewhat obsolete graphics board. But at that point, I didn't realize that I didn't even have OpenGL 2.1. So maybe I need to go back and get that or a similar board.

I was guessing that for a casual game aimed at PC desktops, implementing some graphics from the most widespread OpenGL would help deliver some extra cpu. But from davedes comments, I might as well just stick with Java2D, than try and implement what I have in a with nothing better than OpenGL 1.3.

Example of what I'd like to be able to do: I use lines/rectangles to draw a "pavilion" which includes a smoke effect, made from 40 procedurally generated graphics, each with a gradation of alpha, that get overlaid. With the scene change, using Java2D, I call the following code to fade the pavilion and smoke effects:

"pavViz" goes from 255 maximum to 0 minimum which allows everything drawn in the block to fade to nothing.

If I can't do this in OpenGL except via shaders, then I either give up entirely on using OpenGL, for now, or I try to get up to the lowest common denominator that would allow this to be done somewhat efficiently. Am I correct in thinking that the minimum would be OpenGL 2.0?

But if there is a way to get a boost over Java2D and be able to efficiently change the alpha component of graphics while using OpenGL <= 1.3, then maybe I can deal with that, and be happy that the 9% users relying on "crap Intel cards" can also play the game.

(I understand the stats from that post are stale. But I don't know how far off the numbers are now. I suspect a significant number of those "crap Intel card owners" are buying into mobile rather than upgrading their desktops.)

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

Throwing in the towel on LWJGL for now. Am going to stick with Java2D.

I've just read some more about the newest versions of OpenGL, and the extent to which 'immediate mode' is considered obsolete.

It is hard enough to master all this "old style" stuff, without the disincentive of knowing that there will be yet another set of hurdles mastering the more current OpenGL. Better to come in when I'm ready to rock at the higher level.

Can't afford a new computer right now. Am just going to see what I can do within the limits of Java2D.

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

Seriously... why not give LibGDX a try like I said earlier? It should support GL10; and then you can upgrade your game to GLES20 later on with minimal changes to your code. You can still get down to the wire and learn about "raw OpenGL" if you fancy. And not only will it improve your performance, but it will allow your game to port to other platforms.

Look at it this way: For games, immediate mode has indeed been deprecated for years. But, realistically, Java2D was never even a contender. So you are stepping backwards by choosing Java2D.

Also keep in mind that Minecraft was made with GL10, as well as other successful Java games like some of Puppy Game's earlier works (unless I'm mistaken).

Libgdx also has to wait for a new computer, I think. It really slowed down Eclipse drastically, to put in all the supporting functionality. A better computer wouldn't object as much. If I give it another try, I think I will first just try running it without ANY of the Android or HTML support, just the root project and the desktop version.

I really didn't enjoy my experience with Libgdx at all. I think it is an awesome achievement and a tremendous boon to the Java gaming community, but it also kind of set my teeth on edge. Personality thing, perhaps: I also wrote my own sound engine and procedural synthesizer rather than go with existing sound libraries. (This was before and about the same time that TinySound was made which actually seems pretty good to me.)

I liked the idea of LWJGL being a thin wrapper and that I'd be able to see what was going on that was so tough and strange about OpenGL. I thought since I was able to figure out and work with much of javax.sound.sampled, I'd be able to deal, but I think it is fair to say that OpenGL is a more difficult jump.

Yeah, maybe should have pulled the trigger on that ATI card with OpenGL 3.2. Will rethink that. I have some games that I can't play any more when I replaced the old failed card with the current cheapo. Big mistake.

Anyway, I'm going to let the bruises on my head heal and my thoughts clear for at least a few days--there's lots of other stuff to work on in the meantime.

Everyone that has been helping--keep up the great work, and thank you!!

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

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