Floppy (I)WAD

[AnotherGrunt]

Hello guys,

 

could you please recommend some IWAD (not PWAD) which would fit into one regular 3½″floppy disk? I.e. file size limit 1440kB or less.

 

My initial thoughts were how I'm gonna take Shareware DOOM 1 extract map or two in SLADE, copy PLAYPAL, needed textures and sounds and it's going to work and bam. Just textures little over 2MB. It is not so easy. It is even possible to fit WAD into floppy?

[Dexiaz]

Ok, who time fcuked the universe this time? I suppose this post came from 1994...

 

But seriously talking: it's impossible to put the whole IWAD to 1 floppy disk. And I don't know the way to reduce it's size to 1440 kb. Unless you'll just destroy resize all textures to few pixels...

Edited May 17, 2020 by Deⓧiaz

[Redneckerz]

8 minutes ago, AnotherGrunt said:

Hello guys,

 

could you please recommend some IWAD (not PWAD) which would fit into one regular 3½″floppy disk? I.e. file size limit 1440kB or less.

 

My initial thoughts were how I'm gonna take Shareware DOOM 1 extract map or two in SLADE, copy PLAYPAL, needed textures and sounds and it's going to work and bam. Just textures little over 2MB. It is not so easy. It is even possible to fit WAD into floppy?

 

[AnotherGrunt]

6 minutes ago, Deⓧiaz said:

Ok, who time fcuked the universe this time? I suppose this post came from 1994...

I did. Bought brand new floppy drive just for the ocasion. ;-)

 

6 minutes ago, Deⓧiaz said:

But seriously talking: it's impossible to put the whole IWAD to 1 floppy disk. And I don't know the way to reduce it's size to 1440 kb

Compress it. But that would require decompression mechanism right in Doom binary. Shareware DOOM fits on two floppies but it is compressed with PKZIP.

 

Redneckerz: Great. But maybe something with more textures and everything? File limit is little bigger than 250kB.

Edited May 17, 2020 by AnotherGrunt

[Redneckerz]

2 hours ago, AnotherGrunt said:

Compress it. But that would require decompression mechanism right in Doom binary. Shareware DOOM fits on two floppies but it is compressed with PKZIP.

Which requires prodding with the executable. Your best bet if you want something with more textures is to use a demoscene compressor like Crinkler or .kkrunchy, and even those are targetting files significantly smaller than Shareware Doom.

 

2 hours ago, AnotherGrunt said:

Redneckerz: Great. But maybe something with more textures and everything? File limit is little bigger than 250kB.

Miniwad was made to have a Doom experience as small as possible yet still somewhat resemble Doom. If you want something more than that, then you will need to create your own IWAD.

[AnotherGrunt]

1 hour ago, Redneckerz said:

demoscene compressor like Crinkler or .kkrunchy

On 80386 or 80486? I don't think so.

 

1 hour ago, Redneckerz said:

If you want something more than that, then you will need to create your own IWAD.

Which was exactly my idea. I had to pull the thing out of trash bin. E1M1 + E1M2 with everything unnecessary striped away:

Misc (PLAYPAL, COLORMAP,…): 88,92kB
E1M1+E1M2: 166kB
Sounds: 525,57kB
MIDI(MUS): 96,69kB
Menu and Interscreen: 625,5kB
Guns & Projectiles: 207,61Kb
Monsters & player (Sprites): 401kB
Things: 50,68kB
Environment textures: 893,71kB

This sucks. What more can I omit? Any ideas?

 

Honestly, I really need only necessary things in IWAD because everything else can be packed in PWAD on another floppy. But can I omit environment textures and load them from PWAD? I don't think Init refresh daemon is going to be OK with it. Everything packed with PKZIP: 1,28MB

[sergeirocks100]

i had to type this out again because i posted in the wrong thread by mistake, but i'm going to see if i can make some sort of IWAD fit into 1.44 megabytes, once i'm finished, i'll post the link here

[Redneckerz]

1 hour ago, AnotherGrunt said:

On 80386 or 80486? I don't think so.

You can obviously compress DOS executables on windows. I haven't checked on a DOS equivalent but i do know those exist.

1 hour ago, AnotherGrunt said:

 

Which was exactly my idea. I had to pull the thing out of trash bin. E1M1 + E1M2 with everything unnecessary striped away:

