Image Map Image Map
Page 18 of 21 FirstFirst ... 81415161718192021 LastLast
Results 171 to 180 of 204

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

  1. #171

    Default

    Just a quick status report on the RLE tests...

    Both levels and tilesets are now loaded in Qbasic as a dynamic string and decoded in Assembly. It works and load times improved ALOT. Loading a level now takes about 1 second in Dosbox / 270 cycles.

    Since the tileset package is now 13K, it would be tempting to load the whole thing in to RAM... I'm starting to realize what a mistake it was to use a console-style logic when it comes to swapping data in and out of memory. I'm betting floppies and drives are not gonna enjoy loading both level and tile data every time a level changes. Or maybe just saving the hub-world tileset to RAM would be enough, it would mean much less frequent file access.

    I'm now working on converting the sprite file mask data to single bits instead of nybble per mask pixel. This should slice out another 5K from the distribution.

    The menu layout files are another obvious target. The text strings only use 60 different characters so saving them as bytes is a waste. However, a big chunk of layout data consists of coordinates, attributes, button list and other data which is saved for every line of text. Even with string compression, it'll only affect ~50% of the file.

    I figure a teletype style 5-bits per character, with symbols for character bank switches might work well enough...

  2. #172

    Default

    Quote Originally Posted by mangis View Post
    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
    Do you really need to use /S with BC? It makes the executable larger so don't do that unless you know it's needed.

    I noticed that when calling your assembly routines, you're passing pointers to strings using two parameters, like this;
    Code:
    	p0% = SSEG(loadVarStr)
    	p1% = SADD(loadVarStr)	
    	CALL aUnPackTileGfxRLE (p0%, p1%)
    Instead you can use the built-in routine StringAddress from your assembly routines. Just add this to the top of the assembly file;
    Code:
    	EXTRN	StringAddress:	FAR
    Then you can call it from your procedures like this;
    Code:
    		push	bp		; Create a stack frame
    		mov	bp, sp
    		; Save whatever regs that need saving here
    		push	[bp+6]		; Push the offset address to the String Descriptor to the top of the stack
    		call	StringAddress	; Returns with pointer to string in DX:AX and string length in CX (the latter is undocumented)
    		jcxz	Exit		; If the string can be empty you probably need something like this as a minimum for error handling
    		mov	ds, dx		; The strings segment to DS...
    		mov	si, ax		; and offset to SI
    		; Etc...
    Now you should be able to do this from QUICKBASIC;
    Code:
    	CALL aUnPackTileGfxRLE (loadVarStr)
    This should make things a bit more efficient.

    Oh btw, you're still not using LDS/LES. I think it's time to learn those instructions now.
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

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

    Default

    Quote Originally Posted by mangis View Post
    I'm betting floppies and drives are not gonna enjoy loading both level and tile data every time a level changes.
    That's perfectly reasonable; all games of that era did the same thing. It's not like you're loading a new level every 5 seconds.

    I figure a teletype style 5-bits per character, with symbols for character bank switches might work well enough...
    That's the long tail... it would be a lot of effort for little gain.
    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)

  4. #174

    Default

    Quote Originally Posted by Krille View Post
    Do you really need to use /S with BC? It makes the executable larger so don't do that unless you know it's needed.
    Compiling without /S actually resulted in a bigger executable by ~2K

    Quote Originally Posted by Krille View Post
    I noticed that when calling your assembly routines, you're passing pointers to strings using two parameters, like this;
    Code:
    	p0% = SSEG(loadVarStr)
    	p1% = SADD(loadVarStr)	
    	CALL aUnPackTileGfxRLE (p0%, p1%)
    Instead you can use the built-in routine StringAddress from your assembly routines. Just add this to the top of the assembly file;
    Code:
    	EXTRN	StringAddress:	FAR
    Damn, that's really cool! But couldn't I also use loadVarStr as a parameter without BYVAL? I thought that sends the segment/offset address as well... Just tried to avoid it so far because there were so many other things to worry about.
    I assume StringAddress is a built-in routine of Qbasic, not MASM?

    Quote Originally Posted by Krille View Post
    Oh btw, you're still not using LDS/LES. I think it's time to learn those instructions now.
    I hear that
    I didn't forget your earlier advice about this, I already tried it in C but ended up using the small memory model there and using MOV seemed enough.
    In Magi, the procedure calls send parameters in SEGMENT, OFFSET order from QBasic so I assume they'll be in the wrong order for LES/LDS in the stack. But there are probably alot of points where it could be used, I really should look those up.

    Quote Originally Posted by Trixter View Post
    That's the long tail... it would be a lot of effort for little gain.
    Yeah, I'd probably be better off using something like your LZ4-study for 8088. Implementing that would probably require storing the string data as a big chunk, instead of being separated by additional menu-data entries. It'd probably still mean storing at least 3K of stuff in RAM, but it might be worth the effort, since menu-loading is the most difficult thing to move from Qbasic to Assembly at the moment and it's painfully slow. (The loader needs access to so many Qbasic-declared variables).

    Anyway, the sprite mask binary-decoding works now after some tired Christmas-coding. Distribution size at 146K.
    Last edited by mangis; December 29th, 2015 at 03:09 AM.

  5. #175

    Default

    Quote Originally Posted by mangis View Post
    Compiling without /S actually resulted in a bigger executable by ~2K
    That's odd. /S supposedly "disables string compression". AFAIK, there is no real compression of any kind in QUICKBASIC. It just means that identical strings point to the same string constant in memory. Example;
    Code:
    S1$ = "This is a string"
    S2$ = "This is a string"
    "This is a string" will be stored only once in the exe and S1$ and S2$ will both point to it.

    For some reason I thought using /S was to avoid the compiler going out of memory when compiling programs with lots of quoted strings. Not sure where I got that idea from or if it's true. In any case, I certainly would not expect the program to become bigger when compiling without /S.

    Oh well.

    Damn, that's really cool! But couldn't I also use loadVarStr as a parameter without BYVAL? I thought that sends the segment/offset address as well... Just tried to avoid it so far because there were so many other things to worry about.
    I assume StringAddress is a built-in routine of Qbasic, not MASM?
    Yes, StringAddress is part of the runtime library.

    I'm not sure what you mean with "without BYVAL". BYVAL can't be used with strings.

    Whenever you're calling functions/subs with strings as parameters, what's being passed to the procedure is the offset address to the String Descriptor for that string. The String Descriptor is just a data structure that holds the length of the string and a pointer (far pointer if using far strings) to the first byte of the string.

    I hear that
    I didn't forget your earlier advice about this, I already tried it in C but ended up using the small memory model there and using MOV seemed enough.
    In Magi, the procedure calls send parameters in SEGMENT, OFFSET order from QBasic so I assume they'll be in the wrong order for LES/LDS in the stack. But there are probably alot of points where it could be used, I really should look those up.
    Loading far pointers from the stack or the interrupt vector table is a very common operation and LES/LDS exist to simplify that. The thing to remember is that the lower address contains the offset and the higher address the segment. Here's a perfect example from your code;
    Code:
    mov ds, [bp + 10]		;DS = sprite List segment
    mov si, [bp + 08]		;SI = sprite List offset
    Replace with this;
    Code:
    lds si, [bp + 08]
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  6. #176

    Default

    Beta 2 is now available with the following changes:
    - Faster level loader/decoder.
    - Compressed tileset file format.
    - More efficient sprite file format.
    - More efficient menu layout format.
    - Executable packed with COMPACK from 92K to 56K.

    - More stable camera in POW-mode.
    - ESC can be used to go back in menus.
    - F1 brings up a quick-help screen.
    - Some menu polishes.

    http://www.indiedb.com/games/magiduc...agiduck-beta-2



    The menu improvements only mean using BYTEs instead of WORDs for some additional data and a slightly smaller pointer header.

    My plans for this version are to let it float around for about a month and then just repackage it as 1.0. That is, unless there are some critical bugs or problems. Otherwise I consider the content and features final.

    Since there has been some interest in a boxed version of the game, I'll start working on some artwork for that and test out some printing services. The print materials would also be released as PDF online if anyone wants to print their own.

    I fear my lack of enthusiasm lately means that every change in critical parts of the game could possibly break it due to neglegance caused by boredom. Same thing applies for content, since every change requires a good testing run on multiple emulators and hardware and I'm pretty much blind to the game at this point. I've just played through it way too many times.

    That said, I'm still very interested in any critiques about it. However I'll most likely treat them as reviews and try to improve on noted shortcomings in some new project.

    Quote Originally Posted by Krille View Post
    That's odd. /S supposedly "disables string compression". AFAIK, there is no real compression of any kind in QUICKBASIC. It just means that identical strings point to the same string constant in memory.
    From http://qbasic.phatcode.net/TUT/BCO.HTM

    "/S
    DISABLES THE STRING COMPRESSION. WRITES THE STRINGS QUOTED TO THE OBJECT FILE INSTEAD OF THE SYMBOL TABLE. USE THIS OPTION WHEN AN OUT OF MEMORY ERROR MESSAGE OCCURS IN A PROGRAM THAT HAS MANY STRING CONSTANTS."

    That does sound like your description... I don't think there is much repetition in the strings so maybe it doesn't have any effect. I don't see how it could make the EXE larger either.

    I finally replaced the silly MOVs with LDS/LES, but decided to leave out the string pointer trick. I hope you don't mind, it just didn't seem to be worth the effort in this instance.

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

    Default

    Quote Originally Posted by mangis View Post
    - Executable packed with COMPACK from 92K to 56K.
    I'm curious, why did you go with COMPACK when there are better alternatives (apack, upx come to mind)?
    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. #178

    Default

    Quote Originally Posted by Trixter View Post
    I'm curious, why did you go with COMPACK when there are better alternatives (apack, upx come to mind)?
    I did a quick test on PKLITE but couldn't figure out the command line interface, I remember it just jumping to the next row and blinking the cursor. So I decided to try something else just to see some results...

    The site I was browsing for tools was this: http://www.dcee.net/Files/Archiver/

    So my next try there was COMPACK, which was described as follows "Produces the fastest and smallest EXE and COM files compared with EXEPACK, LZEXE, PKLITE, DIET etc." Maybe not then?

    The resulting size was close to your test with PKLITE, so I made a hasty conclusion about it probably matching the decompression speed you mentioned also. The decompression speed was my main concern and I thought it performed well on both PCem and DosBox.

    Also forgot to check the comparison document you linked, but it doesn't seem to have permissions for public viewing. Sent a request for that just now

    Gotta admit, seeing the .exe crunched down to 56K looked like magic to me so I didn't think much further than that with all the other things to test.
    Last edited by mangis; January 17th, 2016 at 02:34 PM.

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

    Default

    Quote Originally Posted by mangis View Post
    Also forgot to check the comparison document you linked, but it doesn't seem to have permissions for public viewing. Sent a request for that just now
    Sorry about that. Never got the request, but I changed the permissions and everyone should be able to view it.

    I'm very surprised pklite didn't work on your system. Your binary may be corrupt.
    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)

  10. #180

    Default

    Quote Originally Posted by Trixter View Post
    Sorry about that. Never got the request, but I changed the permissions and everyone should be able to view it.

    I'm very surprised pklite didn't work on your system. Your binary may be corrupt.
    Thanks!

    I tried pklite 1.50 and 2.01 again, but only in Dosbox like before. 1.50 freezes with a blinking cursor and 2.01 just exits. Just realized I don't even know if these are for Dos or Windows. Just ran them without any parameters or with /?.

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
  •