Hey, Guurk. Just ran it for a second and things looked very good. Didn’t notice any particular issues, other than the objects don’t appear to scale based on resolution, so things were overlapping.
A couple comments.
-Have you tried using your UIText to display quickly changing text? I.e. the framerate? I’m just curious if it’s a viable alternative to normal text. (Trying to consolidate similar functionality).
-We are now using the code review section to post code prior to committing it. This allows all devs to do spot checks to catch any potential gotchas before committing into CVS.
-You should look into making a template UI for SimpleGame, that way all the demos can have a nice UI look to it. (If you want 
)
I’m very glad you are back!
UIText displays just as fast as the 'regular' text, at least from my tests
In your UITest switch to pure UI components instead of Text, it might be the future of text output...
Code Review is a good idea. I did a search on the forums and see no 'formal' means of doing that. May I suggest that we use branching and merging? CVS does a great job. We could branch changes, let them be reviewed as people have time, and then for releases we could just merge all the stuff in that has passed muster.
Nothing formal at the moment, just post code in there (other than bug fixes unless they are major changes), we discuss, etc. Informal at the moment. The cvs idea is not bad, we can look into implementing a more formal version after next release (whenever that is).
I like the idea of a UI Template... any suggestions? (How's the runtime resolution switching going?)
Only thing I'd like to really see is FPS and scene stats in a nice panel (with slight transparency would be cool). After that, anything else that is useful.
Resolution switching should be fine DisplaySystem.recreateWindow(...)
F - toggles full screen / windowed
R - swaps between 640x480, 800x600 and 1024x768
It should run fine assuming your setup handles those resolutions.
Great to know that work is being done on the GUI again, though I guess I’m going to have to rewrite some of the menus in my game later on.
About the scaling thing, I’m already doing it in my game and have noticed that if everything looks fine in 1280x1024, it doesn’t in, lets say, 800x600. Maybe this is a problem with scaling you can’t escape, but it certainly would be nice if it did
/Per
Well, 800x600 and 1024x768 are 4:3, whereas 1280x1024 is 5:4. Since the monitor dimensions don’t change, the pixel cannot be square in both cases. Maybe that’s a problem?
I’ve written a LayoutManager which does not rechange the size of quads/UIText for that purpose, but rather simply positions them relative to a screen border or edge with an offset.
BTW: guurk, I haven’t looked into the new version yet. Is it possible to enhance UIText by getter methods for scale and size of single characters? I currently need these informations to reposition the UIText objects, if the length of the displayed text changes.
UIText right now just has the the size of the characters as publics… I’ll be making them getter/setter right away. I wanted to get some functionality out, I’ll clean up as I expand.
Look at _texSizeX and _xtrimFactor, you’ll notice that the distance from the beginning of one character to the next is (_texSizeX * _xtrimFactor). _textSizeX is the width of the character itself, and _xtrimFactor is basically the ‘scrunch’ factor, how much to scrunch the letters together, kind of like a combination of kerning and tracking. Turned out I needed this for proper placement of the cursor in the EditBox.
You’ll notice that I’ve gotten rid of all references to ‘scale’ in the UI code, I only deal with X, Y, W, H now. The reason being that scale is really a 3D concept and you’ll never find it in GUI API. That’s because you do the scaling yourself.
The Layout manager that I’m working on will have two types of layout. One will be a relative scale so that the UI components will take up the same amount of screen realestate no matter the resolution. The second will be that they will scale larger or smaller depending on resolution. If you’ve used the SWT GridLayout you’ll know what I’m going to be shooting for.
Here’s a list of what I think I’ll be wanting to get done for components:
ComboBox (Editable and non-editable)
Layout manager
Scroll Bar
Slider
Progress Bar
Moveable/Resizeable Window with frame
Any other’s that I should do?
BTW- I have a question for anyone that can answer. How do I get the actual character that caused an event from addKeyboardAction and KeyInputAction.
You’ll notice that my bufferedKeyAction in InputHandler places the actual keyChar into the event, not the name of the command like the standard KeyAction stuff. You’ll notice that to get my EditBox to work I had to use two different InputHandlers because of this issue. I don’t want to do that. I think I’ll have to make changes to InputHandler and KeyBindingManager unless someone can tell me what I need to do to make things right.
UIText right now just has the the size of the characters as publics... I'll be making them getter/setter right away. I wanted to get some functionality out, I'll clean up as I expand.
If they are publicly readable, fair enough for me.
Look at _texSizeX and _xtrimFactor, you'll notice that the distance from the beginning of one character to the next is (_texSizeX * _xtrimFactor). _textSizeX is the width of the character itself, and _xtrimFactor is basically the 'scrunch' factor, how much to scrunch the letters together, kind of like a combination of kerning and tracking. Turned out I needed this for proper placement of the cursor in the EditBox.
You'll notice that I've gotten rid of all references to 'scale' in the UI code, I only deal with X, Y, W, H now. The reason being that scale is really a 3D concept and you'll never find it in GUI API. That's because you do the scaling yourself.
Looks like I know what I spend the evening with - cleaning up my code XD
The Layout manager that I'm working on will have two types of layout. One will be a relative scale so that the UI components will take up the same amount of screen realestate no matter the resolution. The second will be that they will scale larger or smaller depending on resolution. If you've used the SWT GridLayout you'll know what I'm going to be shooting for.
Dunno whether you have ever looked at the UT engine. The way they handle different screen resolutions is basically by glueing different parts of the HUD to screen edges without rescaling them. I was planning to support resolutions from 800x600 to 1280x1024 as a maximum range, so I can live without rescaling, but I liked the idea of positioning components relative to edges. Will your layout manager be capable of providing such a behaviour, too? Sry for asking, I never used SWT.
Here's a list of what I think I'll be wanting to get done for components:
ComboBox (Editable and non-editable)
Layout manager
Scroll Bar
Slider
Progress Bar
Moveable/Resizeable Window with frame
Any other's that I should do?
You plan to do all of these? I'm impressed! I suggest that when you write "ComboBox (Editable)" you automatically will be providing a text field. It's way more than I was ever hoping for.
Yep, although it took a quick 10 seconds or so to figure out how :D.
Well, I updated jME to migrate towards your new code. I got several issues.
First of all, I can’t get the alpha and texture rendering to work correctly. Even in jmetest.ui.TestUI it does not work. I’ve completely dropped everything to do a clean jME checkout, but still it does not work. All I get from UIText is white background and black text, no font textures. I suppose the green letters provided in conc_font.png should be visible as green. I’ve got the same issue in my own program.
Secondly, since you call updateGeometricState in setText of UIText, any localTranslations gets propagated to the children. Now, if you create a UIText at 0,0, then translate it yourself (which is what I was doing) and afterwards set another text, the translation gets applied to the UICharacter children, which is ok. But after that I recalculate the position on the screen (in case the text is centered and I need to realign it), therefore I might set a different local translation, and then the characters get translated even more, which means, they get translated relatively to the UIText quad and may even leave it. I solved this (after a funny evening of debugging) by setting the local translation of the UIText to all 0 before I call setText again. It is manageable this way, but since it is definitely a difference to the previous behaviour, I’d like to let you know about this.
All I get from UIText is white background and black text, no font textures.
The UIColorScheme forground color determines the 'color' of the text. I'm using setSolidColor on the character. This enables color change of text that starts out white, the standard font file. And accounts for specially textured fonts (like the green one) to show when the forground is set to white. Now, why you get a white background... I don't know... here's a screen shot of what it should look like.
http://hicom.resonus.net//ftproot/uitest.jpg
And if you turn on the alternate color scheme that's commented out it should look like this:
http://hicom.resonus.net//ftproot/uitest2.jpg
This shows the alpha blending working.
I solved this (after a funny evening of debugging) by setting the local translation of the UIText to all 0 before I call setText again. It is manageable this way, but since it is definitely a difference to the previous behaviour, I'd like to let you know about this.
Thanks for pointing this out, I'll take a look.
Layout manager
Scroll Bar
Slider
Progress Bar
Moveable/Resizeable Window with frame
Any other's that I should do?
Interesting idea Per, I’m not sure what ‘standard’ would be though. I’ve been toying with also adding functionality similar to crazy eddie’s gui library for Ogre where you can pass in a ‘look and feel’ image file will all the gui component pieces in it. Then we’d be able to have something like that. I’ll take a look when I get to the windowing stuff.
I mean like info dialogs with only an Ok-button to press. The constructor would take a string that is prompted, and then blocks the app until the Ok-button is pressed.
Take the bumpmap demo for example. When you don’t have a graphics card that supports bump mapping it quits printing something in sysout. It would be much nicer if it would prompt you a info dialog telling that the gfx card was insufficient.
Also dialogs like "Are you sure you want to quit? Yes/No would be cool.
etc.
IIRC swing has a framework for this, which works really well.
I think we are thinking in different areas. A dialog about a gfx card being insufficient would be outside of the actual 3D/game environment and rendering system. My GUI stuff is for inside. That’s why I wonder about look and feel. Everyone’s game look and feels differently and they would want all dialogs, even informational ones, to be consistant.
Ah well ok then, bad example
Ingame info dialogs would still be nice, like “Are you sure you want to keep these settings?” Yes/No 
Sure, having an optional constructor taking an image would work. If that constructor isn’t used changing background & foreground colors and such would still work…
http://hicom.resonus.net//ftproot/uitest.jpg
After spending another couple of trial and error rounds I finally managed to get it working in my code, but UITest still looks different from yours. Here's what I made wrong: I needed to set the foreground color of the scheme to white (didn't notice that and I am not sure whether this is the best way to say "use the texture from the font file for the characters"). Additionally I had to remove several of my own render states lurking in the scene tree above the UIText, so I reorganized my scene graph. Finally, from one desperate test there must have remained a UIObject.BORDER as a flag for the UITest creation. Do I understand this correctly that via this flag you render a background quad for the UIText field, which shows the texture applied to the UIObject, but which currently cannot be set for UIText? It seems to be used in UIButton for the different button states though. Maybe use of the flag should be disabled in UIText. It caused my white background. I thought, this would enable using the font file texture :)
Hi Guurk, just passing by to tell you that I think most of the problems I had yesterday were caused by me, misunderstanding the way the new UI classes work. So I did not want to sound offensive. My last posting was way past midnight, though, and I wasn’t the freshest one, then