Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

On Week 22/2012

edited 2012 Jun 4 in Developers
skyjake:

Last week I did not have that much time for Doomsday. However, together with DaniJ we started drafting a more detailed plan for the next-generation map renderer and some other core features on the roadmap. We are still in a very early phase, though: we first have to agree on what the renderer should be like and how it should work before we can start writing any new code. In any case, next-gen map rendering is not scheduled to start until after 1.9.9, i.e., sometime in the fall.

Thus far we've been relying on iDisk to host the autobuilder-produced files (i.e., all URIs on code.iki.fi). However, Apple will be shutting down iDisk this month, so we'll need to migrate the repository elsewhere. You will still be able to access everything (including the apt repo) via code.iki.fi/builds/ as before, but it will reside on a much slower server. Instead, the main mirror for the Build Repository files and feed will be on Dropbox from now on. The apt configs included in the Ubuntu .deb packages will use the Dropbox address starting with today's build 521.

If you've just been using SourceForge or the dengine.net Build Repository pages, no actions are required from you and nothing should visibly change.

My plan for this week is to continue work on the auto-updater, although I may still be somewhat busy with other matters.

DaniJ:

Although work on the next-generation map renderer is not scheduled to start until after 1.9.9, the plan is to address support for some of the most common id tech 1 map authoring tricks for this release.

The ground work for this began with the BSP Builder refactoring for 1.9.8, which dealt with the "BSP windows" which mappers use to construct one-way windows that allow the player to see through the back side of otherwise one-sided lines. The next family of mapping tricks I plan to address are the "middle texture door" constructs, which require some changes to the way we generate wall geometry.

Last week I spent investigating how these map constructs affect the wall geometry construction and consequently began a new replacing-walldivs work branch. The goal of this branch is to replace the WallDivs structure we use to assist in constructing wall geometry, with a new structure designed to support these constructs (and considering the needs of the next-gen map renderer).

A key piece of information the next-gen map renderer will require is timely notification when wall edge plane interfaces change position/order. When this happens the number of vertices needed to visualize a subsection of map geometry might change and consequently more/less may need to be reserved in order to visualize it.

This week I intend to continue the replacing-walldivs work branch, hopefully completing it for merging back to the master by next Monday at the latest.
Sign In or Register to comment.