Faster picture drawing for GAC adventure games

[Bruce Abbott]

Here's a patch for people who love playing games created with Graphic Adventure Creator, but hate waiting while the pictures render. My code dramatically speeds up filling areas, and also eliminates unnecessary drawing of the picture frame after each fill command. The result is up to 8 times faster rendering and more enjoyable game play.

I originally wrote this patch in 1986.  Sadly the source code was lost when I gave the CPC664 to my father a few years ago, so I had to write it again from scratch! The good news is that this second version is even faster than the original.

If you play games in WinAPE or WinCPC then the easiest way to apply my patch is simply run the game, then load and assemble the source code "gac-fill.asm" into memory. This only takes a few seconds, but has to be done every time the game is run (including each section of a multi-part game).

If you want to permanently patch a game then run the BASIC program 'PATCH.BAS" (found in the disk file "gac patch.dsk"), insert your game disk, then enter the name of the executable to patch (a binary file typically around 40K long) and it will create a patched version of the file. After it returns to the prompt you should reset the computer/emulator to ensure that its memory is cleaned out. This procedure is quite straightforward, but there are a few things to watch out for:-

1. The files that need patching may be read-only and/or hidden, in which case you should change their attributes before patching them.

2. My patch doesn't overwrite any files. If the game is multi-part then you might need to delete each original file after patching it, to reclaim space on the disk.

3. The original file name may not end in ".BIN". It could end in ".BAS" or have no extension. Depending on the particular extension and whether or not you type it in, the patched file may be created with a different name. To continue running the game via its loader you may need to rename the patched file to match the original.       

NOTES:

GAC executables are standalone binary files which load at address &0040 (wiping out any BASIC program that was there) and can be run by simply typing RUN"<name>". Some games are started via a short BASIC loader which allows you select the part you wish to run or display an intro screen etc. but this has no effect on the main game.       

On the included disk file are two versions of the game "Timer Traveler" - one is the original, and the other is the faster 'patched' version. You can see how well the patch works by running each one in turn. To try out the patching procedure run "PATCH.BAS" and enter the name "TIME.BAS". This will create a new file "TIME.BAS" and rename the original to "TIME.BAK".
     
The .asm files on the disk are for reference only, they are not required for patching files or running the game.
           

[ervin]

That's fantastic!
The difference is astonishing.

It makes the games a heck of a lot more playable.

[Gryzor]

So you picked up the project again 27 years later? Wow.

[Bruce Abbott]

So you picked up the project again 27 years later? Wow.

I know. It's crazy, right?

And to think that a few weeks ago I was cleaning out all the useless old computer junk that I have collected over the years, spied a 6128 in the back of the cabinet and thought 'Oh well - perhaps before trashing it I should give it one more spin, just to see if it still works..."
     

[EgoTrip]

I never got on with GAC, but its good to see this.

Do you have any other goodies from the olden days?

[Bruce Abbott]

Do you have any other goodies from the olden days?

Not much. I was working on an adventure game, but got distracted by a shiny new Amiga 1000.

I developed a few hardware mods, including a 256k internal RAM upgrade for the 664 (sold quite a few of those, some of which might still be around in New Zealand). Unfortunately all the circuit diagrams are lost. My own 664's keyboard went bad so I threw it away (doh!).

I ported the CHAMP assembler/debugger from Spectrum to CPC, and my friend Ralph Dames put it in ROM. I still have the ROM and some source code, so I might might release it if I can fix the remaining bugs and make it a bit more user-friendly.
 

[Munchausen]

This is awesome! Got to try it out next week.


BTW people on the forums will scramble for your broken CPCs, especially 664s, so if you can it'd be great if you put a post on here before throwing them!


Hope you're holding on to your 6128 now?

[Bruce Abbott]

Hope you're holding on to your 6128 now?

It's had very little use and is in mint condition, and I had the foresight to disconnect the drive belt before putting it into storage all those years ago. So yes, I'm holding on to it. 

[SyX]

Gret Work Bruce Abbott!!!

I have patched the spanish games made in GAC to use your fill routine and they are a lot faster

A few years ago, i patched those games to use other font instead of the system font (using TXT_SET_M_TABLE, before loading the games), in the same way that zx gac does:
[attach=2]

We only need to replace the system print char (TXT_PRINT_CHAR) for a faster version and then they will fly

[Gryzor]

"before trashing it"?!


Dear gods...

[arnoldemu]

We only need to replace the system print char (TXT_PRINT_CHAR) for a faster version and then they will fly

Does it only need to display letters, or does it need to execute control characters and to change colours?

