Hugor request/improvement - for RealNC
Moderators: Ice Cream Jonsey, joltcountry
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
I was taking another look at .cfg files lately because of something Robb is working on. I think values such as fullscreenwidth work great when somebody is setting values for their own computer, but it's something that's harder to gauge for a general release.
What I'm wondering is, could there be an option to shoot for a 4:3 mode window (something that calculates the width based on the available height... and in the rare cases where someone is playing on a vertical display, calculate the height based on the available width)? (I say "window" but I'm talking about fullscreen stuff here)
What I'm wondering is, could there be an option to shoot for a 4:3 mode window (something that calculates the width based on the available height... and in the rare cases where someone is playing on a vertical display, calculate the height based on the available width)? (I say "window" but I'm talking about fullscreen stuff here)
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
That's a good idea. I'm putting that in, so that you can write:Roody_Yogurt wrote:What I'm wondering is, could there be an option to shoot for a 4:3 mode window (something that calculates the width based on the available height... and in the rare cases where someone is playing on a vertical display, calculate the height based on the available width)?
Code: Select all
widthRatio = 4
heightRatio = 3[/quote]
Which will limit the fullscreen width if it exceeds a 4:3 ratio, but still respect it if it's smaller.
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
This is now in. In addition, the fullscreen width option is now treated as a percentage, not an absolute pixel value.
Windows version for testing:
http://83.212.107.13/~realnc/hugor/test ... 08-w32.zip
An example.cfg file is included. The relevant options compared to the previous version are:
Some bugs still exist. I'll get rid of them and then cut a release.
Windows version for testing:
http://83.212.107.13/~realnc/hugor/test ... 08-w32.zip
An example.cfg file is included. The relevant options compared to the previous version are:
Code: Select all
; Maximum display width in fullscreen mode. Can be between 10 and 100. The
; value represents a percentage. 100 means that the whole width of the screen
; is used. Only integral values are accepted.
;fullscreenWidth = 100
; These two values allow you to set an aspect ratio to limit the width of the
; game's output when in fullscreen mode. For a 4:3 ratio, you would set
; "widthRatio = 4" and "heightRatio = 3". Any ratio is possible, but the most
; common ones are 4:3, 5:4, 16:9 and 16:10. Use the one for which your game
; was designed for. Most games are created with a 4:3 ratio in mind. Using a
; modern widescreen monitor for those would result in extremely long lines of
; text, which is why this setting exists; it ensures that your game will use a
; 4:3 ratio even when running on a widescreen monitor.
;
; Note that if an aspect ratio is set, it will override the fullscreenWidth
; setting, if that setting would result in output that is too wide and would
; exceed the set aspect ratio. fullscreenWidth is still respected if it would
; not exceed the set aspect ratio.
;
; Setting either of these values to 0 disables aspect ratio correction and the
; game will always output to the entire screen.
;widthRatio = 4
;heightRatio = 3
- Ice Cream Jonsey
- Posts: 30175
- Joined: Sat Apr 27, 2002 2:44 pm
- Location: Colorado
- Contact:
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
Yeah, percentages is probably a bit better than pixels. Knowing you're looking at the code again, Nikos, I'll try to remember other suggestions I've had.
One thing off the top of my head is, since the text in the scrollback window is proportional font anyway (throwing off any non-proportional type layout in mind), would it be possible to disregard the carriage returns due to screen width? (so the scrollback window always resizes properly to the current window size?)
I don't feel I'm describing it well, but I guess I'm looking for a glk-esque handling of the scrollback window without forcing glk-esque handling on the game itself.
One thing off the top of my head is, since the text in the scrollback window is proportional font anyway (throwing off any non-proportional type layout in mind), would it be possible to disregard the carriage returns due to screen width? (so the scrollback window always resizes properly to the current window size?)
I don't feel I'm describing it well, but I guess I'm looking for a glk-esque handling of the scrollback window without forcing glk-esque handling on the game itself.
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
This would require modification of Kent's base code, so that a CR that was artificially inserted can be distinguished from an authored one. It would not be possible to tell whether a CR can safely be removed again or not otherwise.
I don't know exactly what's needed in order to achieve this. I'll take a closer look in the base code.
I don't know exactly what's needed in order to achieve this. I'll take a closer look in the base code.
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
The necessary base code changes are now in. Not much was required:
https://github.com/realnc/hugor/commit/ ... 45ae3b8de4
I hope this didn't break anything. It *shouldn't* break anything. I tested a few games and it seems to work as intended, but I'd be nice if other people also took a look at it:
http://83.212.107.13/~realnc/hugor/test ... 09-w32.zip
https://github.com/realnc/hugor/commit/ ... 45ae3b8de4
I hope this didn't break anything. It *shouldn't* break anything. I tested a few games and it seems to work as intended, but I'd be nice if other people also took a look at it:
http://83.212.107.13/~realnc/hugor/test ... 09-w32.zip
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
Looks good so far! Now, I was kind of expecting scrollback behavior to also affect how transcript files are produced, as I'd like to see the same behavior there (so transcripts can easily be dropped into word processor programs for people who want to pretty-fy their transcripts). Would that be possible? Do you see a downside?RealNC wrote:The necessary base code changes are now in. Not much was required:
https://github.com/realnc/hugor/commit/ ... 45ae3b8de4
I hope this didn't break anything. It *shouldn't* break anything. I tested a few games and it seems to work as intended, but I'd be nice if other people also took a look at it:
http://83.212.107.13/~realnc/hugor/test ... 09-w32.zip
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
The only downside is text files would have no linebreaks for people who don't care about copy&pasting into a word processor. "Normal" people ;-)Roody_Yogurt wrote:Now, I was kind of expecting scrollback behavior to also affect how transcript files are produced, as I'd like to see the same behavior there (so transcripts can easily be dropped into word processor programs for people who want to pretty-fy their transcripts). Would that be possible? Do you see a downside?
I'll take a look at it nonetheless. Maybe an option for it would be appropriate.
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
Robb, what's the time frame for this? I'm currently looking into supporting games with video (for Future Boy) on all platforms, but that needs a bit of time. Your games don't use video, so it might be best to ship them with a custom Hugor build that comes without video support if you don't want to wait for a proper 1.1 release.
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
Haha, "normal" people support is cool, too. I'd like the option!RealNC wrote:The only downside is text files would have no linebreaks for people who don't care about copy&pasting into a word processor. "Normal" people ;-)Roody_Yogurt wrote:Now, I was kind of expecting scrollback behavior to also affect how transcript files are produced, as I'd like to see the same behavior there (so transcripts can easily be dropped into word processor programs for people who want to pretty-fy their transcripts). Would that be possible? Do you see a downside?
I'll take a look at it nonetheless. Maybe an option for it would be appropriate.
And yay, looking forward to video support.
- Ice Cream Jonsey
- Posts: 30175
- Joined: Sat Apr 27, 2002 2:44 pm
- Location: Colorado
- Contact:
Yeah, no sweat - I think I will build it for the three platforms and upload new versions of Fallacy of Dawn & Cryptozookeeper to the archive(s). So ... wait, re-reading. Yes, I will do that thing that you just said. =)RealNC wrote:Robb, what's the time frame for this? I'm currently looking into supporting games with video (for Future Boy) on all platforms, but that needs a bit of time. Your games don't use video, so it might be best to ship them with a custom Hugor build that comes without video support if you don't want to wait for a proper 1.1 release.
Thanks!
the dark and gritty...Ice Cream Jonsey!
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
Scriptfile writing is now handled by Hugor rather than the Hugo base code and word wrapping is now configurable in the config dialog.
As a side-effect of this, the encoding of the scriptfile should now be correct on all systems. Previously, the Hugo base code just assumed that everyone out there runs Windows and uses the Windows-1252 codepage. All text is now converted to the actual codepage used by the user's machine (this fixes broken curly quotes, em-dashes, and such.)
New build:
http://83.212.107.13/~realnc/hugor/test ... 11-w32.zip
As a side-effect of this, the encoding of the scriptfile should now be correct on all systems. Previously, the Hugo base code just assumed that everyone out there runs Windows and uses the Windows-1252 codepage. All text is now converted to the actual codepage used by the user's machine (this fixes broken curly quotes, em-dashes, and such.)
New build:
http://83.212.107.13/~realnc/hugor/test ... 11-w32.zip
- RealNC
- Posts: 2301
- Joined: Wed Mar 07, 2012 4:32 am
-
- Posts: 2255
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee