logo
Main

Forums

Downloads

Unreal-Netiquette

Donate for Oldunreal:
Donate

borderline

Links to our wiki:
Wiki

Walkthrough

Links

Tutorials

Unreal Reference

Usermaps

borderline

Contact us:
Submit News
Page Index Toggle Pages: 1 [2] 3  Send TopicPrint
Very Hot Topic (More than 25 Replies) HUD scaling (Read 5977 times)
formercrest
New Member
*
Offline


Oldunreal member

Posts: 2
Joined: Jun 5th, 2016
Re: HUD scaling
Reply #15 - Jun 5th, 2016 at 9:51pm
Print Post  
Masterkent wrote on Jun 18th, 2015 at 7:59pm:
Skywolf wrote on Feb 3rd, 2015 at 7:45pm:
To be honest. I don't even care too much for having the icons and text a higher resolution. Just being able to read them without pushing my face against the screen would be enough for me.

Agreed.

Quote:
Just being able to read them without pushing my face against the screen would be enough for me. Rendering the HUD in a larger scale couldn't be that hard to implement, right?

Switching to other font needs changes in text layout. Finding a proper layout was the most time-consuming thing in my case.


I wonder if it's possible to override drawing an info about currently downloaded packages and statistics provided by commands such as "stat net" and "timedemo 1". I couldn't find a way to enlarge such text without introducing bad side effects.


AlCapowned wrote on Jun 19th, 2015 at 7:39am:
I could give you my Resurgence HUD, or just the renders and code if you want something less Skaarj-themed. It has 64x64 and 128x128 icons.


Could I possibly be PM'd one of these solutions?
I can't read the any of the stock HUDs without some sort of scale change
  
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #16 - Jun 6th, 2016 at 10:18am
Print Post  
I implemented HUD scaling for some multiplayer game type. The only thing I can offer in addition to that for now is adapted version of that implementation for the classic SP campaign - mutator PrototypeSPHUD changes the original HUD to custom HUD that supports 2x scale. Download PrototypeSPHUD.7z

Probably, 227 patch should natively support some HUD scaling - at least for standalone games (SP campaigns and botmatches). I see more and more players using resolutions higher than FHD and 2x scale in game menus, and I can bet they suffer from bad HUD much more than from the lack of OpenGL3/4 features.
  
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7394
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: HUD scaling
Reply #17 - Jun 6th, 2016 at 10:26am
Print Post  
Masterkent wrote on Jun 6th, 2016 at 10:18am:
I see more and more players using resolutions higher than FHD and 2x scale in game menus, and I can bet they suffer from bad HUD much more than from the lack of OpenGL3/4 features.

No idea what this has lost in this topic, but spare me, one thing has no relation to the other and XOpenGL was never about "features", rather more to have an
a) more future proof rendev
b) an overhauled base to work with cleaned up code making fixes way more easy.
If you feel like redoing a new hud, then do so, most stuff can be done very much without any native changes from what I see, and if so, just tell me what you need to have changed.

  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #18 - Jun 6th, 2016 at 11:29am
Print Post  
Smirftsch wrote on Jun 6th, 2016 at 10:26am:
one thing has no relation to the other

Except the potential concurrency for human resources.

Quote:
and XOpenGL was never about "features", rather more to have an
a) more future proof rendev

OK, future-proof is good, but for some users existing HUD became obsolete and troublesome _already_. My point is that considering this issue should be a priority direction.

Quote:
If you feel like redoing a new hud, then do so

I'm afraid, I won't be able to make a good implementation alone. Adding HUD scaling support is not about changing a few lines of code, it requires complete refactoring of UnrealHUD, because everything there uses hardcoded offsets based on knowledge about dimensions of a particular default font. The changes should not cause conflicts with existing custom mods.

In this case I would like to participate in a cooperative work.
  
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7394
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: HUD scaling
Reply #19 - Jun 6th, 2016 at 1:27pm
Print Post  
Masterkent wrote on Jun 6th, 2016 at 11:29am:
Smirftsch wrote on Jun 6th, 2016 at 10:26am:
one thing has no relation to the other