Misc (PLAYPAL, COLORMAP,…): 88,92kB
E1M1+E1M2: 166kB
Sounds: 525,57kB
MIDI(MUS): 96,69kB
Menu and Interscreen: 625,5kB
Guns & Projectiles: 207,61Kb
Monsters & player (Sprites): 401kB
Things: 50,68kB
Environment textures: 893,71kB

This sucks. What more can I omit? Any ideas?

 

Honestly, I really need only necessary things in IWAD because everything else can be packed in PWAD on another floppy. But can I omit environment textures and load them from PWAD? I don't think Init refresh daemon is going to be OK with it. Everything packed with PKZIP: 1,28MB

I used to remember a very old DOS program that could make the shareware episode fit on a floppy, but the name escapes me.

Slightly related, There were 2.88 MB floppies in existence which can hold Doom shareware as is. As it stands it does not seem like there is an option to compress it to 1.44 MB, unless you just go for a single level.

PS: I was thinking that your request was unusual, but as it turns out, it has been asked prior in history. Perhaps Fraggle's Miniwad was a response to that.

One thing i could imagine is to make a single level PWAD and combine that with a very minimal source port, which would run from floppy.

[AnotherGrunt]

3 minutes ago, Redneckerz said:

You can obviously compress DOS executables on windows. I haven't checked on a DOS equivalent but i do know those exist.

Yes but you need to read it and uncompress it quickly. Demoscene compression mechanism just are not what I'm looking for. It has to run at least in DOSBox and realtime.

 

6 minutes ago, Redneckerz said:

Slightly related, There were 2.88 MB floppies in existence which can hold Doom shareware as is.

I'm aware of that but next in line is old 5 1⁄4-inch disk drive, so I'm targeting better software solution, not hardware. Besides, my drive can do only IBM-formated.

 

10 minutes ago, Redneckerz said:

As it stands it does not seem like there is an option to compress it to 1.44 MB, unless you just go for a single level.

If you know which one please let me know. I'm unable to fit even one level on floppy disk.

 

13 minutes ago, Redneckerz said:

One thing i could imagine is to make a single level PWAD and combine that with a very minimal source port, which would run from floppy.

No need to. Binary fits barely into one floppy so I have another floppy just for WAD, but as is WAD standalone file, it needs another floppy in count of one.

[Linguica]

What are the rules? Surely you need to include the EXE on the floppy as well. Could you include utils to, like, create a RAM disk and then unzip the IWAD into memory? Should you include DOS itself on the disk so it could run on a computer with no hard drive at all?

[Dark Pulse]

The only way I could think of would be some kind of procedural generation - i.e; rather than try to crunch the IWAD onto a floppy, you create some sort of program that, when run, somehow recreates the IWAD into RAM, then make sure that program is small enough to fit onto a floppy.

 

As for how you'd do that? Good luck. But I remember that old game .kkrieger took what would've been a 300-400 MB game if done conventionally and fit it all into a single 96k EXE that re-generated the assets when you ran it.

[AnotherGrunt]

1 minute ago, Linguica said:

What are the rules?

There are no rules. I've implemented friggin floppy flickering and just need to see it working. That's all. Binary has to be loaded before execution into memory anyway, so I can simply implement pause to floppy swap. No big deal. Just there is propably not one WAD file which will fit on small floppy. No RAM disk and unzipping please. 

[Redneckerz]

9 minutes ago, AnotherGrunt said:

Yes but you need to read it and uncompress it quickly. Demoscene compression mechanism just are not what I'm looking for. It has to run at least in DOSBox and realtime.

Then something like a demoscene loader (Lel there it is again) comes to mind. On Amiga, in order to speed up pre-calcing, they use these loaders to compress and load modules at run-time. You can even go further beyond on that platform by doing stuff in a boot block, which is residing in the bootloader.

That's not what you are after i realize, but a project that does do this ''Putting Doom in a small space'' idea is Doom UEFI.

I am with Dark Pulse here that if you want something that isn't MiniWad and still looks like Doom but on 1.44 MB tops, you have to do some procedural generation. So not storing the actual textures in a WAD, but a file that describes how a Doom texture looks like, so it can generate it at runtime.

