Attached? lol That’s a good one.
All I wanted to do was give a hassle-free implementation to move the stats in either corner or an arbitrary location.
As far as I’m concerned, the case is closed.
How about letting StatsView provide the useful coordinate ranges?
E.g. minX() and maxX() for the x coordinate range, similar for Y.
People can then place the stats view at minX, maxX, (minX+maxX)/2, and don’t have to bother with looking up what the coordinate system is and the correct formula to use (which usually takes several iterations to get right if you don’t happen to know all these details by heart).
@toolforger said: How about letting StatsView provide the useful coordinate ranges? E.g.minX()andmaxX()for the x coordinate range, similar for Y. People can then place the stats view at minX, maxX, (minX+maxX)/2, and don't have to bother with looking up what the coordinate system is and the correct formula to use (which usually takes several iterations to get right if you don't happen to know all these details by heart).
So minX would be based on where it is currently? Otherwise, why isn’t minX just 0 and maxX just width? Ah, I guess you are saying they subtract themselves from the current camera settings? You’d have to give them the camera settings, though.
I don’t really understand why getWidth() and getHeight() is not enough. You don’t have to look up the coordinate system because it’s the exact same coordinate system as everything else in the guiNode. getHeight() is already there and every time I think about adding a getWidth() I worry I’ll catch crap for it for being too simple. (Not to mention that width varies and that always concerns me, too… but anyway.)
One thing that changed in the last few months is that the stats object works properly even without the stats view. (You have to setEnable(true) on the stats object but as long as you still have the ResetStatsState then things will work properly). So maybe GUI libs could provide some default components that work with their layout code.
…or we also expose alignment on StatsView to right justify them for when they are on the left side of the screen.
It also bothers me that FPS is separate… but that cat is out of the bag since even some of the tests reference the FPS text directly, as I recall.
1 Like
maxX would be screen width minus panel size.
minX would be 0 and present just for symmetry with minY (which is not zero UPDATE: which might or might not be zero depending on what coordinate system orientation you use vertically - falling to the very trap I mentioned below).
Coordinate systems are different for different people. Nifty users live in a top-to-bottom coordinate system; I certainly wasn’t aware that JME’s Nifty wrapper must be inverting the Y axis.
Also, minX/maxX etc. would allow callers to never bother whether the best approach is to use the viewport or the camera. (This might be important in cases where people adjust the camera settings to simulate different aspect ratios, for example.)
BTW normally I’d agree with “just use the camera size and be done with it”. but this is one of the first things that people see, at a time while they’re operating under detail-learning overload. Every detail that can be postponed helps to lower the learning curve.
Also, that code might be one of the things they turn to for best practices.
On a tangent, maybe min/max is the wrong terminology since it assumes knowledge about coordinate directions.
leftX, rightX, topY, bottomY would be comprehensible independently of coordinate direction knowledge.
@toolforger said: maxX would be screen width minus panel size. minX would be 0 and present just for symmetry with minY (which is not zero UPDATE: which might or might not be zero depending on what coordinate system orientation you use vertically - falling to the very trap I mentioned below).Coordinate systems are different for different people. Nifty users live in a top-to-bottom coordinate system; I certainly wasn’t aware that JME’s Nifty wrapper must be inverting the Y axis.
Also, minX/maxX etc. would allow callers to never bother whether the best approach is to use the viewport or the camera. (This might be important in cases where people adjust the camera settings to simulate different aspect ratios, for example.)BTW normally I’d agree with “just use the camera size and be done with it”. but this is one of the first things that people see, at a time while they’re operating under detail-learning overload. Every detail that can be postponed helps to lower the learning curve.
Also, that code might be one of the things they turn to for best practices.On a tangent, maybe min/max is the wrong terminology since it assumes knowledge about coordinate directions.
leftX, rightX, topY, bottomY would be comprehensible independently of coordinate direction knowledge.
a) stats view doesn’t have the info to do this. (ie: no reference to camera or viewport)
b) it’s a lot of code to maintain compared to a really small benefit.
c) anyone who can’t properly do the math to position the stats should quit game development.
re: coordinate systems. The guiNode is always 0 on the bottom. (Just like OpenGL) Anyone messing with stuff in the guiNode needs to know it’s 0 on the bottom. If “insert gui toolkit here” does 0 on the top then I don’t see how that has anything to do with StatsView since it is not an “insert gui toolkit here” component. It is a JME component in the JME guiNode. So regardless of what UI you are using, 0 is on the bottom.
I can’t believe we’ve wasted so much discussion on a debug feature that should be off by default in any real game.
@pspeed said: I can't believe we've wasted so much discussion on a debug feature that should be off by default in any real game.
I think it’s because you’re missing the point.
Nobody argues it’s hard to get the thing at any point on the screen. The point of it was to simply give options to those who wanted it elsewhere without having to bother calculating it in the first place.
It’s not like this would break core compatibility with Android or Mac or whatever. It’s, as you put it yourself, a simple debug feature. And you accuse me of being attached to my code. Oh the irony. 
Code added is code that needs to be maintained.
So, we add code to auto calculate this position stuff. Now the control needs to know what viewport it’s in.
Next, we need to hook into the reshape event somehow because now users are complaining “I put it in the top but then it’s in the wrong place when the screen resolution changes”.
We get still other complaints “I put it on the right side and it starts out right but now when the stats get really big they are clipped”
Better, in my opinion, to leave a simple feature simple and not imply functionality that it does not have.
The missing functionality is that it is nearly impossible to tell how wide the component will be. So basically, today it is impossible to place it on the right side of the screen accurately. I like to correct the impossible. I don’t like to correct the “just do a - b” style math if it requires more than one line of code in the component in question.
I’d love to exchange banter and expose the gaping flaw in your argument, but I have lots of other stuff to do. The changes I proposed in this thread are in my stuff and that suffices to me. If I remember right the code is in the first page if anyone wants to implement it. If it’s not send me a PM and I’ll give it to ya.
Oh and Paul, please close the thread. It’ll be better for everyone if you do. 
@madjack said: I'd love to exchange banter and expose the gaping flaw in your argument, but I have lots of other stuff to do. The changes I proposed in this thread are in my stuff and that suffices to me. If I remember right the code is in the first page if anyone wants to implement it. If it's not send me a PM and I'll give it to ya.Oh and Paul, please close the thread. It’ll be better for everyone if you do.
Heheh. I guess I wasn’t sure if you were arguing for toolforger’s proposal or your own at this point.
Your patch had different issues than toolforger’s recommendation. My recent posts were discussing the latest proposal.
I actually didn’t really read his posts except for a very very quick skimming (this week has been hell). I thought he was “improving” my proposition.
Anyway. You’ve exposed your view on this and you’ve also rigidly set yourself to dispose of any divergent opinion we might have on the subject. Because of that you definitively should close the thread.
One way or the other, I don’t care much, I have my solution and that’s good enough for me.
1 Like