Using Build-engine Maps With ZDoom

Discuss all aspects of editing for ZDoom.
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Using Build-engine Maps With ZDoom

Postby CrystalWolf » Mon Jun 01, 2009 6:28 pm

The first thing I must stress before you read any further than the title of this topic is that this "feature" is completely fucking broken in recent versions of ZDoom and I was just kind of poking around this for my own amusement, and am merely documenting my findings and questions here for posterity. If I were you, I would consider this "feature" to be heavily deprecated and no longer valid in ZDoom or it's child ports.

But yes. Interestingly enough, though I'm sure this has been covered before and is well-known, ZDoom has limited capability to load and run Build-engine .MAP files. I remember at one point reading that Randy had dabbled with making a port of Duke Nukem 3D aptly named ZDuke (though from what I recall it was just a silly little experiment and was apparently based on ZDoom 2.0.48). I decided out of amusement, considering that the "description" field of the only official ZDuke release was denoted as "ZDoom 2.0.48", to see if I could load Duke Nukem 3D .maps (which are Build Engine format 7) with 2.0.63a, and to my amazement at the time, I was partially successful.

That being said, I decided to try again with 2.3.1. The map loaded fine and to my enjoyment I saw the tell-tale list of "Unknown texture BTILxxxx" warnings flood my console, but the executable bombed after loading the map with a segmentation violation. Strangely though, I tried again with the same version of ZDoom a few minutes later, and I got a general protection fault...?

NOTE: Loading an excessively large Build-engine .map file (>400K) will not cause problems by itself in 2.3.1, but attempting to play the map appears to cause ZDoom to hang. I haven't tested this with any other versions though...

Anyway, disappointed, I decided to roll back to 2.0.63a and got some screenshots showing what worked and what didn't back at the time when 63a was the shit. The screens were taken from ZDoom 2.0.63a and EDuke32 v1.4.9.9 on a map (my absolute favorite Duke map) called "RED3.MAP" by an unfortunately unknown author. I have attached the map in question - unfortunately without the text file that I would prefer to keep the .MAP file with - for your convenience if you'd like to play around with it in Duke and 63a. The full-size screenshots were taken from 1024x768 24bpp PNG's from ZDoom and 1024x768 uncompressed TGA's from EDuke32 and all were resized to 512x384 for the sake of speed.

ImageImage

The first thing that deserves attention about this set of shots is that the area represented in the screenshots is not accessible in 63a without noclipping there. It should be noted that Sector Effectors (and presumably all other similar gameplay-altering mechanics) are not implemented in 63a and it is assumed that they never were implemented at all, since loading Build maps is broken entirely after 63a. Giving Sector Visibility values in Build seems to have some effect in 63a as can be more clearly seen in the EDuke32 shot.

Does anyone know if Sector Effectors (and the other game-altering sprites such as GPSPEED and CYCLER) were ever implemented in any version of ZDoom? Moreover, was it ever possible in any version of ZDoom to otherwise define sector effects in Build Format 7 maps (or any format for that matter) for use in ZDoom?

ImageImage

This set of shots here is a little more interesting. Notice that it appears to not be possible to give Sprites orientation values (align to floor/wall/free). Also visible, but not too well illustrated, is the fact that slopes work completely and it appears that geometric entities (walls and sector planes) can be given shading values in Build and is recognized by 63a.

Does anyone know if sprite alignment in Build engine maps was ever implemented in any version of ZDoom?

ImageImage

This 63a screenshot more clearly illustrates that slopes are fully functional and sector shading/visibility values are clearly understood by this version. 63a also appears to have some limited understanding of the CSTAT field in Format 7 maps (which is a field of 16 boolean values IIRC, one of the bools being to apply a parallax effect to the ceiling or floor). This pair of screenshots clearly illustrates that 63a doesn't quite translate Build engine units to Doom units with 100% accuracy.

Does anyone know of further CSTAT flags support in any other version of ZDoom?

ImageImage

It's a bit hard to see, but in the lower right, we can further see that ZDoom somewhat understands the CSTAT flags field (I believe that's where translucency data is stored for sprites), where a sprite is partially transparent. In Duke3D, that sprite is supposed to represent a Lizard Trooper with Palette #4 with half-transparency, which means it appears to be a "ghost" creature, since Palette #4 is all black not counting transparent areas. The EDuke32 shot here doesn't present anything interesting, it's just there to show what the map really looks like.

It is probably safe for me to assume, judging from the implications presented here, that no version of ZDoom has ever supported and will never support the Palette Index values for sprites and walls, which relies on PALETTE.DAT from DUKE3D.GRP. The way the Doom engine uses PLAYPAL leads me to assume that this is also impossible to implement anyway.

ImageImage

This set of shots is meant to illustrate that the overlapping level geometry that the Build Engine has always been known for is completely broken and unsupported by 63a and presumably broken in all other versions of ZDoom. My guess here is that either ZDoom translates Build geometry to Doom geometry and thus renders overlapping sectors unfeasable, or that ZDoom is using the Polymost renderer just fine but overlapping geometry was never fully implemented.

I would greatly appreciate it if Randy, Graf, or another ZDoom expert could clarify this last one. With that, I close my "documentary" on an interesting but useless ZDoom "feature" that is now broken and presumably deprecated. Thank you for reading this far.

EDIT: Forgot to upload the mapfile, and I also wanted to mention that using -file with the .ART files from Duke is NOT a valid way of including the textures and sprites. You would have to extract each tile by hand and import them with BTILxxxx, starting with BTIL0000, into a .WAD.

RED3.zip
(124.78 KiB) Downloaded 223 times
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Mon Jun 01, 2009 6:36 pm

