[WIP] Eviternity - A Boom Format Megawad

[Dragonfly]

It's actually not, though I am one of the mentioned people who had access to the textures. Thanks for the compliments on the screenshots. I'm glad that map feels heavenly, as that is certainly the theme I'm trying to pull off. :P

 

@Catpho I hope to keep the dev diaries somewhat regular and detailed. At the moment though I need to grind away and make some maps to have something to write about!

 

I'll be streaming Eviternity mapping every Monday, for anyone interested. I'll also be trying to squeeze in weekend streams where possible - Here's a link!

 

https://www.twitch.tv/dragonflyos/

[ukiro]

 

1 hour ago, Pegleg said:

 

I assume this is the project that @ukiro last mentioned in February

 

 

This is one project that is using my texture set ahead of the public release (and honestly probably the most ambitious one), but it’s not the only one. Whether any others come out in time for Doom’s 25th birthday is uncertain, so I won’t announce anything. But hopefully this and/or some others make it in time so the release of the textures is accompanied by some examples of expert use. Eviternity is Boom and there’s also vanilla and UDMF stuff in the works. 

 

I’ll start a separate thread about the textures later in the fall I think. 

[Remmirath]

0/10 not enough floor detailing

 

(seriously, though, stuff looks amazing. Lookin' forward to it, mate)

[Gez]

What's in a name? In this name specifically? "Evil Eternity"?

[Dragonfly]

@Gez While Evil Eternity is a cool secondary meaning, the word is an actual English word:

 

[Aquila Chrysaetos]

I personally think Aeternum would've made a cooler name, but Eviternity probably works a little better.

[Tristan]

Aeternum is a skillsaw WAD from 2007.

[Gez]

1 hour ago, Dragonfly said:

an actual English word

Color me surprised. But also glad; I like learning obscure words.

[Black Star]

The first, fifth and last screenshot are positively sublime. To say that I am interested in this would be understatement of the year thus far.

[Test Tickle]

These screens are amazing, can't wait to play this.

[franckFRAG]

To be honest, I don't like the name "Eviternity", I find it too long, not enough impacting, with too much syllable... And maybe even too generic.

 

I propose you a simple solution : translate "Eviternity" in Latin : "AevuM". Of course, it's just a proposal, do as you please x) :P

 

 

[Pegleg]

16 hours ago, Gez said:

Color me surprised. But also glad; I like learning obscure words.

Then you must have loved The Gantlet. Or does it not count because it's just a less common spelling of gauntlet, not an obscure word in its own right?

[Dragonfly]

Thanks for your opinion, but I'm sticking to the name.

[baja blast rd.]

Aeternityum 

[Tristan]

Aevertaernaltaernityivaeraeum

[Jayextee]

Bikeshed.wad

[Aquila Chrysaetos]

Dragonfly's Badass Boom Megawad

[Jimmy]

it's Adam and Eviternity not Adam and Steviternity

 

(sorry)

[Xenaero]

Oh. My goodness.

 

I absolutely adore episodic themed level sets. Probably partly why I dig Doom's ep1-3 so much. I will be keeping a close eye!

[Bauul]

I still liked it when it was Project Decadence.

 

Always made me imagine the map-pack was full of cake.

[Dreadopp]

This looks excellent so far. Looking forward to its release.

 

Keep up the great work, Dragonfly and co. :)

[Nems]

<3

[Dragonfly]

Now that I've finished creating the 11th map to date, it seems an appropriate time to post the second Dev Diary!

 

https://www.dfdoom.com/dev-diaries-eviternity-part-two/

 

This article covers the existing maps, with a description of the map itself, a screenshot, and brief dev-notes for some of them. :)

 

The next diary I intend to post will probably focus on the more intricate content, such as problems I've faced and the ways I've overcome the problems; the current plans for future maps, etc.

 

Cheers!

[Dragonfly]

Woah it's been nearly a month since the last Dev Diary already?! Well, colour me surprised. Regardless, here's the third instalment of the Eviternity Dev Diaries.

 

https://www.dfdoom.com/dev-diaries-eviternity-part-three/

 

We're now up to 13 completed maps, and partway through the 14th. A large portion of this diary comes from @ukiro, who talks about the issues of PrBoom+'s poor handling of TEXTURE1 vs TEXTURE2, an issue which is affecting OTEX, which in turn is affecting Eviternity.

 

We're not letting that slow us down though, don't you worry!

[Gez]

Quote

While the engine can load both TEXTURE1 and TEXTURE2, each of them will reference indexes in PNAMES. But it seems most engines, with the exception of the GZDoom family, merges all loaded PNAMES in memory. But then we have entries in both TEXTUREn lumps referencing the same PNAMES number expecting different things. The result in PrBoomPlus is that TEXTURE1 ends up getting patches from the PWAD, breaking all vanilla textures.

[...]

There is a potential solution for PrBoomPlus: By including references to all IWAD textures in TEXTURE2.

I think you're going at it the wrong way around. Merging the PNAMES yourself would be much simpler. Heck I can do that for you if you want.

 

But there will still be issues when mixing with other texture packs. ZDoom departed from the vanilla logic here to make cumulative texture loading possible, but more conservative ports didn't.

[ukiro]

You’re right I should have gone into more detail on the PNAMES route, but you’re also right in that it wouldn’t achieve what I wanted. 

 

If someone with with a good eye for the source code could verify my other theories here I’d appreciate it—specifically that all PNAMES entries get merged before textures are compiled. 

[Gez]

As far as I know, what happens is simply that ports use the last PNAMES lump loaded, without any merging. I've never looked at PrBoom+'s source code, though, so if they've changed it from how vanilla or even Boom and MBF do it, I wouldn't know.

[ukiro]

17 minutes ago, Gez said:

As far as I know, what happens is simply that ports use the last PNAMES lump loaded, without any merging.

 

Ah you seem to be right. Loading otex with doom 2 makes all vanilla textures point to otex patches, but that's because the IWAD's TEXTURE1 points to numbers in PNAMES, and if it reads the otex pnames it in turn points to otex patches.

 

So if on R_Init the engine did this, we'd be in a better place:

1. IWAD: Read TEXTURE1 (and/or TEXTURE2 if available) and PNAMES to compile "map textures", ignoring PWADs for now
2. PWAD(s): Read TEXTURE1 (and/or TEXTURE2 if available) and PNAMES to compile "map textures", appending these to the "map textures" created in step 1
3. If a NumForName error is thrown within the scope of the latter, expand search to the IWAD patches. This is to allow PWADs to define new textures using IWAD resources.

Would this work? Are there scenarios where this would break things that work today?

 

 

 

Edited August 10, 2018 by ukiro

[Gez]

That's basically what ZDoom-derived ports do. As written in the wiki article I linked:

Quote

Vanilla Doom only loads one PNAMES, one TEXTURE1 and one TEXTURE2 lumps; each being the last encountered. ZDoom allows cumulative loading, though only one TEXTURE1 and one TEXTURE2 lump will be loaded for each archive; and in each archive TEXTURE1 is loaded before TEXTURE2. Each TEXTUREx lump uses the last previously-loaded PNAMES lump as a reference (so for example, the IWAD textures always use the IWAD patches).

 

[Woolie Wool]

The medieval and heaven themes are astonishingly beautiful.