Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Using JOGL's TextRenderer - Issues with multi-color text.  (Read 2067 times)
0 Members and 1 Guest are viewing this topic.
Offline Rejechted

Senior Duke


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Posted 2011-08-19 20:39:43 »

Hello, all.  We've come a long way since my last post about brightening entities, and are now working on implementing damage numbers via the TextRenderer feature of JOGL.  We're using a custom render delegate in order to provide a fancy looking outline, but I'm afraid that this is resulting in some bad things happening.



In this image you can see the enemies on the right taking four damage per tick from a "bleed" effect that draws its damage with a red color.  At the same time, I'm taking 34 "white" bullet damage, however, the '4' in "34" is being colored red as well.  I suspect that this is due to the Renderer using the same glyph vector for the entire font and not per text wrapper (a class that we built to hold information about text to be drawn).

The Render Delegate accesses the font color to draw the glyph vector in via a public static Color instance in our Text class that is updated each render call to be equal to the Color of that text.  I couldn't think of any other way to pass that color through to the Render Delegate; perhaps I'm finding out why.  Any suggestions?

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Offline gouessej
« Reply #1 - Posted 2011-08-19 21:04:31 »

Hi

Rather use a different text renderer per color. The bug you have has been caused by one of my fixes. The memory consumption constantly increases without my fixes, I cannot remove them. You could almost use the new experimental text rendering API which is really faster.

Offline Rejechted

Senior Duke


Medals: 1
Projects: 1


Just a guy making some indie games :D


« Reply #2 - Posted 2011-08-19 21:34:50 »

Can you go into detail on this new API?  We actually got unlucky and ended up with a legacy version of JOGL and are just now in the process of converting to GL2 (no shaders for now, so if the new API involves that, I'm out of luck for now.)

EDIT: Another unrelated yet equally frustrating bug:



Each of our "Text Data" wrappers has a color field as well as several others (scale, rotation, x, y) that we can adjust in our "dynamictext" via "velocities" that adjust the values of these fields over time.

When we use this to adjust the alpha of the color that is used to draw the image, weird stuff like the image above happens, almost as though calls to GL statements are being made under the hood that apply the changes to our text color to the rest of the rendering engine.   Huh

EDIT2: Seems like this bug actually isn't unrelated at all and that there's some quirk with the text renderer that prevents it from dynamically rendering multiple text objects with different colors in the same rendering cycle.  Instead of having each text object manually modify its own alpha over time, we had one global color that the renderer would look at for each text, and we slowly changed this color instead and were successful.

Seems like we need multiple renderers or this new API!

EDIT 3...

It seems like they were unrelated after all.  I now use Color.white for the first draw step in my render delegate that draws the glyph vector.  apparently this was what was causing the color bug.  

The alpha bug persists, however.

EDIT 4 (AKA I'm dumb.):

For anyone using a Color class implementation like Slick's or awt... Never use the static color object if you ever plan to alter it in any way.  For the base case of "white damage" I was passing the actual reference to the static object in Color and then altering its alpha.... thus spelling doom for every other image in our game.

Blog for our project (Codenamed Lead Crystal): http://silvergoblet.tumblr.com
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

theagentd (12 views)
2014-10-25 15:46:29

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

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

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

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

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

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

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

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

BurntPizza (45 views)
2014-10-11 23:10:45
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!