Hugo family tree

Hugo programming discussion.
Hugo By Example:
Roody Yogurt's Hugo Blog:

Moderators: Ice Cream Jonsey, AArdvark

Posts: 7
Joined: Sat Mar 04, 2017 3:32 am

Hugo family tree

Post by Dannii » Mon Mar 06, 2017 4:31 am

Hi everyone, I'm hoping to develop another Javascript port of Hugo using Emscripten, but this time with a Glk interface.

In preparation for this I've put together a new repo on Github with all the various versions of the Hugo source I could find:

You might find this page useful to compare between the versions:

It's probably a good sign that there aren't really that many differences between the versions. Hugor has prefixed a lot of the file functions with "hugo_". Version 3.2 is actually even closer to 3.1.03 than hugo-unix.

For my work I think I'll probably build off the hugo-unix code.

Posts: 2044
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

Post by Roody_Yogurt » Mon Mar 06, 2017 5:08 am

I imagine v3.2 has everything you'd find there (and more), but this directory might have some source not covered by the IF archive uploads: (although anything there is also pre-hugo-unix-fix).

Posts: 7
Joined: Sat Mar 04, 2017 3:32 am

Post by Dannii » Sun Apr 02, 2017 6:22 pm

I want to bump the version number of Hugo so that it's easier to track updates in Lectrote etc. Is there anything I need to be aware of - does the version number of "he" impact how games are played, or only the version number of "hc"?

I'm thinking of bumping it to 3.3.0 to indicate a clean start, skipping 3.2 because I haven't (yet, possibly ever) incorporated any of the 3.2 changes from Trac. But I'll only actually change the version number of "he" as I'm not editing "hc" or "hd" at all.

User avatar
Posts: 6270
Joined: Fri May 16, 2008 9:25 am
Location: Arlington, Virginia

Post by Tdarcos » Sun Apr 02, 2017 7:37 pm

This may be already taken care of in the prior implementations but I'll mention it anyway.

The Hugo language as implemented by the compiler is a 16-bit environment. This should be something to be aware of in case some programs might generate numbers exceeding 16-bits unless the compiler already takes care of this.

I do not remember if Hugo supports floating-point numbers, if so then the probably current 64-bit IEEE floating point will have larger precision and bigger numbers than Hugo originally did.

The string handling is based upon DOS 8-bit ASCII, if JavaScript operates string handling in Unicode this may be something to be aware of if it might cause problems.
"Try to stop my hands from shaking."
- The Outfield, Your Love

User avatar
Posts: 14034
Joined: Sat Apr 27, 2002 3:00 pm

Post by pinback » Sun Apr 02, 2017 8:39 pm

Not a single word of that had anything to do with anything this thread was about, Paul.



BU YAO!!!!!
Above all else... We shall go on... And continue!

Posts: 119
Joined: Fri Jun 27, 2003 12:10 pm

Post by Kent » Sun Apr 02, 2017 8:52 pm

Roody brought this to my attention and I remembered my password so, you know, big day for me here.

I'd say bumping the version number makes sense. I mean, there are obviously some hiccups with the last (official) release, so any updated/refined version will almost certainly be preferable. The effect of bumping the version should be that version 3.3 will open 3.2 and earlier but 3.2 won't open 3.3, so if any changes are made to improve 3.3, they won’t cause problems when using an older engine.

So in fact it's the right thing to do, especially if there are likely to be any improvements/optimizations/whatever.

Know what I mean?

And yeah, the existing engine is totally 16-bit.

Posts: 7
Joined: Sat Mar 04, 2017 3:32 am

Post by Dannii » Tue Apr 04, 2017 4:26 am

Good to hear from you Kent!

The biggest reason I want to bump the version number is because of the fractured state of development Hugo is currently in. I can't fix that myself of course, but at least it will be a little bit clearer. I'm not planning to change the gamefile format, but whenever that happens we can bump the version again.

Post Reply