I was reading about how to transition from SDL 1.2 to SDL 2.0 (thinking of potentially updating the SDL code for 2.0, its been around for at least some time and is provided by even Debian [backported on current stable, Wheezy, available on testing and unstable lines, Jessie and Sid]), and came up with a new layout idea for the client while reading about dual-monitor support in SDL2.
Its biggest drawback is it is a multi-monitor layout, making it impossible to use as a default layout.
The main screen would have the map (and only the map, nothing more), while the second screen would have the inventory, stats, ground, messages, resistances, and other widgets.
It would solve so many space issues that make the client look so cluttered by separating the information from the viewport.
I'll have to whip up a sketch at some point, so I can better give an idea of what I was thinking.
Personally, I don't have a dual-monitor setup to test this on, so I'm not sure if it will ever be made, but I thought it was a worthwhile idea to put on the forum, so if someone chances across it and also thinks its a good idea and has a dual monitor layout, they can maybe make something of it.
A new layout idea
Moderator: Board moderators
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
A new layout idea
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
And here's the layout plan
I can't directly load the image, so its external to this site.
https://www.dropbox.com/s/rnfdchfjewxls ... utIdea.png
A rudimentary plan, but its something (I literally made the image in maybe fifteen minutes, so bear with me for a little bit).
https://www.dropbox.com/s/rnfdchfjewxls ... utIdea.png
A rudimentary plan, but its something (I literally made the image in maybe fifteen minutes, so bear with me for a little bit).
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
-
Leaf
- Forum Aficionado
- Posts: 1994
- Joined: Tue Apr 29, 2003 5:55 pm
- Location: Minnesota, USA
- Contact:
Reminds me of the split window mode that client used to support.
Unfortunately, I don't recall when and why this function disappeared.
Unfortunately, I don't recall when and why this function disappeared.
"Put another, more succinct way: don't complain, contribute. It's more satisfying in the long run, and it's more constructive."
Eric Meyer
Eric Meyer
Split window might have disappeared with the move to gtk2 - not sure on that however.
As a person with a dual monitor setup, the proposed layout has no appeal to me - often on the second monitor, I want to display things unrelated to the game (irc chat, web sites, etc). I often do the same even when playing windows game.
I have no idea what percentage of people have multi monitor setups, so writing a layout for that may just be aiming at a pretty small portion of players regardless.
Note there are some other limitations that come into play - the maximum map area really supported right now is 25x25 (this could be made larger, but would be a non trivial change). Given images are 32x32 pixels, this means an entire map area is only 800x800 pixels - so anything larger than that just means scaling (zooming) the images larger.
While that may create a more pleasing game experience (entire monitor is the map), it won't convey any more information to the player, and may actually look worse due to artifacts of zooming (as an aside, at one time, there was a proposal to make a larger image set (say 64x64 pixels) to be able to play on higher res monitors and still have nice detail. That was a few years ago, and given that 4K monitors are likely to get somewhat affordable in the not to distant future, doing 128x128 pixel images may be better future proofing (scaling down tends to yield better results than scaling up)
But aside from all that, some clients are written which use most of the screen for map data - most commercial games do this and only bring up other windows as necessary (one could imagine a transparent chat window which becomes opaque (more visible) if chat type messages are present, and then fades out over time, etc. Inventory doesn't really need to be up all the time - especially if there were 10 slots on screen for quick access to certain items (potion of healing, etc)
Last thing to note is that for the GTK client, when in SDL model, all the windows are still drawn with GTK logic except the game window, so I'm not quite sure how this plays into that requirement for SDL 2 anyways.
As a person with a dual monitor setup, the proposed layout has no appeal to me - often on the second monitor, I want to display things unrelated to the game (irc chat, web sites, etc). I often do the same even when playing windows game.
I have no idea what percentage of people have multi monitor setups, so writing a layout for that may just be aiming at a pretty small portion of players regardless.
Note there are some other limitations that come into play - the maximum map area really supported right now is 25x25 (this could be made larger, but would be a non trivial change). Given images are 32x32 pixels, this means an entire map area is only 800x800 pixels - so anything larger than that just means scaling (zooming) the images larger.
While that may create a more pleasing game experience (entire monitor is the map), it won't convey any more information to the player, and may actually look worse due to artifacts of zooming (as an aside, at one time, there was a proposal to make a larger image set (say 64x64 pixels) to be able to play on higher res monitors and still have nice detail. That was a few years ago, and given that 4K monitors are likely to get somewhat affordable in the not to distant future, doing 128x128 pixel images may be better future proofing (scaling down tends to yield better results than scaling up)
But aside from all that, some clients are written which use most of the screen for map data - most commercial games do this and only bring up other windows as necessary (one could imagine a transparent chat window which becomes opaque (more visible) if chat type messages are present, and then fades out over time, etc. Inventory doesn't really need to be up all the time - especially if there were 10 slots on screen for quick access to certain items (potion of healing, etc)
Last thing to note is that for the GTK client, when in SDL model, all the windows are still drawn with GTK logic except the game window, so I'm not quite sure how this plays into that requirement for SDL 2 anyways.
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
Hmm... that would make a dual monitor layout difficult (unless GTK2 had support for it).mwedel wrote:Last thing to note is that for the GTK client, when in SDL model, all the windows are still drawn with GTK logic except the game window, so I'm not quite sure how this plays into that requirement for SDL 2 anyways.
So, if such a layout were to exist, it might have to be its own client, rather than an extension to an existing client, which really makes such a layout a lot more work than necessary.
Seems like a layout with fully movable and collapsible windows for stats, inventory, etc. makes more sense than a two-monitor layout. With the second monitor (and the right type of windows), the status windows could be organized, collapsed, expanded, moved, as needed on either monitor, which is already more versatile than the two-monitor layout and would not require a massive rewrite of a lot of code that works fine as it is.
When I had a desktop switcher and multiple desktops set up on my computer (kinda like multi-monitor, but without extra physical monitors), I would usually put the skills window on the second desktop and would switch to that desktop if I wanted to look at my skills (usually in noncombat). Having windows like that would probably work better than a dual-monitor layout anyway, as they can be moved as necessary, and can be used by a larger audience.mwedel wrote:As a person with a dual monitor setup, the proposed layout has no appeal to me - often on the second monitor, I want to display things unrelated to the game (irc chat, web sites, etc). I often do the same even when playing windows game.
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
Note that I think in pretty much all cases now days, multiple monitor output is transparent to the application (xinerama does it at an X server layer, but nvidia, intel, and probably ATI have logic to do it in their drivers)
So right now, someone could just take the existing gtk client and size it big enough to cover both monitors. With clever choices on where the different panes are, one could make this work quite well (make the split where the 2 monitors are something like the line between the chat & inventory window are).
The gtk2 client also supports users making their own layout, so a user certainly could rearrange things and make a custom layout that works better for their needs.
The one area I've seen where 2 monitor support isn't quite transparent to the application is when opengl is being used - it seems that opengl needs to know what monitor it is running on.
Perhaps this is what the issue is with SDL2 - might be built on top of opengl, and thus moving an SDL2 application between displays just wouldn't work quite right - though this is just speculation on my part.
So right now, someone could just take the existing gtk client and size it big enough to cover both monitors. With clever choices on where the different panes are, one could make this work quite well (make the split where the 2 monitors are something like the line between the chat & inventory window are).
The gtk2 client also supports users making their own layout, so a user certainly could rearrange things and make a custom layout that works better for their needs.
The one area I've seen where 2 monitor support isn't quite transparent to the application is when opengl is being used - it seems that opengl needs to know what monitor it is running on.
Perhaps this is what the issue is with SDL2 - might be built on top of opengl, and thus moving an SDL2 application between displays just wouldn't work quite right - though this is just speculation on my part.