• Please review our updated Terms and Rules here

MagiDuck, a DOS / CGA text mode game project

I meant pklite, and what you're seeing is definitely not normal:

attachment.php


I would find another source for pklite 1.2x and download it. Here is one such source: ftp://ftp.oldskool.org/pub/misc/xtfiles.rar
 

Attachments

  • dosbox_001.jpg
    dosbox_001.jpg
    24.1 KB · Views: 1
Trixter said:
I would find another source for pklite 1.2x and download it. Here is one such source: ftp://ftp.oldskool.org/pub/misc/xtfiles.rar
Click to expand...

Thanks! Seems like plenty of other interesting stuff to look through there as well :)

Comparing PKLITE from that archive with COMPACK yielded these results in DosBox at 100 cycles:
Game startup time with PKLITE: 11.8s
Game startup time with COMPACK: 8.5s

I'll try other compressors later, but seems this version of PKLITE is out of the question at least.


In other news, some bugs were found in the Beta 2 so I just fixed the download today with these changes:

- Secret level unlocked - popup windows no longer crash when arrow keys are touched.
- Boss death state can no longer be broken by going to the bottom of the level.
- Slight improvement in POW-mode camera handling.

- Also changed tile compression to support color 15. Apparently using 11 for highlights caused some eyestrain. Maybe I was spared due to partial color blindness and a TFT.

Download still at the same URL: http://www.indiedb.com/games/magiduck/downloads/magiduck-beta-2
 
mangis said:
Comparing PKLITE from that archive with COMPACK yielded these results in DosBox at 100 cycles:
Game startup time with PKLITE: 11.8s
Game startup time with COMPACK: 8.5s
Click to expand...

DOSBox can't be used for accurate benchmarking. Each instruction takes 1 cycle. On real hardware, some instructions take more time than others. So while in DOSBox the code with the least instructions always wins, on real hardware, it's often the case that the fastest code is not the shortest code.
At least, not in terms of number of instructions. On 8088 the total code size is very important, for example.

Anyway, as you could see, the benchmarks we did for 8088 MPH pointed out that pklite is one of the fastest solutions around. I highly doubt that COMPACK is more than 3 seconds faster on real hardware.
 
mangis said:
Thanks! Seems like plenty of other interesting stuff to look through there as well :)
Click to expand...

That was the intention! That archive is nearly a decade old but is full of interesting and useful stuff.

Scali said:
I highly doubt that COMPACK is more than 3 seconds faster on real hardware.
Click to expand...

I will investigate! Mangis, can you make your binary of COMPACK available, or let me know where I can grab what you grabbed?
 
Trixter said:
I will investigate! Mangis, can you make your binary of COMPACK available, or let me know where I can grab what you grabbed?
Click to expand...

http://www.dcee.net/Files/Archiver/cpk45.exe

Is where I downloaded my version. The exe will self-decompress the actual files (compack.exe being one of them) in the same folder cpk45.exe is in.

Interesting too see what happens, I wonder why the software was left out of your original compressor test?

I repeated the test in PCem and got similar results, although the speed was locked to the supposed 4.77mhz there. Results were 5.6s and 6.0s (measured manually, twice, like before). Of course Scali is right and these probably mean nothing. Using MIPS.COM reveals how off both emulators are in their instruction cycles.
 
mangis said:
The exe will self-decompress the actual files (compack.exe being one of them) in the same folder cpk45.exe is in.
Click to expand...

Now that I know what the filename pattern is, I found version 5.1 which is newer and I'll test that.

Interesting too see what happens, I wonder why the software was left out of your original compressor test?
Click to expand...

The name implied it only compressed .COM files so I never looked at it. There were a lot of .COM-only compressors.

edit: Author appeared to be a filthy software pirate ;-) as his examples in the documentation are programs that duplicate copy-protected programs, lol.
 
I re-ran the tests in the spreadsheet with compack and pklite and found that compack does indeed compress smaller and decompress faster. Some quick analysis of compack shows:

  • It compresses smaller because it is an optimal parser; pklite is not (it is a lazy parser).
  • It decompresses faster because it uses no order-0 (statistical) compression; it is pure LZSS. No huffman/elias-gamma/etc. codes to depack. This makes the previous point very interesting; it manages to produce smaller files than pklite even though pklite is using order-0 codes (shannon-fano).
Had I not dismissed compack because of its name, we would have definitely used it for 8088 MPH. The person who wrote it was ahead of their time. I updated the spreadsheet with compack info, and I re-timed all the pklite values too just to be sure I was comparing both the same way.

I love learning new stuff in a field where I thought I knew everything!
 
cthulhu said:
I've just spent several hours looking through this very interesting archive. Did you know some of the LHA archives contained in it appear to be corrupt?
Click to expand...

Perhaps you should try a few different unpackers? LHA wasn't a particularly well-specified standard, and I recall having to wrestle around with different unpackers back in the day (I had LHA, LZH, LHARC, probably more variations of tools).
 
