Need help in testing Hugor interpreter on macOS

Hugor is a Hugo interpreter for Windows, Mac and Linux. It’s been around for quite a while now, but it only supported video on Linux. I’ve now integrated LibVLC into the interpreter, which makes it possible to easily support video on Mac and Windows too.

But I need help with testing it on macOS. I don’t have a real Mac anymore and am using a macOS virtual machine. LibVLC does not play video in that due to lack of hardware acceleration. So I need help with verifying whether video is playing correctly or not.

Can you download the test version of Hugor here:

83.212.107.13/~realnc/hugor/test … -12-29.zip

It requires macOS 10.12, 10.13 or 10.14. (If there’s need for older macOS versions, I can put a separate version together for legacy macOS versions.)

The game to test this with would be Future Boy, but since not many people have that game (the demo version does not have video,) here’s a test game that displays a video in a loop:

83.212.107.13/~realnc/hugor/test … eoTest.zip

It’s a better test than Future Boy anyway, since it only displays a video loop and does nothing else. If the video plays correctly, please test whether you get an interpreter freeze when you quickly cancel the video with the escape key on your keyboard. Try and spam the escape key as quickly as possible. See if that causes the interpreter to hang. The test game will allow you to do that easily, since when you press escape is will simply restart the video.

Please let me know if it works :slight_smile:

I tried it out on 10.12 Sierra, and I can’t get it to hang by spamming escape. There are plenty of other issues, but I guess you are not interested in those at this stage.

Thanks! So the video shows up fine and when you press escape it restarts the video correctly then?

I am. Feel free to point out any other issues as well!

Well, that depends on your definition of correctly, I suppose. When I first tried it, it started in fullscreen with the video tiny at the center, and it was difficult to see whether it was animating at all. Then I found the preferences, and set fullscreen width to 100%, and then it (almost) filled the screen. This may have been caused by old Hugor preferences in my system folder, though.

If I set it to windowed instead, the escape button only seems to work once, after that I get a warning beep every time I press it.

There doesn’t seem to be any Retina support, so all text is low resolution. There also seems to be a bug where switching between fullscreen and windowed will erase part of the text at the bottom of the window.

A slightly frustrating thing is the missing standard shortcuts and menus. Command+Q doesn’t quit, Command+W doesn’t close the window, trying to scroll the text takes you to a new “scrollback” screen. The keys and gestures you try out of habit do something unexpected or nothing at all.

To make sure this wasn’t caused by old settings, make sure Hugor isn’t running and execute the following in a terminal:

defaults delete com.nikos-chantziaras.Hugor

Is the problem still there?

Hm. That is weird. No idea yet why that happens.

Good catch! I completely forgot about display scaling. I’ve now added Retina support and uploaded a new build:

83.212.107.13/~realnc/hugor/test … -12-29.zip

Unfortunately, this is par for the course with graphical implementations of Hugo. Its windowing system does not support resizing or scrolling. When the window shrinks in size, the contents outside the window are lost and thus appear empty when the window size is increased again. The same happens to anything that is no longer visible (like text or images that scrolled off the screen.) The scrollback view is there to provide a way to still get back to previous text.

There might be some tricks possible to get some scrolling support, but not for the time being.

Thanks for these. I’m taking notes :slight_smile: As mentioned above, the scroll issue is due to how the graphical Hugo engine works. But the rest needs fixing. What other keys and gestures do not work?

First of all, thanks for doing this. There are far too few fully-featured Mac interpreters out there.

After deleting the settings, the 100% Fullscreen width setting is gone, of course. I think the default is 63%. However, this is not really a problem with the new Retina-aware version you made, as the default video size is now four times as large as before, which is perfectly watchable.

The problem seems to be that the window (or the view) somehow loses focus when escape is pressed. If I focus it again by clicking in it with the mouse, escape will work again, but only once.

I think the real problem with scrolling is that the two-finger mousepad gesture that I try to use for scrolling instead triggers the scrollback window. It would be much better if it did nothing at all.

Regarding the keyboard shortcuts, the only one I didn’t mention was Command+O for opening a new game. But I guess everyone has their own favourite standard commands that they try instinctively. It would be nice if Alt+Enter toggled between full screen and windowed mode. That is not really a Mac standard, but it is common in SDL and Unity-based applications.

The new version you linked to is a great improvement, by the way.

EDIT: There is something weird going on with the View menu. Enter Full Screen is listed twice when in windowed mode. Also, there is a functional but pretty useless Show Tab Bar command, unless I am missing the point.

Skärmavbild 2018-12-30 kl. 12.58.01.pngEDIT 2: As it happens, I looked this up for another project. Here is how to disable the Tab Bar menu item: https://stackoverflow.com/questions/39399553/how-do-i-disable-the-show-tab-bar-menu-option-in-sierra-apps

First of all, thank you for all the feedback!

I addressed all the issues you mentioned, and added an option to not bring up the scrollback buffer when using the scrollwheel. Alt+Enter can also be used to toggle fullscreen. One thing that’s not addressed is the beeping escape key. Not sure what causes this. Was it only happening when video is playing, or for all games?

I prepared a build that is pretty much a v1.1 release candidate:

http://83.212.107.13/~realnc/hugor/testing/Hugor-macOS-2019-03-18.zip

The video test game from the first post:

http://83.212.107.13/~realnc/hugor/testing/HugoVideoTest.zip

If anyone else wants to give it a go, please do! It needs macOS 10.12 and higher. The preliminary changelog since v1.0 is:

