While debugging these a potential issue with the JavaAgent was discovered:It is possible that multiple threads load classes at the same time, which also means that these thread execute instrumentClass in parallel.I did not add a synchronization to that method (to prevent potential dead locks with ClassLoader locks) as MethodDatabase might need to load additional classes (eg the base class) - so instead I protected the shared hash maps individually.This might cause redundant work (if multiple threads analyze the same class) - but each thread should produce the same results or a warning is generated.

So I suggest to use the JavaAgent only while developing - and keep an eye on the console for warning

For a more complete font support you can take a look at the BMFont format which also supports kerning.The TWL Theme Editor has a font generator tool (Tools -> create font) with 3 different rendering methods:- freetype2: best quality- AWT drawString- AWT vector: most effects

TWL has a color picker widget (in addition to many other useful widgets). You can test the color picker in the TWL Demo or in the TWL Theme Editor (both are webstart links). The editor is completely written using TWL.

MatthiasM has written some extremely awesome texture loaders spun off from TWL that don't require TWL itself. It supports BMP, JPG, PNG, and TGA (no GIF that I can see). It's asynchronous, so you get a callback when the texture is loaded and you can keep on doing your own thing in the meantime (like displaying a loading screen or downloading other resources) without having to manage any threads.

Well - it supports 3 modes of operations:- fully managed by using the TextureManager.getTexture() function - this one is asynchronous (eg loads in a background thread)- synchronous using Texture.loadTexture() function- using the TextureLoader* classes to get the bytes directly

The asynchronous TextureManager method will render a transparent 2x2 pixel texture when the desired texture has not yet (or could not) been loaded.Textures which are not used for some time are also unloaded.

And there is no need to manage threads - the only thing you need to do in your main loop when you want to use the TextureManager is:

You should not use getClass() for resource loading as this will break when the class is sub classed. Use MidiPlayer.class.getResource() to have a fixed starting point.Also make sure that the resources are in the same JAR as the class you use as a base reference otherwise you could get issues depending on how the class loaders are setup.

Fields take only the required amount of storage - so a short is smaller then an int. Java will always align fields to a multiple of their size - so that you don't get unaligned access. Access to these fields is not slower then other fields.

On the other hand if you put small data types on the stack or as method parameters then it needs additional instructions to enforce the desired overflow behavior.

I was considering using TWL for the window system in my game but after I noticed that the jar was like 800kb I reconsidered , the whole game is currently 500kb and seeing as it's an applet it can't take forever to download on slow connections...

Ever heard of pack200 & lzma ? Even with only gzip the file size is below 200KB - with lzma it should be below 150KB 172KB. And LWJGL's AppletLoader directly support pack200 + lzma or gzip.

I did not write PNGDecoder to be used with BufferedImage - it is intended to be used with OpenGL and it decodes into formats understood by OpenGL. And for that it is probably the fastest decoder (and it is small).

As for the byte order - just look at the Format enum (eg RGBA, BGRA etc).

Using an identity hashmap for wrapper classes together with auto boxing is a guarantee for failure. As long as your keys are within the cached range it looks like it will work. But once you use keys outside the cached range (mostly 0..255) you get different objects for the same integer.

So if you use identity hashcode you must use ==. Then you can't use auto boxing.

If you're using JOGL, never mind TWL, but iirc it integrates with swing/awt nicer than LWJGL, so that would be the direction to look in.

TWL can also be used with JOGL. You just have to write (or port) a Renderer implementation.TWL's rendering & input subsystem is completely abstracted. The provided renderer for LWJGL is a simple GL11 based renderer. With libgdx you can run TWL also on Android. If you want you could even render it using AWT :DD

And the main benefit of this PNGDecoder is the ability to decode into a NIO buffer in OpenGL compatible formats. This avoids unnecessary memory copies. To support NPOT textures it's also possible to specify the stride.

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