Aleph One 1.3b1

[Sharkie Lino]

I'm not getting a half second, but it's definitely noticeable. Open ~/Library/Preferences/Marathon Infinity/Marathon Infinity Preferences, and look for samples="1024". Change that to something like 256, and it will be better.

Alright. I did experiment with that few times listening as carefully as I could. I THINK that did make it a little better. There is still some delay, but again, listening as carefully as I could, I think it was not as delayed as before.

[Wrkncacnter]

Another random issue, the "Mouse Aiming" checkbox in the preferences doesn't seem to work. It always shows as checked whether it's on or off, and checking/unchecking the box does nothing.

[ravenshining]

Building the latest from git I get some weird HUD issues when switching weapons..

in M1 using the Default HUD:

in M1 using the XBLA-style HUD:

Eternal with the normal MML HUD:

Eternal with the lua HUD:

Rubicon, also with some weird texture effects:

M1R both blacks the screen and screws up the HUD:

And M1A1 blacks the screen. This doesn't happen in Infinity or Durandal with either normal or XBLA HUDs.

Also, M1R and Rubicon crash with the following error when trying to switch to a weapon that has a glowmap:

Code: Select all

alephone: OGL_Textures.cpp:1459: void TextureManager::RenderGlowing(): Assertion `GlowBuffer || (GlowImage.get() && GlowImage.get()->IsPresent())' failed.
Aborted

system: debian 8 amd64 w/NVIDIA Quadro FX 1600M

[Pfhorrest]

Coincidentally, earlier today doing a vanity search out of boredom, I just happened upon an old thread on the old m-dev sourceforge mailing list that seems like it might be related to this.

Way back until April 18 2006, there was a bug in Aleph One that required high-res replacement images destined for the HUD to be flipped horizontally and then rotated 90 degrees in order for them to show up correctly. If you didn't do that, you'd get some kind of rotated and squished and otherwise garbled images showing up in the HUD in place of what you intended. That bug had apparently deterred anyone else from doing high-res image replacement on the HUD, because nobody was sure what the heck was going on there, but when I figured out what you had to to do the source images to get it to work, Treellama promptly used that info to fix the bug, meaning you didn't need to do that flip and rotate trick, and since no high-res HUDs had been made yet at that point, nobody's ever seen that bug in the wild except we early attempting-to-make-high-res-HUD people.

Since this bug you're seeing looks like it involves some HUD graphics being rotated 90 degrees, I wonder if whatever is causing that problem for you now might be related to the same bit of code Treellama fixed way back then.

[TrajansRow]

Can you try this 5-line patch? I've not seen your particular issue, but I suspect it's related.
https://github.com/Aleph-One-Marathon/alephone/pull/137

Building the latest from git I get some weird HUD issues when switching weapons..
system: debian 8 amd64 w/NVIDIA Quadro FX 1600M

[ravenshining]

Yes, that fixes the HUD issue!

But not the glowmapped weapon issue. M1R crashes with HD weapons turned on, and Rubicon X will always crash if you ever pick up a fusion rifle. Turning off bloom does not help. Perhaps the recent adding bloom to weapons in hand broke glow for weapons in hand?

[treellama]

I didn't think glowmaps were supported for weapons in hand?

[ravenshining]

Well, Rubicon used them way back whenever that came out, and I have found them to have a most pleasing effect for the little lights some weapons have on them, and of course the shock staff.

I suppose most people just never thought of going that far in detailing weapons? And it's only recently that we've had such gorgeous artwork as that produced by Tacticus to appreciate. His sprites really shine when properly illuminated ;-)

Checking out to the commit immediately before the one linked above prevents weapons with glowmaps from causing crashes:

Mind you I made this glowmap long before I realised Aleph One doesn't honour the glow_premultiply flag and kinda gave up on part of the effect, so it doesn't look as nice as it could.

[treellama]

Mind you I made this glowmap long before I realised Aleph One doesn't honour the glow_premultiply flag

It does. I also checked, it looks like it won't do the right thing for DXT2 or DXT4, but if you use DXT3 or DXT5 and set the flag I think it will treat it as pre-multiplied.

Now, why you would care about pre-multiplied alpha for weapons-in-hand, which aren't mipmapped, I don't know. I guess for the texture resolution settings? That would be pretty obscure.

[ravenshining]

Additive blending!

[HelviusRufus]

Maybe for the same reason I jump over the wall and wander around on the Piazza del Sakhmet Rising: because it's there and I can.

[treellama]

Additive blending!

Nope, just premultiplied alpha.

[ravenshining]

Additive blending!

Nope, just premultiplied alpha.

Isn't additive blending the whole point of having premultiplied alpha?

It does. I also checked, it looks like it won't do the right thing for DXT2 or DXT4, but if you use DXT3 or DXT5 and set the flag I think it will treat it as pre-multiplied.

That's not what I see happen, and what I've been going on about all this time. If I take an image that has, R 1, G 0, B 0, A 0, and place it over a black area, I would expect to see black with straight alpha and red with premultiplied alpha. However, if tell Aleph One that it's premultiplied, Aleph One ignores that and still multiplies that A 0 by R 1 and you get black.

[treellama]

The premultiplied alpha is used during mipmap generation, when scaling an image down it keeps the transparent area color from blending into the image. Aorta can do this without using premultiplied alpha using a special edge extrapolation algorithm.

You're thinking of the blend mode, which according to the MML documentation "[is] deprecated, may not work properly, and should no longer be used"

[ravenshining]

You mean these? That have no explanation of how or where they ever were used? I don't see anything in there that looks like premultiplied alpha or additive blending.

glow_blend
image_scale
normal_blend
offset_x
offset_y
shape_height
shape_width
void_visible
x_offset
y_offset

[treellama]

normal_blend and glow_blend used to specify the blend mode, either cross-fade or additive. The explanation was removed when their brokenness/deprecation was documented

[ravenshining]

Okay. So not only is premultiplied alpha broken, but there's also a blend mode that would have allowed additive blending on a straight alpha texture, were it not also broken?

Unless we ever fix it, there should be a caution in the MML documentation that glow_premultiply works for RGB images (assuming it does) and not for RGBA images.

[treellama]

You’re still confusing the blend mode with the image contents. Just because it doesn’t do what you want, doesn’t mean it’s broken. A little humility would go a long way in improving your interactions with busy developers.

That said, I wouldn’t be opposed to removing it altogether. Thanks to Aorta, I don’t think anybody actually uses it.

[ravenshining]

I'm not asking you to change any code. I understand that you are feeling, as you yourself have put it, burnt out; that when you do add or fix something, it's a rare and usually wonderful thing; and that you have a need to be respected for your work. However, I'm feeling worried, because for me to trust you I need to know that you aren't going to go in and start removing features you don't personally like. That worry, that lack of trust makes it very difficult for me to not react in a way that is, admittedly, disrespectful, and I apologise for doing so.

In any case, that's not what I came onto this topic to discuss. I was reporting a major scenario-breaking bug that has now been fixed - thank you for addressing my concern over on github. My initial comment on premultiplied alpha here was just made in passing to excuse my own badly-implemented glowmap.

[$lave]

I don't think you have to worry; I've never known a developer who removed features because they didn't like them. Sometimes, however, features are deprecated because of necessary code or library changes/updates that make them unfeasible to maintain. The best thing to do is probably to just trust that developers know what they're doing and won't go out of their way to sabotage things. Unfortunately no code lives in a static isolated box, and developers can't always maintain full support of absolutely everything.

[treellama]

I think the blend modes were removed because they don't work with fog. That was nine years ago, so I don't remember in detail. I do know it wasn't I who removed them, and I don't particularly dislike them.

[Lion O Cyborg]

1.3b2 is out now, with (attempted) fixes for:

• No sound under Windows
• Broken Lua APIs including adjacent_polygons()
• Failure to launch when no theme is loaded
• Custom loading screen display
• Backwards scroll wheel behavior in lists
• Clip plane issues under Linux Mesa drivers

Hi Hopper. I don't know if you've already seen this thread or not, but I need to inform you that beta 2 does not work, either on PC or Mac. I tested the latter just a minute ago. My thread on the issue I've linked to explains it in detail:

http://pfhorums.com/viewtopic.php?f=22&t=53669

[ravenshining]

I was testing some things out in M1R today, and ticked the "bloom effects" - I had it turned off for the past month or two because it's not compatible with the 3D model plugin - and I just wanted to say, great job! Bloom effects for weapons in hand look awesome!

Rubicon:

M1R:

Although, while taking these screenshots I noticed it can get a little off when things move around. You can see it in this screenshot but it's not terribly noticeable in game because the fusion pistol's just shaking around too fast for you to see.

Not that I'm complaining, actually, I think it adds to the sense of the thing shaking, almost like motion blur, or the afterimage you get when shining bright lights in your face, except inverted. Love it!