[Helixhorned]

CraigFatman, on 20 February 2014 - 12:58 PM, said:

It's great to have multiple blend tables, maybe I could make benefit from it someday. Can they be implemented by direct editing of Palette.dat file?

Yes, the additional blending tables can be packed after the main translucency table, using this format (in pseudo-C):

char magic[12] = "MoreBlendTab";
uint8_t numAdditionalBlendTabs;
struct {
    uint8_t blendnum;  // the .blend index
    uint8_t blendTab[256][256];
} additionalBlendTabs[numAdditionalBlendTabs];

Quote

Also I've got a little issue to report. I've noticed that since some (2013?) build the rotatesprite command aligns sprites to the top-left corner incorrectly (orientation flag 16): some sprites drawn on the screen are offset to the right by one pixel (actually half a texel) what just fucks up all the precise alignment of my HUD. Any hope to have this fixed?

The current build displays the LNGA2 HUD like this for me:

There's the one-pixel vertical line between the 'bars' noticeable, but nothing that's offset by half a texel here (this is 1680x1050). Also, r3284 (which introduced -rotatesprite-no-widescreen) displays it the same.

Can you provide a small example demonstrating the issue? I created the following one:

onevent EVENT_DISPLAYREST
    rotatesprite 0 105 262144 0 2834 0 2 272 0 0 xdim ydim  // red dash
    rotatesprite 0 0 1048576 0 2822 0 0 16 0 0 xdim ydim  // big exclamation sign
endevent

which displays like this:

Passing -rotatesprite-no-widescreen makes the exclamation sign flush to the left border, as expected.

As you can see, screen display is pretty complex and depends on various "environmental" factors. So, an example differing between now and r3284 would be most helpful.

Nukey, on 20 February 2014 - 01:51 PM, said:

Unfortunately the second one doesn't seem to wipe the old animation definitions. When I try, say for the queen texture:

animtilerange 4740 4740 0 0

or any variation thereof, it doesn't stop her from animating. Maybe the queen isn't "animating" per se but is hard-coded to animate instead?

You have to distinguish between engine-side animation and game-side animations via actions. The former is defined from ART. Whenever you see something like "Fwd 15" in the status bar in tile selection mode in Mapster32 (e.g. tile 100, atomic health), that's engine-side animation. Actions are of course defined from CON. In the case of the Queen, here's what makes her animate, in GAME.CON:

action ABOSS4WALK          0 4  5  1  30
action ABOSS4DYING        40 9  1  1  20
action ABOSS4ABOUTTOSHOOT 20 1  5  1  40
action ABOSS4SHOOT        25 2  5  1  10
action ABOSS4LAYIT        50 3  5  1  120
action BOSS4FLINTCH       40 1  1  1  1
action ABOSS4DEAD         49

(Well, actually, these only define potential animations. Actually starting them is done with action. EDIT: the game-time command, that is.)

[Helixhorned]

Fox, on 21 February 2014 - 10:33 AM, said:

Since we are on the rotatesprite subject, what about a orientation flag to bypass art animation? I know that's possible for the original game (i.e. menu selection icon) so it could be extended to CON.

Can you explain in more detail what you mean by "bypassing" it? Which of the standard rendering routines do that? Where is tile 3190 not animated?

James, on 21 February 2014 - 11:22 AM, said:

Would there be a way to detect what type of sound is playing in Event_sound? Specifically ones with the player speech sound flagged. I want to affect all player speech, doing it manually is possible but having a way to automatically affect player speech rather than having to do each one individually would be great.

Accessing sound properties such as their flags is planned for Lunatic. For CON, that would amount to adding a new kind of structure, like "getsound[].xxx". I'm not interested in that.

DanM, on 22 February 2014 - 12:01 AM, said:

strange under sectors pal 29 the prop sprites / extra duke skins i use for edf/cops would display correctly but if i change the sector too pal 31 they stop using their pal and just look like a normal duke in cutscenes when they are props, but when they become bots in game they start using their skins correctly

Is there an easy way to check out the recent DNE development build? (That is, using a version control system.) An example would help in any case.

DanM, on 22 February 2014 - 01:07 AM, said:

THANKYOU

You're welcome, but please don't go on hurried mass-modification sprees whenever EDuke32 changes appear to have broken something in your mod, 'kay?

[Stabs]

no no, everything else was needed all my custom textures needed their own tiles to play nice with the new fog system, they just scale and look better too, i was just using pal 31 because it was a bit different looking than the new pal 29 and i thought i couldn't modify the built in fog shades colors, it was really too blue before which was my main problem and left large black chunks where walls where using pals of 40+ as the fogging would not effect them

btw is there a way i can def the old duke model back in based on its pal so i can have my edf/cops back but still have the new player model

[Micky C]

Hendricks266, on 22 February 2014 - 02:30 AM, said:

Try this. Instructions included.

Hail to the King, baby!

Edit: I was wondering if it was also possible to make an extra option for the script, which takes what you've done on the floor (relative heights, textures, shades, slopes), and apply them to the ceiling of the same sectors, and vice versa? I have a feeling that might be more work, so if it's too much then that's ok.

[Helixhorned]

Micky C, on 21 February 2014 - 11:52 PM, said:

Helixhorned, on 20 February 2014 - 09:45 AM, said:

Probably, what you want is some non-destructible spritework rotating without gradually shifting away, right?

Yeah that's right. Although the map is for the AMC TC so there is custom code involved, but the sprite I'm using is just a regular sprite.

Now that I look at it again, 'normal' static sprites already should be rotation-fixed. STAT_DEFAULT is 0.

As far as other kinds of sprites such as cameras are concerned, I think I'll add a new event, EVENT_ROTFIXSPRITE, that will hook into premap.c:G_SetupRotfixedSprites(). If the camera had its own statnum, I guess I could add it to the list of rotation-fixed ones, but curiously it's changed to STAT_ACTOR on spawn even if there's no actor code for it in GAME.CON.

[Jan Satcitananda]

Helixhorned, on 22 February 2014 - 03:28 AM, said:

Yes, the additional blending tables can be packed after the main translucency table, using this format (in pseudo-C):

char magic[12] = "MoreBlendTab";
uint8_t numAdditionalBlendTabs;
struct {
    uint8_t blendnum;  // the .blend index
    uint8_t blendTab[256][256];
} additionalBlendTabs[numAdditionalBlendTabs];

Glory hallelujah! But can we use this with rotatespritea command? I've put a multiplicative blend table for #1, and it works for sprites, but on-screen graphics behave strange. Doing "setactor[THISACTOR].blend 1" on EVENT_GAME makes all the HUD to use this blend mode too.

Helixhorned, on 22 February 2014 - 03:28 AM, said:

As you can see, screen display is pretty complex and depends on various "environmental" factors. So, an example differing between now and r3284 would be most helpful.

Well, I admit that it's apparently my fault, because LNGA2 works well for me too. Looks like I haven't done sufficient research. I guess I took a way too long break from modding. =) Actually the culprit is my subroutine which dynamically rescales and displaces the HUD graphics. So thanks anyway.

[Hendricks266]

CraigFatman, on 22 February 2014 - 01:45 PM, said:

But can we use this with rotatespritea command?

We are planning to pack the blend member into upper bits of the alpha parameter for rotatespritea and screentext. Probably bits 8-15 (shiftvarl 8).

CraigFatman, on 22 February 2014 - 01:45 PM, said:

Doing "setactor[THISACTOR].blend 1" on EVENT_GAME makes all the HUD to use this blend mode too.

That's weird.

[Fox]

Would it be possible to automatically remap all lookup tables to transform color 255 into 0? That would effectively solve some problems. It would fix the glitch involving translucent textures over a wall/floor textures that uses the transparent/magenta color. Also any wall/floor textures that uses the transparent color would be properly displayed as black in the map editor, while it would still be magenta in the tile browsing.

[MetHy]

About the feature that makes enemies with palettes other than the original one tougher, has that been disabled in any recent eduke32? and if not, when will it be disabled? In the meantime, can you tell me WHEN that was implemented so that I can download the last old eduke32 without that 'feature'?

That was really a terrible idea. Each time I want to play a map and it has enemies with different palettes, the whole balance is ruined and it pisses me off. Tons of maps are unplayable because of that. They take forever to die (more than any 'enhanced' enemy should anyway) and they seem to deal more damage, too. When you're facing even only 2 or 3 enhanced enemies at once that weren't supposed to be like that, it's already too much and shouldn't be like this... not to mention that some maps use DOZENS of those.

If anything the idea of having a super enemy is cool, but it should be left as a decision to the mapper instead of making it mandatory for every non original palette. It should be a feature a mapper can able on any enemy regardless of palette (and if the map is played in non-eduke32 duke3D or in an older eduke32 version they would remain normal enemies, and not make the map eduke32-only just for that one enemy).

[Jblade]

It was like that in the original V1.3D version of Duke, which is why it was added back in - it hasn't proved popular of course, but it would of been nice if Eduke could detect what version the map is made for and amend it that way.

[MetHy]

What? Are you kidding me? I don't believe that at all until I see it with my own eyes. Or perhaps it got taken out in 1.4 and 1.5 which is what most maps are made for anyway. So, it should only happen in maps made for v1.3D.

What's weird is that I do not remember red teleporting liztroops act like that in the original game. Then again, I haven't played v1.3 in more than a decade.

[Jblade]

IIRC it only did it to Pigcops, but I am not fucking with you - I'm fairly sure it only did it to pigcops with a spritepal of 13 or 14 though. Look up an old map called ARMYCAMP, the author makes a brief mention of it there. I played with V1.3D for many years before I got my hands on the atomic edition.

[LeoD]

MetHy, on 23 February 2014 - 03:41 AM, said:

About the feature that makes enemies with palettes other than the original one tougher, has that been disabled in any recent eduke32? and if not, when will it be disabled?

All requests to change that back have been ignored so far.

MetHy, on 23 February 2014 - 03:41 AM, said:

In the meantime, can you tell me WHEN that was implemented so that I can download the last old eduke32 without that 'feature'?

I took a note that it was r3102, so r3101 should be your choice.

[MetHy]

James, on 23 February 2014 - 04:49 AM, said:

IIRC it only did it to Pigcops, but I am not fucking with you - I'm fairly sure it only did it to pigcops with a spritepal of 13 or 14 though. Look up an old map called ARMYCAMP, the author makes a brief mention of it there. I played with V1.3D for many years before I got my hands on the atomic edition.

If it only happened to pigcops, what eduke32 has implemented is completely different as it works on every single enemy. Should be disabled or at best like I said, make it so that mappers decide. This single feature succeeded in ruining the balance of hundreds of maps and renders tons of them unplayable. It's like "Hmmm, how could I ruin 10 years of effort making this port while at the same time ruining hundreds of mappers effort?". I'm not even exagerating.

[Fox]

Yes, it was like that in v1.3D and was removed in Atomic Edition.

[Jblade]

I was the one who requested it I think, although I don't know who added it in. It was never intended as a malicious gesture and I didn't put much thought into it at the time (such is the benefit of hindsight) I just remember thinking it was cool that you could make stronger pigcops in V1.3D without con edits and thought it was a shame they took it out in v1.5.

[Fox]

Nonetheless, Eduke32 should prioritize Atomic Edition above v1.3d in case of conflict like this. Or at least apply such hack only to v1.3d...

[Danukem]

I think this is what James posted that spurred the change: http://forums.duke4....post__p__139246

Then shortly after, TerminX posted this: http://forums.duke4....post__p__139294

Apparently this major change was implemented without any other discussion or fanfare.

[MetHy]

How it should be : pigs with pal 13 and liztroops with pal 21 should be tougher in v1.3D

How it was implemented : every enemy of every non 0 palette of every version is made tougher

[Helixhorned]

CraigFatman, on 22 February 2014 - 01:45 PM, said:

Doing "setactor[THISACTOR].blend 1" on EVENT_GAME makes all the HUD to use this blend mode too.

Are you using the most recent build? This sounds like the bug that James reported earlier and was fixed with r4338.

[MusicallyInspired]

Yes, I remember that from 1.3D. It was the only version I had for years and I ran into that while experimenting with creating maps. There's one palette that makes the pixels around certain monsters' mouths red so it looks like they're bloodthirsty and really dangerous. Quite effective with the added difficulty.