To my knowledge there is nothing in existence that has pulled that off (Procedurally generating a Doom WAD with textures, as opposed to procedurally generating a level) so this is definitely an interesting use case.

 

9 minutes ago, AnotherGrunt said:

No need to. Binary fits barely into one floppy so I have another floppy just for WAD, but as is WAD standalone file, it needs another floppy in count of one.

Then instead of a source port you would need something like a Doom loader program, a very minimalistic executable that just does the bare minimum, which is loading up a Doom WAD.

That could actually work if you could devise a way to procedurally generate the needed textures, flats and what not. Like i said, its definitely interesting, and i do believe this is the way to go, but the implementation might be a challenge, given how Doom relies on a lot of variables.

I am not sure if you can net all these variables in a procedural framework. For that to work, i imagine that you need some kind of table that takes the standard Doom behavior (Read: Repeated and expected behavior) into account.

[AnotherGrunt]

3 minutes ago, Redneckerz said:

I am with Dark Pulse here that if you want something that isn't MiniWad and still looks like Doom but on 1.44 MB tops, you have to do some procedural generation.

 

Or I can link it to libpng, implement ADPCM for sound and convert things but right now I'm just looking for one pretty WAD file which could I run directly from floppy. Even one level to test it.

[Redneckerz]

22 minutes ago, AnotherGrunt said:

 

Or I can link it to libpng, implement ADPCM for sound and convert things but right now I'm just looking for one pretty WAD file which could I run directly from floppy. Even one level to test it.

It seems you have to do that yourself or stick to Miniwad.

So i guess that's the alternative: Make it Miniwad compatible. It won't look great, but hey, its a Doom level on Floppy.

[AnotherGrunt]

Just now, Redneckerz said:

It seems you have to do that yourself

 

I'm not mapper. You need to code something into binary? No problem, but mapping isn't for me.

[Redneckerz]

25 minutes ago, AnotherGrunt said:

 

I'm not mapper. You need to code something into binary? No problem, but mapping isn't for me.

You can't just take ORIGWAD ,OfficialGeeDee's template,  Daniel's Three Test Maps or Kinsie's Gameplay Test Map and try to see if you can get that in floppy?

[Redneckerz]

@AnotherGrunt In addition to the test maps above, perhaps Exl's MC Doom map compressor or CleanWAD might be of use?

[AnotherGrunt]

Redneckerz: Thanks a lot. It looks like useful tool. I'll go through it.

[Gokuma]

Maybe use this or this for sound effects?

 

Could use DShrink on maps.   Not sure how it compares with what Redneckerz posted.

Edited May 19, 2020 by Gokuma

[AnotherGrunt]

Ok, so I took a little more systematic approach and wrote small debugging hack directly into MBF's source code:

 

 

My initial idea was to strip down shareware version just to one or two levels and fit it onto floppy but I was clearly wrong. Do you remember infamous Init DOOM refresh daemon?:

 

 

That thing is responsible for graphical subsystem initialisation. And besides, loading every one damn graphical patch between S_START and S_END and rendering/compositing them into a proper texture in memory. Same goes for digital sounds:

 

 

and last thing before screen mode switch I'm able to see loading data for text/menu and HUD. I don't see it but I assume entire menu textures has to be loaded before menu is shown. Then we have few second pause and loading first demo level with all textures for given map. Yikes!

That is a lot of data. And we haven't even started our first map (don't even ask how it looks for Ultimate DOOM or DOOM2.WAD). So clear thing to do is to partition WAD and arrange things accordingly:

1. One floppy just for binary, maybe miscellaneous things (MBF has lot of embedded things and these can be extracted to standalone WAD). It will barely fit.
2. Second floppy for initialisation. And I'm afraid if one floppy won't be just enough. I don't know.
3. Third floppy for one or two maps or demo maybe. Just for anything from Shareware version that remains and will fit.

 

But get this:

Just after initialisation is done, data (more specifically patched textures but anything can be retaged) are marked by PU_CACHE tag:

           memcpy((byte *) col + 3, source + col->topdelta, len);
            col = (column_t *)((byte *) col + len + 4); // next post
          }
      }
  free(source);         // free temporary column
  free(marks);          // free transparency marks

  // Now that the texture has been built in column cache,
  // it is purgable from zone memory.

  Z_ChangeTag(block, PU_CACHE);

