next »

[Marvin Fröhlich]

I've just committed my last-four-day's work on the HUD. It contains several fixes concerning clipping, pixel-perfectness, z-index calculation, etc. The new z-index calculation is much more stable. Sometimes it was necessary to give a Widget a zIndex greater than zero to ensure it's visibility. This is not necessary anymore. Everything should look a little nicer, too, because of this.

New features:

• Borders are fully supported for all WidgetContainers (like a Panel). There are some new Border classes { EmptyBorder, ColoredBorder, BevelBorder, BorderWidget (for general use) }
• WidgetContainers have methods for padding now
• The Image Widget now has a method setTileSize(), to tile the Texture
• All Background-Textures (like a Panel's one) are tileable, too
• the Progressbar's bar Texture is always tiles now (looks much nicer)
• There's a new List Widget, which is fully working now

Everything should be demonstrated in HUD3DTest.

I still have problems with the pixel perfectness concerning borders. So they tend to look odd, if a virtual resolution is used on the HUD. This is why I didn't release a new cooker built today. I hope to fix this issue tomorrow and will release the new build then.

Please update both xith3d and xith-tk

Marvin

EDIT: One more word about Borders:
Borders are set to a Container by invoking one of the setBorder() methods. The the Border doesn't need a size, since the container overrules it anyway. And you can also create a new instance of a Border class and add it to a Container like a regular Widget ( then it needs a size).
Decorated Frames have a Border by default. So if you used to set the Border for a Frame like I did it before in the HUD3DTest, just remove these lines, since this border would be added to the ContentPane.
The Frame class implements the BorderSettable interface, too (like the WidgetContainer -> and a Panel) and this changes the Border of a decorated Frame.

['n ddrylliog]

Great !

Looking forward to having perfect-pixel-perfectness-with-borders. 

[Marvin Fröhlich]

Wow, this was a tricky one. I fixed the pixel-perfectness problem. The solution was to quantize the values calculated from HUD-logical-values to scenegraph values. That means, they always have to be exactly a multiple of one pixel in scenegraph scale. Well... its fixed . Check it out.

Marvin

Ah, btw: It concerns Checkboxes and RadioButtons and Button-Borders as well. They all look just perfect now .

['n ddrylliog]

Well it's sure better now but it's strange : some things don't get displayed in the HUD3DTest.

Ex. the closing button for frames, or the handle for slides things like that. I could send you screenshots if you wanted.

[Marvin Fröhlich]

Well it's sure better now but it's strange : some things don't get displayed in the HUD3DTest.

Ex. the closing button for frames, or the handle for slides things like that. I could send you screenshots if you wanted.

Well, I believe yo without these screenshots. But they are displayed on my system. Strange...

Please try the following:

• Open org.xith3d.ui.hud.base.WidgetBase.java and move to line #64
• change the value for Z_INDEX_UNIT_ASSEMBLER to 0.01f

If this helps, I could maybe fix it. Otherwise I have to wayt for an idea .

Marvin

[Marvin Fröhlich]

Please try the following:

• Open org.xith3d.ui.hud.base.WidgetBase.java and move to line #64
• change the value for Z_INDEX_UNIT_ASSEMBLER to 0.01f

If this helps, I could maybe fix it. Otherwise I have to wayt for an idea .

Marvin

For get that. I found domething that should be responsible for this bug. Even if it still didn't appear on my system, it should be solved now. Please recheckout.

Marvin

['n ddrylliog]

Now everything displays but pixel-perfectness is correct only on fullscreen...

Also, could we make a system where the last test ran is registered in a file somewhere and then when Xith3DLauncher is started again it's selected. What do you think ?

Oh and the window titles aren't really visible : that could be lot better..

[Marvin Fröhlich]

Now everything displays but pixel-perfectness is correct only on fullscreen...

I know. This is because the inner width and height of the canvas window is first returned correctly after the first frame. I tried to fix it by adding a scheduled operation which calls the resize method, but it doesn't do the job perfectly. I classified this as a lower priority, since most games will run in fullscreen. And it won't change the API. So this is a task for post-1st-beta-release. There're other thigs to do pre-beta.

Also, could we make a system where the last test ran is registered in a file somewhere and then when Xith3DLauncher is started again it's selected. What do you think ?

Sure. On non-JAR environments. Or we could store it in the user's home directory. I will do it soon.

Oh and the window titles aren't really visible : that could be lot better..

I guess you're talking about ugly fonts on some Windows, not on all. At the moment I don't have an idea, why this happens. I will solve it, when I get the idea.

Marvin

['n ddrylliog]

OK

[Marvin Fröhlich]

Another massive update

Fixes:

• Many internal calculations fixed
• All fonts are now cleanly rendered
• Some picking related fixes
• Input is now correctly handled

New features:

• new List Widget is complete
• new ComboBox Widget is ready
• new TextField Widget is not ready but already included and usable
• A Window's (Frame, Dialog) header Widget is now publicly available and can be extended and used for Frame extensions.

I've changed the internal structure in many concerns, which may effect you, if you have built your own Widgets. Please tell me, if there's anything, that you don't understand.

@Hawkwind: Please send me your Widgets, that you wanted to be included in the toolkit.

Marvin

[hawkwind]

Please look at http://home.mindspring.com/~hawkwind/dump.zip

I have two widgets, one that display due to mouse over, one that shows for a fixed time.  Widgets are embedded into a hacked HUDT3DTest.  Zip includes some images.  Change as needed.

[Marvin Fröhlich]

Please look at http://home.mindspring.com/~hawkwind/dump.zip

I have two widgets, one that display due to mouse over, one that shows for a fixed time.  Widgets are embedded into a hacked HUDT3DTest.  Zip includes some images.  Change as needed.

Thanks. I will integrate them into the tk. Well, maybe I will just add these features to the existing Frame widget, don't know. But unfortunately I don't have too much time this week. So it could become next week's monday.

For now just a question. Why do you use you own Texture loading system together with createTexture(), which is btw deprecated in TextureLoader and should be used in TextureCreator? Does it have any advantages over TextureLoader.getTexture()?

Marvin

EDIT: Please don't update to the current SVN until I tell you. There's a strange new bug in the HUD code, that causes some textures to disappear when a Frame is dragged.

[hawkwind]

The texture loading is old code I had when the Texture loading of Xith was mishandling something, don't recall.  I am slowly converting over to the correct system..

['n ddrylliog]

The texture loading is old code I had when the Texture loading of Xith was mishandling something, don't recall.  I am slowly converting over to the correct system..

That would have been cool if you reported it.. 

[hawkwind]

Agreed...

The trouble is I don't always update my source as often as updates are pushed because it sometime causes a significant, reworking of my code to integrate changes.  This sometimes leads me to delay error reporting until I am up to date, and compensating for problems with local changes, and only reporting a problem when I do an update/integrate cycle.

In this case I am in between Xith updates with some old kludges when I pushed the two widgets I was using to the forum.

After all this time I am sure it is obvious that I love to fuss and will do so when I can