Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Java 2D / Re: Graphics.drawImage() composite problems on: 2007-12-18 12:55:33
I've mailed you an isolated test case Dmitri.

Thanks for your time Smiley
2  Java Game APIs & Engines / Java 2D / Graphics.drawImage() composite problems on: 2007-12-17 10:25:26
I'm trying to render anti aliased text to an offscreen buffer for caching purposes, but I'm having a little trouble rendering the cached text back to the screen. I'm drawing the strings onto a BufferedImage using the pixel format BufferedImage.TYPE_INT_ARGB and the composite function AlphaComposite.Src

When sampling my offscreen buffer I can see the pixel are stored with premultiplied alpha for some reason. That is, a semi transparent white pixel is stored as 0x7F7F7F7F instead of 0x7FFFFFFF. So my brain tells me that I should use the AlphaComposite.SrcOver composite when drawing this offscreen buffer onto another graphics object, but when doing so I get really poor results. I just can't understand what's going wrong. For instance if I draw my offscreen buffer onto a completely white graphics object i get gray edges where anti aliasing occurs. How can this be?? With AlphaComposite.SrcOver I should be getting a completely white surface.

JavaDoc from AlphaComposite.SrcOver
Quote
The source is composited over the destination (Porter-Duff Source Over Destination rule).

Fs = 1 and Fd = (1-As), thus:

        Ar = As + Ad*(1-As)
        Cr = Cs + Cd*(1-As)

So let's try a semi transparent white pixel on top of a white pixel using this formula:

Ar = 0.5 + 1.0 * (1.0 - 0.5) = 0.5 + 0.5 = 1.0
Cr = (0.5, 0.5, 0.5) + (1.0, 1.0, 1.0) * (1.0 - 0.5) = (0.5, 0.5, 0.5) + (0.5, 0.5, 0.5) = (1.0, 1.0, 1.0)

So why am I seeing gray pixels ?

My conclusion: awt's implementation of AlphaComposite.SrcOver is not functioning properly Smiley
3  Java Game APIs & Engines / JOGL Development / Re: How to make *.glf type font from True Type Font on: 2007-07-03 11:46:03
From opengl.org on using GLF:

Quote
Disadvantages
    * The .glf font file format is currently undocumented. No known way to convert fonts to the .glf format.

If you have some c++ code that can convert .ttf to .glf why don't you just use that and bundle the .glf with your java app?
4  Java Game APIs & Engines / JOGL Development / Re: Has anybody problems with Intel 945G??? on: 2007-06-15 08:20:22
Quote
Can the "No Frame buffer object support" do than a JOGL slows down to 0.04FPS in an example where the average  FPS in 100 PCS are 17FPS?
Sounds to me like the example uses a feature that is only supported through software in your driver. If the example uses the FBO extension I guess it would simply fail instead of slow down.
5  Java Game APIs & Engines / JOGL Development / Re: Render webpage on openGL quad on: 2007-06-12 22:46:05
The layout engine used in Mozilla and Firefox is called Gecko and is open source. As an alternative you could parhaps wrap this layout engine in some JNI and use it to render to a texture you could bind in JOGL?

If that is too big a undertaking you could take a look at http://jrex.mozdev.org/ which I believe is a project to do just that. Only thing is, last update was 2 years ago so I don't know how useful it is.
6  Java Game APIs & Engines / JOGL Development / Re: Bug in TextRenderer using custom RenderDelegate on: 2007-05-20 19:24:02
Quote
From discussions with Phil Race from the Java 2D team, my understanding is that if you want full Unicode support, you really need to do string-by-string caching. Apparently there are some languages like Arabic where certain glyphs behave differently in different situations so it isn't easy to render them in isolation into a glyph cache.
Yes that's indeed a major problem. I also believe certain combinations of characters will be represented by only a single glyph in some languages. These are problems I don't even believe can be solved because of the limited access to such information from the API.

