Project

[Garth's Equipment Shop]

I have been wanting to start learning how ACK works under the hood for a long time. I have the source and all and have examined the code a few times. It's just difficult to see any orderly arrangement for the source files so that is what I've been working on mostly with the source is trying to identify what each source file contains and what all each file depends on each other file for and that sort of thing.

Its a daunting task but I really feel someone has to do it before any real headway can be made with bug fixes and in my dream world the glorious day when us die hard ACK fans collaborate on some sort of source documentation and perhaps even a complete rewrite of all the source code so all the bug fixes and features that Chris had to sort of hack in will actually be planned for and truly built into it. AAND maybe even use the most recent version of Pascal to do it!

As far as I know the most recent descendent seems to be Free Pascal. http://en.wikipedia.org/wiki/Free_Pascal Last updated this year. And according to the wiki it tries to retain backwards compatibility with older code such as Turbo Pascal and Delphi.

Quoted from wiki:

In addition to its own Object Pascal dialect, Free Pascal supports, to varying degrees, the dialects of several other compilers, including those of Turbo Pascal, Delphi, and some historical Macintosh compilers. The dialect is selected on a per-unit (module) basis, and more than one dialect can be used to produce a single program.

A member of the write once, compile anywhere campaign, Free Pascal is available for many architectures and operating systems

Free-Pascal Website

[Tdarcos]

I wrote a program for ICJ using Free Pascal that was a conversion of a Delphi program to create a maze and in this case, write it out in a form usable for an Adventure game programming language. While it generated code for Hugo, it was still a good tool for implementing an otherwise tedious, repetitive task.

Jonsey and Pinback call it "The Genesis Device" and Jonsey said he was very pleased with it.

Thing was, while the original program I modified was written for Delphi, I was able to compile the program for both Windows 7 64Bit and for the old 32bit Power PC Macintosh, and except for the fonts being different sizes, the same program, unmodified, will compile correctly, and run identically on both platforms, Windows and Mac OS X.

I also wrote a program 16 years ago in Turbo Pascal. It was designed to test the possibility of the time and the date not being synchronized if a program was running when Midnight occurred between the date request and the time request. Originally run on a standard PC, it did about 6,000 date/time requests in one second.

The same program written for Turbo Pascal 16 years ago, except changed to write to a form instead of writing to the screen, was re-run under Free Pascal. On my 32-bit Macintosh, it was able to issue about 3 million time requests in one second. On my quad-core 64-bit Windows 7 machine, it did about 14 million requests in one second.

Yeah, Free Pascal is very compatible with Turbo and Delphi. In fact, I'm working on figuring out how to do a port to the IBM 370 / zSystem mainframe.

[Garth's Equipment Shop]

Awesome thanks for the confirmation Tdarcos. Hmmm... You wouldn't be interested in volunteering your Free Pascal expertise to the unborn ACK source rebuild project by chance would you? :)

[Tdarcos]

Awesome thanks for the confirmation Tdarcos. Hmmm... You wouldn't be interested in volunteering your Free Pascal expertise to the unborn ACK source rebuild project by chance would you? :)

Possibly. But isn't ACK primarily written to run under DOS as opposed to being a Windows application?

It would require redesigning the system to draw on a window instead of a graphic image in MSDOS mode which wasn't that hard to do back then.

[Ice Cream Jonsey]

Awesome thanks for the confirmation Tdarcos. Hmmm... You wouldn't be interested in volunteering your Free Pascal expertise to the unborn ACK source rebuild project by chance would you? :)

Brian, don't!!

[Tdarcos]

Awesome thanks for the confirmation Tdarcos. Hmmm... You wouldn't be interested in volunteering your Free Pascal expertise to the unborn ACK source rebuild project by chance would you? :)

Brian, don't!!

Wrong metaphor, Jonsey. I have no interest in breaking out in a chorus of "Bird is the word."

But, the point being, if the intent is to bring ACK up to date so it can be a Windows / Mac / Linux graphical application running in a window instead of what it is now, which is a cheesy CGA-class DOS application, it's going to require significant Don Rogering, err I mean retooling.

Has he considered what he wants the new program to do, and is it going to have added functionality, and what sort of things will be added? Will it add a lot of what Hugo can do, i.e. sound, video, triggers, fuses and a bunch of other things? (I'm not familiar with ACK since I went with Hugo, so I don't know what the original system did, despite the fact I host on one of my websites a large Adventure game library available for downloading. I posted the link here once.)

I read one of the messages Garth has posted, from some of what I gather based on the names, a lot of the code which was written to get around the limitations of DOS is unnecessary now, specifically the overlay structure and memory management. I mean, with most computers routinely holding 4 GB of memory and/or being 64 bit machines, the need to squeeze into less than 1 megabyte are long gone.

The only thing I find unfortunate is because of the heavy use of objects, any Free Pascal application designed to run as a Windows-based application will take a minimum of 14 megabytes just for the executable.

[Admiral Ackguh]

I suppose you could ask Chris or "rld" for their notes on the Pascal source code - if they still have them. This particularly applies to Chris. I have found from experience that coming back to an old programming project means having to figure out not just the code but documentation as well, unless you documented it very well.

[Tdarcos]

I suppose you could ask Chris or "rld" for their notes on the Pascal source code - if they still have them. This particularly applies to Chris. I have found from experience that coming back to an old programming project means having to figure out not just the code but documentation as well, unless you documented it very well.

I was interviewed for a programming job (in COBOL) in Baltimore back around November, and when I was asked what would be the first thing I would do if I was hired, I said I'd probably spend several days reading the code other people wrote there, because I'd need to make sure I follow the coding standards other people there are doing, because it doesn't matter how long I work there, some day I'm going to leave, and someone else is going to have to maintain the code I'm working on.

I said that otherwise you can end up with the condition where you look at some code that you can't figure out what it is doing, you say, "What brain-dead moron wrote this code?" and you discover the brain dead moron who wrote it six months ago was you, because you're the "someone else" who has to maintain the code you wrote.

[Admiral Ackguh]

Something strange has happened to my message.

It originally looked like this:

I suppose you could ask Chris or "rld" for their notes on the Pascal source code - if they still have them. This particularly applies to Chris. I have found from experience that coming back to an old programming project means having to figure out not just the code but documentation as well, unless you documented it very well.

Now it looks like this:

Precisely. For example, there are a lot of self descriptive variable names...[rest deleted]

Someone else posted that second message, but it ended up under my name, and it overwritten my original. There is a bug (and security issue) with this webpage.

[Garth's Equipment Shop]

Damnit sorry Admiral. I think I accidentally hit edit while reading your post instead of quote like I meant to. Very sorry.

Its not a bug, I just forget I have moderator powers sometimes. :D
K its fixed now... and heres my response that was previously hijacking your post - hehe.

I suppose you could ask Chris or "rld" for their notes on the Pascal source code - if they still have them. This particularly applies to Chris. I have found from experience that coming back to an old programming project means having to figure out not just the code but documentation as well, unless you documented it very well.

Precisely. For example, there are a lot of self descriptive variable names for things like player stats and such but those variables that serve more technical under the hood purposes seem to have more cryptic names. Would be nice to understand the naming conventions he used a little better. Hopefully there was some sort of method to the madness and not just random names he once had written somewhere to keep track of but then lost or threw away/deleted.

But even if that were the case I would not be discouraged. I remember the days of trying to figure out where variables are stored and what they do with a hex editor in order to get more lives or better stats in a game. If that can be done without ever seeing any readable code or variable names then surely having access to all the precompiled code and all variable names makes our job simply a matter of walking through the code, following loops and procedures and functions to see where they take us.

[Admiral Ackguh]

Damnit sorry Admiral. I think I accidentally hit edit while reading your post instead of quote like I meant to. Very sorry. Its not a bug, I just forget I have moderator powers sometimes. :D
K its fixed now... and heres my response that was previously hijacking your post - hehe.

OK ... sometimes I get paranoid. :)

[Admiral Ackguh]

For example, there are a lot of self descriptive variable names for things like player stats and such but those variables that serve more technical under the hood purposes seem to have more cryptic names.

That's the problem with (modern) languages that allow longer variable and procedure names. Not all these names are self-descriptive. With more primitive languages, such as 8-bit BASIC, or ACK for that matter, you need to keep a side record of what each variable does!

I remember the days of trying to figure out where variables are stored and what they do with a hex editor in order to get more lives or better stats in a game. If that can be done without ever seeing any readable code or variable names then surely having access to all the precompiled code and all variable names makes our job simply a matter of walking through the code, following loops and procedures and functions to see where they take us.

The good old days of save-file hacking! :)

I used to do this extensively with Roadwar 2000 and Roadwar Europa - and a D&D comp game that got stuck because of a bug. I just lost my patience, hacked the save file, and finished the game. This was in the days before Internet, where I had to figure out everything by myself and a few friends.

[Garth's Equipment Shop]

The good old days of save-file hacking! :)

I used to do this extensively with Roadwar 2000 and Roadwar Europa - and a D&D comp game that got stuck because of a bug. I just lost my patience, hacked the save file, and finished the game. This was in the days before Internet, where I had to figure out everything by myself and a few friends.

Information Age Stagnation or WHAT HAPPENED TO MY FILTER?

Yep. Isn't it amazing the things we were able to accomplish without google back then? Makes me wonder why now that we have so much more information at our finger tips and so much more powerful systems and so many cool things to tinker with out there now, we don't seem to pull off such amazing feats anymore. Is it similar to how game programmers and pixel artists back then pulled off amazing feats because they were forced to work within the hardware restraints of the time?

Restraints or limitations force us to narrow our focus and concentrate all our powers on just one or a few specific things whereas today we have virtually no limits and so many options and information and resources at our disposal that we can too easily piss away all our time just exploring all our options or trying too many things and never fully committing to just one or a few. Thus we stagnate.

Now I remember something I learned back in business psychology about how the mind works. Our brain has the capacity to store way more information than we can actually utilize, and our senses actually reflect this by taking in way more than we are able to process. So our conscious mind filters most of what our senses are picking up and forces our brain to narrow it's focus on just what is most important. So why is it so hard to stay focused on what is important to us now in the information age?

If you (anyone reading this) do not have this problem and somehow avoid stagnation when confronted with the endless possibilities and vast explorable information landscape of the interwebs please share your secret with me and everyone else who shares my problem. How do you do it? What is the trick to avoid short circuiting the normal function of our conscious mind's filtering mechanism and thereby overloading our brain's processing powers?

[Admiral Ackguh]

Yep. Isn't it amazing the things we were able to accomplish without google back then? Makes me wonder why now that we have so much more information at our finger tips and so much more powerful systems and so many cool things to tinker with out there now, we don't seem to pull off such amazing feats anymore. Is it similar to how game programmers and pixel artists back then pulled off amazing feats because they were forced to work within the hardware restraints of the time?

To think back on such masterpieces as Star Control 2 which was developed by two guys who rented a cabin in Alaska for six months, on just two 486-class PCs, with no internet access at all!

Restraints or limitations force us to narrow our focus and concentrate all our powers on just one or a few specific things whereas today we have virtually no limits and so many options and information and resources at our disposal that we can too easily piss away all our time just exploring all our options or trying too many things and never fully committing to just one or a few. Thus we stagnate.

Problem #1: Time is not one of those resources that increases with greater information access.

Problem #2: Feature creep.

Now I remember something I learned back in business psychology about how the mind works. Our brain has the capacity to store way more information than we can actually utilize, and our senses actually reflect this by taking in way more than we are able to process. So our conscious mind filters most of what our senses are picking up and forces our brain to narrow it's focus on just what is most important. So why is it so hard to stay focused on what is important to us now in the information age?

Maybe it is harder to know what is important?

I found that it helps to write down (on a piece of paper) the main goals and sub-goals in tabular or tree form. Keep it short and sweet. Paste that sheet above your monitor, or in another place easily visible. Always ask yourself: Is it good enough? Does it work? If so, then that step is finished. Move on to the next one. I tedn to get bogged down in details, refinements, and "making it perfect."

[joebonk]

Good questions Garth.

Wonderful points Admiral Ackguh.

I think it is never assuming it can't be done.
If there is an idea, and you are given only so much to work with.
You ask yourself, how do I get it working?

It's like the Apollo movie when Tom Hanks was stuck in space, and was running out of air. And Houston put a pile of objects on the table and said "We need to make an air filter out this stuff. Get to it."
When it is a fun hobby, then maybe their isn't the tension involved, but the idea is the same.

I also think a very big plus is to never form ideas with the platform in mind. Let the platform conform to the idea.
For games, tell a story, a story that you would have fun making in any era, even if it had to be a board game.

The mind gets foggy when we satiate our senses. So much visual media begins to blur. So many meals seem more a routine then a treat. The appreciation diminishes. And this is the doorway to lethargy and being on auto-pilot constantly.

To break the stagnation, break the routines. Saturate attention with something different, anything will do. But I find the more adverse to the appetite (or to the ego) the action is, the better the results. Controlled dissociation does not bring chaos, but order. Perhaps the real chaos is putting all of our eggs in one basket.

[Admiral Ackguh]

It's like the Apollo movie when Tom Hanks was stuck in space, and was running out of air. And Houston put a pile of objects on the table and said "We need to make an air filter out this stuff. Get to it."
When it is a fun hobby, then maybe their isn't the tension involved, but the idea is the same.

I just love the movie Apollo 13. It's an object lesson in problem solving, even for the problems that at first seem unsolvable.

I also think a very big plus is to never form ideas with the platform in mind. Let the platform conform to the idea. For games, tell a story, a story that you would have fun making in any era, even if it had to be a board game.

And let the implementation details follow the overall plan.

To break the stagnation, break the routines. Saturate attention with something different, anything will do. But I find the more adverse to the appetite (or to the ego) the action is, the better the results. Controlled dissociation does not bring chaos, but order. Perhaps the real chaos is putting all of our eggs in one basket.

That's good advice, too, for any creative work.

I believe Kurt Vonnegut said "have the guts to cut". Don't get too attached to certain details.

[Garth's Equipment Shop]

Heya Totoro. I was rereading some posts to make sure I didn't miss anything important and I noticed something in your macros I hadn't noticed before.

I am having some problems with the marco language and wanted someone to look it over and tell me if I'm doing something wrong.

The title sequence runs the following macro to set up T = 1 (meaning our heroine is dehydrated and thirsty):

Macro 11: INITIAL MACRO
1: SET T = 1
2: STOP

Then, I want her to lose HP every turn until she finds water:

Macro 8: HOURLY MACRO
1: IF T = 1 THEN 3
2: STOP
3: SET HP = HP - 1
4: SMSG 2
5: STOP

Finally, she discovers a drinking pot that refreshes her and gives EXP, unless she is no longer thirsty:

Macro 12: DRINKING POT
1: IF T = 0 THEN 5
2: SMSG 9
3: SET T = 0
4: SET EXP = EXP + 100
5: STOP

So far, it isn't working. Macro 8 does not fire. It's previous version fired no matter what:

Macro 8: HOURLY MACRO
1: IF T = 0 THEN 4
3: SET HP = HP - 1
4: SMSG 2
5: STOP

The previous version of macro 8 appeared to fire no matter what because you have it going to line 4 instead of 5 when T=0. Line 4 is the message you get when your thirsty I assume and it fires everytime you lose hp, while T=1. Thus the message was shown whether T=0 or T=1.

Now as to why the other version of your macro never fires that I couldn't say without looking at your actual adventure and everything in it. But from the looks of the macros you've shown us I would expect it to fire repeatedly provided the Title macro does it's job of assigning 1 to T every game.

However I would also expect it to never fire again after drinking the flask because the flask turns T to 0 and as far as I can tell there is nothing to turn T back to 1 again until you start a new game and the Title macro can be run again. So perhaps that is the actual problem you were describing. Solution then I would say is to start a counter after drinking flask, and increment the counter every hour and after so many hours turn T to 1 again to begin thirst over again.