Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Dragonfly

[WIP] Eviternity - A Boom Format Megawad

Recommended Posts

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/

Share this post


Link to post

 

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. 

Share this post


Link to post

0/10 not enough floor detailing

 

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

Share this post


Link to post

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

Share this post


Link to post
1 hour ago, Dragonfly said:

an actual English word

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

Share this post


Link to post

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.

Share this post


Link to post

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

 

 

Share this post


Link to post
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?

Share this post


Link to post

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!

Share this post


Link to post

I still liked it when it was Project Decadence.

 

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

Share this post


Link to post

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

 

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

Share this post


Link to post

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!

Share this post


Link to post

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!

Share this post


Link to post
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.

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post
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?

 

 

 

Share this post


Link to post

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).

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×