so data can be freed from memory if not needed (PU_CACHE block is freed by zone allocator if it runs out of memory) and then reloaded back again just as they are needed. Clever, really clever. But a bit of pain for me.

If I will partition main wad and add a little pause for floppy swap I can't just stop somewhere and write on screen something like "Whoops, texture not cached anymore. Please insert disk #2 press ENTER and switch it back again".

 

So, clear thing to do is just go through source code and delete any Z_ChangeTag to PU_CACHE and leave as much PU_STATIC resources in zone memory as possible. Hmm. But I don't like that either. Memory management is pride of DOOM engine. It's like little symphony between available resources. Between available memory, HDD and what is on the screen (yes, textures can be freed after they are rendered and not in view anymore). If you understand how virtual texturing (aka Megatexture in idTech5) works, it's almost the same thing. It is nothing new. And I don't want to destroy it with making it static because I have to swap floppies. 

So questions follow:

• How to solve this shit? Do you guys have any cleverer idea? I mean, how would John Carmack do it?
  I've been thinking about marking every resource by additional tag with resource location but as I said: I can't imagine how it would work in gameplay.

  Quote

    -Lump 384 not cached. Please insert disk #3 and press any key
    -Lump 108 not cached. Please insert disk #2 and press any key
    -Lump 205 not cached. Please insert disk #4 and press any key

    -...

   

• Is booting process (meaning anything before resolution mode switch and displaying menu) somewhere described in detail and in plain english language? It is really interesting stuff I should know about and I don't want to scan entire source code. It is time consuming.
• As far as now, I'm going to partition and fit on floppies Shareware WAD because it is smallest. If you know any smaller but interesting WAD, please let me know. And no, Minimalist IWAD isn't interresting enough. Sorry.

Edited June 14, 2020 by AnotherGrunt

[AnotherGrunt]

Ok, so I went through list and spliced Shareware WAD accordingly:

• I_WALLPATCH.WAD - between P_START → P_END, PLAYPAL, COLORMAP, other (necessary) stuff; 828 kB
• I_THINGS.WAD - between S_START → S_END; 816 kB
• I_SOUNDSFX.wad - sounds and D_INTRO; 548 kB
• I_HUD.wad - textures necessary for HUD initialisation; 136 kB
• M_MENU - Menu textures; 368 kB

But I'm still missing something:

 

 

Any idea?

[Dexiaz]

12 hours ago, AnotherGrunt said:

Any idea?

According (obviously) to the error text - you're missing patches in textures.

R_InitTextures: Missing patch in texture %s
A texture definition references a patch which was not found in any loaded WAD file.

So you need to add missing patches in your I_WALLPATCH.WAD

Edited July 13, 2020 by Deⓧiaz

[AnotherGrunt]

On 7/13/2020 at 8:22 AM, Deⓧiaz said:

According (obviously) to the error text - you're missing patches in textures.

R_InitTextures: Missing patch in texture %s
A texture definition references a patch which was not found in any loaded WAD file.

So you need to add missing patches in your I_WALLPATCH.WAD

 

Yes, you're right. But unfortunatley, these pacthes are virtual or what. I dont't see them (in SLADE). They are in WAD (can find them through Hexaedit) but I don't see them in editor. Do I need diferent editor?

[Dexiaz]

10 hours ago, AnotherGrunt said:

I dont't see them (in SLADE)

 

That's why you're getting the error.

 

And you don't need different editor.

 

You need to load into your wad WALL00_3 (this is Patch 0 for AASTINKY), WALL00_1 (for GRAYTALL), SW12_4 and SW12_5 (for STARTAN1), and SW1S0 + SW1S1 (for SW1STRTN and SW2STRTN)

[AnotherGrunt]

13 hours ago, Deⓧiaz said:

 

That's why you're getting the error.

 

Oh, now I get it. AASTINKY is name of texture and WALL00_3 is patch for texture. Thanks man. I had to add few things (STDISK, F_START, F_END) and it finaly works. It is 2698kB just to get main menu. Then 10 seconds and F_SKY1 missing because engine is trying to load first demo. Horror.

[Da Boi]

I got the full game wad on 3 floppy's but without the program to run it.

[Da Boi]

Using winrar and im VERY YOUNG.

Edited September 1, 2023 by Da Boi