Hey, Amos, is this QuickHUD class still necessary? I added a new static method to the HUD class called createAndInitialize. Please check it out and tell me if we still need QuickHUD?
Marvin
I don’t use RenderLoop nor these ScheduledOperation things so this class is useful for me.
By the way, what happened to HUD class :o I can’t register it any more on keyboard or mouse…
[quote="<MagicSpark.org [ BlueSky ]>,post:3,topic:27922"]
By the way, what happened to HUD class :o I can’t register it any more on keyboard or mouse…
[/quote]
Sorry, I simplified the Input- and Picking System of the HUD (a little to far, I guess). But it’s fixed now.
No offense, but why don’t you use RenderLoop?
EDIT: My question aims at missing features that you may need and that could be implemented in the (Ext)RenderLoop class, so that you can effectively use it.
Please recheck the factory methods of the HUD class. I added some more and could therefore simplify your QuickHUD class. First of all, I hope that’s ok, and secondly I really think this class is not needed anymore, because it just holds an instance of HUD and OperationSchedulerImpl. So this is just as easy to use directly.
i actually don’t want to use the render loop too … i like the way shown in the book ‘Killer game programming for java’ … it uses a single thread, but suspends the rendering if necessary to achieve a given ups (updates per second) rate
have a look at one implementation here: www.fhaust.de/downloads/GameTimer.zip
It seems like this implementation just handles to hold a maximum FPS and to render the scene in that interval. The RenderLoop also does it and a lot more. Maybe I got this coding wrong, but I don’t see, that it did more.
that’s not entirely true …
this implementation seperates the FPS (frames per second) from the UPS (game logic updates per second)
and tries to hold a given ups rate at the cost of suspending rendering calls where necessary
for the user this results in smoother viewing as the updates are constantly kept the same even in graphic intensiv scenes
you can set the maximum number of skipped render calls so it won’t drop below a fixed point
but afaik it won’t annoy the view if the fps drops down to ~25fps as long as the ups stay at the needed rate
so far … Flo
Sorry, I simplified the Input- and Picking System of the HUD (a little to far, I guess). But it’s fixed now.
No offense, but why don’t you use RenderLoop?
EDIT: My question aims at missing features that you may need and that could be implemented in the (Ext)RenderLoop class, so that you can effectively use it.
[/quote]
I like to know when it’s rendering. I don’t like to think I’ll have to schedule everything.
[quote="<MagicSpark.org [ BlueSky ]>,post:9,topic:27922"]
I like to know when it’s rendering. I don’t like to think I’ll have to schedule everything.
[/quote]
Of course and naturally I have nothing against it, that you’re not using (Ext)RenderLoop 
But you actually know, when it’s rendered -> the closest time possible -> the next render loop. And you can still decide to override loopIteration to do and sync everything “by hand”. (Ext)RenderLoop does so much for you. I just think it’s a good idea to use it. You’d have much less code and much less to do and think about, don’t you?
Of course and naturally I have nothing against it, that you’re not using (Ext)RenderLoop But you actually know, when it’s rendered -> the closest time possible -> the next render loop. And you can still decide to override loopIteration to do and sync everything “by hand”. (Ext)RenderLoop does so much for you. I just think it’s a good idea to use it. You’d have much less code and much less to do and think about, don’t you?
[/quote]
Well I’m gonna think about it when I’ve got 2 seconds for me.
If you say it’s gonna make me have less code then it sounds interesting…
But the problem I see with that is it’s scenegraph-centric. Which is not the case of every game. It should be logic-centric.
[quote="<MagicSpark.org [ BlueSky ]>,post:11,topic:27922"]
But the problem I see with that is it’s scenegraph-centric. Which is not the case of every game. It should be logic-centric.
[/quote]
I don’t understand exactly, what you want to say. Before I start to guess, could you please be more precise?
Some changes :
- Fixed the issue with QuickHUD : it was due that full-screen JOGL canvases don’t have a Window, in which case we simply take canvas3d.getWidth/Height() for innerWidth/Height
- Fixed an issue : operations scheduled by buttons were returned as not alive, which caused them not to be executed by OperationSchedulerImpl
- Some things I forget
Attached : a little screenshot of my game’s model viewer. This HUD system just works great…
[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:27922"]
Some changes :
- Fixed the issue with QuickHUD : it was due that full-screen JOGL canvases don’t have a Window, in which case we simply take canvas3d.getWidth/Height() for innerWidth/Height
- Fixed an issue : operations scheduled by buttons were returned as not alive, which caused them not to be executed by OperationSchedulerImpl
- Some things I forget
[/quote]
Ah, cool. Thanks. So this was the error. In my test cases I’m not using fullscreen, even if the Xith3DTestStarter supports it by just one click. I should try it from time to time
I just modified the HUD class slightly, such that we don’t let the exception-catching mechanism do too much and a real error/exception, which we didn’t foresee, will still be thrown.
EDIT: btw. really cool screenshot. Nice kind of HUD usage.
[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:27922"]
Attached : a little screenshot of my game’s model viewer. This HUD system just works great…
[/quote]
Wow - really nice. Just one question - the larger icon on the frame - did you paint the frame or is this a window manager thingy ?
I don’t think, he used a window manager. This is all done by the HUD and some Image Widgets. Correct me, Amos, if I’m wrong. Well, at least it should be done this way. The HUD can do this and should be faster than the window manager, which is not know to be very fast.
Maybe it even is one big image with an alpha channel used to produce full transparency in the center.
Wow - really nice. Just one question - the larger icon on the frame - did you paint the frame or is this a window manager thingy ?
[/quote]
The window has no border. The “borders” you see is a 800x600 background image. However, MInimize buttons is working.
I wanted to make possible window dragging, too but when I tried it was a bit buggy so… maybe later.
(attached : background image).
I’ve just updated the Frame Widget and added a Dialog Widget. Both are fully usable now.
I’ve fixed the ProgressBar Widget and added Mouse Wheel support to the WidgetContainerBase (–> Panel).
And just to have it in this thread: Clipping is working now.
Marvin