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.
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?
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?
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?
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.
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 261 times
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.