Comments (11)
@tmewett nice work! tried on Windows there seems to be some wierdness with +/- keys, they work once after the window was resized and then don't. They both seem to be doing the same thing, resize down to closest matching proportion.
You might want to look at it.
from broguece.
On Linux, the display resolution is adjusted, but it leaves black bars on the bottom and right (on 1080p). When switching back out, the game appears to be frozen, though it is rendered as a still frame.
from broguece.
Let me take a stub at analysing this. My apologies if this is off the mark - not much prior experience.
Scaling
To me it looks like the fundamental problem is that scaling does not work and did not work very well with the type of rendering we have. You get a crisp picture in a window, when it's sized to exactly one of the 13 sizes, but in fullscreen it does not look that good, because scaling kicks in. This is the main reason why the windows cannot be scaled outside of the predefined increments.
This above something that holds true for both old and new versions
Extent of scaling
I could be wrong but I think that from SDL point of few the way this full screen scaling works depends on screen resolution and window size that is set in the program. The feed back about "stretching" that we get, to me seems to be due to the fact that tcod based implementation would put the borders on opposite sides of the screen when it cannot scale fully, but the new implementations, instead put the borders on the bottom and rights, and thus, the screen appears off centre. It appears that borders are present in both new and old behaviour, they are just different as described.
Screen resolution
My default is 1920x1200 and with this resolution if I use font of 13 when going full screen it looks decent. It's still a bit off centre, but since it takes up most of the screen it's bearable.
On a smaller resolutions though, defaulting to 13, when going full screen while simplest, won't work, the pitcure won't fit into screen. On bigger resolutions (4k) the picture will still appear off centre, in the top left corner, even with size 13.
Full screen vs borderless
In SDL, when entering full screen you can specify SDL_WINDOW_FULLSCREEN
or SDL_WINDOW_FULLSCREEN_DESKTOP
with the latter no scaling happens and the picture looks crisp. We might want to consider this later option, however in this case we will have to compensate for the lack of scaling
Alt-tab black screen issue
This one seems to be relatively straight forward:
else if (event.type == SDL_WINDOWEVENT && event.window.event == SDL_WINDOWEVENT_SIZE_CHANGED) {
refreshWindow();
}
The above may be all that is needed to fix it.
Possible solutions
Here is what we could do in the order from easiest to most difficult.
Option 1
I personally dislike how scaling looks alot, so I will not consider the option of keeping using SDL_WINDOW_FULLSCREEN
. Thusly we can:
- swith to
SDL_WINDOW_FULLSCREEN_DESKTOP
- default to fot size 13 with going to full screen mode. Probably a good idea would be to save the previous font size and restore it when exiting full-screen mode.
This is very easy to implement but will work decently only on certain screen sizes, around 1920x1200.
As of the time of writing, implementation of this option can look like this
Option 2
- As above, but check the screen size in full screen mode, and select the biggest font size that still fits to it.
- Update rendering code to make sure that the picture is always in the screen centre
This is quite a bit more labourous that previous option, but may be a good balance. We will have sharp output, it will scale down well, however for higher resolutions it probably won't be much preferable to a window.
Option 3
- As above but get some more PNGs for font size above 13. This way higher resolutions can be supported to.
I personally have no idea how to get bigger font sizes.
Option 4
Use true type fonts and SDL_ttf. This obviously a major re-write of the display sub system.
Other issues
With multiple displays of different resolutions I sometimes saw behaviour, when the full borderless window size created was from the other display, not the one the window was rendered to. This might need some additional looking at.
from broguece.
Great write-up, thanks!
In SDL, when entering full screen you can specify
SDL_WINDOW_FULLSCREEN
orSDL_WINDOW_FULLSCREEN_DESKTOP
with the latter no scaling happens and the picture looks crisp. We might want to consider this later option, however in this case we will have to compensate for the lack of scaling
I don't remember exactly when, but at some point I had FULLSCREEN_DESKTOP, and people said that the game wasn't scaling, so I changed it.
else if (event.type == SDL_WINDOWEVENT && event.window.event == SDL_WINDOWEVENT_SIZE_CHANGED) { refreshWindow(); }
Good idea, hope that's enough.
Option 2
* As above, but check the screen size in full screen mode, and select the biggest font size that still fits to it. * Update rendering code to make sure that the picture is always in the screen centre
This is my preferred option for bitmap fonts, with one amendment. I think it would be good if the window was freely resizeable, and the game chose the best-fitting font size and drew itself centred in the window. This would mean FULLSCREEN_DESKTOP would work automatically based on that.
Option 4
Use true type fonts and SDL_ttf. This obviously a major re-write of the display sub system.
I think this is the best way to go. With the prospect of merging in the official tileset, it might be better to consider a vectorised SVG font file. (That would enable us to continue to use the proper Brogue font without worrying about distributing a proprietary TTF!) But some kind of vector-based drawing will be best I feel.
from broguece.
Good thought about SVG.
- https://s3.amazonaws.com/Brogue/brogue-1.7.2-svg2-win32.zip
- https://s3.amazonaws.com/Brogue/brogue-1.7.2-svg2-osx.dmg
- https://s3.amazonaws.com/Brogue/brogue-1.7.2-svg2-source.tar.gz
- https://s3.amazonaws.com/Brogue/brogue-1.7.2-svg2.patch.gz
Those SVG's are avaialbe, however, not everyone will like them, I have a feeling. This build though solved big monitor problem - it seems to support scaling up indefinitely.
from broguece.
Thanks for your work, @AndrewSav ! I compiled your build and it worked - however, I noticed that on my widescreen monitor (2560x1080) the game was still rendered on the left. In addition, the size of the font on fullscreen was too large, and I was unable to change it through - and + buttons.
I did a quick and dirty fix for this for my end by changing the brogueFontSize to 11 when fullscreened, and also by centering the output of the font.
SDL_DisplayMode DM;
SDL_GetCurrentDisplayMode(0, &DM);
int Width = DM.w;
int Height = DM.h;
int isFullScreen = SDL_GetWindowFlags(Win) & SDL_WINDOW_FULLSCREEN_DESKTOP;
if(isFullScreen)
{
dest.x = (Width-cellw*COLS)/2+cellw * x;
}
else
{
dest.x = cellw * x;
}
dest.y = cellh * y;
I then did the same for SDL_MOUSEMOTION and for when the mouse button is clicked.
I put up the full code for sdl2-platform.c, which is the only thing I modified. https://pastebin.com/jnPuJ1x6 The changes should be apparent with a quick diff. Again, this was really quick and dirty, if you need something more cleaned up don't hesitate to ask.
Apologies if I am not going about this the right way - I do not use GitHub all that much, but I still wanted to help fix this issue for other users.
from broguece.
I've just made some commits which I think should fix most if not all issues discussed in this thread. They include a similar patch to @Chaoclypse's above.
Could anyone please test current master branch on their OS, and try resizing the window, toggling full-screen, and alt-tabbing while fullscreen? Those unable to compile can try this snapshot which contains the patch: https://github.com/tmewett/BrogueCE/actions/runs/60342385
from broguece.
@AndrewSav could you test again on latest master?
from broguece.
@tmewett do you happen to have the snapshot link like you did last time?
from broguece.
From my testing on Linux, this is a major improvement. The resolution scales well with the content, and fullscreen mode seems to work without issue, even when switching out and back into the game. My only "complaint" (if you can even call it that), is that the window can be resized ignoring the game's aspect ratio. This isn't a problem, but it allows the window to be unnecessarily large and filling the extra space with black. IMO the ideal scenario would maintain the aspect ratio, except in fullscreen where padding is needed. Regardless though, this is in no way detrimental to the experience, and it works great now.
from broguece.
Good to hear. I'm reasonably confident everything is fixed here for now, so I'm closing this issue.
from broguece.
Related Issues (20)
- Goblins don't know how to swim HOT 4
- BrogueCE-1.13-windows HOT 2
- Mirrored totem glyphs block path to rest of level, including downstairs
- When a turret or totem is negated there is no obvious indication of effect
- [Question] What does `pdsMap` mean? HOT 2
- [Question] How to compile for Miyoo Mini? HOT 2
- Gauging Interest in Controller Support and Potential Pull Request HOT 6
- A dialog should appear if peforming an attack would turn an ally into an enemy
- [Opinion] Eels shouldn't be able to open doors HOT 2
- Auto-ID ring kind if possible
- Rat trap wall broke open a vault HOT 2
- Bloodwort submerged in lava HOT 1
- Fire potion doesnโt ignite door after returning from descent potion
- Grappled, blink away, monster blinks adjacent and immediately grappled again
- Priority issue; goblin tool pile renders over shallow water
- Hunting monster stuck on corner, but easy path to player HOT 1
- Mangrove Dryad doesn't avoid known net trap triggers HOT 1
- Incompatible const pointer warnings (ERRORS on GCC 14) HOT 1
- X Error of failed request: BadValue HOT 1
- Paralysis runic broken
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from broguece.