Quote
If we could have essentially two implementations of the TextRenderer which are switched between with some boolean flag, where the user can indicate whether they want for example "high performance" or "high fidelity", that would probably be ideal.
Yes I agree that this would be optimal. We could limit the "high performance" renderer to only support one-to-one glyph mapping and thereby open up for all the glyph-caching-based optimizations.

Quote
Would you be willing to push your glyph caching implementation further to make it a viable alternative in this context?
I will definately be working on making a glyph-by-glyph caching renderer. My few tests only confirmed my feelings that string caching is not the way to go for games atleast. But I believe making a generic solution for the masses is beyond the scope of my current project. The best I can offer is to make my source code available when I'm done. I could perhaps commit it to the util project?
7  Java Game APIs & Engines / JOGL Development / Re: Bug in TextRenderer using custom RenderDelegate on: 2007-05-17 23:25:48
I went ahead and made a quick'n'dirty text renderer based on glyph caching and pitched it against the TextRenderer in a benchmark battle to the death!

The benchmark consisted of drawing 456 strings destributed over 8 columns and 57 rows using the default java font in 3 different cases:
1) Where all strings were identical and unchanged each frame
2) Where all strings were unique but unchanged each frame
3) Where all strings were unique and changed each frame
I did the 3 benchmarks with the default RenderDelegate and with a complex RenderDelegate where I simulated heavy effects by drawing the string 10 times on top of it self.

Results below
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
Simple RenderDelegate

All strings static and identical
TextRenderer: 542.0 FPS
GlyphRenderer: 68.5 FPS

All strings static but different
TextRenderer: ~15.0 FPS
GlyphRenderer: 72.0 FPS

All strings dynamic
TextRenderer: ~15.0 FPS
GlyphRenderer: 71.0 FPS


Complex RenderDelegate

All strings static and identical
TextRenderer: 526.0 FPS
GlyphRenderer: 66.0 FPS

All strings static but different
TextRenderer: 7.0 FPS
GlyphRenderer: 70.0 FPS

All strings dynamic
TextRenderer: 7.0 FPS
GlyphRenderer: 69.5 FPS

The results were pretty much as i expected. The TextRenderer excels in alot of static text as long as it can fit them in the backstore, but when you reach the enough unique strings each frame to triggers a clear of the backstore the FPS really takes a hit. Also I noticed sudden radical changes in FPS while testing the TextRenderer. Stuff like it being stable on 70 FPS then suddenly dropping to 40 FPS for a couple of seconds and then back up to 70 FPS.

If you want to test for yourself the GlyphRenderer can be found here: glyphrenderer.zip
Keep in mind that it's a really quick'n'dirty alteration of the TextRenderer and shouldn't really be used for anything. I also included a interface wrapped TextRenderer for easier benchmarking.
8  Java Game APIs & Engines / JOGL Development / Re: Bug in TextRenderer using custom RenderDelegate on: 2007-05-17 14:48:00
Quote
Can you suggest changes to the RenderDelegate mechanism that would make it more useful? I think it would be unfortunate if you couldn't just reuse the TextRenderer. You could allocate (and reuse) a BufferedImage in your RenderDelegate, render your text there with effects, and then draw it into the TextRenderer's Graphics context.
Yes that would be a solution but this would require more memory allocation and an extra read'n'write of pixels, and I think I'm a little old-fashioned in the way that I hate going through these extra loops because it's better OOP. Hmm also you would have to re-allocate this backbuffer on-the-fly because you can't predict how big a string you would have to render. I'm afraid I don't have a better solution myself.

But again, the main reason I think the TextRenderer is less than perfect for my needs is it's string caching scheme. Consider the extreme case where rendering a string takes 1 second: The TextRenderer would lag the game 1 second everytime it renders a dynamic string while a glyph caching renderer would lag just like the TextRenderer in the beginning of the game until all used glyphs has been cached, after which it will run totally smooth.

Quote
Please note that its string-by-string caching should provide much higher quality results than most glyph-by-glyph caching schemes. Note also that it fully supports Unicode and bi-directional text, even within the same string, which is very hard to do in a glyph based scheme.
Please specify what you mean by much higher quality. Are we talking kerning between glyphs? A glyph-by-glyph caching scheme can easily support this by creating and caching the GlyphVectors of entire strings much like the TextRenderer does but unlike the TextRenderer it would only use these GlyphVectors for positioning of the individual glyphs which are prerendered on a backstore. It's true that bi-directional text would prove a challenge, but atleast for games I don't consider this to be a concern.
9  Java Game APIs & Engines / JOGL Development / Re: Bug in TextRenderer using custom RenderDelegate on: 2007-05-17 12:39:54
Thank you for the quick fix Ken.

Quote
First, it's good to see people starting to use this new functionality
Speaking of that I might aswell share my thoughts about this with you. The RenderDelegate is a fine solution for the most simplest of effects but it just doesn't cut it down the road. I need to have access to the raw pixel data to make effects like soft shadows, outer glow and more than 1px outline. This leaves me with two options:
1) Do some heavy modification to the TextRenderer
2) Write my own
I'm probably gonna go with option 2 because the string caching mechanism you are using in the TextRenderer is really geared towards alot of simple static text (which is why it's perfect for java2d). As the complexity of the effects on the text goes op the effectiveness of the TextRenderer goes down because you are rendering much more than a simple glyph caching text renderer would.

Quote
I've checked in a fix which will show up in nightly builds dated 5/17 or later. Note that I believe tonight's nightly build will fail because our Linux box is in the process of being reinstalled, so if you need the fix right away then check out and build the source tree.
I can't pull the jogl project from the CVS for some reason. I probably messed something up in my CVS configuration, but nevermind I'll just wait for the nightly build.

One last thing i wanted to ask. When i throw the TextRenderer in debug I'm getting spammed with these messages (several every second):
1  
2  
3  
4  
Clearing unused entries in preExpand(): attempt number 0
Clearing unused entries in preExpand(): attempt number 0
Compacting TextRenderer backing store due to vertical fragmentation 0.8
 TextRenderer allocating backing store 256 x 256

Is it really re-allocating 256x256 textures everytime it writes this? If so, isn't that MAJOR overhead and should be considered a bug?
10  Java Game APIs & Engines / JOGL Development / Bug in TextRenderer using custom RenderDelegate on: 2007-05-16 23:01:38
I have encountered a rather annoying bug with the TextRenderer.

I wanted to implement my own RenderDelegate to add a simple shade and outline effect on my text, but found that the backstore got currupted under certain circumstances when my delegate returned false in intensityOnly(). I've tried my best to isolate the problem in a test case, and the result is attached this post as a java file. It apparently happens when I draw a series of long dynamic strings after which I draw a smaller string. The most frustrating thing about this is that when I enable jogl.debug.TextRenderer the darn thing works like a charm! This made me think that the TextureRenderer fails to clear it's content when in non-"alpha only" mode, and simply by showing this texture (as you do in debug mode) the backstore gets properly flushed or whatever. Anyway that was a sick theory of mine Smiley

Screenshot
Click to Play

(the text in this shot should read "Simple String")

Test case:
DebugTextRenderer.java

Does anyone else have similar experiences with the TextRenderer?

My setup is as follows

GL Strings:
 GL_VENDOR: NVIDIA Corporation
 GL_RENDERER: GeForce 6800/AGP/SSE2
 GL_VERSION: 2.0.3

OS:
 Windows XP SP2

Graphic driver:
 ForceWare version: 91.31

JDK:
 1.5.0_06
11  Java Game APIs & Engines / JOGL Development / Re: Fatal error when rendering text on: 2007-02-28 11:52:02
Sorry for posting off-topic but I must say that Ken's dedication to the JOGL community is nothing less than extraordinary. Keep up the good work!
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (28 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (53 views)
2014-10-14 00:39:48

TehJavaDev (54 views)
2014-10-14 00:35:47

TehJavaDev (43 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!