>>2373949
>I looked into those "texture errors" and can't seem to figure out what's actually going on.
>Crispy doom runs it relatively normally, but renders a lot of flats with some pretty bad tutti frutti looking errors. It also has unknown linedef types, so I'm assuming it has some boom-only shit to it.
freedoom maps require boom compatibility, yes.
>In zdoom/gzdoom, the same tutti-frutti flats fail to render at all. I'm not sure they're "missing", per se, but rather, I'm pretty sure it's just another case of the libre software movement being utterly incompetant again. They render (albeit, broken) in one engine, but not at all in another? that smells like a poorly made wad rather than outright missing textures.
both freedoom wads come with the same set of textures, unlike doom where there is some overlap, but, for example, many of the space base textures from Doom1 are missing in Doom2. freedoom made them all available with no messing around.
you seem both highly misinformed and intent on blaming others for errors that you created yourself by separating the maps from the textures.
>Prboom and Prboom+ fail to load the maps at all, which makes sense, given that there are some obviously zdoom-only features in certain maps (specifically, e1m2 has some weird 3d floor + transparancy thing going on. not cool)
this is false, there is no zdoom specific mapping features in freedoom maps. more likely you are seeing visual glitches from missing textures as i explained already. e.g. you're trying to run freedoom e1m2 which uses textures that aren't present in doom.wad.
>right, the purpose is to have an iwad to run pwads that serve as game replacements (megawads, basically). Actually playing the maps without the freetard content doesn't make sense.
no, the purpose as i said already is to make a completely free FPS game based on the GPL doom source code. being able to run other megawads with freedoom is a secondary goal but does not drive the project.