myk
webbed digits

Posts: 14316
Registered: 04-02 |
CEOofAEP said:
I think I kind of do- like a referencing index?
The markers you guys are talking about (more properly PP_START and PP_END, with the double P both times) are so that editing tools can detect wall patches. The game engine itself does not used these markers because it relies on PNAMES instead (though it does use other markers I mention below.) The markers are only for wall patches, and not all graphics, but only the ones drawn on walls. Not the floors and ceilings, nor the menu, status bar, intermission or title pic graphics. Those don't go between these markers. The ones you included in E1M0.WAD don't need or use any markers around them.
PNAMES is just a list of wall patches. The engine uses that list to identify each wall graphic (patch) so as to place them on textures. Textures are information making the compound graphics you place directly on walls. You know how you can have an image with "layers" while editing with Paint Shop or the GIMP? A texture is like that, using the wall patches, placing one on top of another to make a wall graphic. They made it like this so they could use fewer graphics to create a variety of varied textures, such as making one concrete wall, and then a similar texture that uses the same concrete background plus a switch on top of it.
TEXTURE1 (also TEXTURE2 in DOOM, but you can pretty much ignore it as far as adding graphics is concerned) is a list of compound textures (with "layers," as mentioned above) one can select when mapping. Each texture has width and height dimensions (these will be important when placing it on a wall in the level) one or more patches from PNAMES assigned to it and coordinates for the placement of each patch.
In addition, there are flats (placed on ceilings and floors.) These are simple 64x64 graphics in a different format, and they all go between FF_START and F_END (double F the first time, single F the second.)
Then you have sprites, which are the monsters, items, decorations and weapon graphics. These go within SS_START and S_END. In brief, these are the hardest to replace in the standard (not source port specific) engine. You can only modify existing ones and not really add new ones.
All other graphics (title pic, help and credit screens, intermission pics, intermission animations, intermission text and level names, menu graphics, status bar, status bar patches and animations and small chat font) are all in a format like the patches and sprites, but don't go within any sort of marker. They're roughly bunched together much like they are in the IWAD.
Here's what I did: I created a new WAD in SLumpEd, called it "e1m0.wad", opened the "doom.wad" and copied all the entries that I wanted to replace from "doom.wad" to "e1m0.wad". Then I went through each entry and selected "Lump|Import|-select file-".
The issue here is that SlumpEd decided to retain the GIF format. DOOM normally has no clue what a GIF is and instead has its own graphics formats; flats and all other graphics. Everything that is not a flat uses the latter. The latter can be aligned right-left and up-down, while flats are always placed in a fixed 64x64 position. SlumpEd has an option somewhere, to reformat each graphic (independently or by selection, I suppose) to the "Doom Gfx" format, if I am not mistaken (unfortunately I must rely on memory here because on my computer SlumpEd knows little but how to quit with a crash or error.) Look for that option and reformat each graphic. It probably also has an option to import in the "Doom Gfx" format in the first place. Do that for all graphics except flats, where you would use the "Doom Flat" format.
I also adjusted the "offset" of the graphics the way they were in the original doom.wad
You might need to change this once you reformat the graphics into the Doom Gfx format, unless these new graphics are all the same size as the originals. If you still get Bad V_DrawPatch once you're reformatted the graphics, it's because one or more are wider or taller than the originals and are being drawn partly off the screen. You have to align these away from the screen edge till they fit, or make them smaller. Fortunately, this error comes up when the graphics are used in the game, so if there's some off-screen graphic on the intermission screen, Chocolate Doom will close there with the error.
I set up Doom Builder(2) to load this WAD along with the level I wanted to test (e1m1, in this case)... but when I test-play the level (in Eternity), none of the graphics show up. In fact I get something much like a HOM where those graphics should be (and the cursor skull doesn't show up at all, either)
Are you interested in retaining your WAD's "vanilla" compatibility? If so, use Chocolate Doom (or the DOS executable on DOSBox) for testing. Most modern ports are lenient on many glitches and errors that would otherwise cause Doom to quit with an error or crash. My advice is to test first and foremost with the "base" engine for what you are aiming to do. I'd use Eternity as the main testing engine only if I were making a WAD that is specific for Eternity.
CEOofAEP said:
So much work back then- especially considering they never saw any sort of public exposure.
They worked because DMGRAPH or whatever just took GIFs and converted them to the DOOM graphics format. Now, editing tools like SlumpEd allow you to import stuff in many ways, which leaves you wondering what option to use, what menu to open, when trying to do anything.
BTW- how do I replace SKY1? I see it in the textures but there's no option to extract it. Would I just add it as a Lump between P_START and P_END and then add it to PNAMES?
The skies are special. They are placed like flats on the ceiling or floor (which like I said above are simple 64x64 graphics that are placed in a fixed position) but are "wall textures." So, to change the sky, you have two choices. The simpler one is to place a 256x128 graphic called SKY1 between PP_START and P_END among all the wall patches. It's a patch. This will change the sky, but you won't be able to use the original SKY1 graphic in your levels because you have essentially replaced it. Normally, this isn't a problem, unless you want to use the sky as a wall texture, on a wall, somewhere in your level.
If you do want to retain the option to use the old sky (maybe as a sky for another episode or as a wall,) then you need to import your new (probably 256x128) sky (as Doom Gfx) just as above, yet instead of calling the new patch SKY1, you'd give it a different name, such as MYSKY, adding it to PNAMES. There should be an option for this when you right click the patch lump name in the main list to the left. After that, you edit the SKY1 entry in TEXTURE1. Select TEXTURE1, look in the list that appears to to the right (it says Textures at the top) and find SKY1 (yes, there are two things called SKY1, a texture entry in TEXTURE1 and a patch.) Now to the lower right of the large box that shows the texture graphic there's a Patches list. The only thing in there is SKY1. Choose Remove patch. Now over the Patches list and under the PNames list is Add patch. Look for MYSKY and add it. It will appear where SKY1 used to be. Now you'll have a new sky and the possibility to use the old graphic as well.
Gez said:
I think you might want to try by targeting a port that's easier to mod for, such as ZDoom.
It's not "easier to mod" unless you use ZDoom just to do the same thing you'd do for vanilla or Boom, for example. ZDoom makes some things easier but then adds a bucketload of things which are not that easy to master or combine. Treating ZDoom like some kind of "easier vanilla" you get those people who barely know the difference between a flat and a texture and waste their own time using ZDoom in a half-assed manner to everyone's perverse amusement.
That is, even if one uses ZDoom's additional texture specifications to simplify things when making a ZDoom-based mod, it's much more convenient to know how to use vanilla flats and textures, as well, as it'll allow the designer to examine and modify the majority of existing WADs, which use the original methods. More so, even, if one is interested in making levels that work across many engines or likes to make rather classic-styles levels for one reason or another. Were someone making some type of "new game" mod for an "advanced" source port, unrelated to all the existing WADs and megawads in design and style, then maybe ignoring the old methods would make sense.
|