Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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  
  Text2D quality problem  (Read 3583 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Posted 2006-07-29 12:00:42 »

hi

We have a quite serious Text2D quality problem. On some backgrounds the characters look really ugly. I first thought, this could be solved by not drawing them transparently ind setting the color through the Coloring Attributes of the Shape3D, but drawing them in the desired color. But it didn't do the trick.

Does anyone have an idea or know the solution? Matthias and Goliat, you're famiiar with Textures and Text2D. Do you know anything about that?

Marvin
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #1 - Posted 2006-07-29 12:31:25 »

The glitches only happen when you resize the textures. When they are displayed 1:1 they look absolutely perfect. That's why we should make new textures when the HUD is resized, and not resize the existing textures. That's also why one image for button theme is not enough. 9 is what we need (topleft, top, topright, right, bottomright, bottom, bottomleft, left, center).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #2 - Posted 2006-07-29 13:10:14 »

The glitches only happen when you resize the textures. When they are displayed 1:1 they look absolutely perfect. That's why we should make new textures when the HUD is resized, and not resize the existing textures.

Do you mean, the fonts look ugly when the underlying texture is resized? Sounds strange.

That's also why one image for button theme is not enough. 9 is what we need (topleft, top, topright, right, bottomright, bottom, bottomleft, left, center).

Yes. That's true.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Goliat

Junior Devvie





« Reply #3 - Posted 2006-07-29 13:42:00 »

can you specify 'ugly' ? ... i had no problems in scaling the Char2D's ... (which is why i created no scaling method)
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-07-29 13:51:04 »

The glitches only happen when you resize the textures. When they are displayed 1:1 they look absolutely perfect. That's why we should make new textures when the HUD is resized, and not resize the existing textures.

Do you mean, the fonts look ugly when the underlying texture is resized? Sounds strange.
Huh no that not what I mean. When a texture sized 512x512 appears 520x520 on the screen, it looks strange cause it's resized by the graphic card. The only way to avoid that is to make it display truly 512x512, or to create a new texture with the appropriate size.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #5 - Posted 2006-07-29 13:59:56 »

can you specify 'ugly' ? ... i had no problems in scaling the Char2D's ... (which is why i created no scaling method)

Please have a look at HUD3DTest and you'll see the effect. And the effect is only well visible on small fonts (font-size 15 or below or shinked ones).

Huh no that not what I mean. When a texture sized 512x512 appears 520x520 on the screen, it looks strange cause it's resized by the graphic card. The only way to avoid that is to make it display truly 512x512, or to create a new texture with the appropriate size.

Well, the fonts aren't scaled on the HUD. They're displayed in the exact texture size.
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #6 - Posted 2006-07-29 17:40:21 »

magnification and minifications filters are handled via texture paramters in OGL, if the textures become ugly when you get closer to them, its probably because your using the ugliest (but fastest) method to obtain the pixel from lower resolution texels, and thats GL_NEAREST.

Read up on GL_MIN_FILTER and GL_MAG_FILTER

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline bohdan

Junior Devvie




Java-positive...


« Reply #7 - Posted 2006-07-30 23:55:44 »

Hi!

Just my 5 cents. I had a look at HUD3DTest and what I see, to my opinion has nothing to do neither with scaling neither with filtering. BTW, base_lever_linear is applied as "mag" and "min" filters in Character2D, so filtering is definetely not the problem here. Scaling, even if it does - still will not create that kind of picture...

There is something different. Those "things" we see around charatcers - they are artifacts, this is not what was actually drawn as character - it seems to be just improper result of blending! You can see that it is not distortion, the color "corona" oround characters exists and that color is not the color of character...

So, I think transparency have to be considered, blending and whatever things migth be regarded to it.

Bohdan.

EDIT: @Marvin: Try to remove backgrounds for your "panel1" & "panel2" (totaly remove, no default) in HUD3DTest and you will see that those corrupted labels suddenly looks just fine!!
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #8 - Posted 2006-07-31 03:08:58 »

EDIT: @Marvin: Try to remove backgrounds for your "panel1" & "panel2" (totaly remove, no default) in HUD3DTest and you will see that those corrupted labels suddenly looks just fine!!

Yes, I know. But this is not an option. There must be the possibility to display a characater over a background.

btw. Thanks for your troubles.
Offline Goliat

Junior Devvie





« Reply #9 - Posted 2006-07-31 10:29:02 »

ah .. i guess i know what you mean ... i had the same problem in the text2d demo ... i guess it is due to the way java2d renders the characters on the image ...
i guess they are antialiased somehow which results in a conora ...

greets ... Golly
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bohdan

Junior Devvie




Java-positive...


« Reply #10 - Posted 2006-07-31 12:38:34 »

EDIT: @Marvin: Try to remove backgrounds for your "panel1" & "panel2" (totaly remove, no default) in HUD3DTest and you will see that those corrupted labels suddenly looks just fine!!

Yes, I know. But this is not an option. There must be the possibility to display a characater over a background.

btw. Thanks for your troubles.

No-no, there is no problems to display the character over the background. Do the folowing change to your HUD3DTest and you will see that:
instead of panel1.addWidget(infoText, new Point2f(10, 82));
just add that label to the top "container": this.addWidget(infoText, new Point2f(10, 82));
(and regulate location a bit so the label is over your panel1)
and you will see it is just perfectly displayed!!! and over all the underlying images/backgrounds.
So if that label is in panlel1 OrderedGroup - you have artifacts, if it is simply out of it (but the screen looking same way) - perfect. So, I still think there is something to do with maybe blending order or sorting etc.. - well I don't know.
You will probably will be laughing but once when I have that problem I switch off the DepthTest on ceratin things - and everything become perfect. So there is nothing to do with your HUD, there is more general problem, and if you want I will prepare for you test-case, where the problem showing up and the way to fix it - but it will be up to you to figure out why it helps  Wink, because I have no clue Smiley Hopefully today if I will have time.

ah .. i guess i know what you mean ... i had the same problem in the text2d demo ... i guess it is due to the way java2d renders the characters on the image ...
i guess they are antialiased somehow which results in a conora ...

greets ... Golly

Yes, you have antialiasing ON in you character2d, but it is good thing. At some stage I used a lot of java2d drawing things and never have a problem with that. Try to switch antialiasing off and you will see that the problem still persist. It is more a guess, but as I mentioned above, simply putting that characters to different node in the scenegraph - resolves the problem totaly.... And now the question is - why  Huh Huh Huh What makes suddenly a difference...  Undecided Something to do with Xith transparency/sorting/orders/blending etc.. don't know...
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #11 - Posted 2006-07-31 18:12:43 »

Thanks for your huge reply.

I worked half the day on this problem. But I can't solve it. It seems to have something to do with a background image in the "wrong" group. When I don't give the Panel a background image but add an Image Widget to it which has a lower z-index than the Label, it just looks great. But I can't see the difference for xith.  Huh

I tried to directly add a Quad and a Text2D node to a TransformGroup and even then the shit started to happen.
Offline bohdan

Junior Devvie




Java-positive...


« Reply #12 - Posted 2006-07-31 19:42:47 »

Thanks for your huge reply.
You are welcome Smiley
I worked half the day on this problem. But I can't solve it. It seems to have something to do with a background image in the "wrong" group. When I don't give the Panel a background image but add an Image Widget to it which has a lower z-index than the Label, it just looks great. But I can't see the difference for xith.  Huh
Yes, that's what I was surprised with too... Shouldn't do any difference... or maybe we just don't understand something...

Just want to point on another, I think pretty explanatory example (as what is the story about), just to destruct attention from the Labels, because it is more general problem.
In you HUD3DTest change:
Widget william = new Image(40, 40, 3, "HUD/DropshadowPanel.png", true);
See attachment (well I changed HUD background to WhiteBackground.png..., but just for the sake of better "contrast" Smiley )

As you see it is clear that the problem is that that image william or Label or whatever transparent and blended is there, no matter what is in some reason blended not with the underlying backround of the panel widget but with HUD background. If you put Blue background, blending corona would be blue etc...
Exactly same is corrupting and label too.. Funny staff... have no idea why, but it is clear - it is blending/transparency etc problem. Something wrong with it in xith... seems like at least... hmmm... 

BTW, you are using OrderedGroup... just wonder why?
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #13 - Posted 2006-07-31 22:08:43 »

I realized this blending problem, too. But it doesn't always occurr (strange). In the case I descripbed in my last posting (not setting the background image of a Panel by calling the setBackground() method but adding an Image Widget) the artifacts didn't come up. So just as you say: Maybe there's something, that we don't understand...

BTW, you are using OrderedGroup... just wonder why?

It doesn't seem to be necessary. I inserted this one to ensure, that the parts of an assembled Widget are rendered in a certain order and to avoid using the z-index mechanism, which is nothing more than translating in z-direction in a minimum (-effective) step, which is 0.0001f. Well, anyway I think, I can leave this group.

OrderedGroup is anyway something I don't really understand. A normal Group like TransformGroup also has an order. So what is the OrderedGroup for? Somewhere I read, that xith (or JOGL or something) sorts nodes for their blending attribute. So blended nodes are rendered first (or last?). I can't see what this is good for. There can't be a preferred order any mechanism knows of from itself. So the only order to be honored should be the insertion order of the group's children. In that manner the sense of OrderedGroup is no more and this class could be removed/deprecated.

But the bleding problem stays. Could please someone, who knows these internals look at the code?

Marvin
Offline bohdan

Junior Devvie




Java-positive...


« Reply #14 - Posted 2006-08-01 02:34:26 »

BTW, you are using OrderedGroup... just wonder why?

It doesn't seem to be necessary. I inserted this one to ensure, that the parts of an assembled Widget are rendered in a certain order and to avoid using the z-index mechanism, which is nothing more than translating in z-direction in a minimum (-effective) step, which is 0.0001f. Well, anyway I think, I can leave this group.

I actually asked for purpose   Wink. I have seen that you have "zIndexUnit" defined, but I was suspecting as well that you might not everywhere use it since there is OrderedGroup mentioned. To say true, I didn't clearly understood from you answer, are you still using z-translations togather with OrderedGroup, or because of OrderedGroup you don't need using that translations?

Bacause if you don't - it might be (probably) explanation to the problem. I have mentioned above in the post that once I have the problem just the same!, and I have to switch DepthTest.. to be specific it was when I had two coinsiding (same z-translations) geometries and I needed blending to work!!! For example if background z-translation (absolute!) would be same as in other transparent Shape3D there would be a problem.
As Yuri Vl. Gushchin explained once, OrderedGroup really works (well, I still not totaly agree with him, anyhow - I believe he know better Smiley) either for transparent pass, either opaque, but not in combination. In combination you need to make a difference in their absolute z-translations (well, it works for me)....

In general, what about OrderedGroup see this thread:
http://www.java-gaming.org/forums/index.php?topic=12856.0
Offline bohdan

Junior Devvie




Java-positive...


« Reply #15 - Posted 2006-08-13 19:41:06 »

Just wonder if there is any progress with that issue?
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #16 - Posted 2006-08-14 02:49:41 »

Just wonder if there is any progress with that issue?

Sorry. I had so much to do. So had left it aside for the moment.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #17 - Posted 2006-08-15 01:10:53 »

I fixed the problem by accident Smiley It seems to have something to do with the order the TransformGroups have in each other. But since I don't understand the logic behind it (there should be no difference), I guess the problem may occurr again in the future. But for the moment it is fixed.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2006-08-15 10:54:02 »

I fixed the problem by accident Smiley It seems to have something to do with the order the TransformGroups have in each other. But since I don't understand the logic behind it (there should be no difference), I guess the problem may occurr again in the future. But for the moment it is fixed.
I do *love* that kind of accidents.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline bohdan

Junior Devvie




Java-positive...


« Reply #19 - Posted 2006-08-16 17:48:40 »

Great!!!  Grin

@Qudus: Could you please briefly disclose some details, coz I'd love to steal your solution!    Grin
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #20 - Posted 2006-08-16 19:32:06 »

@Qudus: Could you please briefly disclose some details, coz I'd love to steal your solution!    Grin

Well, as I said. It happened by accident. So it is not really a solution. The change, that did the trick, was in org.xith3d.ui.hud.base.WidgetAssembler. This class assembles a Widget from existing ones. It holds a TransformGroup that is added to the Widget's main group. A Widget's background Image is added to this WidgetAssembler. The WidgetAssembler's TransformGroup was added to to Widget's group at initializing phase, which is later than the construction phase. This delay was not necessary in this case, so I decided to do it at construction time.

I moved this line:
1  
ownerGroup.addChild(this.transformGroup);

from the init method to the constructor. And voila, all Labels looked just fine. So I guess it has something to do with the order of the HUD system's TransformGroups. But I really don't know, why this is the case.

I hope, this helps you. Maybe you can see, why this happens...

Marvin
Offline bohdan

Junior Devvie




Java-positive...


« Reply #21 - Posted 2006-08-17 22:19:29 »

I hope, this helps you. Maybe you can see, why this happens...

Yes, thanks, any information can be helpfull...!

Sorry Marvin, just one more question on that mater (sorry for annoying... Roll Eyes), the question I posted earlier before:
http://www.java-gaming.org/forums/index.php?topic=14575.msg115497#msg115497

Thanks,
Bohdan.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #22 - Posted 2006-08-21 22:31:47 »

Sorry Marvin, just one more question on that mater (sorry for annoying... Roll Eyes), the question I posted earlier before:
http://www.java-gaming.org/forums/index.php?topic=14575.msg115497#msg115497

You're not annoying me. So don't worry. And sorry for the late anwser, I was an a short holiday for the weekend.

I've eliminated this OrderedGroup. Maybe one could replace the z-translation with an OrderedGroup, when one had actually understood it Wink. It was for ordering the "components" or parts of a Widget, which is assembled by other (simpler) Widgets. Maybe I'll put the OrderedGroup back into the system. But for now it is gone.

Marvin
Offline bohdan

Junior Devvie




Java-positive...


« Reply #23 - Posted 2006-08-22 20:45:33 »

Thanks, Marvin! Satisfied with your answer  Grin (simply was worrying about those OrderedGroups, and agree with your decision to go away from them)
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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!