Single Status Update
I'm bored at work, so I've decided to finally let loose some of my ideas that were going to be incorporated in to Mooditor.
A few years ago, I got the grand notion to build a Doom level editor. The lack of 3D editing was annoying me. I can't remember whether I decided to start before or after Doom Builder was announced, but needless to say it was around that time. I decided to call it Mooditor, as not only did it contain the word "moo" but the first four letters also spelt Doom backwards and blended rather nicely in to the word editor. A release that loads up a map is still available. Whether it still runs is something I am unaware of :-P
If it does run, you'll notice that it dumps directly in to 3D mode (albeit minus flats drawing). That's because the editor was going to be exclusively 3D editing.
I hadn't worked out how to draw the flats as I hadn't worked out a nice way for on-the-fly sub-sector generation. Relying on pre-calculated BSP trees was completely out of the question due to the fact that moving a vertex would kill the tree. Thanks to my research in to portal engines 4 years ago, I knew that the Doom engine stored the necessary data to implement a portal culling solution as opposed to its BSP selection. A portal engine divides its world in to concave sectors. If a sector is convex, it subdivides it in to concave subsectors. Surfaces where two sectors meet are portals. Culling is achieved by using the view frustum, and adding additional culling planes to the frustum until you can't see anything else. Doom's map format already stores concave sectors and subsectors, and portals can be very easilly represented as a linedef with two sidedefs in different sectors. (SIDE RANT: With that in mind, you may understand why I'm unimpressed with alot of the advanced features like portals going around lately - they're still based in BSP land. Remove the hacks, implement a proper portal culler, and notice just how much easier everything becomes. Yes, it's slower than a BSP tree, but welcome to 2006, modern computers can handle it.)
I was aiming to have little to no keyboard shortcuts. You would move the camera around with the mouse, or a keyboard/mouse combo. Left click would select vertices/lines/sectors/things. Right click would bring up contex menus. Simply left clicking on something and dragging would move that object around. I was aiming to make the editing process faster via intuition rather than assigning hundreds of commands to hundreds of key combinations. Navigation and editing of the map was to be as far removed from the current crop of editors as possible - but due to wide scope of the ideas, it would have been entirely possible to snap a camera to look directly down and move along the X/Z axis thus emulating the current crop of editors.
It would have taken me a couple of months to get everything up and running as I envisioned it. Once it was working, I was even thinking of migrating it to a Doom engine (no doubt ZDoom) and having an in-game editor as standard (as I'd need the portal culler, it would also open up shiteloads of potential by making a dynamic world possible). But, as usual, I lost interest.
My programming interests are far removed from Doom currently, and I doubt they'll go back there. I'm not professionally interested in the current FPS formula, and as a result any research and programming I do in my own time has as little to do with FPSs as possible. Some of the ideas I've mentioned here will be making it in to an editor for a game I'm working on in my spare time, but if any editor author feels inspired by this post go ahead and try it with your own code.
- Show previous comments 6 more
Portals are easy. If you know anything about plane mathematics (in this case, how to test what side of a plane a point is on and where a line intersects a plane) then you can whip up a portal culler quite quickly. Consider the edges of your screen as planes, and add the near and far plane to the culler for good measure. The tests you'll need with Doom's line renderer would be:
WARNING: DODGY PSEUDOCODE ENSURES
The clipping function is the slowest there as you'll need a divide - the rest is done with a couple of multiplies. From memory, the Doom engine clips its lines before it renders them, but that's not the reason I put the test in there. By clipping the line, you have a better line to base your portal tests from as you're only using what you can see. If you expand the code to work with 3D surfaces, the clipping test also solves another problem you'll encounter. If the clipping test wasn't there in 3D, there's a chance you could get false positives where a line is outside the current portal culler, but passes the test by having at least one point of the line on the positive side of each plane. Working in 3D data is a good thing anyway - the 2D renderers used in source ports could convert the lines in to 3D surfaces using sector heights and use portal culling to easilly perform height visibility tests. These same portal tests can be generated from a monster's POV to determine if it can see the player or not.
DIE BSP TRAVERSAL!!!!
EDIT: ONE THING I FEEL I NEED TO POINT OUT ABOUT PORTALS
Ideally, a portal renderer would be set up so that each sector is centred (YES I'M AUSSIE) around the origin, and a transformation matrix supplied at each portal to describe how to transform the next sector to the correct world space. This kind of flexibility means that you can dynamically change a portal's linked sector. It also lets you do crazy shit, like walk through a portal, turn around, and where you just came from is no longer there. Just imagine the head-trip games you could do with features like that in your game :-D
(That's also a subtle hint as to how current "portals" can be implemented with the portal culler I described above)
Yup, it sure would be - if there's lots of line interesection with the culler, or if there's alot of portals (linedef with sidedefs on different sectors), otherwise it'd be as proportionally slow as normal. Then again, maps with lots of lines run slow as it is. I remember complaing about Caverns of Darkness when it first came out as, even on a decent (for back then) computer, the final map would chug like a bitch because of the amount of visible lines. Even GL nodes couldn't save me - in fact, I couldn't generate GL nodes as there were too many lines for it to handle.
Conversion on-the-fly of Doom maps to a native 3D format, and allow 3D objects to be described in a 2D editor, would remove the need for a gazillion lines to define detail. Slopes in ZDoom have helped alot with the detail thing, as most detail that uses alot of lines is to simulate slopes.