Except the potential concurrency for human resources.

This may sound odd for you, but currently my life is more what I have to do and not what I want to do and I'm pretty much exhausted all the time. So I'm always happy being in one task not having to switch between things. Result is, I'm trying to finish open work first before moving to something (entirely) different. HUD for example means for me to work myself into something different again, which eats up a lot of energy and time. Therefor I want to avoid switching whenever possible and finishing things still open. Of course I see that stuff like XOpenGL is a long time project, but right now I'm really in these matters and progress is good- despite the fact that working on it is fun for me and working on HUD only (necessary) pain.

But as said, I'm sure we can work something out together, it's not that I would deny the advantages of an overworked HUD (although I am not sure if it's really necessary or that I would see the requirement/priority to play with something like 2xFHD).
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #20 - Jun 6th, 2016 at 3:06pm
Print Post  
Smirftsch wrote on Jun 6th, 2016 at 1:27pm:
although I am not sure if it's really necessary or that I would see the requirement/priority to play with something like 2xFHD

I didn't see people playing with 4K resolution yet. Large resolutions that I could find in server logs are:

2560x1080
2560x1440
2560x1600

Speerunfemale said that her monitor supports 5160x2880, but double-sized fonts looked too tiny with such a resolution, so she plays with 2560x1440 and double-sized fonts. Reducing the resolution even more just for comfortable reading would be funny...
  
Back to top
 
IP Logged
 
Bleeder91[NL]
Betatester
Offline


Personal Text:

Posts: 895
Location: Location, Location, Location.
Joined: Oct 4th, 2009
Gender: Male
Re: HUD scaling
Reply #21 - Jun 6th, 2016 at 3:42pm
Print Post  
With DNS I can go up to 3840x2160 with my screen Tongue
I suppose one could remake the HUD to reduce Canvas.ClipX/Y while using Canvas.SetTile3DOffset() to scale everything up (this does scale everything including fonts while keeping position of HUD parts). I did try that just now for funsies and it's acceptable I guess. Not sure if such a thing could be implemented or used compatibly with other mods.
  
Back to top
WWW  
IP Logged
 
formercrest
New Member
*
Offline


Oldunreal member

Posts: 2
Joined: Jun 5th, 2016
Re: HUD scaling
Reply #22 - Jun 7th, 2016 at 4:28am
Print Post  
Masterkent wrote on Jun 6th, 2016 at 10:18am:
I implemented HUD scaling for some multiplayer game type. The only thing I can offer in addition to that for now is adapted version of that implementation for the classic SP campaign - mutator PrototypeSPHUD changes the original HUD to custom HUD that supports 2x scale. Download PrototypeSPHUD.7z

Probably, 227 patch should natively support some HUD scaling - at least for standalone games (SP campaigns and botmatches). I see more and more players using resolutions higher than FHD and 2x scale in game menus, and I can bet they suffer from bad HUD much more than from the lack of OpenGL3/4 features.


much thanks
  
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #23 - Jun 8th, 2016 at 10:47am
Print Post  
Bleeder91[NL] wrote on Jun 6th, 2016 at 3:42pm:
I suppose one could remake the HUD to reduce Canvas.ClipX/Y while using Canvas.SetTile3DOffset() to scale everything up (this does scale everything including fonts while keeping position of HUD parts). I did try that just now for funsies and it's acceptable I guess. Not sure if such a thing could be implemented or used compatibly with other mods.

It seems, SetTile3DOffset is not documented, and I have no idea how to use it (too lazy to make tests to figure out the meaning of its parameters).

Upscaling everything is a universal method (and the only method that can be relatively safely applied to custom HUD and scoreboard types), but it has a disadvantage - upscaled fonts look blurry (although blurry is better than tiny and unreadable).

Replacing small fonts with bigger fonts helps to avoid blurriness of text, and, I think, this method should be used where it's applicable.
  
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #24 - Jun 11th, 2016 at 6:31pm
Print Post  
Does Canvas.DrawColor.A affect anything?

The standard HUD implementation widely uses code like

Code
Select All
	Canvas.DrawColor.R = 255;
	Canvas.DrawColor.G = 255;
	Canvas.DrawColor.B = 255; 


I'd rather prefer to use something like

Code
Select All
Canvas.DrawColor = MakeColor(255, 255, 255); 


instead. Strictly speaking, these options are not equivalent: the former does not change Canvas.DrawColor.A, while the latter does. So maybe it makes sense to introduce some helper function like Canvas.SetDrawColorRGB(byte R, byte G, byte B) with a UScript definition or Canvas.SetDrawColor(byte R, byte G, byte B, optional byte A) with a native definition? Or maybe alpha is ignored anyway and custom HUD types most likely don't rely on its value either?
  
Back to top
 
IP Logged
 
Bleeder91[NL]
Betatester
Offline


Personal Text:

Posts: 895
Location: Location, Location, Location.
Joined: Oct 4th, 2009
Gender: Male
Re: HUD scaling
Reply #25 - Jun 11th, 2016 at 6:46pm
Print Post  
Canvas.DrawColor.A does affect alphablended textures. I used it for some HUD parts in 227i.
  
Back to top
WWW  
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #26 - Jun 12th, 2016 at 3:18pm
Print Post  
OK, then I need a helper function that would not change Canvas.DrawColor.A.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 482
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: HUD scaling
Reply #27 - Jun 14th, 2016 at 8:08am
Print Post  
In my opinion the best solution for the HUD scaling issue would be a separation of the physical screen size and a virtual screen size for the Canvas rendering.

This way one would "see" when dealing with Canvas HUD drawing a smaller virtual size, and the Canvas rendering functions would handle the translation of the coordinates to the physical screen size.

Thats basically the approach ION took for scaling the UI in DeusEx, though I don't in particular like the way they implemented it. They used some GC abtraction to wrap Canvas drawing.

They choosing multiplyers as Mult=min(floor(ScreenWide/640),floor(ScreenHeight/480)) and the virtual Screen size would get (ScreenWide/Mult, ScreenHeight/Mult).

This has the advantage that one doesn't need to write all UI rendering code to deal with multiple resolutions in the first place and get some upscaled version of the UI if desired.

This however doesn't prevent you from selectivly choosing higher resolutions for certain UI elements. For example, in Revision when the UI scale is above 2 we render higher resultion datavault images. In fact we just use for both the same DrawStrechedTile() calls and just switch the texture.

Another approach would be to fabricate an own mip map set for a given texture, so with PF_NoSmooth NEAREST/NEAREST_MIPMAP_NEAREST filtering would select the appropriciate texture. But that might require to honor the DrawScale of the texture for Canvas drawing (if not already done).

Regarding the blur issue MK mentioned, it basically breaks down to personal preferences and whether PF_NoSmooth is set. Setting PF_NoSmooth will just double the pixels using NEAREST filtering, so it won't get blurred. Having it not set results in linear filtering which blurs it out. I personally prefer the pixelated pixel doubling approach, while others prefer blurred textures over it. Just set PF_NoSmooth for the font page textures and you are good.

However there is a decent amount of Pixel art scaling algorithms to scale up especially non antialiased images popular in the emulation scene. These might work in particular well for creating a higher resolution versions of existing bitmap fonts. However this should be done offline, not during rendering itsself.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 795
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: HUD scaling
Reply #28 - Jun 14th, 2016 at 3:08pm
Print Post  
han wrote on Jun 14th, 2016 at 8:08am:
In my opinion the best solution for the HUD scaling issue would be a separation of the physical screen size and a virtual screen size for the Canvas rendering.

This way one would "see" when dealing with Canvas HUD drawing a smaller virtual size, and the Canvas rendering functions would handle the translation of the coordinates to the physical screen size.

That's what Bleeder suggested. HUD implementation commonly uses Canvas.ClipX and Canvas.ClipY to determine screen width and screen height. In some cases (drawing messages) it relies on PlayerPawn(Owner).Player.Console.FrameY.

In standard scripts, we can replace existing uses of Console.FrameY with Canvas.ClipY, temporarily modify Canvas.ClipX and Canvas.ClipY before rendering HUD

Canvas.ClipX = Console.FrameX / HUDScale;
Canvas.ClipY = Console.FrameY / HUDScale;

and then restore the original values

Canvas.ClipX = Console.FrameX;
Canvas.ClipY = Console.FrameY;

when HUD is rendered. This is a very simple solution that can give us a decent level of quality in many cases. I have two concerns:

1) Shouldn't we try to offer a bit better looking HUD using hi-res large fonts instead of upscaling small fonts?
2) How to achieve the best compatibility with custom HUD elements?

