EWad proposition

Good idea?

  • Great idea!

    Votes: 0 0.0%
  • Good idea.

    Votes: 0 0.0%
  • Don't care / don't understand

    Votes: 0 0.0%
  • Bad idea - not worth the effort

    Votes: 0 0.0%

  • Total voters
    0
Status
Not open for further replies.

hotdog003

Member
Hey, all!
I have a crazy + evil + far-fetched idea: What if we made a new standard for WAD files? I got to thinking, and devised this geeky little tidbit:
Code:
////////////////////////////
//Standard wad3 structure//
//////////////////////////

//Old style

wad {
    4byte string	"IWAD" or "PWAD"
    4byte long  	Number of lumps
    4byte long  	Directory pointer

    Lump {
        Data
    }

    // Begin the directory.

    Lump index {
        4byte long	File offset
        4byte long	Size of lump
        8byte string	Lump name
    }
}

////////////////////
//EWad structure //
//////////////////

//Enhanced Wad Format: Shiny New style

ewad {
    4byte string	"EWAD"
    4byte long		Number of lumps
    4byte long		Pointer to directory
    Lump {
        Data
    }

    //Begin ewad directory

    Lump index {
        4byte long	File offset
        4byte long	Size of lump
        2byte int	Leingth of lump name
        *byte string	Lump name
    }
}
Basically, the new format allows just over 65,000 characters in a lump name, unlike wad3 which you are confined to just 8. Think about the possibility: You could have folders within WAD files by abusing the long lump names. Think: Instead of having "PLAYA2A8", you could have "/Skins/Sonic/Frames/Standing/Angle28" as a lump name. That would be REALLY good for n00bs who don't know how to wad, as it really simplifies things.

You all may think I'm crazy, and you all may think it's a stupid idea, and you may not be far from the truth, but I think it's worth considering. Besides, it wouldn't be too hard to fix in SRB2's code, right?

The only problem I see with this setup is that there are no editors that can write to this format. So, unless you have the proper tools to export it, you'd have to stick with the wad3 standard, which is annoying if you want to make a character.

But, think of the possibility: You could have folders at the root containing things such as /images, /flats, /textures, /skins, /maps, /music, /sounds and within, oh, say /skins, you could have /skins/playernamehere/frames, /skins/soc, /skins/icons, /skins/playernamehere/frames/standing, etc.

EDIT: My original plan was to have this be backwords-compatible by having two directories, one would be wad3 format and one would be ewad format, but since this change is so basic, then it would be rather pointless, as most wad editors erase any extra data within the wad file, including the ewad directory and... yeah.
 
SRB2 Wad Editor, DigbyWAD, I could write a new lumpmod version too if need be.

EDIT: Maybe we could take it one step further and add a 1byte short integer to the directory structure for each lump specifiying the lump type, so that you would instantly know what type a lump is (ogg, wave, midi, flat, Doom Sprite, etc etc.), but the only problem with that is if you'd want to convert a sprite to a patch or something, and normal wads are already good at identifying types as they are.
 
I'm loving this idea, but it would screw any hope of making maps. :\

EDIT: I just remembered that Doom Builder is Open Source so we could actually mod it to support this EWAD type. OMFG IT WORKS
 
I don't see it as worth it. I mean, why would you need that many letters in your lump name. Yeah, I agree that it can be a hassle with such short names, but one click on it will show you what it is in most editors. It's certainly not worth breaking compatibility with every WAD editor in existance ^_~
 
The long lump names, as Hotdog suggested, can be part of a folder hierarchy. A lump editing program can just emulate a folder tree out of the lump names, yet in the WAD itself, it's just stored as such.

Agreed, I don't think it's possible to completely abandon Wad3, but then again, most WAD editors aren't really that great anyway, mine included.
 
For
It provides structure. You can have folders, as mentioned above.
It's practical. Long lump names are better.
It's not to hard to impliment in the code. You wouold change just three things: The header, the size of the strings, and the directory loading routine.
You can go backwards if you want. If your editor doesn't support EWad, why not have the option of ADDFILEing plain wad3 files?

Against
It's hard to impliment in the files. Who wants to spend the time renaming 12,000 lumps in srb2.srb, the player files, and the ring weapons? I sure don't.
It's new. This format wouldn't be well known. You again would have to change every single wad editor if you didn't want to use the old wad3 style.
There are better formats out there that do just as good of a job. If we really want long lump names, then why not just replace it with a .TAR or a .ZIP loading routine?
 
hotdog003 said:
It's practical. Long lump names are better.
It's not to hard to impliment in the code. You wouold change just three things: The header, the size of the strings, and the directory loading routine.
You can go backwards if you want. If your editor doesn't support EWad, why not have the option of ADDFILEing plain wad3 files?
Excuse me sir, but how do you even know either of these things? Have you actually bothered looking at SRB2's lump management code?

And "Long lump names are better" is just... Almost unintellegent, when you plainly say it like that.

I have indeed thought of removing the limits of wads, replacing all textures and sprites with png files which could have semitransparency by the pixel and whatnot, using 7z format for it, etc. ...

But it's not worth the effort of rewriting all that code just so your wad can already be zipped up and your lumps can be pretty-looking, now is it? As it is, we have few editors which can even support lowercase characters. x_x
 
JTE: Actually, I must admit that I didn't do my homework by looking at SRB2's code, so... yeah... This was intended just to be a crazy idea, something to consider, but if it won't work, then that's just what I thought would happen.
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top