Image Map Image Map
Page 17 of 21 FirstFirst ... 7131415161718192021 LastLast
Results 161 to 170 of 204

Thread: MagiDuck, a DOS / CGA text mode game project

  1. #161
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    Quote Originally Posted by Scali View Post
    Well, you could also take a page from the book of C64, and make it a double-sided game?
    On the PC, this requires physical modification of the disk jacket to add an index hole on the other side. (Jacket only -- do NOT punch another hole into the wafer!) I've done it a few times successfully with a hole punch, but that's asking a bit much for end-users. 360KB is perfectly reasonable.

    (The C64 didn't use the index hole IIRC.)
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  2. #162

    Default

    Quote Originally Posted by mangis View Post
    The game folder is 162 KB. I hope fitting into a 180 KB floppy is still acceptable for a 5150 release?
    While it's acceptable, it would take a bit longer to load than necessary, and you may be spending more time blitting than you need to as well.

    Like looking at your CTG files, I really think you could benefit from a simple RLL encoder. You don't even need to get fancy with it... just use one bit as a flag of "repeat next byte x times" or "blit next x bytes raw". Looking at all the repeated bytes in those files, I think 8:1 or even 10:1 from a control:data word width should be possible. Less disk access and decoding == faster program load, always a good thing.

    ... and if you REALLY know ahead of time that certain bytes are used in long runs more than others, a variable byte-width encode specific to the data could offer even more benefits.

    I think you could probably cut the distro size in half, and possibly speed up the codebase as well.
    From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.
    CUTCODEDOWN.COM

  3. #163
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by Trixter View Post
    On the PC, this requires physical modification of the disk jacket to add an index hole on the other side. (Jacket only -- do NOT punch another hole into the wafer!) I've done it a few times successfully with a hole punch, but that's asking a bit much for end-users. 360KB is perfectly reasonable.
    I thought they sold those as-is as well. I know I have a few of these floppies in my collection, and they don't seem 'home-made'.
    Anyway, that's up to the end-user as I say. They could still put it on a single 180KB or 360KB disk and the 'flip disk'-part would never be triggered (it is my understanding that the 160KB disks were a software limitation, not a hardware limitation. Using DOS 2.x should allow 180KB disks even on the earliest 5150s).

    Quote Originally Posted by Trixter View Post
    (The C64 didn't use the index hole IIRC.)
    Nope, you just had to cut a hole in the other side to remove the write protection

    Edit:
    It seems they are called 'flippy disks': http://ascii.textfiles.com/archives/4226
    Last edited by Scali; December 10th, 2015 at 04:08 AM.

  4. #164

    Default

    Quote Originally Posted by deathshadow View Post
    Like looking at your CTG files, I really think you could benefit from a simple RLL encoder. You don't even need to get fancy with it... just use one bit as a flag of "repeat next byte x times" or "blit next x bytes raw". Looking at all the repeated bytes in those files, I think 8:1 or even 10:1 from a control:data word width should be possible. Less disk access and decoding == faster program load, always a good thing.

    ... and if you REALLY know ahead of time that certain bytes are used in long runs more than others, a variable byte-width encode specific to the data could offer even more benefits.

    I think you could probably cut the distro size in half, and possibly speed up the codebase as well.
    Since over half of the distro comes from the 90Kb executable I wouldn't be so optimistic until the game would be rewritten in C or such.

    The wasteful CTG-files are there because they are very fast to load with Qbasics BLOAD. The slow level loads are mainly due to RL decoding written in Basic, where almost every tile requires converting from string to integer among other string related issues.

    I can see the loading times are a bother though so I should probably rewrite all the file loads in Assembly.

    I actually tried a naive RLE on the tileset files already but ended up increasing the file size from before. A quick try to make it less naive this morning turned up with a 75% compression. I'll try your suggestion tonight since I didn't try the flag bit but a flag byte to inform a run was beginning.

    The amount of potential runs looks pretty small to me though. Just considering that most tiles have outlines means that only two bytes could form a run and only if the middle area is a solid color which is a rare occurrence.

    Might also be interesting to try to store 15 most used bytes in a "palette" table and XLAT those. Value 16 could instruct the decoder to read a literal value instead. The background tiles might benefit from that especially.

    Just realized that the maximum value for a tile in the level files is 59 so I could easily use the highest two bits for RLE flags. Let's see what happens...
    Last edited by mangis; December 10th, 2015 at 06:31 AM.

  5. #165
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by mangis View Post
    Since over half of the distro comes from the 90Kb executable I wouldn't be so optimistic until the game would be rewritten in C or such.
    I take it you already ran pklite on the exe?

  6. #166

    Default

    Quote Originally Posted by Scali View Post
    I take it you already ran pklite on the exe?
    No, never heard of that. Thanks for the tip!

  7. #167
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    Wow, you really are new at this which makes your progress all that more impressive. Yes, executable packers were a thing. There is a noticeable delay when starting an executable, but since you only do that once, it's a small price to pay for a smaller executable.

    pklite shrinks duck.exe down to 57K. So there's some free space for you. There are other packers that will crunch it more, like UPX and APACK. Let's check:


    raw DUCK.EXE 91,294
    pklite 57,295
    APACK -x 53,413
    UPX --8086 --ultra-brute 53,408

    You get an extra 4K using better packers, but the start-up time is noticeable. pklite does a "good enough" job while being nearly transparent to decode. When I was writing portions of 8088 MPH, I benchmarked many packers with many different types of binaries and found that pklite was the decompression speed king, so much so that it actually sped up loading times from floppy disks. Results here.

    What will really bake your noodle is deciding whether or not you should convert all of your assets to binary objects and then link them into one giant executable. You can then compress the entire executable. This saves disk space and time at the cost of higher memory requirements (all of your assets are always loaded into memory). If your memory target is lower than your available disk space, you wouldn't do this.

    Edit: I just checked the memory utilization of DUCK.EXE and it uses 198704 bytes of RAM (I showed all the help screens and completed the first level). So Magiduck requires a 256KB system to run normally. If you stuck everything into the executable and then packed it, my guess is that the resulting .exe would be about 100KB, but would then require a 384KB system to run. If you are trying to be period-accurate, 256KB RAM systems and clones were more common before 1985 than 512KB/640KB systems, so I wouldn't bake everything into the exe to save disk space. But at least now you know that's an option for you next project
    Last edited by Trixter; December 10th, 2015 at 07:35 PM.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  8. #168

    Default

    There are also various ways to reduce executable size when compiling with QuickBASIC. If you don't need the features in 7.1, compile with BC.EXE from QB 4.0. Linking with stub files can also help.

  9. #169
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by Trixter View Post
    If you stuck everything into the executable and then packed it, my guess is that the resulting .exe would be about 100KB, but would then require a 384KB system to run. If you are trying to be period-accurate, 256KB RAM systems and clones were more common before 1985 than 512KB/640KB systems, so I wouldn't bake everything into the exe to save disk space. But at least now you know that's an option for you next project
    Yup, but you could also go for a best-of-both-worlds approach:
    Have a pkzip-like decompressor in your executable (some LZ-derivative algorithm, very efficient on low-end systems), and compress your data files. These algorithms aren't too complex to implement, and you can probably find some libraries/example code on the net already.
    That way your data files will get pretty decent compression as well (much better than RLE in most cases), while maintaining the advantage of not having to load everything into memory.
    If you go for some clever in-place decompression (put the compressed data at the end of the buffer, so you can decompress into the same buffer, overwriting the compressed data that was already decompressed), you won't even need any extra temporary memory during decompression.

    Anyway, it's not an issue right now, because pklite already made everything fit on a 160K floppy easily

  10. #170

    Default

    Quote Originally Posted by Trixter View Post
    Wow, you really are new at this
    My first computer was a Pentium 100mhz with Win95 in 1996, so all this really is more like archeology than nostalgia for me

    Quote Originally Posted by Trixter View Post
    pklite shrinks duck.exe down to 57K.

    What will really bake your noodle is deciding whether or not you should convert all of your assets to binary objects and then link them into one giant executable.

    Edit: I just checked the memory utilization of DUCK.EXE and it uses 198704 bytes of RAM (I showed all the help screens and completed the first level). So Magiduck requires a 256KB system to run normally. If you stuck everything into the executable and then packed it, my guess is that the resulting .exe would be about 100KB, but would then require a 384KB system to run. If you are trying to be period-accurate, 256KB RAM systems and clones were more common before 1985 than 512KB/640KB systems, so I wouldn't bake everything into the exe to save disk space. But at least now you know that's an option for you next project
    The game already has so many compromises made to minimize memory footprint that it would be a shame to waste it on packing everything. (per-byte instead of per-pixel scrolling, minimal graphics buffers, streamed menus among other things)

    But yeah, packing the executable seems nice. Thanks for the info about the settings and the memory usage. The menu-loader uses one dynamic string variable so it could certainly affect the memory usage.

    I'm still wondering why DosBox and actual MS-DOS are showing around 520K available memory when quitting the game, since it should probably be more like 440K. Maybe I'll try to add some extra debug to find out if the value changes during the course of the game.

    Last nights RLE improvements reduced the level package from 27K to around 20K with possibly faster loading times too. The tilesets went from 18K to 13K. I'll have to think of a good way to get most of the loading done in Assembly now.

    Quote Originally Posted by Plasma View Post
    There are also various ways to reduce executable size when compiling with QuickBASIC. If you don't need the features in 7.1, compile with BC.EXE from QB 4.0. Linking with stub files can also help.
    Thanks, I've already been using stub files which currently decrease the executable by about 5K.

    These are the BC and LINK parameters I'm using:
    BC dgame16.bas dgame.obj nul.lst /O /FPi /Ot /Lr /Fs /S
    LINK bgame+libelfb+dgame+libelf+noedit+nocom+nolpt+smal lerr+nograph+noisam,duck,NUL,BCL71EFR+libelf /EX /NOE /NOD:BRT71FR.LIB

    But I haven't tried earlier BC versions yet, I'll give it a go.

    Quote Originally Posted by Scali View Post
    Have a pkzip-like decompressor in your executable ...
    Certainly worth a look when and if I'll rewrite the game in C.

    There have been many really interesting suggestions lately such as sound card support, joystick support, configurable controls and packing schemes that should be great for a remake. Right now I'm pretty much building a house on a foundation of twigs, so most ideas are going into "use this when I learn to code" storage.

    I hate projects that don't end, so I figure 1.0 of the game will be the QuickBasic version built on the current foundation. 2.0 deserves its own project and would be complete rewrite and possibly a sequel. 1.0 will be a flawed product in many ways, but I think it's still a product from a player perspective, if not from an engineer/developer perspective as the code is almost un-maintainable.

    Before work on 2.0 can begin I think I'll just play around with C for at least a year and slowly build a new library of routines. So far I have a custom timer, a back-buffered line routine and some structure for 3d-routines done in C and it certainly feels nice to let go of Basic.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •