Eternal X 1.2

Discuss and unveil current Marathon projects.

Re: Eternal X 1.2

Post Aug 17th '19, 06:41

Pfhorrest wrote:but I think if we were to implement it, I would want to create the variant switches myself for complete consistency between all the textures


Oh, of course! These are nothing more than concept sketches, suggestions of what may be. I could make those full resolution and add bump and glow if I hated my carpal tunnels, but that wouldn't be original artwork. And I like my carpal tunnels, poor little things.

The Man wrote:Anyhow, I presume that redefining what textures are used in each set for a given switch behaviour would automatically retexture any switch that used it, though I haven’t verified this.


I'm fairly certain it does. I've dealt with this when using JUICE or Chisel to convert texture sets, and in M1R - that's how I was able to cram in nine 0.5 x 1 WU and two 0.25 x 1 unique terminal textures PLUS pattern buffers without resorting to per-level MML!
User avatar

ravenshining
Hawai'i

Post Sep 3rd '19, 06:41

Re the Narcstar and Blackogen Eternal stream Sunday last (I've Got A Bad Feeling About This):

The switch at poly 248 and the switch at poly 68 can be turned on then turned off but will not turn on again. If turned off after being turned on, the exit terminal will give the failure message.

The switch at poly 266 can be turned on then off but then on again any number of times but, as it controls the big lift, it shouldn’t be off but IF IT IS and the lift is down you can get to the exit terminal which will have the fail message but you can't get back to the switch to turn it on again because the lift isn't working.

The switch at poly 488 can be turned on and off and on again and controls the lift in the early big room that must be working to advance in the level. This switch does not affect the failure/success message.
I just play 'em; I don't know how they work.
User avatar

HelviusRufus

Post Sep 3rd '19, 17:23

Thanks for investigating that! I haven't even had a chance to finish watching the stream yet. I'll add your comments here to the buglist.
User avatar

Pfhorrest
California

Post Sep 9th '19, 05:30

For those who hadn’t been paying attention, Rampancy.net finished their Let’s Play of Eternal on Friday. Pfhorrest, raven, and I were all there, both in voice chat and as participants in the network game, to commemorate the occasion. The whole playlist is here.

I’ve noticed a couple of typos in various terminals, which I’ll find later. More importantly, though, the opening terminal of “Septococcal Pfhoryngitis” needs to be updated – the player no longer starts in a sewer, and the uplink chip could be in one of three locations. I suspect both of these should be noted, unless there’s some specific reason for the discrepancy. (On the chip placement count, perhaps Hathor will say that the chip got intercepted and she doesn’t know where it is or something along those lines.) This is honestly half the reason I haven’t written a lot of the Chronicles terminals yet – story details details like this change in development, and I’m certain that I would forget to update some important plot elements.

This has inspired me to do some more work on Marathon stuff, though, so maybe I’ll finish all the stuff I wanted to get done for 1.2.1 within the next couple of months.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Post Sep 9th '19, 17:20

Thanks Aaron, could you please make sure to note that and any other typos or whatever you might find on the Github Issues page? That's where I've been noting everything found during the Let's Play.
User avatar

Pfhorrest
California

Post Sep 9th '19, 17:52

The Man wrote:For those who hadn’t been paying attention, Rampancy.net finished their Let’s Play of Eternal on Friday. Pfhorrest, raven, and I were all there, both in voice chat and as participants in the network game, to commemorate the occasion. The whole playlist is here.

I’ve noticed a couple of typos in various terminals, which I’ll find later. More importantly, though, the opening terminal of “Septococcal Pfhoryngitis” needs to be updated – the player no longer starts in a sewer, and the uplink chip could be in one of three locations. I suspect both of these should be noted, unless there’s some specific reason for the discrepancy. (On the chip placement count, perhaps Hathor will say that the chip got intercepted and she doesn’t know where it is or something along those lines.) This is honestly half the reason I haven’t written a lot of the Chronicles terminals yet – story details details like this change in development, and I’m certain that I would forget to update some important plot elements.

This has inspired me to do some more work on Marathon stuff, though, so maybe I’ll finish all the stuff I wanted to get done for 1.2.1 within the next couple of months.


There's also a Hathor terminal in Chapter 4's failure plank dream where she gloats over becoming stronger than the W'rkncacnter and actually killing it: it's the one near the umbilical to the exit that doesn't work in the other dreams, but it's broken in 1.2. I can't remember if it's in 1.03 or not, but it is in 1.1.

https://steamcommunity.com/sharedfiles/ ... 1704174540
https://steamcommunity.com/sharedfiles/ ... 1704175480
User avatar

Lion O Cyborg
UK (which is IN EUROPE!)

Post Nov 30th '19, 19:59

Since I'd like Eternal 1.2.1 to come out by the end of the year, I’ve been slowly going down the list of features I'd like to implement and getting some of them done. I just got done with a big one.

Here are the remastered sounds for Marathon Eternal. This is overall very similar to my remastered Marathon Infinity sounds, but there are a couple of major differences. Most notably, all the sounds are in the 8-bit sound slot rather than the 16-bit sound slot. All of the sounds are actually 16-bit, but with one caveat, the game mostly doesn’t care. Since it doesn’t see a sound in the 16-bit slot, it just reads from the 8-bit slot if you have 16-bit sounds selected. If for some reason you have 8-bit sounds selected, I think it converts down to 8-bit on the fly, but I’m not actually sure. However, at least you will get sound rather than silence.

The big caveat is that you will need to quit and restart Aleph One after selecting this sounds file, or all the sounds will play at the wrong speed. I don’t know why this occurs, but I’m assuming it’s a memory cache issue.

The other major issue of note is that, because these are all about 6 dB quieter than you’re used to, they’ll have roughly half the perceived volume. This means you’ll need to adjust your music volume to suit your taste – but as a plus, it at least brings the proportional levels between the music and game sound effects back to roughly their original state!

Most of these are the same sounds as the Infinity remastered sounds, except, of course, those that are exclusive to Eternal (or absent from Infinity, but shared with Marathon 1 and a few other games). I’ve remade a few sounds a bit since my release of the Infinity remastered sounds (which, actually, I need to re-release for a few reasons – hopefully this will also come by the end of the year), and may make a few further revisions. Some people have commented that a few of the sounds (mostly the Fighter, Compiler, and Drone sounds) sound higher-pitched, just due to the presence of high-frequency information that wasn’t present in the originals. I may run a mild low-pass filter on them if this really bothers people, but I’ve quickly grown used to the new versions.

Anyway, let me know if there are any issues. I’ve tested these briefly in Aleph One 1.3b2 on Windows 10, but I haven’t played every sound in the game yet, nor have I tested other Aleph One versions or operating systems, so it’s possible there’s some issue I haven’t uncovered.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Post Feb 4th '20, 08:01

I'm back from other projects and starting to work down the buglist I have compiled on GitHub in preparation to release a version 1.2.1 as soon as possible. Everyone please make sure any bugs you know of are listed on that page, and add them if they're not because that's what I'm working off of as I go about fixing things.

The first bug I'm tackling tonight is the stripey media textures that appear when people turn down the texture quality to avoid out-of-memory errors on Windows (which I've confirmed is repreoducable when turning down the texture quality even on Mac where that's not necessary). I plan to reduce texture size in general so that people don't have to do that in the first place, but I also want to make sure that if people do turn down the texture size for some reason, this bug doesn't happen.

However I've run into a complication and it's not clear to me that there is actually a solution to it. If anybody (Treellama?) can think of one, please let me know, I would greatly appreciate it. Here's the sitch:

After extensive sleuthing, it appears that some media textures (like the human sewage), when saved with no MIPmaps and no DXTC as in the 1.2 release, look fine with texture quality set to Unlimited, but stripey in different ways at lower texture quality settings.

Correct appearance at Unlimited (no MIPmaps):
noMIP-noDXTC-Unlimited.jpg


Appearance at Highest (no MIPmaps, no DXTC):
noMIP-noDXTC-Highest.jpg


Appearance at Higher or High (no MIPmaps, no DXTC):
noMIP-noDXTC-High.jpg


Saving them with no MIPmaps and with DXTC still works fine in Unlimited, but fails to load the texture at all (defaulting to software) at lower texture settings:
noMIP-DXTC-Highest.jpg


Saving them with MIPmaps, regardless of DXTC, and running with any texture quality settings, isn't stripey, but is ugly in an even worse way, which is presumably why I saved them without MIPmaps (since that makes them look fine at the default Unlimited settings):
MIP-noDXTC-Highest.jpg


Any idea what the hell is going on here and what to do about it?

(And why this appears to affect only some media textures but not all of them?)
User avatar

Pfhorrest
California

Post Feb 4th '20, 13:55

So, first, without mipmaps, the texture quality settings aren't super helpful. Since they just load the next smaller image in the chain, and you're not including any smaller images in the chain. Still, Aleph One should load the single available texture if mipmaps aren't available and ignore the texture quality setting, which it doesn't seem to be doing in your screenshots. That may be a bug.

Anyway, I recommend always using mipmaps for high res textures.

As for the ugliness, mipmaps should only affect the next smaller images in the chain, so there should be no difference when set to unlimited. So your images are different, or there's something wrong with your MML. Can you create a reference map with a single replacement texture MML that reproduces the problem?
User avatar

treellama
Pittsburgh

Post Feb 4th '20, 13:59

Wait, are the issues only with media textures? Make sure you're not using any of the opac_ options for DXTC textures--Aleph One will have to decompress them to apply those conversions and you'll lose the benefits of DXTC.
User avatar

treellama
Pittsburgh

Post Feb 4th '20, 21:36

It is only for media texture, and yes the MML is using the opac_type="1" option, though it's doing that for all of them, even the ones that work fine, and most of the problems described above occur whether or not DXTC is used (everything looks fine at Unlimited regardless of DXTC so long as no MIPmaps are used, and everything looks ugly at any setting regardless of DXTC whenever MIPmaps are used; it's only the no-MIPmaps cases at lower settings where DXTC makes a difference in what kind of problem occurs, either stripes without it or failure to load at all with it).

It's definitely not different images, because I re-created four DDS options (with and without MIPmaps * with and without DXTC) from the same PNG files last night to test where the problem is coming from. The ugly appearance that shows up in all cases when MIPmaps are used looks like a blending problem (it sort of looks like the textures are set to Photoshop's "burn" blend mode), which makes me think it is probably a transparency problem.

I'll try removing the opac_type setting tonight, and if that doesn't help I'll make that test map for you.
User avatar

Pfhorrest
California

Post Feb 4th '20, 22:15

opac_type="1" is the one that's OK :)
User avatar

treellama
Pittsburgh

Post Feb 4th '20, 23:32

That's good to hear. I just tried it with that opac_type="1" removed (with DXTC and MIPmaps both), and get the same problem.

I'll throw together that test map as soon as I get a chance.
User avatar

Pfhorrest
California

Post Feb 5th '20, 04:01

Here's a test map, and also the texture and mask if you want to try saving them to DDS yourself:

http://www.geekofalltrades.org/_misc/test.zip
User avatar

Pfhorrest
California

Post Feb 5th '20, 13:54

Hmm, this is intended to use some existing MML...I think you missed the point! Create a reference map with its own MML, etc., and see if it still happens. Because I really suspect it's an MML conflict somewhere in your scenario.

For example, just try replacing a single texture in Infinity with the problem texture. Like, if you replace the water texture, install your tiny reference MML in Infinity, and check out Duality.
User avatar

treellama
Pittsburgh

Post Feb 5th '20, 19:08

Lia helped me sort out the issue last night. It seems to be a bug in Aorta, because she re-exported a DDS file of the problem texture using GIMP + a DDS plugin (that doesn't seem to be available for Mac, so I can't use that method myself) and it works fine.
User avatar

Pfhorrest
California

Post Feb 5th '20, 20:34

For a transparent liquid you should be using DXT5 compression, mipmaps, no premultiplied alpha, no halo removal or fill. I can try compressing the problematic texture if it's the one in that zip file.

Aorta is pretty old, won't even run in Catalina. I'm surprised there's still nothing that can export DDS on the Mac!
User avatar

treellama
Pittsburgh

Post Feb 5th '20, 20:39

The one in the zip file is one of the problematic textures, but Lia did already get me a working version of it -- though I'm not sure if she got the alpha and halo settings right, but it looks fine for me in both Unlimited and High.

If you're willing to compress that for me with all the exact right settings just to be safe, I'd appreciate it. I'm also waiting on Lia to compress the other transparent textures in the scenario (10 in total), but she said it might take her some time as she's busy, so if you'd be willing to do those too I'd really appreciate it.

All of the PNGs of the other textures and their masks are in this Github thread:

https://github.com/Pfhorrest/Eternal/issues/87
User avatar

Pfhorrest
California

Post Feb 6th '20, 08:18

I also experimented around with some options for saving to DDS on Mac that I could find, and none of them produced files that worked (resulted in not even loading at lower texture quality, falling back to software, like in this screenshot), or even gave me file options like Aorta does. So unless someone knows of a better solution, I guess I'm going to be dependent on some Windows user to generate the DDS files for transparent textures, or else just fall back to PNGs.

EDIT: tested falling back to PNGs and reducing texture quality, and it yields the same stripey problem that the non-MIPmapped DDS textures did (like in this screenshot). So... I guess falling back to PNG is not an option if I want to avoid this bug, and I absolutely have to have some Windows user convert these ten files for me. Hurray.
User avatar

Pfhorrest
California

Post Feb 6th '20, 10:12

DXT5 with mipmaps is what I did. I set wrap mode to repeat and didn't specify any fancy filters, mess with gamma or alpha test coverage, or tick the "use perceptual error metric" box. The GIMP DDS plugin doesn't allow premultiplied alpha. I'll probably use DXT3 for the grating, and DXT5 for all the liquids and glass.

And I'm not a Windows user thank you very much :-) All my work on Eternal was brought to you by Debian Linux.
User avatar

ravenshining
Hawai'i

Post Feb 6th '20, 21:09

Thanks Lia, forgot you were on Linux!
User avatar

Pfhorrest
California

Post Feb 12th '20, 06:57

Lia took care of the resaving to DDS, and now I have the first beta walls plugin for 1.2.1 available to download and test.

http://eternal.bungie.org/files/_releas ... v121b1.zip

All I think this fixes so far is the stripey appearance of some media textures at lower texture quality settings, but if people who needed to turn down the texture quality to get Eternal to run wouldn't mind checking both if that is fixed for them, and also if they still need to turn down the texture quality (I don't see why this would fix that, but may as well make sure before I go reducing things to fix that) I'd appreciate it.

I also fixed the HUD network bug the other day thanks to some troubleshooting from Wrk, and that's up there now too:

http://eternal.bungie.org/files/_releas ... v121b1.zip

And Aaron's remastered sounds are in that same folder for testing too:

http://eternal.bungie.org/files/_releas ... 1.sndA.zip
User avatar

Pfhorrest
California

Post Feb 17th '20, 21:22

It occurs to me that I should make a note of another potential bug in Windows Aleph One I’ve found: Version 1.3ß2 seems to load Eternal with the highest texture settings fairly consistently without any problem, but 1.3ß3 frequently crashes. This seems to be true for several users both on the Discord and in the subreddit (see exchange here for an example), so I don’t think it’s just something weird with my setup.

Now that I think about it, there’s also a separate, unofficial “LAA” build of 1.3ß3 that I remember also loading levels fairly consistently. However, I’ve been defaulting to 1.3ß2, because neither version of 1.3ß3 will actually render films on my computer – which is also a bug, and if I had the faintest idea of how to assist with debugging it. I don’t know why I didn’t think to report that earlier, either. If memory serves, it just renders a few frames and then stops. I can’t remember if it actually crashes or if it just returns to the main menu; I’ll try again later today (assuming I remember) and report back.

Regardless, I don’t know what changes in 1.3ß3 would’ve caused it to start crashing again when it tries to load Eternal (or to stop rendering films), but since at least Treellama is reading this thread, I figured it would be good to report here. I haven’t tested Eternal consistently enough on Windows to be able to say confidently that 1.3ß2 always loads levels, or that the standard release of 1.3ß3 never does, but something in the standard build of 1.3ß3 definitely seems to have resulted in a downgrade in memory management on Windows.

Anyhow, maybe the Aleph One devs are already aware of these issues, but if not, hope this helps a bit. If there’s anything specific I can help test later, I’ll see about getting to it when I have some spare time. If it would be helpful to make bug reports for both of these on Github, remind me and I’ll do that, too. (I also need to try loading Eternal with those new textures in 1.2.1 and 1.3ß3 – I don’t expect it to change anything, but you never know.)
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Previous

Return to Projects



Who is online

Users browsing this forum: No registered users