I already have a function that makes 6 pixel wide chars, so I could edit this to work with mode 1 chars and speed this up

[SyX]

Does it only need to display letters, or does it need to execute control characters and to change colours?

I already have a function that makes 6 pixel wide chars, so I could edit this to work with mode 1 chars and speed this up

Yes, only needs to display letters, no control codes and no change of colours (the text is always in pen 1). And because those interactive fictions games make a heavy use of the firmware, an increase of speed in print text, it will accelerate the play of this games a lot

[Sykobee (Briggsy)]

I'm certain I remember that some GAC games used control characters to get some colour effects... or was that just me messing about in my copy?


Oddly enough I think a variable width font option would work very well in some GAC games ... at the cost of requiring more memory for the font definition and rasteriser :-(

[SyX]

I'm certain I remember that some GAC games used control characters to get some colour effects... or was that just me messing about in my copy?

I would say that for zx yes, but for CPC i don't remember any now... but i would be glad of trading colour by speed any day, jejeje.

Oddly enough I think a variable width font option would work very well in some GAC games ... at the cost of requiring more memory for the font definition and rasteriser :-(

Exactly like this Athough it has been a few years since that demo was published.

It has been a few interesting threads in wos about using proportional fonts, like this, that it could be ported to the CPC without too much effort.

Off-topic to this thread, another very z80 interesting threads of wos about compression are this and this.

[Sykobee (Briggsy)]

That FZX looks like a good candidate for a CPC port.  I also recall some articles in ACU(?) a long time ago about such text - a table of per-character widths was required, but this FZX is clever in not storing blank lines of the font... although that means it must also store an address of each character in the table as you can simply multiply char#*8 to get an address.


I wonder how SymbOS does its proportional fonts...

[cngsoft]

I've been following this thread since Nich pointed me here, and while the patch is brilliant and I've succesfully included it into several "compactages" of mine, I'd like to say a couple of things:

1.- the single RET must be disabled in several games. "La Guerra de las Vajillas" is a case of the bucket fill merging with the frame and flooding the screen:



A less serious case is "Don Quijote" where no flood happens but frames are still corrupted.

2.- GAC does use control characters: for example, press ESC when you're supposed to enter a line, and notice the change of colour - it's done with CHR$(15)"3ESC"CHR$(15)"1". Several games use them as well, for example the aforementioned "Don Quijote" that uses different colours in several messages (inventory, "what do you say?", etc.)

[Bruce Abbott]

1.- the single RET must be disabled in several games. "La Guerra de las Vajillas" is a case of the bucket fill merging with the frame and flooding the screen:

Please try this new version 1.1, which avoids redrawing the whole picture frame by repairing it after each fill.

For this patch I had to steal space used by the frame redraw routine for my code. As far as I can tell this routine is not used anywhere else. However, if some other part of the game does try to call it then it will probably crash!

I think some beta testing would be a good idea, so until it is proved to be stable I am only providing the source code (for use with WinAPE etc.).

[Bruce Abbott]

With this new patch applied, the picture in your "La Guerra de las Vajillas" example (Cabina De Navegacion) renders in less than 4 seconds, compared to 11 seconds with the original code.


BTW since I didn't know which location that was in the game I went through the entire first part, when I could have just used the password for the second part! (and my Spanish is nonexistent...). Anyway, that's one game that seems to work fine.

[cngsoft]

Your solution to the edge corruption is wonderfully clever :-) Now "La Guerra de las Vajillas" and "Don Quijote" look perfect and run like the lightning!

[Bruce Abbott]

Please forgive me, I have another update!

Version 1.2 constrains the fill to inside the picture area, so there is no need to 'repair' the sides of the picture frame. Large fills are a tiny bit slower, but small fills are faster.  The picture "Cabina De Navegacion" now renders in 3 seconds.

[SyX]

No problem Bruce, feel free of making of the updates you like, in my case i have everything automatized for adding your patches

[jbaudrand]

It's amazing to read this in 2013. thanks for updating your routine.

[Bruce Abbott]

I managed to shave a few bytes off the code, so here is V1.2b - which is a _tiny bit faster. 

As this version is small enough to fit within the original fill code space and seems to be stable, I have also updated the patch disk. 

[Kukulcan]

I adding a little article in cpc-power 

[SRS]

To get this old topic up again:

I just found it, amazing

Did someone do the "fast text" patch inbetween ?

And is someone able to redo the "look" command - it does not need to redraw the picture each time. Would it make faster.

And third: is there a patched GAC that puts out faster games "out of the box" without need of patching afterwards ? Could be a "push" for more adventure development maybe.