Page 3 of 3

Posted: Sat Apr 02, 2016 12:07 am
by Tdarcos
RealNC wrote:Ah, yes. Any sufficiently advanced technology is indistinguishable from magic.

Now, multithreading is not really "sufficiently advanced technology", but let's pretend ;-)
I actually use that line in my book, it's
"Any sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke
"If it is distinguishable, it's not sufficiently advanced."
- Anonymous

Something I thought about with respect to Hugo, can we create a different file format so that the interpreter can be bumped up from 16-bit to 64-bit? So that an older 16-bit application would work but the new format would support more advanced features, such as

* 64-bit integers
* support for floating point (I have this memory of it not allowing it or not providing it)
* 1024 properties, up from 128
* object numbers are 64 bit or perhaps 32bit, possibly signed
* fixing some of the default assumptions in the compiler, so a reference in a room to a string as a destination means you want to print the string and not go there, not attempt to enter the string as if it was a room (possibly make constant objects have a negative number or something to distinguish them from enterable objects) the current behavior in the compiler makes no sense as there really no reason to do it that way
* True string support at least as good as Basic had back in the late 1970s
* Unicode support to encourage use in other non-latin-based character sets
* Support for displaying text right-to-left
* More system functions to support more of the machine's functionality
* Test capability so a program can query the interpreter to determine what's available on this machine

I am thinkling; Hugo can be more than just a game system, it could be used to support any text-based command system or application where the user clicks on things to select them, which might be useful for computer-assisted- / computer-based- instruction and for giving tests.

Posted: Sat Apr 02, 2016 12:50 am
by RealNC
This falls outside the scope of Hugor. It's a Hugo engine front-end (not even an engine implementation; it uses the official engine under the hood.)

Most importantly, it's not a Hugo compiler. Removing the 16-bit limits cannot be done in the front-end or even the engine.

Posted: Sat Apr 02, 2016 9:41 pm
by Roody_Yogurt
RealNC wrote: Typo. You get this back:

30 8888 4 11 22 33 44
As of right now, I have the debugging opcode monitor produce text like this:
[unrecognized opcode 5 attempted]
[unrecognized opcode 10 attempted with 3 arguments (1,2,3)]

Posted: Tue Apr 19, 2016 6:49 pm
by Roody_Yogurt
Tonight I was testing the fade opcode with Guilty Bastards, trying to put together a version with cool fades between rooms and such.

As far as I can tell, fading only affects the current window, eh? Would it be possible to add a fullscreen version that only works off fading in and out of black (as opposed to the current background color)?

Also, for unblocked fades, would it be possible to have an additional time argument that is a wait time before the fade is even begun? Ideally, I'd like to draw some of the screen while it's dark and then fade in to everything already being there.

Posted: Wed Apr 20, 2016 10:01 pm
by RealNC
Hm, it should work for the entire game area. Can you send me the modified version of the game? It would make it easier for me if I don't have to code the test cases in Hugo myself.

An explicit fade-to color and timing parameter should be doable. Although that sounds wrong for your use case. You should do a blocking fade out, update the screen, then do a blocking fade in.

Posted: Thu Apr 21, 2016 4:34 am
by Roody_Yogurt
I'll send the code after work today.
RealNC wrote:You should do a blocking fade out, update the screen, then do a blocking fade in.
The reason I avoided that was just in case the game throws up enough text to have a MORE prompt (or some other instance that holds up the game), I didn't want the player to be caught with a dark screen.

Posted: Sat Apr 23, 2016 7:13 am
by Roody_Yogurt
For the benefit of anyone watching this thread, it turned out that in the case of the transition that was bothering me, I had multiple fades going on and it gave the impression it wasn't fading correctly (and I wasn't fading out quick enough).

Tweaking my code fixed the problem.

Posted: Mon Sep 12, 2016 10:37 pm
by Ice Cream Jonsey
Okay, I think the other thing I need to do is use this version of Hugor going forward, and also put the documentation somewhere.

I'll get us organized.

Re: Random Nikos questions

Posted: Fri Mar 27, 2020 2:31 pm
by Ice Cream Jonsey
I ran a RoodyLib routine called OpCodeAudit and it looks like the Windows version of Hugor I have from October 25, 2019 only supports the first opcode, "IS_OPCODE_AVAILABLE". Does that sound right? Should I be on a later version of Hugor?

Re: Random Nikos questions

Posted: Sat Mar 28, 2020 2:23 am
by RealNC
There is no version released on that date. So I don't know what you have. Version 2.2 is the latest one and released on Apr 6, 2019:

https://github.com/realnc/hugor/releases/latest

Re: Random Nikos questions

Posted: Sat Mar 28, 2020 12:42 pm
by Roody_Yogurt
Op code stuff isn't fully functional on the last uploaded Roodylib. Robb, I'll have to get you something more recent directly or when I upload the newer code.