andrewj

Eureka's 3D renderer has several limitations: it does not support some slope types, and does not support sloped 3D floors, and does not do lighting properly underneath a 3D floor. Oh and you cannot select the planes or sides of a 3D floor like you can normal walls and planes. These things would require major work to be supported, probably even chucking the current renderer and starting from scratch, perhaps using more modern GL standards would be good too. What exists is the best I could with the miniscule amount of energy and motivation I had at the time.

that's a question for @Coraline....

How difficult was it to convert the C code to C#? I don't know anything about C# but given the name I assume you get at least a bit of compatibility with C (like curly brace syntax), but I imagine the semantic differences would be signficant.

It's funny that Doom 2016 did not have a random snap-map maker, it was very doable.

Original theme means the themes of each episode will follow the original game, e.g. in Doom 2 you will get tech bases in E1, urban (city) theme in E2, and hell theme in E3.

The use of more words in Lua never bothered me, if code is properly indented then you can see the structure regardless if it is words or curly brackets. Lua's main limitation, especially for large projects, is that it is a dynamically typed language and does not have C-like structs where you get a compiler error if you mis-type a field name. For smaller things and one-off scripts, it is still pretty good (and better than shell scripting by a long way).

Search the internet for "ACS decompiler" -- I found something straight away.

Yeah the KeenDie action will try to open all sectors tagged as 666 like a door. A funny thing about doors is that they won't open if there is a neighbor sector which is also closed (at same heights). I'm guessing this is used in that wad, when you enter a new arena it uses a non-door action to open a sector next to the arena exit door which then allows the door to open on the next usage of KeenDie.

I think Lua is also good for beginners, there is a framework called Löve https://love2d.org/ which uses Lua makes it fairly easy to open a window and draw things, play sounds (etc), and it has a big community around it too.

That's how I view C++ these days, as a language that tries to mix both low-level unsafe do-whatcha-like semantics of C with a high-level mostly-safe language. A franensteinian monster indeed. Bjarne Stroustrop once said that within C++ is a clean language struggling to get out, it's a shame he never developed THAT language as a separate thing, but there's way too much momentum behind C++ now, and as Graf said the "easy" interfacing with C libraries is a massive win (ignoring the fact that many of them have #ifdef cplusplus in their headers).

Yeah that's a big pain point for me when using Go (like right now) -- comment out some code and suddenly you're getting a compiler error about an unused variable or a unused package import. Or when creating a rough outline of a few functions and just want to check for typos.

Well UDMF is more similar to Hexen format that Doom format, so try using the Doom-in-Hexen format and see if you still get that warning message when switching to UDMF.

Large sectors, even ones with 3D floors, are fine. The nodes builder takes care of subdividing the map into smaller pieces on the 2D view of the map (i.e. the XY plane). Doing this yourself can actually make this slightly less efficient than without it, though probably not enough to really notice. 3D floors cannot be optimized in the vertical direction (the Z axis) in a Doom engine -- that's because node builder does not divide geometry vertically (unlike Quake where it IS done vertically). This can make 3D floors less efficient to render than in the later engines like Quake. But as a mapper there is nothing you can really do about it, so I say don't worry about it. If a sector has separate non-contiguous pieces (e.g. on each side of a map), the nodes builder creates separate subsectors for them -- it is no problem for the engine and making them be individual sectors yourself does not change anything for the renderer.

You laughed out loud silently? Or has "lol" become a generic term for laughing now? (sorry if this is off-topic)

I'd like to see the Patrick Troughton (not sure of spelling) episodes of Doctor Who. I must have seen some of them as a kid when Doctor Who was shown here in Australia, as I have some extremely vague memories of an episode or two, would be great if they got found somewhere.

Congrats on making a working game. Most people have no idea how much work it takes to create even a "simple" game like this from scratch.

I've got a feeling that Xephyr is the problem -- it may support an 8-bit visual but that doesn't necessarily mean it emulates a paletted display. I suggest trying it on a real videocard -- i.e. make your normal X run in 8-bit mode.

Some info (possibly repeating what Gez said) : 1. SCRIPTS is not really a "standard" map lump, it does not exist in the IWADs for example. But some tools let you store some ACS scripts there and can compile it, so editors generally support it being there like a map lump. 2. the BEHAVIOR lump is either an empty stub, or it is compiled from an ACS script. That script is not necessarily the SCRIPTS lump in a map, it could be just some files on your harddrive, and then the output of compiling the scripts is inserted into the map. 3. the BEHAVIOR lump is the main (only) way that source ports and editors know whether a map is Hexen format or original Doom format (ignoring UDMF for now). If your map does not have it yet, then it must be in Doom format and you need to convert it to Hexen format if you want ACS scripting to work. Adding it yourself is going to lead to a broken map! 4. Eureka does not have any ACS compiler built in (the sources are not GPL compatible, so I couldn't do that), and does not run an external ACS compiler.

Woah that is some cruddy old code, I had to include "errno.h" in i_sound.c to prevent the weirdest link error I've error seen, and comment out some lines in m_misc.c which the compiler did not like, plus the 64-bit version seems broken (it crashes when reading theTEXTURE1 lump). Compiling as 32-bit seems to work, will do some more testing soon....

That xdpyinfo output looks fine -- definitely an 8-bit screen. Do the colors change when you pick up items? If not, it suggests that the code for setting the palette (which X windows calls a "colormap") is failing somehow. Where did you download the source from? I'd like to try it myself.

What is the output of the "xdpyinfo" command?

Yeah I'd say about half of the map is the original MAP01, the vertices for that half are still at the same coordinates too. Very lazy mapping in my book.

Out of DOOM 2, the one I find least fun is MAP08 "Tricks and Traps". Too many gimmicks, nearly every room is a poor space for fighting in, and the path to the exit is a real bastard when keyboarding (no mouse).

That "God" character from the bible.

It's not odd, developers usually compile a program for testing much more often than they compile a release version for other people to run.