1. The following screenshots illustrate the difference between two approaches (drawing in reduced resolution vs drawing in native resolution using bigger fonts):





In the former case I used SetTile3DOffset:

Code
Select All
		ScreenWidth = PlayerPawn(Owner).Player.Console.FrameX;
		ScreenHeight = PlayerPawn(Owner).Player.Console.FrameY;
		Offset.X = (ScreenWidth - ScreenWidth / HUDScale) / 2;
		Offset.Y = (ScreenHeight - ScreenHeight / HUDScale) / 2;
		Offset.Z = 0;
		Canvas.DrawActor(none, false, true);
		Canvas.SetTile3DOffset(true, Offset,, false, HUDScale);
		Canvas.ClipX = ScreenWidth / HUDScale;
		Canvas.ClipY = ScreenHeight / HUDScale; 


This implementation doesn't scale HUD correctly, so the result looks a bit worse than it could be with proper scaling. I presume, the image is very close to properly scaled, and we can do some comparisons. Which variant is the best, in your opinion?

2. What can go wrong with custom HUD elements?

Probably, the least disaster is when some text retains the original size. In the worst case, a HUD element can be rendered in an appropriate place and possibly overlap with other elements.

It's relatively easy to control the layout of all elements when we own the code responsible for drawing them all. The problem is that HUD is not represented by a single class responsible for drawing all elements in it. There are at least 4 things that can draw parts of HUD:

