Page 1 of 1

Hugor game communication protocol

Posted: Thu May 30, 2013 6:58 am
by RealNC
I've been thinking about ways to make player experience a bit nicer with Hugor when it comes to resizing the window. Hugo doesn't deal well with this since its display model is based on the MS-DOS framebuffer model.

Maybe we can shoehorn something in by having Hugor communicate to the game that a certain event happened. The idea is quite simple: when the game is waiting for input, if an event happens that would require the game to update the screen, a specially formed string is returned to the game. Of course this means that the game must recognize it and then choose to clear the screen completely and redraw everything. In order to stay compatible with existing games, games that do support this form of communication protocol would indicate this though a cfg entry.

This could also work in reverse, of course. If the game wants something done that's otherwise not possible through the standard Hugo routines, it could tell Hugor to do it (maybe by trying to print a specially formed string). For example a "fullscreen" command, so that the game can switch to fullscreen on its own. Or whatever else it might want to do.

Perhaps Roodylib would then provide transparent access to all that functionality, making sure the game will keep working fine in other interpreters that don't support the protocol.

Do you guys think this is worth pursuing?

Posted: Thu May 30, 2013 11:18 am
by Roody_Yogurt
The first thing you mention sounds like display.needs_repaint, which gets set to true after the screen gets resized. Roodylib currently uses this to redraw the screen as best as it can after a screen-size change.

I get the impression, though, that you are talking about something a little more powerful. I thought the things you described just weren't possible, but they sound great. If these things could be done without breaking other ports, I don't see why it's not worth exploring.

Posted: Thu May 30, 2013 11:25 am
by RealNC
Roody_Yogurt wrote:The first thing you mention sounds like display.needs_repaint, which gets set to true after the screen gets resized. Roodylib currently uses this to redraw the screen as best as it can after a screen-size change.
The idea is to get the game to update the display without the player needing to enter anything. Currently, Roodylib has to wait for the player to press enter first before that can happen.

Posted: Thu May 30, 2013 11:30 am
by Roody_Yogurt
Heh, it's actually on a two-second timer, but I let the impatient jump ahead with a keypress.

Posted: Thu May 30, 2013 11:41 am
by Roody_Yogurt
So, if handled by Hugor, the text in the main window would be re-drawn with no text loss? The current pause in Roodylib is there to kind of explain to the player why I had to clear away the previous text (in case they were surprised by that).

Posted: Thu May 30, 2013 12:06 pm
by RealNC
Oh. I didn't know that. I'd be interested in seeing an example of this, as I'm not aware of any games doing that yet. Or being able to do anything at all while the main game loop is blocked during line input. How'd you get around that problem?

It seems you already solved the problem and it's just that no games caught up with it yet?
Roody_Yogurt wrote:So, if handled by Hugor, the text in the main window would be re-drawn with no text loss?
Nope.

Posted: Thu May 30, 2013 12:12 pm
by Roody_Yogurt
Oh, yeah, no, my code (Roodylib) doesn't do it at the input prompt, just at PreParse. My point mainly was that if you're going to redraw the screen in a way that'll result in prose loss, I feel we should warn the player about what's going on.

Posted: Thu May 30, 2013 12:24 pm
by RealNC
You had me puzzled there for a minute :-) Yes, my suggestion was about letting the game know immediately that a resize happened by aborting line input and returning a "secret" string sequence. Though the clearing of the text does sound problematic, so it seems it's not a good idea to pursue this one any further.

(In any event, redrawing the text after the screen is cleared is not something that can be done from the interpreter side. The game itself would have to keep track of what it has printed already in a buffer and how much of that buffer it wants to print again after the current screen gets wiped. The interpreter cannot make any decision on what the text represents or whether redrawing it would even be appropriate.)

Posted: Thu May 30, 2013 12:28 pm
by Roody_Yogurt
Well, the other idea still sounds intriguing, if it's possible. It'd be great to be able to do meta interpreter commands in-game.

Posted: Wed Nov 23, 2016 2:41 am
by Tdarcos
In order to separate games that need this functionality from those that don't the game would have to indicate it knows what is going on by setting some value or calling a routine (I would normally have said "procedure" but this is Hugo.) Like the way you end a game by setting a specific variable whose name I can't remember and am too lazy to look up to a non-zero value to indicate they won or lost the game.

Otherwise it might produce undesirable results.

If you know much about "real" programming, where you actually use either MS-DOS system calls or the Windows API, you might know that when they implemented long file names, the old MS-DOS open call uses a standard 8+3 file name, and if it is a long file name, it is specified using the "mangled" name with a tilde character and a number added.

However, your DOS-based program can, if it is Long File Name-aware, issue a different open call indicating it is using a long file name argument. (But the mangled name also works here too.)

This addition means old programs still work as expected but new programs that know how to handle it can take advantage of the improved functionality.