Prism UI (continued)

ID:118747
 
Sep 18 2011, 11:49 am
Keywords: prism, ui
I mentioned before that Prism uses windows rather than screen objects as its HUD. There are several reasons we chose to implement the HUD that way. Firstly, it allows us to place text in our HUD more efficiently. This makes things like dynamic tool-tips trivial. Secondly, it offers more flexibility to the player. Prism will feature an interface editor that allows the player to change the position and size of any HUD element.

The only challenge posed to using windows as HUD elements is determining the position of the "child" windows. Prism will allow the player to choose a screen resolution. Prism automatically rearranges the "child" windows based on some properties defined in the user interface. As mentioned earlier, Prism features an interface editor. The player may choose the position of each element and assign the element a top, left, bottom, and right anchor. Then, based on the size and position of the game window, the HUD windows reposition.

Testing shows that, in order to allow the game window to be resized using the sizer, a delay of about 0.25 is necessary for smooth repositioning of child windows. However, with a delay that low, CPU usage was not favorable. To combat this, Prism will do one of the following, undetermined things: Use a higher lag and suffer the cosmetic consequences, or force a maximized window and not run a loop.

Attached is a demo.



2011-09/NefariousDevelopment-0004/child_windows.zip

Sep 18 2011, 11:51 am
Keep up the good work, bro.
Sep 18 2011, 11:56 am
IIRC, placing transparent interface elements over a map element forces software rendering.

While moving, the demo nearly fully exhausts a core of my 4.2Ghz i5-2500k.
Sep 18 2011, 12:01 pm
Yeah, but that CPU usage should be purely client side. I end up with about 50% CPU usage while moving non-stop in the demo. I'm not sure if this is anything to be concerned about, because I don't think client-side CPU is going to get much higher than that.
Sep 18 2011, 12:04 pm
NefariousDevelopment wrote:
Yeah, but that CPU usage should be purely client side. I end up with about 50% CPU usage while moving non-stop in the demo. I'm not sure if this is anything to be concerned about, because I don't think client-side CPU is going to get much higher than that.

Can I go out on a limb and assume you have a dual core processor?
BYOND will only effectively use one of your cores, as it's not written to take advantage of multithreading.
Sep 18 2011, 12:04 pm
Good work. CPU usage was at ~25% using an AMD A6.
Sep 18 2011, 12:09 pm
Murrawhip wrote:
Can I go out on a limb and assume you have a dual core processor?
BYOND will only effectively use one of your cores, as it's not written to take advantage of multithreading.

I'm running a dual-core. Why does it matter if my CPU is no where near over-heating? Seriously, I've played many games where my CPU runs higher than 50%.

Sep 18 2011, 12:13 pm
NefariousDevelopment wrote:
I'm running a dual-core. Why does it matter if my CPU is no where near over-heating? Seriously, I've played many games where my CPU runs higher than 50%.

I apologise for not explaining more clearly. If your CPU is reporting 50% of usage, then it is using an entire core. It cannot use anymore than that while running a BYOND game.

My processor, the i5, is a quadcore. If it's using 25%, it cannot use anymore processing power in order to play your demo. That's bad, because someone with a slightly older CPU is going to see jerky movement.

Exploshun's processor, the AMD A6 is also a quadcore. It's using 25% as well.

Your processor is dualcore. It's using 50%.

All 3 of our processors are needing to work 100%, effectively, to render your demo. You're going to run into problems with this later down the road, so I suggest you do something about it.
Sep 18 2011, 12:30 pm
Murrawhip: There's a couple things about the demo that attribute to the cpu usage while moving besides the transparent windows. As I mentioned in the post, the tick lag is set to 0.25, which is 40 FPS. Simply reverting to the default tick_lag of 10 lows the max CPU usage of the demo for me to 30%. Secondly, the demo uses unrestricted motion, which is uncommon in games. By restricting movement to one tile per half second, CPU usage dropped to 20% for me.

Also, I should mention that I am testing this at a resolution of 1920x1080. Without using transparent windows, I used about 30% of my CPU at 40 FPS while moving, just walking around an isometric map with no code behind it.
Sep 18 2011, 12:33 pm
NefariousDevelopment wrote:
Murrawhip: There's a couple things about the demo that attribute to the cpu usage while moving besides the transparent windows. As I mentioned in the post, the tick lag is set to 0.25, which is 40 FPS. Simply reverting to the default tick_lag of 10 lows the max CPU usage of the demo for me to 30%. Secondly, the demo uses unrestricted motion, which is uncommon in games. By restricting movement to one tile per half second, CPU usage dropped to 20% for me.

Also, I should mention that I am testing this at a resolution of 1920x1080. Without using transparent windows, I used about 30% of my CPU at 40 FPS while moving, just walking around an isometric map with no code behind it.

Okay. Good luck.
Sep 18 2011, 1:02 pm
Anyway, thanks for the advice Murrawhip. After playing around with this, I'm seeing similar CPU usage while moving at 40 fps without software rendering as I am with software rendering @ 10 fps. So I'll need to decide what's more important: High FPS or transparent windows. After seeing what pixel movement looks like at 40 FPS, I might just remove window transparency.

[edit]I'll likely make anything with transparency a screen object, and anything with dynamic text and window without transparency.