sinclaj1
U.S.A., 21.09.2009, 22:21 |
DOS Game - Galactic Conquest v9.00 test (Announce) |
It has taken a while, but I've pretty much re-written the guts of Galactic Conquest 9.0, including taking most or all of the suggestions from this board concerning 8.0. (Those folks are in the credits too, btw.)
Here is a link to the ZIP file. This is a temporary host for the file (GMail won't let me email it because of the .EXE in it), so this link will be updated with a new host as soon as I can procure one.
http://www.elevationchurchonline.org/media/gc/
The zip file contains the game, the source code, the font editor, and DosBox 0.73 (I recommend using it for the game). The source is written in Borland's Turbo Pascal 7.01, patched against the runtime bug. **Please note that I've changed out my CRT unit for a newer one with more functionality, it has not been included yet, I'll work on getting that out if I can.**
Also, I'm still writing the documentation for it when I can (work has been very busy for me). In the meantime, use the link above to get the v7.5 documentation...it will suffice for now. As soon as RR can get the file, I'm guessing he can host it here as well.
I'm also trying to stamp out the last of the few bugs I know of. The biggest one happens when you create a new map for a new game...sometimes it will hang. I'm still tracking that one down. Everything else appears stable.
For testing, you can choose levels 1-5, or an insane challenge with level 99.
For tons of production and ships on your homeworld, choose a name of Pilot and a title of "Test". (It will then let you choose a new name so you don't have to play the entire game with that goofy name).
That's it. I know it's been a while, but I've added some good stuff and learned a lot of tricks with TP7 since the last version. Hopefully, this will be the final version of the game. One of these days I'll get around to converting it to something else. In the meantime, enjoy the game and let me know what you think of it. I might make a few more tweaks here and there, but I've been working on this every chance I've gotten for the past 3 months, and I'm taking a breather from it for a moment. |
Rugxulo
Usono, 21.09.2009, 23:16
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> It has taken a while, but I've pretty much re-written the guts of Galactic
> Conquest 9.0, including taking most or all of the suggestions from this
> board concerning 8.0. (Those folks are in the credits too, btw.)
Wow, I thought you'd long forgotten!
> Here is a link to the ZIP file. This is a temporary host for the file
> (GMail won't let me email it because of the .EXE in it), so this link will
> be updated with a new host as soon as I can procure one.
>
> http://www.elevationchurchonline.org/media/gc/
I think if you rename the file (.EXE -> .EX) they won't complain anymore. (Yes, very juvenile behavior of them, but what can you do?) You could also use Rapidshare.com for very temporary file download hosting.
> The zip file contains the game, the source code, the font editor, and
> DosBox 0.73 (I recommend using it for the game).
I recommend leaving DOSBox as a separate download as most of us already have it.
> The source is written in
> Borland's Turbo Pascal 7.01, patched against the runtime bug. **Please
> note that I've changed out my CRT unit for a newer one with more
> functionality, it has not been included yet, I'll work on getting that out
> if I can.**
Huh, surprised you didn't use FPC or similar, but I guess this way is better compatibility for old machines.
> That's it. I know it's been a while, but I've added some good stuff and
> learned a lot of tricks with TP7 since the last version. Hopefully, this
> will be the final version of the game. One of these days I'll get around
> to converting it to something else. In the meantime, enjoy the game and
> let me know what you think of it. I might make a few more tweaks here and
> there, but I've been working on this every chance I've gotten for the past
> 3 months, and I'm taking a breather from it for a moment.
Sure, take a break, enjoy! The best free games I've played recently are FreeDoom and Dungeon Crawl: Stone Soup. Try 'em! |
sinclaj1
U.S.A., 21.09.2009, 23:48
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> > It has taken a while, but I've pretty much re-written the guts of
> Galactic
> > Conquest 9.0, including taking most or all of the suggestions from this
> > board concerning 8.0. (Those folks are in the credits too, btw.)
>
> Wow, I thought you'd long forgotten!
I actually forgot my login stuff for the board and only kept in contact with RR about it. Found the site again and read every entry, just never posted on it. This time I'm posting.
> > Here is a link to the ZIP file. This is a temporary host for the file
> > (GMail won't let me email it because of the .EXE in it), so this link
> will
> > be updated with a new host as soon as I can procure one.
> >
> > http://www.elevationchurchonline.org/media/gc/
>
> I think if you rename the file (.EXE -> .EX) they won't complain anymore.
> (Yes, very juvenile behavior of them, but what can you do?) You could also
> use Rapidshare.com for very temporary file download hosting.
I tried renaming the EXE files as .TXT, .JPG, .EX, and .EXE-SAFE. The files are inside a .ZIP file as well. G-mail still went boo-hoo. Maybe I just need to email it through Outlook, it seems to be less fussy.
> > The source is written in
> > Borland's Turbo Pascal 7.01, patched against the runtime bug. **Please
> > note that I've changed out my CRT unit for a newer one with more
> > functionality, it has not been included yet, I'll work on getting that
> out
> > if I can.**
>
> Huh, surprised you didn't use FPC or similar, but I guess this way is
> better compatibility for old machines.
When I started updating the game again, it was mainly as a surprise for my little brother (he just got a new laptop and he was playing 7.5, so I thought I'd update it a bit. Well, that was in June...and I apparently can't seem to make just "little" changes). So the code stayed in TP7 for ease and speed.
I actually downloaded FPC and tried to look at the code in it. Got nowhere fast. That's probably going to be a major thing to learn for me, and a lot of the new code is probably nowhere near compatible.
> Sure, take a break, enjoy! The best free games I've played recently are
> FreeDoom and Dungeon Crawl: Stone Soup. Try 'em!
Thanks, I'll take a look at them. Anything like that is something my brother would love to play too. He wants me to remake some old Intellivision games (think Atari competitor from 1980's). |
sinclaj1
U.S.A., 09.10.2009, 17:51
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
Has anyone had a chance to try this game out? Any thoughts on it? |
Rugxulo
Usono, 09.10.2009, 22:56
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> Has anyone had a chance to try this game out? Any thoughts on it?
My bad, I'm like the king of procrastination. I'll give it a go later today. (Sorry!) --- Know your limits.h |
Rugxulo
Usono, 10.10.2009, 08:28
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> > Has anyone had a chance to try this game out? Any thoughts on it?
>
> My bad, I'm like the king of procrastination. I'll give it a go later
> today. (Sorry!)
It looks really really good, but I've forgotten how to play!
Guess I'll have to skim the docs. (And I still had the older version installed locally too!) --- Know your limits.h |
Rugxulo
Usono, 10.10.2009, 10:47
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> > > Has anyone had a chance to try this game out? Any thoughts on it?
Well, I'll have to double-check what makes planet production good (class? number of ships?), but so far I suck pretty badly. I like the special effects, the title screen(s) are cool, no more F2 -> C bug (good), no more "Press Enter" thanks to timed exits in intermission (good), all-in-one .EXE (good), etc. So all in all, very good!! :D
P.S. I see that "Rugxulo" is one of many testers in the credits. If that bothers you, I can tell you my real name (since a nickname among so many other real ones looks wrong) although I doubt I'm worth crediting anyways, honestly. |
sinclaj1
U.S.A., 22.10.2009, 05:16
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> > > > Has anyone had a chance to try this game out? Any thoughts on it?
>
> Well, I'll have to double-check what makes planet production good (class?
> number of ships?), but so far I suck pretty badly. I like the special
> effects, the title screen(s) are cool, no more F2 -> C bug (good), no more
> "Press Enter" thanks to timed exits in intermission (good), all-in-one .EXE
> (good), etc. So all in all, very good!! :D
>
> P.S. I see that "Rugxulo" is one of many testers in the credits. If
> that bothers you, I can tell you my real name (since a nickname among so
> many other real ones looks wrong) although I doubt I'm worth crediting
> anyways, honestly.
Everyone who has contributed to the game, including just playing it and giving meaningful feedback, is in there. To that end, you gave me some great ideas that I simply never thought of. BTW, the name in the credits is up to you, doesn't matter to me, it's your name.
To answer your first questions ... Planet classes are 1-9. The higher the class, the more potential production the planet has. Also, higher class planets are a bit stronger when it comes to protection from certain natural disasters.
I need to start writing the instructions to the game, but work's been running me ragged. For now, the v7.5 instructions will give you enough to be decent, but there have been other changes as well.
Anyone else out there had a chance to look at this game and take it for a test drive? Any other ideas, thoughts, suggestions? I'm hoping to finalize it soon. |
Rugxulo
Usono, 22.10.2009, 15:25
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> Everyone who has contributed to the game, including just playing it and
> giving meaningful feedback, is in there. To that end, you gave me some
> great ideas that I simply never thought of. BTW, the name in the credits
> is up to you, doesn't matter to me, it's your name.
Well, I feel almost silly / sheepish telling anybody my name (although I don't actively hide it), for personal reasons. I guess I'm barely / vaguely paranoid. And it's a generic name, too! So why am I worried?
EDIT: But BTW, it just looks really silly to me to see everyone else's true name and my silly nick in quotes like I'm such a badass too cool to reveal himself. I'm nobody important and have the boring name to prove it!
Anthony J. Williams, Esq. (the "Esq." is a joke, heh, don't use that)
N.B. Not the Alink guy!
> To answer your first questions ... Planet classes are 1-9. The higher the
> class, the more potential production the planet has. Also, higher class
> planets are a bit stronger when it comes to protection from certain
> natural disasters.
I guess I have to send probes to guess the production value. I'm still confused over the "high" (attack!) vs. "huge" (wait!) strategy. Also, it seems that if I send very low amounts of ships (like < 5), they almost ALWAYS make literally no dent on the enemy at all, just get wiped out, almost no point in sending such small amounts. Oh well, at least self destruct (after evacuating the one lonely ship left) is cool.
> I need to start writing the instructions to the game, but work's been
> running me ragged. For now, the v7.5 instructions will give you enough to
> be decent, but there have been other changes as well.
Yeah, it's good enough for now. At least, I don't see anything obvious that needs documenting, but I'm no pro.
> Anyone else out there had a chance to look at this game and take it for a
> test drive? Any other ideas, thoughts, suggestions? I'm hoping to
> finalize it soon.
I can go ahead and announce it on FreeDOS News if you want. |
rr
Berlin, Germany, 22.10.2009, 18:39
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> I guess I have to send probes to guess the production value.
That's right. --- Forum admin |
rr
Berlin, Germany, 22.10.2009, 18:47
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> Everyone who has contributed to the game, including just playing it and
> giving meaningful feedback, is in there.
I'm still a little busy (for the next days), but I plan, of course, to integrate GALCON into our website. --- Forum admin |
sinclaj1
U.S.A., 08.12.2009, 02:10
@ rr
|
DOS Game - Galactic Conquest v9.00 test |
> > Everyone who has contributed to the game, including just playing it and
> > giving meaningful feedback, is in there.
>
> I'm still a little busy (for the next days), but I plan, of course, to
> integrate GALCON into our website.
I'm working on the game again, to get rid of a couple glitches that have been sent into me, as well as the documentation.
Anyone have any recommendations or things to fix? |
Ninho
08.12.2009, 23:53
@ sinclaj1
|
GMail doesn't like zips either, rename too ! |
> > > Here is a link to the ZIP file. This is a temporary host for the file
> > > (GMail won't let me email it because of the .EXE in it)
> >
> > I think if you rename the file (.EXE -> .EX) they won't complain anymore.
>
> I tried renaming the EXE files as .TXT, .JPG, .EX, and .EXE-SAFE. The
> files are inside a .ZIP file as well. G-mail still went boo-hoo.
FYI Gmail objects to file.ZIP, too. Just change the extension from .zip to .zzz (say) and you're done ;=) --- Ninho |
Rugxulo
Usono, 09.12.2009, 22:04
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> I'm working on the game again, to get rid of a couple glitches that have
> been sent into me, as well as the documentation.
>
> Anyone have any recommendations or things to fix?
Nothing except packaging changes: remove DOSBox, put doc in main .ZIP (even if only old version), and it should be good to go! |
DOS386
11.12.2009, 01:45 (edited by DOS386, 11.12.2009, 02:00)
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> Anyone have any recommendations or things to fix?
PKUNZIP (R) FAST! Extract Utility Version 2.50 03-01-1999
Copr. 1989-1999 PKWARE Inc. All Rights Reserved. Shareware Version
PKUNZIP Reg. U.S. Pat. and Tm. Off.
Searching ZIP: GCV900.ZIP
Inflating: FADEUNIT.TPU
Inflating: GCEND.TPU
Inflating: GCINIT.TPU
Inflating: GCTITLE.TPU
Inflating: GCTURN.TPU
Inflating: GCUNIT.TPU
Inflating: GCWAR.TPU
Inflating: DosBoxStart.BAT
Inflating: GCDOSBOX.conf
Inflating: COMPNAME.DAT
Inflating: COMPRANK.DAT
Inflating: QUOTES.DAT
Inflating: j2.ico
Inflating: FONTEDIT.COM
Inflating: INTVFONT.COM
PKUNZIP: (W10) Warning! can't create: DOSBox0.73-win32-installer.NOTE
Inflating: GALCON.NOTE
Inflating: FADEUNIT.PAS
Inflating: GCEND.PAS
Inflating: GCINIT.PAS
Inflating: GCTITLE.PAS
Inflating: GCTURN.PAS
Inflating: GCUNIT.PAS
Inflating: GCWAR.PAS
Inflating: galcon_001.png
PKUNZIP: (W18) Warning! galcon_002.png already exists. Overwrite (y/n/a/r)?n
Inflating: gpl.txt
There are errors ^^^ in the ZIP
GC8B1.ZIP 190'511
GCV900.ZIP 1'749'746
Also, the bloat ^^^ has extremely (9.2 times !!!) increased:
Finally, there is (or only seems to be ???) no EXE inside the archive, so nothing to run or test
And, there is no manual either (the only TXT file is the boring GNU GPL), so no idea what to do with the thing ...
Rugxulo (or I ???) wrote:
> Nothing except packaging changes: remove DOSBox
Rugxulo wrote:
> I can go ahead and announce it on FreeDOS News if you want.
Good, but please check that it also works in FreeDOS before --- This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft *** |
sinclaj1
U.S.A., 11.12.2009, 04:33
@ DOS386
|
DOS Game - Galactic Conquest v9.00 test |
> > Anyone have any recommendations or things to fix?
>
>
> PKUNZIP (R) FAST! Extract Utility Version 2.50 03-01-1999
> Copr. 1989-1999 PKWARE Inc. All Rights Reserved. Shareware Version
> PKUNZIP Reg. U.S. Pat. and Tm. Off.
>
> Searching ZIP: GCV900.ZIP
> Inflating: FADEUNIT.TPU
> Inflating: GCEND.TPU
> Inflating: GCINIT.TPU
> Inflating: GCTITLE.TPU
> Inflating: GCTURN.TPU
> Inflating: GCUNIT.TPU
> Inflating: GCWAR.TPU
> Inflating: DosBoxStart.BAT
> Inflating: GCDOSBOX.conf
> Inflating: COMPNAME.DAT
> Inflating: COMPRANK.DAT
> Inflating: QUOTES.DAT
> Inflating: j2.ico
> Inflating: FONTEDIT.COM
> Inflating: INTVFONT.COM
> PKUNZIP: (W10) Warning! can't create: DOSBox0.73-win32-installer.NOTE
> Inflating: GALCON.NOTE
> Inflating: FADEUNIT.PAS
> Inflating: GCEND.PAS
> Inflating: GCINIT.PAS
> Inflating: GCTITLE.PAS
> Inflating: GCTURN.PAS
> Inflating: GCUNIT.PAS
> Inflating: GCWAR.PAS
> Inflating: galcon_001.png
> PKUNZIP: (W18) Warning! galcon_002.png already exists. Overwrite
> (y/n/a/r)?n
> Inflating: gpl.txt
>
>
> There are errors ^^^ in the ZIP
>
>
> GC8B1.ZIP 190'511
> GCV900.ZIP 1'749'746
>
>
> Also, the bloat ^^^ has extremely (9.2 times !!!) increased:
>
> Finally, there is (or only seems to be ???) no EXE inside the archive, so
> nothing to run or test
>
> And, there is no manual either (the only TXT file is the boring GNU GPL),
> so no idea what to do with the thing ...
>
> Rugxulo (or I ???) wrote:
>
> > Nothing except packaging changes: remove DOSBox
>
>
>
> Rugxulo wrote:
>
> > I can go ahead and announce it on FreeDOS News if you want.
>
> Good, but please check that it also works in FreeDOS before
>
Not sure why GALCON.EXE isn't coming out in your .zip file. That's odd. Maybe the file is corrupted? I'm going to upload an updated version tonight or tomorrow, so maybe that will fix it. I need to bang out the documentation too, I'll try to work on that tonight...it's just not something I've had the stomach for but yeah, it needs to be done and I'm sure it will be helpful for those testing it.
DOS386, if you give me a name I'll put you into the tester credits.
As for bloat...almost all of the increased size is just from DosBox being included in the .ZIP file. A lot of the included files are the source code. I can probably remove some of those, but I know folks here can tinker with the code (ie: play around with converting it to FP). There used to be like five or six EXE's that a batch file controlled to run the game, those have now been integrated into a single file. The code itself has grown about 25%, and that's after I cleaned out and rewrote a lot of stuff...but I've also added a lot of new functionality as well over version 7.5.
I can take DosBox out of the .ZIP file, the only reason I included that is because a lot of folks don't have any DOS alternative (or way to run DOS) on their machines...I included it as a "just-in-case" measure for them. |
sinclaj1
U.S.A., 11.12.2009, 04:35
@ Ninho
|
GMail doesn't like zips either, rename too ! |
> > > > Here is a link to the ZIP file. This is a temporary host for the
> file
> > > > (GMail won't let me email it because of the .EXE in it)
> > >
> > > I think if you rename the file (.EXE -> .EX) they won't complain
> anymore.
> >
> > I tried renaming the EXE files as .TXT, .JPG, .EX, and .EXE-SAFE. The
> > files are inside a .ZIP file as well. G-mail still went boo-hoo.
>
> FYI Gmail objects to file.ZIP, too. Just change the extension from .zip to
> .zzz (say) and you're done ;=)
I'll try that in the future. Hopefully that will work, I'd love to be able to email stuff like that without resorting to an Exchange email address. |
Rugxulo
Usono, 11.12.2009, 07:33
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> > Inflating: GALCON.NOTE
> >
> > Finally, there is (or only seems to be ???) no EXE inside the archive,
> so
> > nothing to run or test
> >
>
> Not sure why GALCON.EXE isn't coming out in your .zip file. That's odd.
> Maybe the file is corrupted?
No, it's just named GALCON.NOTE for some reason. Eric's FILETYPE.COM is your friend.
c:\temp>filetype galcon*.*
GALCON~1.NOT: EXE or similar
> I'm going to upload an updated version
> tonight or tomorrow, so maybe that will fix it. I need to bang out the
> documentation too, I'll try to work on that tonight...it's just not
> something I've had the stomach for but yeah, it needs to be done and I'm
> sure it will be helpful for those testing it.
The old text (GALCON.TXT) from 7.50 seemed sufficient, and that's what I just (locally) zipped into the main .ZIP itself.
> DOS386, if you give me a name I'll put you into the tester credits.
BTW, Borland compiler stuff isn't part of Borland or Inprise anymore, it got sold to Code Gear and then currently belongs to Embarcadero (I think).
> I can take DosBox out of the .ZIP file, the only reason I included that is
> because a lot of folks don't have any DOS alternative (or way to run DOS)
> on their machines...I included it as a "just-in-case" measure for them.
It's easier for them to get it themselves, I think, esp. if a new version is released (or they want to try a CVS build, even). Besides, DOSBox runs on more than just Windows! (Oh, and you'd have to include sources too because it's GPL.) |
sinclaj1
U.S.A., 11.12.2009, 10:35
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
Yeah, I'm probably going to remove DosBox from the zip file. I will be including a config file for DosBox though, so that makes life easier for those users.
I just fixed a few things and added a few more tonight. Also finished about 1/3 of the documentation. Snagged some screenshots for part of it too. Hopefully will be done tomorrow with it. It's really really late here (0430) and I have to work in a few hours, so I'm calling it a night.
I did finally fix that nasty bug that would lock up the game when creating certain types of galaxies. That was well worth the longer night.
The documentation is going to be fun...as will be adding the several pages of changes since 7.5, all the way through current (which is 9.0 build 53). For reference, the build that you guys have been looking at is 9.0 build 41.
PS -- Whatever's happened to RR? |
Arjay
11.12.2009, 11:11 (edited by Arjay, 11.12.2009, 12:07)
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
Hi Jason,
> (GMail won't let me email it because of the .EXE in it), so this link will
> be updated with a new host as soon as I can procure one.
I tend to rename .EXE's to .XEX that way it's still "fairly" obvious what it is, I seem to remember this was also fairly common back in the BBS days.
> The zip file contains the game, the source code, the font editor, and
the kitchen sink
Ok, having not seen this game before my initial comment on opening the ZIP is well pretty much everyone else: you need to heavily prune the contents of the ZIP. Here is a list of what I think needs to go myself:
1)The DOSBOX installer (I second all the comments above).
10/06/2009 23:03 1,460,010 DOSBox0.73-win32-installer.NOTE
2)The screenshots should really be on a website not in the ZIP or to put it another way if I can load the game to look - why do I need a screenshot?:
18/09/2009 18:01 4,760 galcon_001.png
18/09/2009 18:03 6,342 galcon_002.png
3) All the TPU's - why? Well if it needs TP7 and you've supplied the units then people can create the TPU's themselves. (I'll come back re your own CRT)
14/08/2009 19:54 4,496 FADEUNIT.TPU
17/09/2009 20:35 15,296 GCEND.TPU
17/09/2009 20:35 54,272 GCINIT.TPU
17/09/2009 20:35 17,664 GCTITLE.TPU
18/09/2009 00:15 112,368 GCTURN.TPU
17/09/2009 20:35 78,240 GCUNIT.TPU
17/09/2009 21:50 61,568 GCWAR.TPU
4) PC Magazines's Fontedit
03/06/1993 06:59 2,944 FONTEDIT.COM
Why? Well not for size but copyright reasons:
FONTEDIT 1.0 (C) 1988 Ziff Communications Co. ■ PC Magazine ■ Michael J. Mefford
Now firstly concerning point number 4 - I seem to remember sometime back Ziff started following up with various organizations (Simtel being the main one I seem to remember) to get all PC Magazines utils removed across their sites.
I believe it had something to do with Ziff wanting to charge people to access to download their utils.... Anyway... whatever the reasons, most Simtel mirrors you will come across now days don't have the PC Mag files available for download even if they have a list showing them being available - usually they aren't. (Some good examples of exactly that here and here and here). Note: I also used to "legally" (so I thought at the time!) distribute their utils on my BBS via a legally purchased copy of the Walnut creek "simtel archive" CD-ROM's....
Anyway it's obvious that the FONTEDIT you have here is the original assembler one (not the C++ one which is called fonted16.zip) and I believe that was just distributed as FONTEDIT.COM + FONTEDIT.DOC, somewhere I'd expect there is a FONTEDIT.ASM as well. So from a legal standpoint if you want to stick with it I'd suggest that it is probably best to mention the name of the original PC Mag archive in your documentation instead of distributing it.
I also doubt most people playing the game will know where to start with regards to editing fonts. And those of us who do will have our own tools etc. I can see that INTVFONT.COM was created with FONTEDIT, not sure if your loading it using a call or a direct read but this old posting explains the basic FONTEDIT format for anyone else interested.
Which brings me onto my next point. I do have TP7 code that I wrote for loading Windows FON/FNT fonts - I've been thinking to open source that code :)
Other points:
+ galcon will compress down at least between 50-60% depending on which EXE compressor you use. Again this will make the ZIP file considerable smaller.
+ You could easily build COMPNAME.DAT + COMPRANK.DAT from within the EXE if they are not present in the current directory.
+ Indeed I'd stick as much into the EXE as possible but that's just me.
+ I would also recommend sticking the source into a ZIP within the main ZIP.
+ dosboxstart.bat is hard coded and is basically I would imagine unusable by anyone except you and those still familiar with how to modify/use batch files.
That may seem like a odd comment to make but I've been amazed by people who knew DOS really well back in the day, yet now act like newbies with it. Thus better to assume your batch is going to need to be simple to use by end users and easy to edit by people who may be a bit rusty with their own DOS skills :)
ZIP file size
If you remove all the redundant stuff I/others have called out then even without any EXE compression (or merging files in) the contents of your ZIP go down to 474,006 bytes. Compress the EXE and your go down to below 370k.
Your ZIP file *should* be around 160k vs the 1.7Mb that it is right now !
> **Please note that I've changed out my CRT unit for a newer one with more
> functionality, it has not been included yet, I'll work on getting that out
> if I can.**
Ok, now to come back to this point. There are now many CRT replacements available, so if possible perhaps it might just be easier to alter your games code to fully use a "public" CRT instead? e.g. Frank Heckenbach's NEWDELAY (see also Dr J.R Stockton's excellent pages). If your using Frank's NEWDELAY.PAS then you don't need to supply that EITHER but rather just call it out in documentation and provide a link to this library or better still a link to Frank's website: http://fjf.gnu.de/.
> Also, I'm still writing the documentation for it when I can (work has been
Documentation is always a pain.... but an important one. It always seems to take longer than the time it takes to write software in the first place !
> For testing, you can choose levels 1-5, or an insane challenge with level
> 99.
> to converting it to something else. In the meantime, enjoy the game and
> let me know what you think of it. I might make a few more tweaks here and
Ok I'll see what testing I can do since believe it or not I haven't even played the game yet, so this is just my initial feedback based on the contents of the ZIP - will see if I can play the game later on a DEV box.
Regards Richard |
Arjay
11.12.2009, 13:59
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
Hi Jason,
Ok I have quickly checked re my TP7 fixed font code. Looks a pretty straight forward for me to release it as there are only 3 units involved with this one:
29/12/1997 10,523 win3font.pas - FON/FNT file definition in TP7 format
18/01/1998 2,616 rjmem.pas - Basically my own malloc code (used widely)
30/12/1997 3,121 loadres.pas - Wrapper (calls other units-I will drop out)
In short this is an basic example of my using my library from within TP:
-----------------------------------------------------------------------------
Write('# Resources - LoadFont(GrubFont) status : ');
If GrubFnt=nil then
Begin
Writeln('Failed!!!');
HALT(1);
End
else
Begin
Writeln('Successful!');
End;
GrubCharFnt:=LoadFont('GRUBCHAR.FNT', 0);{GRUBCHAR}
Write('# Resources - LoadFont(GrubCharFont) status : ');
If GrubCharFnt=nil then
Begin
If GrubFnt<>nil then LoseFont(GrubFnt);
Writeln('Failed!!!');
HALT(1);
End
else
Begin
Writeln('Successful!');
End;
-----------------------------------------------------------------------------
And an example of a Game's startup screen where I am calling that code:
-------------------------------------------------------------------------------
Please wait, initialising....
# Version - GrubWorm v0.01a (BETA - DO NOT DISTRIBUTE!)
# Monitor - Colour VGA
# CPU - 80486 (or above)
# DOS - v5.0 (Windows not loaded)
# Resources - LoadFont(GrubFont) status : Successful!
# Resources - LoadFont(GrubCharFont) status : Successful!
Please wait loading the amazing BGI graphics drivers....................
-------------------------------------------------------------------------------
I'm happy to release a modified version of my code if you feel it would help?
Regards Richard |
DOS386
11.12.2009, 14:28
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> I'll try that in the future. Hopefully that will work, I'd love to be able to email
> stuff like that without resorting to an Exchange email address.
Just missname your ZIP as ARC
> Yeah, I'm probably going to remove DosBox from the zip file. I will be
> including a config file for DosBox though, so that makes life easier for
nonDOSsers. Better only "config" , best would be nothing (no PIF-PAF, no REG, no DOG-BOX, no config, ....).
> Also finished about 1/3 of the documentation.
Is it plain text ?
> BTW, Borland compiler stuff isn't part of Borland or Inprise anymore, it got sold
> to Code Gear and then currently belongs to Embarcadero (I think).
And now Grpogjsdfkljgsdflkjgfdslkgjdlskfg bought it from them for ??? $$$
> Besides, DOSBox runs on more than just Windows!
Yeah, again
> 1)The DOSBOX installer (I second all the comments above).
> 10/06/2009 23:03 1,460,010 DOSBox0.73-win32-installer.NOTE
Kick it out
> 2)The screenshots should really be on a website not in the ZIP or to put
> it another way if I can load the game to look - why do I need a screenshot?
Vote for keeping. Screenshots are good, PNG format is good. But:
- Name them so they don't kill each other when extracting the archive
- Use PNGOUT, OPTIPNG, DEFLOPT
> 3) All the TPU's - why?
Kick them, if one can brew them from the source anyway
> + galcon will compress down at least between 50-60% depending on which EXE
> compressor you use. Again this will make the ZIP file considerable smaller.
Bad idea
> If you remove all the redundant stuff I/others have called out then even
> without any EXE compression (or merging files in) the contents of your ZIP
> go down to 474,006 bytes. Compress the EXE and your go down to below 370
Use TAR before ZIP'ping or 7-ZIP instead of ZIP
> I would also recommend sticking the source into a ZIP within the main ZIP.
A TAR would make the ZIP smaller --- This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft *** |
ecm
Düsseldorf, Germany, 11.12.2009, 14:36
@ DOS386
|
DOS Game - Galactic Conquest v9.00 test |
> > [...] EXE compressor you use.
> > Again this will make the ZIP file considerable smaller.
>
> Bad idea
Especially because the compressed executable might be less compressible. Did you test compressing it yet?
> Use TAR before ZIPping or 7-ZIP instead of ZIP
The 7-Zip archiver even creates normal (compatible) Zip files with better compression than some other programs. |
DOS386
11.12.2009, 14:38
@ ecm
|
DOS Game - Galactic Conquest v9.00 test |
> The 7-Zip archiver even creates normal (compatible) Zip files with better
marginally
> compression than some other programs.
As KZIP does and DEFLOPT helps. --- This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft *** |
Arjay
11.12.2009, 14:56 (edited by Arjay, 11.12.2009, 15:42)
@ ecm
|
DOS Game - Galactic Conquest v9.00 test |
> > > [...] EXE compressor you use.
> > > Again this will make the ZIP file considerable smaller.
> >
> > Bad idea
Depends on your view point.
> Especially because the compressed executable might be less compressible.
A compressed executable will very likely be less compressible by ZIP etc. However I was primarily suggesting EXE compression for the reason it reduces the filesize on the disk after unzipping. I was suggesting merging files into the EXE as that also makes stuff easier to manage. As personally I prefer smaller and less stuff when something is unzipped but again that's personal preference. Still we could all waste hours talking about the topics of "compression vs slower loading", "tiny programs vs default file allocation units" etc. But when it comes down to it the best answer is to do the best thing for the situation.
> > Use TAR before ZIPping or 7-ZIP instead of ZIP
I disagree, probably a ZIP and a *nix friendly format are required or just ZIP. I see tar/gzip et al as fine if target is *nix but NOT if the target is for DOS/Windows, unless the target audience are very likely to have those tools but as I'm sure you appreciate the majority of people don't have them under DOS/Windows. So I guess that comes down to who this game is being aimed at? If it's mostly DOS/Windows people I would use the most common widely used format; in the case of DOS the most common format was and always will be ZIP (I'm excluding ARC...!).
Yes things like ARC/LHA/RAR were common back in the day but to a *significant* lesser extent, they were and never as common as ZIP. And despite the limited success of LHA/RAR compared to ZIP they aren't exactly commonly installed on PC's anymore (LHA's use on the Amiga/BIOS's totally different subjects!).
> The 7-Zip archiver even creates normal (compatible) Zip files with better
> compression than some other programs.
So does Winzip etc but the question then is can other programs unpack those ZIP's. Start trying to get too clever with file archive compression and you end up shutting out people. e.g. I used LHA a lot back in the day (usually to automatically convert updated stuff from LHA into ZIP!), however a while back I had to spend a while surfing .jp sites and dealing with a Kanji version of LHA under Windows - all because someone distributing a DOS program "insisted" in using the *very* latest for LHA version that created LHA files that were unpackable by *any* of the versions for DOS or indeed any of the English Windows versions! Thus I think it is always the case of using the right tool for majority of the target platform. Hence if I'm distributing for Windows then no LHA, no RAR, no GZIP etc etc. And normally no ZIPS for Linux... which is why I feel probably 2 packages might actually be best here.
But obviously I do appreciate other peoples opinions are different. |
Arjay
11.12.2009, 15:31
@ DOS386
|
DOS Game - Galactic Conquest v9.00 test |
> > BTW, Borland compiler stuff isn't part of Borland or Inprise anymore, it
> got sold to Code Gear and then currently belongs to Embarcadero (I think).
> And now Grpogjsdfkljgsdflkjgfdslkgjdlskfg bought it from them for ??? $$$
>
heh! Search for "Borland Museum" I tend to find this moves as appropriate
> Vote for keeping. Screenshots are good, PNG format is good. But:
Kind of agree with you. However again similar comments re target audience... .PNG came about after DOS.... so again depends on target audience. But I'll stop short of suggesting PCX/BMP. Mind you I hear TGA's compress very well !!!
> > 3) All the TPU's - why?
> Kick them, if one can brew them from the source anyway
:) |
ecm
Düsseldorf, Germany, 11.12.2009, 15:40
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> I was suggesting merging files into
> the EXE as that also makes stuff easier to manage.
I agree to this; packing things together into the same file makes life easier for the user. And it even can allow better archive compression.
> As personally I prefer
> smaller and less stuff when something is unzipped but again that's
> personal preference.
I certainly agree to less stuff (i.e. less files), that's certainly convenient. However, I don't really care about the actual space the files take up anymore. My old computers all have at least 40 GiB hard disks that I don't have time to fill anyway.
Programming things they way they don't take up space unnecessarily (such as stack, heap, tables that could better be initialized online) is necessary for me, but I don't squeeze out every possible byte.
> I disagree, probably a ZIP and a *nix friendly format are required or just
> ZIP. I see tar/gzip et al as fine if target is *nix but NOT if the target
> is for DOS/Windows, unless the target audience are very likely to have
> those tools but as I'm sure you appreciate the majority of people don't
> have them under DOS/Windows. So I guess that comes down to who this game
> is being aimed at? If it's mostly DOS/Windows people I would use the most
> common widely used format-in the case of DOS was and always will be ZIP
> (I'm excluding ARC...!).
Right, don't use "obscure" formats in case the file should go to normal users. I'm not certain about this in case of beta versions, but I'd still suggest Zip just because it's a game. It shouldn't require a PC expert to play it.
> > The 7-Zip archiver even creates normal (compatible) Zip files with
> > better compression than some other programs.
>
> So does Winzip etc but the question then is can other programs unpack
> those ZIP's.
This is why I mentioned that they are compatible. I'm using 7-Zip regularly to pack Zip archives and no one complained about these so far. (I know that most people in question don't use 7-Zip and probably not WinZip either to unpack them.) --- l |
Arjay
11.12.2009, 16:02
@ ecm
|
DOS Game - Galactic Conquest v9.00 test |
> I agree to this; packing things together into the same file makes life
> easier for the user. And it even can allow better archive compression.
Yes, less archive overhead (filename/path/date/timestamps...) as less entries.
> However, I don't really care about the actual space the files take up
> anymore.
Some people do... my historical viewpoint was if it doesn't need to be included don't include it. That said I'm kind of with you on this one.
> My old computers all have at least 40 GiB hard disks that
Harddisks....? Some of my old computers don't even have harddisks :-0
> necessary for me, but I don't squeeze out every possible byte.
Likewise. But there are times when doing that is still necessary, e.g: 256byte games / 4k/64k demo competitions or just good old hardware limits! :)
> Right, don't use "obscure" formats in case the file should go to normal
> users. I'm not certain about this in case of beta versions, but I'd still
> suggest Zip just because it's a game. It shouldn't require a PC expert to
> play it.
Glad you agree and importantly ZIP support is now integrated within later versions of Windows etc.
> This is why I mentioned that they are compatible. I'm using 7-Zip
> regularly to pack Zip archives and no one complained about these so far.
Nor should they providing you stick with the standard default "normal" settings. When people start using the maximum/extra compression options which are usually often program specific that is when the problems start.
I'd be lying if I said I didn't use those options myself at times, however I don't use them when distributing something that I want others to be able unzip |
ecm
Düsseldorf, Germany, 11.12.2009, 16:20
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> Yes, less archive overhead (filename/path/date/timestamps...) as less
> entries.
Saving unnecessary file headers and such might save more, but that certainly depends on the type of data and storage format.
(Of course compressing all data together probably makes an actual difference.)
> > My old computers all have at least 40 GiB hard disks that
>
> Harddisks....? Some of my old computers don't even have harddisks :-0
I'm not that long into DOS fandom. That's either sad or good
> Likewise. But there are times when doing that is still necessary, e.g:
> 256b game competitions
Site seems to be down / replaced by vicious ads. But fitting something into 256 bytes is an interesting task. See MBR and boot sectors for actual applications of that.
> or hardware
> limits!
Or working with DOS kernels and TSRs. Spending some more bytes than necessary there isn't going to kill the system, but I'd rather keep the resident parts small.
> Nor should they providing you stick with the standard default "normal"
> settings. When people start using the maximum/extra compression options
> which are usually often program specific that is when the problems start.
7-Zip does support some of these special options, but I usually stick just with its highest "compression level" 9. These levels don't affect the used method but supposedly try longer/harder to compress the data. --- l |
sinclaj1
U.S.A., 11.12.2009, 16:39 (edited by sinclaj1, 11.12.2009, 16:49)
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
Wow, lots of discussion on here... let me pick through it all.
First...let me know your names, guys, so I can add you to the tester credits. Otherwise I'll just put your screen name from the forums here.
The zip that I'm currently hosting...the reason there's so much stuff in it was because it is in testing right now, and you guys are basically the only audience. I threw everything in there (including the kitchen sink) with the hope that everyone could look at everything that was done and do whatever they wanted with it.
I will be taking the DosBox installer out, though it is legal to distribute it. The source code will be in a separate .zip inside the main .zip. The font editor will be removed. The documentation is going to be a .pdf but I can throw a text copy in there too. The batchfile isn't necessary anymore because everything's in the .EXE, so that solves that issue.
The COMPNAME.DAT and COMPRANK.DAT files, along with QUOTES.DAT, are not going to be integrated into the game because they are meant for the users to add/edit them however they wish.
The game itself runs without any .TPU files being present, so I won't include those at all. The exception would be the version of the enhanced CRT unit I used, which is freely distributable and will be included with the source. As for that CRT unit, the main reason I used it was for enhanced keyboard key reads, not the TP200 runtime issue.
The archive will be .zip so that non-tech savvy users can use it. BTW, I use WinRAR to archive, so a .rar is also possible.
I'm working on the documentation right now while testing some fixes from last night. I'll keep you guys posted. |
Arjay
11.12.2009, 17:27
@ ecm
|
DOS Game - Galactic Conquest v9.00 test ( off topic) |
> (Of course compressing all data together probably makes an actual
> difference.)
Correct. e.g. In the case of actual disk storage you have default allocation (minimum) units, e.g. 512 bytes in size. Thus if you have a file of 10 bytes it will from the file systems perspective take up 512 bytes of space [if 512 bytes is the default allocation unit]. So if in this case you have 2 files of 10 bytes each then separately they are taking up 1024 bytes (1k) of space.
If you combine them together they instead only take up 512 bytes; which is still enough space for several DOS games certainly even large 256 sized ones.
This doesn't matter so much on older systems but if you get really low-level it still matters a lot and it matters a lot if your still using 1980's kit.
> Site seems to be down / replaced by vicious ads.
It is a great shame 256b.com is down - I'll remove it from my homepage
> I'm not that long into DOS fandom. That's either sad or good
Well it either means you are several years younger than many of us or you weren't as sad as we were in getting involved with computers when things like playing computer games were very unfashionable. Indeed I pointed out to someone the other day that the concepts of storing/ripping music electronically are not exactly new even if most people think they are... Still I digress/get off my lawn and all that!
> But fitting something into 256 bytes is an interesting task.
> See MBR and boot sectors for actual applications of that.
Oh great fun, particularly when in a competition you quickly learn that the target ends up being a LOT lower, like about a quarter of 256 bytes (or less) well that is the target if you want to stand a chance of winning that is.
Indeed in the dark days before most of the world even discovered the Internet some weird folks even having discussions about having boot sector demo competitions. I mean who are those type of people.... Oh never mind...
> Spending some more bytes than necessary there isn't going to kill the system
Depends on the system.... :)
> but I'd rather keep the resident parts small.
Indeed. These days I like the whole system to myself. So remind me what is a TSR again? heh |
Arjay
11.12.2009, 17:51
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> First...let me know your names, guys, so I can add you to the tester
> credits. Otherwise I'll just put your screen name from the forums here.
Note: In many cases if you click onto a posters name you get their full name or website where several folks have their names on them.
> The zip that I'm currently hosting...the reason there's so much stuff in
> it was because it is in testing right now, and you guys are basically the
> only audience.
No worries but I would imagine that due the majority of folks on here will either have already or know where to get something. Thus use URL's in a readme.txt to the extra stuff, helps point people to places also to learn.
> I threw everything in there (including the kitchen sink)
:) Still thank you for taking on our collective feedback.
> The COMPNAME.DAT and COMPRANK.DAT files, along with QUOTES.DAT, are not
> going to be integrated into the game because they are meant for the users
> to add/edit them however they wish.
Ok. Have you thought about using a basic INI file and sticking them both into that - it would also allow you to expand the game further in the future.
> The game itself runs without any .TPU files being present, so I won't
> include those at all. The exception would be the version of the enhanced
> CRT unit I used, which is freely distributable and will be included with
> the source. As for that CRT unit, the main reason I used it was for
> enhanced keyboard key reads, not the TP200 runtime issue.
This enhanced CRT unit your using is it your own? From a quick check of the EXE you appear to only be using Int 16h for keyboard. If you can't/don't want to distribute your keyboard routines in source code, I'll happily open source some of mine for you (even though there are stacks on the web).
> The archive will be .zip so that non-tech savvy users can use it.
Thanks.
> BTW, I use WinRAR to archive, so a .rar is also possible.
No comment... !
> I'm working on the documentation right now while testing some fixes from
> last night. I'll keep you guys posted.
I think I saw you use the word PDF. TXT and/or HTML would be better. |
Arjay
11.12.2009, 17:56
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> Ok. Have you thought about using a basic INI file and sticking them both
> into that - it would also allow you to expand the game further in the
> future.
On this point. For a quick and dirty .INI file parser you could refer to IVTUTIL. Not the best example out there but it works and I'm happy for you to rip re-use that code with pleasure. Indeed that's part of the reason why I've been busy working to release a lot of code to help others in the same way that people before me helped me. If we can help you open source all of your game then great as others will learn from it. |
ecm
Düsseldorf, Germany, 11.12.2009, 19:01
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test ( off topic) |
> Correct. e.g. In the case of actual disk storage you have default
> allocation (minimum) units, e.g. 512 bytes in size. Thus if you have a
> file of 10 bytes it will from the file systems perspective take up 512
> bytes of space [if 512 bytes is the default allocation unit]. So if in
> this case you have 2 files of 10 bytes each then separately they are
> taking up 1024 bytes (1k) of space.
> If you combine them together they instead only take up 512 bytes; which is
> still enough space for several DOS games certainly even large 256 sized
> ones.
That doesn't apply this way to compression as the archive formats usually provide an optimized kind of "file system" that's designed to avoid this and other problems. (Plus you forget to mention saving the directory entries, of course.)
However, various compression methods work by noting in the output (i.e. compressed) stream occurances of the data to compress next that came earlier in the input (i.e. source) stream. If no such earlier copy of the data sequence can be found, the sequence has to be stored in more "expensive" in the output stream (as literal bytes, or by using other ways of compression that aren't as effective as marking doubled sequences). With such methods, and archive formats that compress each file's data separately, splitting the same data into multiple files decreases the achievable compression ratio because the compression has less reference data to work with.
> Well it either means you are several years younger than many of us or you
> weren't as sad as we were in getting involved with computers when things
> like playing computer games were very unfashionable.
Yeah, I only got into this stuff when DOS was publicly declared quite dead already.
> Still I digress/get off my lawn and all that!
Oh I don't think a bit of this bothers anyone here. At least not me, and therefore I'd say it must be our official policy
> Indeed. These days I like the whole system to myself. So remind me what
> is a TSR again? heh
Oh but I can't live without CmdEdit or FDAPM/IDLEDPMS or that text-mode clock thingy anymore. The XMS driver is required anyway. Not to mention how important my debugger is for development, and after all it stays resident during debugging too.
An absolute requirement, however, is a keyboard layout driver. Working without the driver is just painful. The minor changes (such as exchanged Z and Y keys) are non-issues, but most punctuation and additional characters on the right are mapped differently with the German layout. One doesn't get US-layout keyboards at retail here either. --- l |
Rugxulo
Usono, 11.12.2009, 19:30
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> > > Use TAR before ZIPping or 7-ZIP instead of ZIP
> I disagree, probably a ZIP and a *nix friendly format are required or just
> ZIP. I see tar/gzip et al as fine if target is *nix but NOT if the target
> is for DOS/Windows, unless the target audience are very likely to have
> those tools but as I'm sure you appreciate the majority of people don't
> have them under DOS/Windows. So I guess that comes down to who this game
> is being aimed at? If it's mostly DOS/Windows people I would use the most
> common widely used format; in the case of DOS the most common format was
> and always will be ZIP (I'm excluding ARC...!).
Most people don't use ARC anymore or even know of a way to unpack it. But there is the freeware DOS Pascal DEARC tool.
> Yes things like ARC/LHA/RAR were common back in the day but to a
> *significant* lesser extent, they were and never as common as ZIP. And
> despite the limited success of LHA/RAR compared to ZIP they aren't exactly
> commonly installed on PC's anymore (LHA's use on the Amiga/BIOS's totally
> different subjects!).
As rr well knows, modern UNRAR has been compiled with DJGPP, so it works. However, I think the GNU folks consider it non-free (although it's free enough, I think).
> > The 7-Zip archiver even creates normal (compatible) Zip files with
> better
> > compression than some other programs.
> So does Winzip etc but the question then is can other programs unpack
> those ZIP's.
It's fully compatible output, I use it all the time. AdvanceComp (advzip) works well too (same 7-Zip rewritten / optimized Deflate). The latter just removes comments and extra fields, I think, which aren't important to 99% of users anyways. That doesn't affect the actual data at all. (It might also remove redundant Deflate EOS markers, which AFAIK nobody needs.)
> Start trying to get too clever with file archive compression
> and you end up shutting out people. e.g. I used LHA a lot back in the day
> (usually to automatically convert updated stuff from LHA into ZIP!),
> however a while back I had to spend a while surfing .jp sites and dealing
> with a Kanji version of LHA under Windows - all because someone
> distributing a DOS program "insisted" in using the *very* latest for LHA
> version that created LHA files that were unpackable by *any* of the
> versions for DOS or indeed any of the English Windows versions!
Must have used lh7, then, as LHA 2.55 would (undocumented) unpack lh6, just as PKUNZIP 2.50 would (also undocumented) unpack Deflate64 (Info-Zip too). BTW, you could always use LHA-UNIX (or its DJGPP compile).
7-Zip and Info-Zip (Zip 3.0 / Unzip 6.0) both support Bzip2 methods inside .ZIPs now, and 7-Zip also (unsurprisingly) supports LZMA. It's things like encryption that PKWare and WinZIP differed on (although IZarc and 7-Zip support both methods). BTW, p7zip (DJGPP compile) and 7za.exe + HX both work in DOS.
> Thus I
> think it is always the case of using the right tool for majority of the
> target platform. Hence if I'm distributing for Windows then no LHA, no
> RAR, no GZIP etc etc. And normally no ZIPS for Linux... which is why I
> feel probably 2 packages might actually be best here.
>
> But obviously I do appreciate other peoples opinions are different.
As you mentioned, modern Windows (since ME?? 2k??) support extracting ZIPs (thanks to liberal ZLIB license).
Ubuntu has Info-Zip (zip, unzip) installed by default, but sadly most others don't. .tar inside .zip is accepted and unpacked by GNU tar + GNU Gzip but not *BSD Gzip. If you want solid compression and remain .ZIP compatible, better to do "zip -0 file0 * && zip -9m file file0.zip".
BTW, a nice DOS .tar + .gz combined tool (w/ srcs but "non-commercial" only) is tar321#4.zip, e.g. "tar +gnu -c.9f myfile.tgz *.*". |
sinclaj1
U.S.A., 11.12.2009, 22:38
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> Note: In many cases if you click onto a posters name you get their full
> name or website where several folks have their names on them.
Thanks, I'll check that out.
> > The COMPNAME.DAT and COMPRANK.DAT files, along with QUOTES.DAT, are not
> > going to be integrated into the game because they are meant for the
> users
> > to add/edit them however they wish.
> Ok. Have you thought about using a basic INI file and sticking them both
> into that - it would also allow you to expand the game further in the
> future.
Hadn't thought of that, may try that in a future build or version. Most of the settings I have are saved in the games themselves and the game is coded to let the user change things that way.
> This enhanced CRT unit your using is it your own? From a quick check of
> the EXE you appear to only be using Int 16h for keyboard. If you
> can't/don't want to distribute your keyboard routines in source code, I'll
> happily open source some of mine for you (even though there are stacks on
> the web).
It is not mine, and at the moment I cannot honestly remember where I got it from. I'll try to track that part down. I need to put a reference to that in the document too. As for distributing the source, if I had the source I would distribute it. All I had was the precompiled enhanced CRT.TPU that I found.
I'm now about 1/2 done with the documentation. Once the documentation is done I'll bundle up build 53 and put it on the same server as before. I'll try to finish it this weekend, but my wife is headed out of country again, so I'm going to spend time with the family this weekend. I'll keep checking back here. I appreciate the feedback. |
Arjay
11.12.2009, 23:12
@ ecm
|
DOS Game - Galactic Conquest v9.00 test ( off topic) |
> (Plus you forget to mention saving the directory entries, of course.)
No I didn't but we have ended up talking cross purposes here. Archive formats are a different matter but yes you are right on what you say there.
> Yeah, I only got into this stuff when DOS was publicly declared quite dead
> already.
Ah ok... we had no real option back in 1985 :)
> Oh I don't think a bit of this bothers anyone here.
> At least not me,
Me neither.
> An absolute requirement, however, is a keyboard layout driver.
Agreed or if like me your using your own code just remapping as appropriate.
> Working without the driver is just painful.
That's where [ALT] [numeric keypad] comes in useful :)
> The minor changes (such as exchanged Z and Y keys) are non-issues,
You say that but it is damn annoying switching back again after a few days ! |
Arjay
11.12.2009, 23:40
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> Most people don't use ARC anymore or even know of a way to unpack it.
I'd take that one step further and say that the majority of folks online these days won't have even *ever* heard of ARC. Thom Henderson's statement on the death of Phil Katz is an interesting read, as is the BBS Documentary's entry on ARC vs ZIP.
Anyway you realize I was joking re my ARC ref, right? :)
> there is the freeware DOS Pascal
Thanks. I still have a ton of code to deal with ARC etc from my SYSOP days. Indeed I'm thinking to open source lots of BBS related TP code, ANSI code etc.
> It's fully compatible output, I use it all the time.
You may be right but it might not have been the case when I last looked at it.
> The latter just removes comments and extra fields, I think, which aren't
> important to 99% of users anyways.
That annoys me a LOT. Was very useful back in the day and importantly if like me your a registered ZIP licensee the -AV stuff doesn't show up. Not that it matters much now days, but was annoying when it became more hidden.
> Must have used lh7, then
Correct it was.
> as LHA 2.55 would (undocumented) unpack
> lh6, just as PKUNZIP 2.50 would (also undocumented) unpack
> Deflate64 (Info-Zip too).
Useful info thanks.
> tar321#4.zip
I agree works well as I have use it myself in the past.
Btw guys, I feel we need to get this thread back onto the main topic. Still I think with collective responses have had a lot of good links to archive tools/info which will help Jason make up his own mind as to how to progress. |
Arjay
11.12.2009, 23:54
@ sinclaj1
|
DOS Game - Galactic Conquest v9.00 test |
> It is not mine, and at the moment I cannot honestly remember where I got
> it from.
Perhaps the one @ pedt.demon.co.uk?
> I'll try to track that part down.
Try taking a comment line or line of code that is quite long and unique; then simply past that line into a search engine and see what comes back. Often works.
> I need to put a reference to
> that in the document too. As for distributing the source, if I had the
> source I would distribute it.
> All I had was the precompiled enhanced CRT.TPU that I found.
I'll look at your EXE again as I should might be able work it out from that.
> I'm now about 1/2 done with the documentation. Once the documentation is
> done I'll bundle up build 53 and put it on the same server as before.
Ok great looking forward to seeing it.
> I'll try to finish it this weekend, but my wife is headed out of country
> again, so I'm going to spend time with the family this weekend.
Yes very important to get the family/coding balance right - which is exactly why I don't tend to code through the night very much (if ever) now... :) |
Arjay
12.12.2009, 00:07 (edited by Arjay, 12.12.2009, 01:34)
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> > It is not mine, and at the moment I cannot honestly remember where I got
> > it from.
> Perhaps the one @ pedt.demon.co.uk?
Note all of the download links / many links on pedt.demon.co.uk are now dead.
I did wonder if the library might be Bob Ferguson's jrfpas06.zip (note link to his download page not zip) - however looking through his library (for the 1st time) I believe that is unlikely.
I have also wondered if it could also be a 3rd party commercial CRT.TPU however it doesn't look like it, as I dumped out all of the TEXT in your EXE into a file and then checked/read through that. I found/can see no copyright notices other than Borland's: "Portions Copyright (c) 1983,92 Borland".
If it was commercial e.g. Turbo Power's stuff then I would have expected an additional copyright statement. Thus I wondered at first if it was a free CRT library from someone rather than commercial as no additional copyright statements. If it is around "around" or slightly over 4200bytes then that will likely be a modified Borland CRT.TPU. [I don't the size of your CRT.TPU as you haven't shared that info (might be helpful to track it down if you do), so I'm looking at this from your resulting EXE which obviously contains part of the CRT.TPU you have. [note CRT.TPU "normally" lives inside TURBO.TPL along with SYSTEM.TPU, DOS.TPU, OVERLAY.TPU PRINTER.TPU unless they have been extracted out with the aid of a util in order to be patched/replaced etc].
I thus wondered if it was more likely that what you have is Borland's original CRT library but just patched by someone to firstly fix RTL200 and maybe add a few other little tweaks rather than a complete replacement of CRT written from scratch. Indeed looking at the CRT library in GALCON vs the original TP7 CRT.TPU that is exactly what it looks like [note: I'm still checking into this]. As the CRT you are using appears to have an additional move code inserted into Borland's standard code:
---------------------------------------------------------------------------
ORIGINAL.CRT
0000:0000 BA 12 00 3B D3 73 1A F7-F3 8B D8 E4 61 A8 03 75
0000:0010 08 0C 03 E6 61 B0 B6 E6-43 8A C3 E6 42 8A C7 E6
GALCON.CRT
0000:0000 BA 12 00 B8 DD 34 3B D3-73 1A F7 F3 8B D8 E4 61
0000:0010 A8 03 75 08 0C 03 E6 61-B0 B6 E6 43 8A C3 E6 42
---------------------------------------------------------------------------
---------------------------------------------------------------------------
ORIGINAL.CRT
00000000: BA1200 mov dx,00012
00000003: 3BD3 cmp dx,bx
00000005: 731A jae 00000021
00000007: F7F3 div bx
00000009: 8BD8 mov bx,ax
0000000B: E461 in al,61
0000000D: A803 test al,003
0000000F: 7508 jne 00000019
GALCON.DAT
00000000: BA1200 mov dx,00012
00000003: B8DD34 mov ax,034DD
00000006: 3BD3 cmp dx,bx
00000008: 731A jae 00000024
0000000A: F7F3 div bx
0000000C: 8BD8 mov bx,ax
0000000E: E461 in al,61
00000010: A803 test al,003
00000012: 7508 jne 0000001C
Note: The inserted move instruction at the start is 3 bytes in length hence the jae / jne instructions which then come after it are 3 bytes further in !
---------------------------------------------------------------------------
etc
etc
So yes what I believe you are looking for is a "modified" Borland CRT library which might explain why you only have it as a TPU. Thus what we now need to determine is what patch / patch program has been applied to make that version. |
Arjay
12.12.2009, 02:12
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
Hi Sinclaj1,
Can you advise on the file size of your CRT.TPU and SYSTEM.TPL's? as this will be very helpful in helping you track down exactly what patch/TPL you have there.
e.g.
03/03/1993 07:01 48,464 TURBO.TPL = original for v7.1
19/07/1997 10:36 48,496 TURBO.TPL = BP7PATCH for v7.1
19/07/1997 22:46 4,272 crt.tpu = original for v7.1
19/07/1997 00:57 4,304 crt.tpu = BP7PATCH for v7.1
[As above CRT "normally" does NOT exist as a separate file outside of TURBO.TPL]
The examples above should give you some idea of why this information is helpful. |
Arjay
12.12.2009, 02:59 (edited by Arjay, 12.12.2009, 03:47)
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
That info is helpful but probably not now necessary as I believe I have now solved this little mystery. At a high level, based on my investigations I am *pretty* sure now that the CRT unit you have there is a VERY likely to be a version of Pedt Scragg's CRT unit. His homepage should have his latest versions available, however all of the links are sadly now dead: http://www.pedt.demon.co.uk/crt/
However I established that it can still be downloaded from here:
http://www-ftp.lip6.fr/pub/pc/garbo/pc/turbopas/crt.zip
I obtained a copy and extracted out the relevant data to compare against the CRT unit in your own EXE, pretty close match but a few differences. Some due to linkers etc, but others I'm not so sure about (tired which doesn't help):
------CRT70.CRT-------------------------------------------
0000:0000 BA 12 00 B8 DD 34 3B D3-73 1A F7 F3 8B D8 E4 61
0000:0010 A8 03 75 08 0C 03 E6 61-B0 B6 E6 43 8A C3 E6 42
0000:0020 8A C7 E6 42 CA 02 00 E4-61 24 FC E6 61 CB 8B DC
0000:0030 36 8A 47 04 A8 F0 74 04-24 0F 0C 80 80 26 00 00
0000:0040 70 08 06 00 00 CA 02 00-8B DC 36 8A 47 04 24 07
0000:0050 B1 04 D2 E0 80 26 00 00-8F 08 06 00 00 CA 02 00
0000:0060 80 26 00 00 F7 CB 80 0E-00 00 08 CB A0 00 00 A2
0000:0070 00 00 CB 8B DC 36 8B 4F-04 E3 17 8B 3E 00 00 8E
0000:0080 C7 33 FF 26 8A 1D A1 00-00 8B 16 02 00 E8 05 00
0000:0090 E2 F4 CA 02 00 2D 01 00-83 DA 00 72 05 26 3A 1D
------GALCON.CRT------------------------------------------
0000:0000 BA 12 00 B8 DD 34 3B D3-73 1A F7 F3 8B D8 E4 61
0000:0010 A8 03 75 08 0C 03 E6 61-B0 B6 E6 43 8A C3 E6 42
0000:0020 8A C7 E6 42 CA 02 00 E4-61 24 FC E6 61 CB 8B DC
0000:0030 36 8A 47 04 A8 F0 74 04-24 0F 0C 80 80 26 96 EA
0000:0040 70 08 06 96 EA CA 02 00-8B DC 36 8A 47 04 24 07
0000:0050 B1 04 D2 E0 80 26 96 EA-8F 08 06 96 EA CA 02 00
0000:0060 8B DC 36 8B 4F 04 E3 17-8B 3E 70 00 8E C7 33 FF
0000:0070 26 8A 1D A1 9C EA 8B 16-9E EA E8 05 00 E2 F4 CA
0000:0080 02 00 2D 01 00 83 DA 00-72 05 26 3A 1D 74 F3 C3
0000:0090 80 3E A4 EA 00 75 01 C3-C6 06 A4 EA 00 8A 26 A6
This is the file in Pat's 1999 distribution that I checked against:
30/05/1999 07:19 5,680 CRT70.TPU
So it may just be that people need to obtain CRT70.TPU however as you I believe said that you are basically using it for his keyboard routines then it might be better if you obtain "Extended Keyboard unit by PEDT SCRAGG":
http://www.bryantmcgill.com/technology/pascal-delphi/Keyboard_IO/Extended_Keyboard_unit_by_PEDT_SCRAGG.html
If you want to get in touch with him, he might be contactable via the email address that appears with his photo here].
-----------------------------------------------------------------------------
Tried a compile (using CRT70 as above) fadeunit.pas compiled fine but not gcunit with that version (which all the other units require to compile!):
q:\test>tpc gcunit
Turbo Pascal Version 7.0 Copyright (c) 1983,92 Borland International
Warning: TURBO.TPL not found.
GCUNIT.PAS(645): Error 26: Type mismatch.
X1:=ABS(X1);Y1:=ABS(Y1*1.6); {1.6 IS TO "SQUARE-UP" MAPBOARD)}
However gcunit compiles fine with the normal/standard TP7.1 routine libraries,
indeed if I had the main source code file I would have tried a full compile.
-----------------------------------------------------------------------------
Still speaking of source. I immediately reconised routines out of FADEUNIT as coming from "ASPHYXIA Demo Trainer Series" / related demoscene work. The header looks a lot more basic than I would imagine on the standard release, so not sure where you got it from but be aware of it's original origin:
hornet.org: Mike Schutz or hornet.org: Effect
Sadly Hornet is no longer serving files so you can't download fade2.zip there, however Programmers Heaven is and the original file is available here:
http://www.programmersheaven.com/ph/Search/Search.aspx?query=fade2.zip
And as I expected as per the documentation in that zip file original reference material (and some of the routines I might add) came from ASPHYXIA.
Yup I'm that sad I even can recognize some routines back to their origin |
DOS386
12.12.2009, 10:04 (edited by DOS386, 12.12.2009, 10:27)
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> ZIP. I see tar/gzip et al as fine if target is *nix but NOT if the target
> is for DOS/Windows, unless the target audience are very likely to have
> those tools but as I'm sure you appreciate the majority of people don't
> have them under DOS/Windows. So I guess that comes down to who this game
> is being aimed at? If it's mostly DOS/Windows people I would use the most
Yeah, Linuxers unable to UNZIP and Windaubers unable to UNTAR , only DOSsers can both
> common widely used format; in the case of DOS the most common format was
> and always will be ZIP (I'm excluding ARC...!).
Poor compression wins
> does Winzip etc but the question then is can other programs unpack those ZIP's.
NO, and no need to introduce or promote ( already introduced ) even more incompatible archive formats without any benefit justifying them.
> no GZIP etc etc. And normally no ZIPS for Linux... which is why I
> feel probably 2 packages might actually be best here.
Or even 3 (assume some bloated source package) : ZIP (50 MiB) , TAR.GZ (40 MiB) , TAR.BZ2 (30 MiB) , total 120 MiB Guess what I would upload: just one file, 7-ZIP'ped TAR , 20 MiB
> again similar comments re target audience... .PNG came about after DOS.... so
what is the problem ???
> again depends on target audience.
My audience for my releases are progressive DOSsers knowing what to do with stuff like PNG, TAR, OGV, 7-ZIP, & Co
> Mind you I hear TGA's compress very well !!!
Evidence please ! Upload it
sinclaj1 wrote:
> source code will be in a separate .zip inside the main .zip.
OK. Also try to make the inner ZIP uncompressed (Store) (I still love TAR ...).
> The documentation is going to be a .pdf but
you can't read PDF's in DOS
> I can throw a text copy in there too.
Much better.
> The batchfile isn't necessary anymore because everything's in the .EXE, so that solves that issue.
COOL --- This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft *** |
Arjay
12.12.2009, 11:23 (edited by Arjay, 12.12.2009, 18:34)
@ DOS386
|
DOS Game - Galactic Conquest v9.00 test |
> only DOSsers can both
:)
> Poor compression wins
It still amazes me that RLE support within BMP's has never been used as much as it should have been. Not that I'm supporting the use of BMP's mind !!!
> NO, and no need to introduce or promote ( already introduced ) even
> more incompatible archive formats without any benefit justifying them.
Totally agree with that.
> Or even 3 (assume some bloated source package) : ZIP (50 MiB) , TAR.GZ (40
There's no need for sarcasm.... oh wait there is!
> > again similar comments re target audience... .PNG came about after
> DOS.... so
> what is the problem ???
Well I was thinking of DOS viewer support. e.g. QV v2.58 doesn't support PNG whereas PV v2.78 does support PNG. I can't remember when I lasted looked at real old stuff like CSHOW etc but last time I checked that didn't support PNG!
I was not aware of attempts to get Firefox to under HX until I read your own posting about it, but clearly not even that looks like an option for viewing PNG under DOS right now.... and lets not add FF to the ZIP just to view a couple of PNG's. Indeed I have been following the HX threads with interest for sometime. I did note that Rugxulo and myself seem to be very aligned about NOT using PNG's under DOS for the very good reasons we've pointed out.
> My audience for my releases are progressive DOSsers knowing what to do
> with stuff like PNG, TAR, OGV, 7-ZIP, & Co
Ok, fine. Feel free to limit your audience :)
> > Mind you I hear TGA's compress very well !!!
> Evidence please ! Upload it
Real world experience.... [EDIT: removed code to reduce size of this thread]
> > The documentation is going to be a .pdf but
> you can't read PDF's in DOS
But your progressive. Can't you read it with Firefox along with PNG's
> > I can throw a text copy in there too.
> Much better.
Totally agree. TXT copy and HTML copy is good. PDF not.
> > The batchfile isn't necessary anymore because everything's in the .EXE,
> so that solves that issue.
> COOL
Yeah I think Jason's done a good job of taking on everyone's feedbacks! I'm looking forward to seeing the final game and hopefully many more to come!
Keep up the good work Jason! |
ecm
Düsseldorf, Germany, 12.12.2009, 11:38
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> > > I can throw a text copy in there too.
> > Much better.
> Totally agree. TXT copy and HTML copy is good. PDF not.
Try Halibut (or from its developer's site), it lets you write messy text files with a small amount of markup and converts them to proper text files and HTML documents and PDF documents (and some more). --- l |
Rugxulo
Usono, 12.12.2009, 12:11
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> > Poor compression wins
> It still amazes me that RLE support within BMP's has never been used as
> much as it should have been. Not that I'm supporting the use of BMP's
> mind !!!
Even PCX has some wimpy optional compression, no? I think most tools don't support the compressed variants, that's why. (I guess you know that JPEG is a pain!!!)
> > > again similar comments re target audience... .PNG came about after
> > DOS.... so
> > what is the problem ???
> Well I was thinking of DOS viewer support. e.g. QV v2.58 doesn't support
> PNG whereas PV v2.78 does support PNG. I can't remember when I lasted
> looked at real old stuff like CSHOW etc but last time I checked that
> didn't support PNG!
The only PNG viewers for DOS (off the top of my head) are Display, QV/PNG, and Pictview. Nothing for < 386, though (probably moot but still ... I can't say I don't dream of writing / porting bzip2 [-2 at least], .png viewer, etc).
> I was not aware of attempts to get Firefox to under HX until I read your
> own posting about it, but clearly not even that looks like an option for
> viewing PNG under DOS right now.... and lets not add FF to the ZIP just to
> view a couple of PNG's. Indeed I have been following the HX threads with
> interest for sometime.
Actually, I think we were both naive. That Firefox on HX is apparently just an April Fools joke. Ironic, though, since it's plausible in theory (barely)!
> > My audience for my releases are progressive DOSsers knowing what to do
> > with stuff like PNG, TAR, OGV, 7-ZIP, & Co
> Ok, fine. Feel free to limit your audience :)
OGV -> search for the APEG thread
7-Zip -> 7za (Win32 binary w/ HX), DJGPP p7zip, my various 7zdec compiles
> > > The documentation is going to be a .pdf but
> > you can't read PDF's in DOS
> But your progressive. Can't you read it with Firefox along with PNG's
>
>
> > > I can throw a text copy in there too.
> > Much better.
> Totally agree. TXT copy and HTML copy is good. PDF not.
You can definitely read .PDFs in DOS, just not easily (and I never bothered), e.g. Ghostview, XPDF, Acroread (only old old .PDFs, but my Falcon 4.0 CD has it!). Nah, I wouldn't recommend it, but heck, I still think the text file from GALCON 7.5 seems good enough!!
> Keep up the good work Jason!
It's almost funny how all you guys (you, Ninho, Jason) have to be careful not to annoy the wives with your computer projects, heh. I guess I'll get there one of these days. |
Arjay
12.12.2009, 12:42
@ Rugxulo
|
DOS Game - Galactic Conquest v9.00 test |
> Even PCX has some wimpy optional compression, no?
Correct it's RLE. Very easy to implement. Indeed I remember there was/is a PCX viewer in asm for 320x200 which compiles to 128 bytes which interestingly means you can just replace the useless header with the viewer. Very cool ;)
> I think most tools don't
> support the compressed variants, that's why.
Yeah just quickly looked at my old BMP code. Looks to me like (at least in the past) that although BMP structure itself had to entries "CompressionType + CompressedImageSize" that things like the BMP/DIB clipboard format didn't !
> (I guess you know that JPEG is a pain!!!)
Yup hence I never wrote a viewer myself/well also moved onto other things.
> The only PNG viewers for DOS (off the top of my head) are Display, QV/PNG,
> and Pictview. Nothing for < 386, though (probably moot but still ...
Useful background info thanks.
> I can't say I don't dream of writing / porting bzip2 [-2 at least], .png
> viewer, etc).
Well there is still time as I guess we are all still relatively young ! :)
> Actually, I think we were both naive. That Firefox on HX is apparently
> just an April Fools joke. Ironic,
Doh! That'll teach me to not read through it further.
> though, since it's plausible in theory (barely)!
Indeed...
> You can definitely read .PDFs in DOS, just not easily (and I never
Indeed hence not worth including it when .TXT / .HTML easier to view. Good call re the document convert above btw.
> think the text file from GALCON 7.5 seems good enough!!
Yeah totally agree .TXT is best. Has to also have the .TXT extension as sadly as you know we lost the .DOC one a long time ago... !!!
> It's almost funny how all you guys (you, Ninho, Jason) have to be careful
> not to annoy the wives with your computer projects, heh.
It's a fine balance.... speaking of which ttfn !!!
> I guess I'll get there one of these days.
Yeah life soon catches up with you. |
DOS386
12.12.2009, 13:40 (edited by DOS386, 12.12.2009, 13:57)
@ Arjay
|
DOS PNG support |
> It still amazes me that RLE support within BMP's has never been used as
> much as it should have been. Not that I'm supporting the use of BMP's
Forget RLE in BMP's
> There's no need for sarcasm.... oh wait there is!
see below
> Well I was thinking of DOS viewer support. e.g. QV v2.58 doesn't support PNG
True, but not relevant
> PNG whereas PV v2.78 does support PNG.
Display supports PNG, PictView supports PNG, Blocek supports PNG (regrettably buggy), CSHOW reportedly supports PNG (crappy), NCONVERT supports PNG, my experimental PNG code supports (but what ??? ), ...
> looked at real old stuff like CSHOW etc but last time I checked
20 years ago
> that didn't support PNG!
It does, if you use the Time Dilatation Hack correctly to suppress the ERROR 200 BUG
> I was not aware of attempts to get Firefox to under HX until I read your
> own posting about it, but clearly not even that looks like an option for
> viewing PNG under DOS right now.... and lets not add FF to the ZIP just to
> view a couple of PNG's.
See ^^^ above
> Indeed I have been following the HX threads with interest for sometime.
> I did note that Rugxulo and myself seem to be very aligned about
forgot to set the AC bit in EFLAGS ???
> id=7332 NOT using PNG's under DOS for the very good reasons we've pointed out
YES, the reasons are there, but are just invalid. But feel free to use PNG's under CP/M only
> Ok, fine. Feel free to limit your audience
> Real world experience.... Indeed I vaguely remember writing for this code
> Type
> TGA_Head=Record
> ID_filed_Length:Byte; {1 1}
> ColorMapFlag:Byte; {1 2} {1 = paletted image, 0 = TrueColor}
> ImageType:Byte; {1 3}
> FirstColorMapEntry:Word; {2 5}
> ColorMapSize:Word; {2 7}
> ColorMapEntrySize:Byte; {1 9}
> X_Left:Word; {2 10 }
> Y_Upper:Word; {2 12 }
> PixelWidth:Word; {2 14 }
> PixelHeight:Word; {2 16 }
> Bits_Per_Pixel:Byte; {1 17 } {Number of bits per pixel for each
> plane}
> ImageDescriptorByte:Byte; {1 18}
Is it Fortran or Cobol ??? Supply a "well" compressed TGA
> > > The documentation is going to be a .pdf but
> > you can't read PDF's in DOS
> But your progressive. Can't you read it with Firefox along with PNG's
NO. FireFox doesn't support PDF, RTFM
> Try Halibut (or from its developer's site), it lets you write messy text files with a
> small amount of markup and converts them to proper text files and HTML
> documents and PDF documents (and some more).
Yeah
> Even PCX has some wimpy optional compression, no?
YES, it's just dead (see far above)
> The only PNG viewers for DOS (off the top of my head) are Display,
> QV/PNG
???
> and Pictview.
Isn't it enough ???
> Nothing for < 386, though (probably moot but still ... I can't say I don't
> dream of writing / porting bzip2 [-2 at least], .png viewer, etc).
Me too
> OGV -> search for the APEG thread
NO. Search for DUGL Player thread.
> 7-Zip -> 7za (Win32 binary w/ HX), DJGPP p7zip, my various 7zdec compiles
YES.
> You can definitely read .PDFs in DOS, just not easily (and I never bothered)
Didn't work for me. You can well use PNG, TAR, OGV and 7-ZIP in DOS, but not PDF.
> Acroread (only old old .PDFs, but my Falcon 4.0 CD has it!).
From 1992, < 1% of PDF's around.
> > The only PNG viewers for DOS (off the top of my head) are Display, QV/PNG,
> > and Pictview. Nothing for < 386, though (probably moot but still ...
> Useful background info thanks.
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.GraphPaintCAD
> Yeah totally agree .TXT is best. Has to also have the .TXT extension as sadly
> as you know we lost the .DOC one a long time ago... !!!
Indeed.
FYI, the 2 PNG's in the ZIP can be losslessly optimized by factor 1.51 saving almost 4 KiB of bloat
> Keep up the good work Jason!
Don't do this !!! Or at least don't come back into this thread, it's bloated, and you will never finish reading it all --- This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft *** |
Arjay
12.12.2009, 15:23 (edited by Arjay, 12.12.2009, 17:31)
@ DOS386
|
DOS PNG support |
> > looked at real old stuff like CSHOW etc but last time I checked
> 20 years ago
With regards to CSHOW almost correct, I think it was about 15.... Whatever
> It does, if you use the
> Time Dilatation Hack
> correctly to suppress the ERROR 200 BUG
------------------------------------------------------------------------------
[EDIT: removed into new posting as realized info provided is useful to others]
TIP:How to get C o m p u S h o w 9.04a running on modern PCs
------------------------------------------------------------------------------
And your absolutely correct sir, CSHOW 9.04a does support PNG so I will eat humble pie and stand corrected. I'm backing down on my anti-PNG under DOS perspective!
> See ^^^ above
Yeah you got me :)
> YES, the reasons are there, but are just invalid.
As above I fully agreed with you !!
> Is it Fortran or Cobol ??? Supply a "well" compressed TGA
Haha, never bothered with Fortran much. Cobol... I'd rather not remember...
> NO. FireFox doesn't support PDF, RTFM
it does with a plugin :) but lets drop the FF for DOS discussion eh?
> > Even PCX has some wimpy optional compression, no?
> YES, it's just dead (see far above)
Indeed also agree as you can't even easily open them in lots of places now.
> > QV/PNG
http://www.multimediaware.com/qv
http://www.multimediaware.com/pv
> Isn't it enough ???
Yes I agree.
> > Acroread (only old old .PDFs, but my Falcon 4.0 CD has it!).
> From 1992, < 1% of PDF's around.
Well at least I think we all agree PDF for DOS stuff not a great idea.
> FYI, the 2 PNG's in the ZIP can be losslessly optimized by factor 1.51
> saving almost 4 KiB of bloat
We should all get out more... heh Indeed it's not even raining in the UK right now... well my part (south) which means the North must have rain...
> Don't do this !!! Or at least don't come back into this thread, it's
> bloated, and you will never finish reading it all
LOL ! |
sinclaj1
U.S.A., 12.12.2009, 17:00
@ Arjay
|
DOS Game - Galactic Conquest v9.00 test |
> > I'll try to finish it this weekend, but my wife is headed out of
> country
> > again, so I'm going to spend time with the family this weekend.
> Yes very important to get the family/coding balance right - which is
> exactly why I don't tend to code through the night very much (if ever)
> now... :)
Only when the wife's out of town do I code that late...usually because I can't sleep. |
rr
Berlin, Germany, 12.12.2009, 22:11
@ DOS386
|
DOS PNG support |
> Display supports PNG, PictView supports PNG, Blocek supports PNG
> (regrettably buggy), CSHOW reportedly supports PNG (crappy), NCONVERT
> supports PNG, my experimental PNG code supports (but what ??? ), ...
Don't forget QPNG/386 version 1.7e or QPV/386 version 2.0 by Oliver Fromme. Both freeware. --- Forum admin |