- the main HUD object (whose type is a subclass of Engine.HUD),
- the scoreboard object (whose type is a subclass of Engine.ScoreBoard),
- the current weapon owned by the player,
- any HUD overlay object (whose type is a subclass of Engine.HUDOverlay).

All parts should be mutually compatible.

Suppose we implemented scaling in UnrealShare.UnrealHUD through modified layout based on native screen coordinates. An author of a custom weapon might want to add an indicator for some alternative ammo type (primary fire and secondary fire could use two different types of ammo) closely to the indicator for the primary ammo type assuming that the primary indicator is rendered exactly as defined in UnrealHUD in versions 224 - 227i. The placement of the secondary indicator most likely won't fit in the new scaled layout of UnrealHUD.

Suppose we implemented HUD scaling through stretching the image drawn in reduced resolution. If our hypothetical custom weapon with secondary ammo indicator relies on Canvas.ClipX and Canvas.ClipY and does not try to use real screen coordinates obtained by other means, then there should be no any new problems with layout. Theoretically, this way seem to offer better compatibility in general.

So, in either case we seem to sacrifice either compatibility or quality of fonts. Many players really don't care about mods and they could choose better quality, while others could prefer better compatibility with mods or even classic fonts. Maybe both approaches should be implemented then?
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 482
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: HUD scaling
Reply #29 - Jun 14th, 2016 at 3:23pm
Print Post  
I don't quite get how a modified ClipX/ClipY has any influence on the scaling, or is this a 227 thing?
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1 [2] 3 
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo