[Helixhorned]

 Helixhorned, on 02 June 2014 - 08:12 AM, said:

 Diaz, on 01 June 2014 - 11:04 PM, said:

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

(...)

Is this the new expected behavior or a bug?

It's kind of a bug. It has nothing to do with the introduction of sector[].fogpal, but is a consequence r4335: the predicate that tells whether a sprite should take over the floor pal of its sector was changed with a then-unforeseen side effect. It only concerns nonzero pals that are not the default fog pals (26 .. 29 for the vanilla LOOKUP.DAT). More on that later.

I still owe you a detailed explanation, but in the meantime, can someone check whether the problem goes away with r4818, and if everything looks all right in WGR2 in particular?

[Helixhorned]

 Fox, on 22 July 2014 - 04:08 PM, said:

2 - Can someone upload a Duke 3D palette with additive translucency replacing the default additive (33% and 66%)?

PS: Yeah yeah I know there is a built-in feature in Mapster32, but I probably will perform a sucefull ocular surgery before figuring out how to use it.

Aw, c'mon, it's not that hard. You have to figure out two parts: first, how to load shadexfog.lua into Mapster32. Given the directory structure of the r4814 Lunatic build, it can be done like this from the console, or in m32_autoexec.cfg:

lua "require'lunatic.test.shadexfog'"

Next, open up the "Lua functions" menu with [;]+[F]. See entries "Create addtv. trans. tab" and "Save pal+sh+trans DAT f.", whose usage should be straightforward.

Spoiler

In the second function, when it asks you for the "Blendnum of base transluc. table", give it the number you created the additive one in the first step.

[Fox]

How do I replace the default translucency tables?

How do I set a specific value (i.e. first transparency level is 50% alpha)?

How do I save it to a file? I can see some options for saving it to a .DAT or lookup file, but it asks questions like "Triangle ABC has AC = BC, and ∠ACB = 96°. D is a point in triangle ABC such that ∠DAB = 18° and ∠DAB = 30°. What is the measure (in degrees) of ∠ACD?" which I don't know the answers.

[Helixhorned]

 Fox, on 13 December 2014 - 04:20 PM, said:

How do I replace the default translucency tables?

By replacing the default PALETTE.DAT with the one generated by the "Save pal+sh+trans DAT f." menu entry. The help text states that it's a PALETTE.DAT-formatted file that's written. Yes, it contains these three things.

Quote

How do I save it to a file?

The file name is the very first thing that menu function asks you for.

Quote

How do I set a specific value (i.e. first transparency level is 50% alpha)?

First, let's clear up some terminology.

 Fox, on 22 July 2014 - 04:08 PM, said:

2 - Can someone upload a Duke 3D palette with additive translucency replacing the default additive (33% and 66%)?

The default one is alpha blending, "mixing" the color components of the sources like alpha*SourceColorA + (1 - alpha)*SourceColorB. What you're asking for is additive blending, like factor*SourceColorA + SourceColorB. Here, you shouldn't be calling the factor "alpha" any more. From the help text we learn that a range of numtables blending tables are created, which is a number you are queried for:

Quote

Creates numtables blending tables of smooth additive translucency,
starting with the blending number startbl, with factors for the background color

1/numtables, 2/numtables ... numtables/numtables.

numtables must be a power of two in [1 .. 128].

fullbriOK: should fullbright color indices (>= 240) be permitted as
the blending result of two color indices?

So, if you ask for 8 tables, you get those with factor 1/16, 2/16, ... 8/16. The remaining half is obtained using the reverse translucency bit on the object of question.
Edit: To answer the original specific question, if you create only one additive blending table, it trivially has factor 1/2.

EDIT2: Just to be clear, it's a two-step process. First, you create some blending tables indexed by "blend numbers", installing them with the engine. Next, you write out a PALETTE.DAT containing the desired translucency table -- which may be the original one or a custom, just created one -- and optionally, more blending tables. The latter is an EDuke32 extension for the PALETTE.DAT format.

EDIT3: The old help text for shadexfog.create_additive_trans() had a copy-paste issue, fixed.

[Fox]

 Helixhorned, on 14 December 2014 - 03:25 AM, said:

First, let's clear up some terminology.

I know that, but now I want the two translucency levels to be different, the first one is 50% alpha and the second one 100% additive.

[Helixhorned]

 Fox, on 14 December 2014 - 07:55 AM, said:

I know that, but now I want the two translucency levels to be different, the first one is 50% alpha and the second one 100% additive.

So you want two tables? One table that somehow squeezes alpha and additive blending together doesn't make a lot of sense.

50/50 alpha can be had by just creating any number of alpha tables (for example, 1). The last (or only) one will have alpha 0.5, according to the help text of shadexfog.create_alpha_trans():

Quote

Creates numtables blending tables of smooth alpha translucency,
starting with the blending number startblend, with values of alpha

1/(2*numtables), 2/(2*numtables) ... numtables/(2*numtables).

numtables must be a power of two in [1 .. 128].

fullbriOK: should fullbright color indices (>= 240) be permitted as
the blending result of two color indices?

(Also note the third edit of my earlier post, which corrects that of shadexfog.create_additive_trans().)

You can play around with the functions to your heart's content. As I said earlier, they merely set up engine state. When you're happy with some result, you can finally save the relevant tables to disk.

[TerminX]

He needs one that somehow crams them both into one for the sake of Total Meltdown, I guess. Apparently one of the transparency levels is additive there and the other isn't.

[Helixhorned]

 TerminX, on 14 December 2014 - 01:04 PM, said:

He needs one that somehow crams them both into one for the sake of Total Meltdown, I guess. Apparently one of the transparency levels is additive there and the other isn't.

But what's a "translucency level" in that context? Did they implement multiple blending tables, too? After all, you can't just use one half of the table (e.g below/above diagonal) for one mode and the second one for the other, since it may be accessed with any pair of (foreground, background) color indices. The other plausible option is duplicating colors in the base palette and handling them differently.

[Fox]

Transparency level one and two are sprite cstat 2 and 514. In Total Meltdown sprites with cstat 2 have 50% alpha and sprites with cstat 514 are 100% additive.

[sergey808a]

When this bug will be fixed?
eduke32_win64_20141213-4814



In eduke32_win64_20140907-4593 everything works fine.

[Hendricks266]

 Fox, on 13 December 2014 - 02:26 PM, said:

What is the most accurate program to apply a palette to an image? Most programs doesn't get even close to a precise conversion. For example, Microsoft Paint will fail to correct assign the pixels of the snapshot of a 256 colors palette within the same 256 colors palette. I just want something that does the math right, i.e. find the index with the closest match to the RGB values.

IrfanView's "use nearest color" option is the best I've ever found. You'll need to look up the command line options to apply it in batch, unfortunately.

[Fox]

I tested, and Irfanview seems to add dithering. So it's not what I want.

[Hendricks266]

How about GIMP's indexed color conversion?

[Helixhorned]

 Fox, on 14 December 2014 - 02:43 PM, said:

Transparency level one and two are sprite cstat 2 and 514. In Total Meltdown sprites with cstat 2 have 50% alpha and sprites with cstat 514 are 100% additive.

That's not possible with only one table. Consider the blending result of two identical colors. The result of the alpha blend is the same color as the input color, while the result of additive translucency is in general different from it. But "the blending result of two identical colors" is just what the diagonal entries of the table hold, so there's no way to get both alpha and additive by swapping foreground and background color indices for its indexing (cstat 512).

For sprites, you can use EVENT_ANIMATESPRITES and set the .blend member of the drawn tsprite according to its cstat, similar to how lunatic/test/sprite_access.con handles the alpha --> blend index translation.

[LeoD]

 sergey808a, on 15 December 2014 - 12:03 AM, said:

When this bug will be fixed?
eduke32_win64_20141213-4814

In eduke32_win64_20140907-4593 everything works fine.

Can't confirm this one. Follow the standard instructions and post both 4593/4814 logs as attachments.

[Helixhorned]

 LeoD, on 15 December 2014 - 11:11 AM, said:

 sergey808a, on 15 December 2014 - 12:03 AM, said:

When this bug will be fixed?

Can't confirm this one.

True, can't confirm this either. What becomes especially noticeable in Stadium though is that in Polymost, the faked floor shadows of actors have effectively become much darker compared to older revisions. I didn't do a bisection, but could this have something to do with the sprite depth offset changes?

[Helixhorned]

 Roma Loom, on 02 December 2014 - 11:38 PM, said:

Is it just me or loading a savegame doesn't load maphacked polymer light sources?

For a simple test -- saving E1L1 on Polymer+HRP and loading from a just started EDuke32 instance -- everything works as expected for me. However, that doesn't exclude the possibility of failure for more complicated usage paths. Map hack light info is not stored in the savegame itself. Rather, the file map name stored in the savegame is used to construct that of a .mhk file (by replacing .map with .mhk) and that one is attempted to be loaded. So, if there's a discrepancy of what EDuke32 sees as its virtual file system between when the savegame was made and at load time, issues can arise.

[Fox]

 Helixhorned, on 15 December 2014 - 11:10 AM, said:

That's not possible with only one table. Consider the blending result of two identical colors. The result of the alpha blend is the same color as the input color, while the result of additive translucency is in general different from it. But "the blending result of two identical colors" is just what the diagonal entries of the table hold, so there's no way to get both alpha and additive by swapping foreground and background color indices for its indexing (cstat 512).

I don't fully understand how the translucency tables work, but doesn't the game holds different lookup tables for 33% and 66% alpha?

[LeoD]

 Helixhorned, on 15 December 2014 - 11:35 AM, said:

True, can't confirm this either. What becomes especially noticeable in Stadium though is that in Polymost, the faked floor shadows of actors have effectively become much darker compared to older revisions. I didn't do a bisection, but could this have something to do with the sprite depth offset changes?

If that's addressed to me: no idea what you're talking about. Looks like some kind of setup issue to me.

[Helixhorned]

 Fox, on 15 December 2014 - 12:32 PM, said:

I don't fully understand how the translucency tables work, but doesn't the game holds different lookup tables for 33% and 66% alpha?

No, you have one table. For input color indices a and b representing colors A and B, the result of transluc[a][b] is a color index whose color is close to 0.33*A + 0.67*B. Now if you swap the foreground and background inputs, you get: transluc[b][a] = 0.33*B + 0.67*A. This swapping is just what the "reverse translucency bit", 512 for sprites, effects. So the ingenuity with Duke3D's table is that it packs two translucency levels into one table, but intuitively speaking, that's only possible because they're of the same kind.

Edit: an equivalent formulation is saying that, in matrix terms, the transposed table is accessed with the non-swapped indices: transluc^T[a][b]. So conceptually, there are two tables, but physically, there's only one.

 LeoD, on 15 December 2014 - 04:59 PM, said:

If that's addressed to me: no idea what you're talking about.

Nah, that was mainly addressed to TX. He will know.

[Fox]

 Helixhorned, on 16 December 2014 - 02:15 AM, said:

No, you have one table. For input color indices a and b representing colors A and B, the result of transluc[a][b] is a color index whose color is close to 0.33*A + 0.67*B. Now if you swap the foreground and background inputs, you get: transluc[b][a] = 0.33*B + 0.67*A. This swapping is just what the "reverse translucency bit", 512 for sprites, effects. So the ingenuity with Duke3D's table is that it packs two translucency levels into one table, but intuitively speaking, that's only possible because they're of the same kind.

Edit: an equivalent formulation is saying that, in matrix terms, the transposed table is accessed with the non-swapped indices: transluc^T[a][b]. So conceptually, there are two tables, but physically, there's only one.

If I understand it, there is only one translucency table of 33%, and the game simply swap the background and foreground pixels to create the effect of a 66% table.

Rats, I would then need a way to replace the two default translucency levels.

[Micky C]

The AMC TC uses both the alpha and additive blending types. Like Helix said, just have different tables and differentiate between them with the .blend function.

[Fox]

Blend won't do the job. I need to replace all instance which the two translucency levels are used.

[sergey808a]

This bug occurs if the folder autoload there are other packs except duke3d_hrp.zip, for example - duke3d_music.zip.
eduke32_win64_20141213-4814
Also, not working ending movies after 2nd and 3rd bosses.

Attached File(s)

•  eduke32.log (10.09K)
  Number of downloads: 296

[LeoD]

 sergey808a, on 16 December 2014 - 11:24 PM, said:

This bug occurs if the folder autoload there are other packs except duke3d_hrp.zip, for example - duke3d_music.zip.
eduke32_win64_20141213-4814
Also, not working ending movies after 2nd and 3rd bosses.

Delete textures.cache, textures, and retry.

[Fox]

It seems that "bright red" assigns the player with pal 22 instead 21.

[Hendricks266]

 Fox, on 17 December 2014 - 05:16 PM, said:

It seems that "bright red" assigns the player with pal 22 instead 21.

Oops.

[Micky C]

The new high res viewscreens are nice There are some problems though.
1) The viewscreen seemed to change its size after the first use.
2) It stopped animating when I went to the menu and returned. Couldn't get it to animate again.

Btw where did all the options like "show level stats" go? I can't see it anywhere. I'm using r4814 btw.

[Hendricks266]

 Micky C, on 18 December 2014 - 04:24 AM, said:

Btw where did all the options like "show level stats" go? I can't see it anywhere. I'm using r4814 btw.

We culled the menus in preparation for Android. That one is in Display Setup --> On-Screen Displays.

[Fox]

 Micky C, on 18 December 2014 - 04:24 AM, said:

1) The viewscreen seemed to change its size after the first use.

Spoiler

Probably the result of the tsprite x-yrepeat being truncated.