Changelog
  • Improved SDL audio engine, using SDL_audiolib instead of SDL_mixer.

    Resampling quality is improved and the engine will now correctly apply
    resampling (if needed) in all cases. Previously, certain sample rates could
    cause resampling to be skipped, resulting in audio that plays at the wrong
    speed.

    MIDI music is now rendered using an internal SoundFont synthesizer
    (FluidSynth) or an OPL3 emulator (DOSBOX OPL through libADLMIDI) and thus
    it no longer matters whether or not the operating system supports MIDI. For
    FluidSynth, you can use your own SoundFont instead of the default one.

    Higher quality and more accurate playback of MOD-based music through
    libopenmpt. You can optionally use libxmp or libmodplug instead when
    building the interpreter from source.

  • The FMOD audio engine has been removed. It was there as a better alternative
    to SDL_mixer, but FMOD is proprietary software and thus could not be shipped
    with Hugor by default and thus required people to build from source. Since
    we now use SDL_audiolib, FMOD no longer serves any purpose.

  • The sound volume is now configurable through a slider in the preferences
    dialog.

  • The behavior of the “mute sound in background” setting has been changed. It
    now only mutes the sound when the application is minimized, not when it
    loses focus.

  • Video is now fully supported in the Linux, macOS and Windows versions of
    Hugor. The default video backend is libVLC, but you can optionally use
    GStreamer instead when building from source (although this is not
    recommended, as GStreamer has issues with the video format used in “Future
    Boy”.)

  • The interpreter is now executing games in their own thread. A game that (for
    whatever reason) freezes and stops responding will no longer freeze the
    entire application with no possibility to quit. Also, games that carry out
    time consuming operations between input prompts will no longer cause
    temporary UI freezes.

  • Improvements for Retina (and high DPI in general) displays. UI, text and
    graphics should no longer appear blurry.

  • Added two new text caret shapes, underline and block, as alternatives to the
    default “I-Beam” shape, along with three thickness levels for I-Beam and
    underline.

  • The “Fullscreen Width” configuration option is now a percentage, rather
    than an absolute pixel value.

  • If this version of Hugor is started for the first time, fullscreen mode will
    default to a 4:3 display ratio, as otherwise text lines can be extremely
    long on wide screen displays.

  • Fullscreen mode is now restored correctly between sessions.

  • Alt+Enter and Alt+Return can now be used on all platforms to toggle
    fullscreen mode, in addition to the platform-specific shortcuts.

  • The margin color auto-detection when in fullscreen mode can now be disabled
    and a custom color can be manually configured.

  • The mode in which the interpreter starts (fullscreen, window, last state) is
    now configurable.

  • Alt+tabbing out of the interpreter when in fullscreen mode will now minimize
    it.

  • The scrollback now ignores main window word wrapping and does its own word
    wrapping.

  • The scrollback font is now configurable.

  • A new “show scrollback when using scrollwheel” configuration option
    controls whether or not the scrollback is shown when trying to scroll with
    the mouse wheel.

  • Scriptfile output can now be word-wrapped. The text width to use when
    wrapping is configurable through a new configuration option.

  • Scriptfiles are now written using the correct character encoding of the
    operating system’s locale.

  • Games that expect mouse input will no longer receive right-clicks (or
    left-clicks on left-handed mouse setups), since this is reserved for the
    context menu.

  • Context menu entries set by the game are now supported and displayed in the
    context menu.

  • Pasting words on double-click now only works with the left mouse button.

  • Images are now always scaled using bilinear filtering and the “smooth image
    scaling” option has been removed from the preferences dialog.

  • Support for game-specific start-up configuration files. See the
    “example.cfg” file for details.

  • The Hugo base code was updated, fixing rare cases of crashes and failures to
    restore saved games.

  • When building from source, you can now do “make install”, which installs to
    /usr/local by default. See README on how to change the default path.

  • At least Qt 5.6 and SDL 2 are now required to build Hugor. Qt 4 and SDL 1
    are no longer supported.

  • Building the source code now requires at least a C++14 compiler.

  • Hugor is now licensed under the GNU General Public License version 3, along
    with an additional permission to combine and distribute it together with the
    Hugo Engine. (The special permission is needed, since the Hugo Engine uses a
    license that is not compatible with the GPL.)

Good job!

I’ve downloaded a bunch of Hugo games and pretty much everything seems to work, including movies and midi music. Thanks for implementing my suggestions!

That system beep when pressing escape thing is pretty rare. I think a system beep usually means that the active view does not accept keyDown events.

The only problem I have found is that switching between fullscreen and windowed mode tends to cause all kinds of glitches. One easily reproducible example is the options menu in Future Boy, which seems to lose track of its coordinates and print lines twice.

Keep up the good work!

2.0 is now released. Thank you so much for helping out! I really appreciate it. It’s safe to say the macOS port would have sucked without your feedback :slight_smile:

This is one of those “it’s how the Hugo engine works” things. Hugo games don’t keep track of screen size changes as they happen. They only do that after entering commands, and even then, it’s a bit half-assed as they don’t repaint the screen. As a result, resizing the interpreter window will cause things like this until you leave the menus and enter them again.

I’m thinking about ways to work around this issue, but since this could cause incompatibilities with some games (an extreme example would be Hugo Tetris), I left it for a future release. It’s been 8 years since 1.0 and I wanted to finally get a new version out the door.

HugoJS does layout on the interpreter side, which seems to work fairly well for most games, so I’ll probably try the same in Hugor. It’s probably going to be a bit more complicated though, since Hugor tries to be 100% compatible with the full feature set of Hugo (including abuses like Tetris.) The official Hugo interpreter for which Hugor is supposed to be a drop-in replacement for shows exactly the same behavior when resizing the window. But coming up with ways to make resizing work better is definitely on my to-do list :slight_smile: