I have made a GUI that has multiple components with it and now I need to populate those components with text.
My specifications:
Preferably uses LWJGL (OpenGL)
Isn't exceptionally complicated
Doesn't use any other external libraries (bar the LWJGL library)
Has to be fairly optimised, it will be used a lot on a very fps intensive GUI
Has the possibility of being anti-aliased?
Possibly have the ability to run on most major Operating Systems
How could I do this in java?
I would consider using SVG, and particularly Batik for managing the fonts. I am doing quite a lot with this myself and it's somewhat of a learning curve. I would be prepared to start simply and find out what particular features you need before worrying about performance. But until you give clearer ideas I'm not sure we can help much more
You have three options: Bitmap fonts, texture fonts and vector fonts.
Bitmap fonts are only useful if all you want to do is render text for a 2D GUI. However, you can't do antialiasing if you use Bitmap fonts. On the other hand, they're pretty easy to use and they're quick to render.
Texture fonts allow for antialiasing, but again they're best for 2D GUIs. If you want to render text in world space, you'll get lots of artifacts because of the texture scaling that's taking place. To use texture fonts, you have to create a texture atlas that contains an image for each character of a particular font that you want to use (usually you'll want to restrict the character set to ASCII, otherwise your texture will be too large). You can use AWT to create a rectangular image that contains all the characters you need. Then you can render a character by rendering a quad with the appropriate texture coordinates for that character. It is advisable to use a luminance alpha texture so that you can blend it with the color you want the text to be in. You can optimize this by using display lists for each character and possible for each string, but you'll run into problems with kerning etc.
Vector fonts give you the best results if you want to render your text in world space. They will give you perfect font rendering incl. kerning, but they're more expensive to render. My usual approach is to create a path (using AWT) for each string that I want to render, flatten that path and then trace it using the GLU tesselator. This will give you a bunch of triangles, triangle strips and triangle fans which you can put into a VBO for optimal performance. Then you can render that string by issuing the appropriate rendering commands for the VBO. You can optimize this further by using a display list for each string. That way, you will only have to send one command per string, but of course this will still be more expensive than the other methods.
Related
I want to draw Strings in my Libgdx game but i cant use BitMap Fonts because the scale of my game is to smal to use them.
It sounds like you mean the scale of your viewport is too small to show fonts correctly. There are two solutions. The first is better for legibility while the second is quick and dirty.
One is to use a second viewport for the UI that has an appropriate scale for text. You would first call gameViewport.apply(), draw the game, and end the batch. Then use uiViewport.apply() and then draw the UI. The downside with this method would be if you want to draw text that aligns with moving objects in the game, you would have to use the two viewports to convert coordinates. Otherwise, this is the ideal method to get a crisp looking UI. Ideally you would use a ScreenViewport and select a font size at runtime based on the screen dimensions, either by shipping your game with multiple versions of the font at different scales, or by using FreeTypeFontGenerator.
The second method is to scale down all your text. First call bitmapFont.setUseIntegerPositions(false) do it won't round off positions to integers. Then call bitmapFont.setScale() with however much you want to shrink it to fit in your game viewport.
There is a gdx-freetype project:
https://www.badlogicgames.com/wordpress/?p=2300
and it uses TrueType fonts as source to generate bitmap font on the fly.
Not sure how stable this is - didn't use it.
I'm using JOGL (OpenGL for Java) for my application and I need to draw tons of strings on screen at once and my current solution is far too slow. Right now I'm drawing the strings using TextRenderer using the draw3D method and for even a moderate number of strings (around 300-500), it just kills the FPS. I started messing with drawing text onto the object textures, which is much faster, but there are a few problems with it. The first is that allocating all those textures requires a lot of memory. The second is that I need to find a way to size the texture so its only as big as the string and then map it to the object without stretching. The problem there is that all these thousands of boxes are using a single model being rendered with a call list. I'm not sure its possible to change the texture mapping for each object in that situation.
I don't mind if the text appears flat or 3D, it just has to be positioned in 3D space. I would prefer to render the text in the highest quality possible without sacrificing too much speed, since readability of the text is the most important part of the application. Also, nearly all of the strings are different, there aren't many duplicates.
So, my question: Am I going down the right path with drawing the strings on the textures, and if so, how can I overcome those 2 problems? Or is there another method that would suit my needs?
Depending on exactly how TextRenderer works - you might be able to use display lists to batch up your text drawing commands.
If TextRenderer works by having a texture of individual character glyphs and piecing together a string a glyph at a time: it'll be fine. just bookend your text drawing code with glNewList and glEndList. Once a list is defined, just use glCallList to use it.
If however, TextRenderer works by drawing complete strings into a texture and using one quad per string - display lists may not work. If the strings in one batch do not all fit within TextRenderer's cache, it will delete the least-recently used one to reclaim some space. Display lists will only recreate the OpenGL calls made, and so the work done by TextRenderer to update the string cache texture will be lost and you'll get incorrect output. From a quick scan of the source, I suspect that TextRenderer works in this manner.
To summarise: Display lists will greatly speed up your rendering, but will only if you don't overflow TextRenderer's string cache texture and don't use the TextRenderer after the display list has been defined.
If you can't meet these constraints you're going to have to go a bit hardcore and write your own text renderer that renders glyph-by-glyph - it'll then be trivial to cache the output geometry and extremely quick to re-render. There's an example of such a system here, with the tool to create a font here. It uses LWJGL rather than JOGL, but the translation between the two will be the least of your worries if you want to integrate it - it's meshed with the texture management etc.
I was planning on drawing text with opengl and couldn't figure out how I would get it to draw/build the actually string. If I wanted to draw "Hello World", I can create a texture for each letter and draw them all but I know there's got to be an easier way of "pulling" out the correct set of characters all at once and then drawing just once. I figured I could get all the separate textures, add them into a vertex array, and then draw the vertex array with only one call to draw, but that seems inefficient. Any tutorials that cover this particular section?
Assuming that you want just the 2D letters to appear at a certain point in 3D space, the normal way to do this is the one you describe. Well actually I would create a single bitmap for the entire string and then draw the bitmap into the scene. It's not really inefficient - in fact it's very efficient, because you can cache the bitmap of the text, and only have to calculate it once instead of each time the scene is drawn. It seems like a lot of code for something simple, but OpenGL is often like that.
I'm written an Android loader and renderer for my Bitmap Font Generator (CBFG) that does what you are talking about.
Android source to load and display the fonts is at http://www.codehead.co.uk/cbfg/TexFont.java
The tool to create your own the font files is at http://www.codehead.co.uk/cbfg
Basically, all the font glyphs are arranged on a single bitmap and the letters are drawn by rendering a series of identical quads changing the UV coords each time to display the required letter.
Hope that helps.
I've googled around everywhere, but cannot find much for rendering strings to textures and then displaying that texture on a quad on the screen. Can someone provide a run-down on the process or provide good resources that describe how? Is rendering strings to textures even the best method for displaying text in an Android OpenGL ES app?
EDIT:
Okay, so LabelMaker interferes with alpha blending, the texture (created from a PNG with a transparent background) now has a solid black background, rather than a transparent background. If I comment out all the LabelMaker-related code, it works fine.
UPDATE:
Nevermind. I took a look at the code to find that LabelMaker was disabling blending after drawing the labels.
I think this is what you are looking for.
If you don't want to use GL extensions you need to create the font as a bitmap and then create a class to convert that string into quads that you can draw.
I use this method with the 2 fonts in my game. I have a class that takes a wide texture with all the letters evenly spaced, and a string that matches the image, then uses lookups on the letters to find out how far in the bitmap it should go.
Your other option is to render your text to a offscreen bitmap using android, and then bind the text as a texture. This will let you use androids built-in font processing and rendering to create texture-based fonts.
The second method I have not used yet, but I have rendered google maps to a offscreen canvas and then bound the bitmap as a GL texture, so doing it for text should be much simpler.
If you are planning to have modifying string data in a gl loop you need to really worry about StringBuilder too, because it causes GC and performance issues. I hardcode all my strings so it doesn't allocate, and all my rapidly numbers are done through a second draw function dedicated to drawing changing numbers without using string-builder.
I'm writing a basic sprite engine for my own amusement and to get better aquainted with Java's 2d API. Currently I am making use of large numbers of separate .png files with transparent backgrounds to represent the various sprites and different frames of animation that I need. Most 'real world' game development projects seem to make use of 'sprite sheets' which contain multiple sprites or frames of animation within a single file. Also, rather than making use of native image transparency support, people often nominate an arbitrary colour that does not appear in the sprite pallette to be the transparent colour. How does one manage a file like this programatically?
how do you know where one sprite
starts and the next begins
how do you deal with transparency
There may be other factors that I've not thought of here, so I may add to the list above as I think of things or as people make suggestions (please do so in the comments).
I currently use XML files generated by a simple sprite editor that store the sprite as a collection of (optionally animated) poses, which are in turn a collection of frames or cells. Frames store per-frame information like the x and y offset of the frame in sheet, cell width and height, and any transformation (resize/rotation/hue/etc.). Poses store individual frames and animation information (speed, for example), and a pose name to easily identify them in the program (hero.pose = sprite.pose["standing_right"]). Sprites serve as a document root to hold several poses, such as a pose for each facing direction.
A less flexible alternative I used earlier was to specify fixed sizes for cells and sheets and calculate frame offsets and sizes based on these values (e.g. width is always 32 pixels, so third sprite is at 32 * 2). Later I started specifying these dimensions in the file name (e.g. sprite_name_32x64.png) for sprites that don't fit the fixed cell dimensions. I like the new approach more, especially with a simplistic editor that fills most values for me and allows me to use sprites as templates for other sprites.
I use the alpha and transparency information stored in PNG images directly so I don't need to worry about storing it elsewhere, although other approaches would be to pick a fixed value per sprite and store somewhere, use the leftmost pixel in the pose if you know it's always empty, use a specific palette entry if you're using those, sprite masks, or what have you.
Not about java but generally you can make your all sprites in the same size. Thus, you will be able to generate your sprites in your game (or app) with a simple for loops.
But for different sized sprites there may be problem for spritesheet size (it can be larger than expected). So you must define an xml or json file for your spritesheet to find your sprite images in your code. You can use sprite sheet editors (there are plenty of them, I'm using Sprite Master) for quick and easy way to generate sprite sheet and coordinate datas.
Make your sprite sheet knowing the size and number of each sequence.
Grab a buffered image of your sheet and use something like this:
currentframe=spritesheet.getSubimage(x, y, w, h);
Your x and y will change based on the frame you are on. Keep the width and height the same to make things easy on yourself.
Forget trying to keep the entire game on one sheet. It's nuts and hard to manage. Use a new png for each animation sequence. If you are anal about saving space only create moving right animations and just flip the buffered image real time to move left.
Java will read png files with the alpha so don't worry about the transparency colour. Draw everything in pngs. Use Photoshop or Gimp.
Search google for java image TYPE_INT_ARGB
Well, since most of them are custom, those details are up to the implementor.
You'd generally have the file start with header information that contains the details of height/width and encoding, transparency, etc.
A lot of the time things are in one file because it is very expensive to open/read multiple files compared to open/read one file. Many game engines use zip or "ziplike" files with 0 compression to treat a single file as a filesystem.