[Hendricks266]

James, on 23 February 2014 - 03:51 AM, said:

it would of been nice if Eduke could detect what version the map is made for and amend it that way.

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

[Helixhorned]

Fox, on 22 February 2014 - 06:56 PM, said:

Would it be possible to automatically remap all lookup tables to transform color 255 into 0? That would effectively solve some problems. It would fix the glitch involving translucent textures over a wall/floor textures that uses the transparent/magenta color. Also any wall/floor textures that uses the transparent color would be properly displayed as black in the map editor, while it would still be magenta in the tile browsing.

What we do now is to tweak the main translucency table if a Duke3D 1.5 or LameDuke translucency table is detected: for every i, 0 <= i <= 255, we set

transluc[255][i] = transluc[0][i]
transluc[0][i] = transluc[255][i]

This fixes the first issue you mention: a background color index 255 blended with a foreground color will yield a result as if the background had been color index 0.

What's left for vanilla Duke3D 1.5 is that in Mapster32, color index 255 is displayed as magenta for solid walls (in the game, the base palettes are modified shortly after being loaded, setting index 255 to a black color for the default, water and slime base palettes). In Mapster32, the Lunatic 'engine' module functions like engine.setblendtab and engine.setshadetab allow registering the tables as many times as desired (for the game, we error if an already registered one is attemted to be set again). So, the tweaks you mention can be easily implemented in Lua code and the command running them added to m32_autoexec.cfg.

We don't modify the translucency table if the loaded one differs from the Duke3D 1.5 one because mods may be using row/column 255 for their own purposes. The LNGA page for example states:

Quote

LNGA uses a table of color addition. The last row and column correspond to the transparent color (0xFF); they are dedicated to non-linear conversions.

Edit: so a solution would probably be allowing re-registering tables 0 in the game for the engine.* functions? Otherwise, there's no way to change palookup/blend 0 programmatically at startup.

[Helixhorned]

MusicallyInspired, on 23 February 2014 - 09:08 AM, said:

Yes, I remember that from 1.3D. It was the only version I had for years and I ran into that while experimenting with creating maps. There's one palette that makes the pixels around certain monsters' mouths red so it looks like they're bloodthirsty and really dangerous. Quite effective with the added difficulty.

Interesting. The only difference between 1.3D and 1.5 lookups is for pal 2 though, in the fourth-to-last 16-tuple of consecutive indices, the orange ramp with a "bend" in the middle when plotted. The default base palette and shade table are identical. This leaves the tiles themselves, might be interesting to compare them byte-wise.

[Hendricks266]

Pal 24:

[Helixhorned]

About sprite rotation-fixing again. I think I'll hold EVENT_ROTFIXSPRITE for now. It should be possible to rotation-fix CAMERA1 by declaring it a type-4 useractor. Since it doesn't have actor CON code on its own, its functionality will not be lost. If people realize that this trick isn't enough, for example because they don't want the hard-coded rotation-fixing for particular sprites, that's when EVENT_ROTFIXSPRITE will come into play.

[Fox]

Hendricks266, on 23 February 2014 - 10:03 AM, said:

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

Instead of checking the bytes of the GRP, wouldn't it be better to detect the version of the CON files? The number of entries in gamestartup command is a giveaway.

[HellFire]

Hendricks266, on 23 February 2014 - 10:03 AM, said:

No such thing is possible. However, it would be possible to only implement the effect when a v1.3D GRP is selected.

I think a better idea would be: add a "Gameplay options" menu which would behave in a similar way to the one with same name from G/ZDOOM. In there, options like "1.3d monter's pal behavior", "1.3d kick behavior" (you know, being able to kick with both legs at the same time) as well gameplay changes introduced by eduke32 could be toggled by the user himself, if he likes.

[Plagman]

Quickly go through the walls and sprites to check for tile numbers that correspond to Atomic Edition would maybe be a good first approximation?

[Hendricks266]

Fox, on 23 February 2014 - 03:07 PM, said:

Instead of checking the bytes of the GRP, wouldn't it be better to detect the version of the CON files? The number of entries in gamestartup command is a giveaway.

The code would be using the existing game-mode check, so (!PLUTOPAK) or something like that.