I've tried at least four different LHA archivers, including the DOS version included in xtfiles.rar. All give the same CRC error when extracting REDROSE.COM from REDROSE.LHA.
 
Trixter said:
I re-ran the tests in the spreadsheet with compack and pklite and found that compack does indeed compress smaller and decompress faster. Some quick analysis of compack shows:
  • It compresses smaller because it is an optimal parser; pklite is not (it is a lazy parser).
  • It decompresses faster because it uses no order-0 (statistical) compression; it is pure LZSS. No huffman/elias-gamma/etc. codes to depack. This makes the previous point very interesting; it manages to produce smaller files than pklite even though pklite is using order-0 codes (shannon-fano).
Click to expand...

Sounds great! I'll go find version 5.1 too :)

Did you analyze the resulting exe-file or the compressor itself to come to this conclusion?
 
cthulhu said:
I've just spent several hours looking through this very interesting archive. Did you know some of the LHA archives contained in it appear to be corrupt?
Click to expand...

I didn't know some of the *.lha files were corrupt, thanks for letting me know. They appear to be:

Code: 
apputils\SOUND\SPEAKER\1-BIT:

09/21/1989  11:53 AM            62,816 DIGITIZE.LHA
08/24/1989  02:59 PM            28,590 DP.LHA
01/07/1990  04:01 AM            23,105 PASCPLAY.LHA
10/30/1989  12:30 AM            35,328 REDROSE.LHA
08/27/1989  04:41 AM            33,120 TRAN.LHA

...which signals to me that there must have been some single-bit errors when I transferred them to/from the floppy disk. The oldest source I have for them are on my 5160 dev system where they also appear to be corrupt. Whoops!

All of the files can still be used if you extract them except for TRAN.EXE which can be downloaded from other sources online. If I run across the original disks/files, I'll update the archive.
 
Plays great, the load times are much improved. Pretty much the only suggestion I would make to improve the game would be to add joystick support. Is that feasible without causing too much of a performance hit?
 
mangis said:
Did you analyze the resulting exe-file or the compressor itself to come to this conclusion?
Click to expand...

I compressed a small dummy .com and disassembled the resulting compressed file. Other than an elias-gamma-like decode sequence for match length, there's virtually no bit handling. As for it being an optimal parser, that's an educated guess based on the results (I know that pklite is lazy-match so the only thing that could beat it is an optimal parser).

Now I really want to track down the author and talk to him :) It was an impressive achievement to outperform pklite on all fronts in the same years pklite was being developed.
 
Trixter said:
I compressed a small dummy .com and disassembled the resulting compressed file.
Now I really want to track down the author and talk to him :) It was an impressive achievement to outperform pklite on all fronts in the same years pklite was being developed.
Click to expand...

Cool!

I'm sure you already tried "COMPACK -o" to bring up the order form with some italian address on it :)

Great Hierophant said:
Plays great, the load times are much improved. Pretty much the only suggestion I would make to improve the game would be to add joystick support. Is that feasible without causing too much of a performance hit?
Click to expand...

I have some concerns about adding joystick support... Mainly, the game slows down quite abit when there are many sprites or objects in general. Adding even a 10% hit to that might mean making it less playable on target hardware. That might be mangeable if the joystick support can be disabled.

Another thing is the memory usage, which is already very close to exceeding my target of 256KB. Adding more bells and whistles like joystick calibration and new menu code could mean alot more memory usage...

Third, I don't have hardware to test it on at the moment. Looking at things now, I feel pretty dumb to even start developing a game for hardware I have no access to :/

It would be fun to add support for joysticks later, but I think it'd be safer with a complete rewrite in C.

Thanks for the feedback and the mention in your article. Very interesting read once again, I added a link to it from Magi's indieDB site :)
 
mangis said:
I'm sure you already tried "COMPACK -o" to bring up the order form with some italian address on it :)
Click to expand...

I hadn't because that notice is from 1993. I may try harder someday :)

Adding even a 10% hit to that might mean making it less playable on target hardware.
Click to expand...

I disagree somewhat because your framerate is IIRC locked at 24fps. However, as previously discussed, it does take roughly 10% of every screen refresh to read the joystick so if you're near performance boundaries, it may be best to wait.

Another thing is the memory usage, which is already very close to exceeding my target of 256KB. Adding more bells and whistles like joystick calibration and new menu code could mean alot more memory usage...
Click to expand...

Joystick code is about 50 bytes to do the read, so don't worry about that.

Thanks for the feedback and the mention in your article. Very interesting read once again, I added a link to it from Magi's indieDB site :)
Click to expand...

Oh my, that's quite an article!
 
Great Hierophant said:
Nice PVM you have there, is it accepting the CGA signal natively or are you running it through a converter of some kind?
Click to expand...

Natively! This particular PVM has a TTL RGB input on the back, as well as the usual assortment of inputs. So, with a button press I can toggle between viewing composite and digital CGA.

Unfortunately it does suffer from the "Ski Free Dog Pee" yellow problem. (I.e. not remapping dark yellow to brown)
 
You must log in or register to reply here.
Back
Top