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.
That's fantastic!
The difference is astonishing.
It makes the games a heck of a lot more playable.
So you picked up the project again 27 years later? Wow. :D
Quote from: Gryzor on 20:35, 09 November 13
So you picked up the project again 27 years later? Wow. :D
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..."
I never got on with GAC, but its good to see this.
Do you have any other goodies from the olden days?
Quote from: EgoTrip on 22:21, 09 November 13
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 (http://www.worldofspectrum.org/infoseekid.cgi?id=0008012) 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.
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? :)
Quote from: Munchausen on 00:42, 10 November 13Hope 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. ;D
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 :)
"before trashing it"?!
Dear gods...
Quote from: SyX on 10:39, 10 November 13
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 :)
Quote from: arnoldemu on 10:54, 11 November 13
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 :)
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 :-(
Quote from: Sykobee (Briggsy) on 14:56, 11 November 13
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.
Quote from: Sykobee (Briggsy) on 14:56, 11 November 13Oddly 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 (http://www.worldofspectrum.org/forums/showthread.php?t=34693) ;) 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 (http://www.worldofspectrum.org/forums/showthread.php?t=44088), 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 (http://www.worldofspectrum.org/forums/showthread.php?t=42037) and this (http://www.worldofspectrum.org/forums/showthread.php?t=42176).
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...
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:
(http://cngsoft.no-ip.org/guerraex-gac_bug.png) (http://cngsoft.no-ip.org/guerraex-gac_fix.png)
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.)
Quote from: cngsoft on 22:09, 12 November 131.- 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.).
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.
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!
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.
No problem Bruce, feel free of making of the updates you like, in my case i have everything automatized for adding your patches :)
:) It's amazing to read this in 2013. thanks for updating your routine.
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.
I adding a little article in cpc-power (http://www.cpc-power.com/cpcarchives/index.php?page=articles&num=316) :)
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.
Quite some time back (when I used the Caprice emulator) I used GAC and discovered a problem with the graphics that I had created. Everytime I chose one of my creations the image displayed looked messy and displayed lines and shapes which I hadnt included.
Maybe it was Caprice which caused the issues? Never the less, I had alot of fun milking as many colours out of the 4 allowed with stipple mode :)
I really love the patch, the GAC was known for drawing the pictures a bit slowly and the patch vastly improves this. Regarding the creation of new games with the GAC, I guess that I would be choosing PAWS or DAAD all the way but it is a question of personal preference :) . I think that the biggest difference is that the GAC allows you to use complex conditions, something not possible with PAWS. Moreover, using vectorial graphics is much more tape friendly, since the PAWS graphics patch requires loading the graphics in real time (although they can be much more detailed). Those two things make the GAC to stand out.
Problem nowadays is that the GAC is an application by itself, based on a menu system, whilst the CPC version of PAWS is just a compiler, an interpreter and a graphics patch. This allows coding in the PC using the text editor of your choice and then compiling the game the same as if you were coding in any other language. I find this, that was a problem in the past, extremely convenient nowadays because it allows you to annotate the code as much as you want and organize and edit it in a very efficient way. For example, the code of our game including annotations is more than 350KB, and this is a blessing because the vast amount of notes allows me to navigate it very fast. Another advantage is that PAWS interpreter, including the graphics patch, only uses 13.5 KB of RAM. The rest is free for the adventure and loading graphics does not consume additional memory, you can add as many graphics as you want if they fit in the floppy.
Nevertheless, GAC is a great parser, way better than the Quill in my opinion, and there are great games written with it. It just happens that, by chance, working with PAWS for the Amstrad is still very user friendly nowadays and allows seamless integration with PC tools, like Scite, Photoshop... (the same is true for the DAAD). This is a bit of a paradox, in the past if you were working with PAWS you had to write all the code in CP/M using a text editor and I can imagine that it was a bloody nightmare :-X :-X
You are right, ||C|-|E||: I made the CPC version of CommodorePlus games (Mansión Kali 1+2 and The Prisoner) by using The Quill in emulators and it was worse than a chinese torture, even when I was using some emulation acceleration!
thx for your updates !
after my actual project (porting an old short c game to cpc) i may have a look at paws (and the patch for it).
I had GAC back in the day made a couple of games but was never happy enough with them to send them out
Quote from: dcdrac on 22:48, 18 August 16
I had GAC back in the day made a couple of games but was never happy enough with them to send them out
Well, perhaps you could recover them for us ;)
I'd love to use this on hte games I made using GAC but sadly, they no longer exist...
they were on discs long since gone sorry