There should be a command line paramater called -art <directory> which points to a directory (NOT FILE!!!) of art files. There should also be a paramater named -bpal <palette.dat> which should allow you to load a Build Pallette file (even with this, levels won't display 100% right though.)
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby Ceeb » Mon Jun 01, 2009 6:37 pm

Very interesting to read, and fanticize about what could've been. :trippy:
User avatar
Ceeb
Official Idoit Of ZDoom
Banned User
 
Joined: 11 Jun 2008
Location: Castle Wut

Re: Using Build-engine Maps With ZDoom

Postby CrystalWolf » Mon Jun 01, 2009 7:31 pm

Taking InsanityBringer's help to hand, I extracted the .ART files from DUKE3D.GRP and PALETTE.DAT, LOOKUP.DAT, and TABLES.DAT, dumped them into 63a, and got a new shot. It reveals a little more info, but of course, not alot. It's worth mentioning though.

Image

As can be gleamed, even using a PALETTE.DAT straight out of Duke 3D does not quite yield desirable results and is just generally quite ugly. This may have something to do with the fact that Duke3D's palette files are constructed rather unusually (PALETTE.DAT is 8k larger than it is supposed to be due to 3D Realms truncating 32 shades off the shade table but not properly cleaning up that 8 extra KB in the palette file according to Ken Silverman), but I'm probably just overanalyzing that. 63a just probably doesn't read the palette properly.

63a clearly does not interpret sprite alignment as it should here, meaning that it is safe to assume that not all of the CSTAT flag field is properly parsed by this version of ZDoom. Similarly, ZDoom does not appear to recognize the "expand texture" flag in CSTAT, most noticeable in the ceiling light in the screenshot, and also noticeable is the fact that texture scaling and whatnot is not done accurately. This quirk is probably relevant to the fact that Build .maps are not scaled to size correctly in-game.
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Mon Jun 01, 2009 7:41 pm

What is your OS? I've actually noticed that with 63a on Vista it's less likely to get the right (or similar) colors
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby CrystalWolf » Mon Jun 01, 2009 7:44 pm

Windows XP SP2. On a side note, I also noticed that all sprites and walls, regardless of their Palette Index, are just assigned the same weird garbled palette seen in my previous shot; and sprites seem to be justified improperly all around. Most sprites seem stuck way too far in the ground, and some sprites aren't even recognized at all. It looks like 63a just doesn't want to read some of the ART files.
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Mon Jun 01, 2009 7:45 pm

Hmm, must be a issue with 63A and the drivers or card on my vista machine then.
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby CrystalWolf » Mon Jun 01, 2009 7:48 pm

By the way InsanityBringer, would you mind snapping a screenshot of these palette abnormalities you're experiencing, if it's not too much hassle?
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Mon Jun 01, 2009 7:53 pm

Here's a screenshot of what I get on my current machine:

Spoiler:


Compare this to a screenshot from my older XP machine:

Spoiler:


Note: I used the Lameduke stuff since that was much more readily available at the moment. If you need something from the release game tell me and I'll go through the process of getting it set up
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby CrystalWolf » Mon Jun 01, 2009 7:56 pm

Nah, unless you want to go through the trouble. :P This illustrates the point quite clearly. I'm probably missing my guess, but if I had to bet, I'd say that could be some strange bug while 63a is loading the Duke3D palette and the fact that Vista interfaces with graphics hardware differently than XP.

I figure that the deal with sprites being stuck in the ground might have something to do with the fact that Doom puts the origin of the sprite (determined by their offsets in the WAD) at the floor and the Build engine just uses the bottom of the sprite to justify, rarely ever using offsets differing from (0,0) in the ART files.
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Mon Jun 01, 2009 8:00 pm

Hmm, oddly enough, the pistol on your screenshot has the same colors as the pistol on my XP screenshot. I'm assuming that Zdoom doesn't read and apply the palette 100% correct. At some point I might attempt to make a Playpal version of the PALETTE.DAT file and see if that works better
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby The_Funktasm » Thu Jun 04, 2009 8:03 am

What the hell? You could do this? Any way to dump the loaded map to a wad?
The_Funktasm
Banned User
 
Joined: 17 Mar 2009
Location: done making ZDF free sprites

Re: Using Build-engine Maps With ZDoom

Postby InsanityBringer » Thu Jun 04, 2009 9:24 am

The dumpmap CCMD will dump the map to a wadfile
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: Using Build-engine Maps With ZDoom

Postby The_Funktasm » Thu Jun 04, 2009 12:11 pm

InsanityBringer wrote:The dumpmap CCMD will dump the map to a wadfile

Do the maps come out at all similar to their original form?

EDIT: Nevermind, I am a douche that cannot read...
The_Funktasm
Banned User
 
Joined: 17 Mar 2009
Location: done making ZDF free sprites

Re: Using Build-engine Maps With ZDoom

Postby CrystalWolf » Fri Jun 05, 2009 2:41 pm

Yeah, the maps come out relatively similar but are a good bit off scale as seen in my original post, screenshot pair #3. Heightwise, everything seems to translate correctly, but there is some factor of error when translating Build units to Doom units on the XY plane. If you intended to convert Build maps directly to ZDoom for some purpose, you could get away with using Doom Builder to scale the whole map by a certain percentage I imagine. Keep in mind that you would also have to retexture the entire map by hand, since no editor I'm aware of supports loading Build .ART files.

It just doesn't seem to have any immediate use considering that ZDoom no longer appears to support Build-engine .maps.
User avatar
CrystalWolf
dumb asshole
 
Joined: 06 May 2009
Location: New Orleans, LA

Next

Return to Editing (Archive)

Who is online

Users browsing this forum: No registered users and 1 guest