[Helixhorned]

James, on 18 February 2014 - 09:49 AM, said:

I've noticed a strange glitch with the new blend feature (with the custom pal and all) Whenever an object with a blend of 255 is onscreen (using the additive mode) it seems to apply it to translucent HUD elements as well (or rather things using rotatesprite I guess) It doesn't do it all the time, only if the item is onscreen.

Ah yes, I forgot to propagate the blending table index to all rendering routines. Good catch, once again!

Hendricks266, on 18 February 2014 - 09:56 AM, said:

Maybe negative inputs for <alpha> use blending tables instead? A new orientation bit?

I'll add the suggestion of packing the blending table index into bits 9..16 of the alpha argument. That way, one won't need to branch on the rendering mode in the CON code if one wants both alpha and blend.

Micky C, on 19 February 2014 - 03:37 AM, said:

I have some sprites in a (thin) rotating sector, and gradually over time the sprite positions are being offset tangential to the path

Sprite movement effected by rotating sectors is implemented by adding the corrensponding circular arc to its current position in each tic (using rotatepoint). It is expected that roundoff error accumulates when doing this repeatedly. The right way to rotate an object which must stay fixed with respect to the pivot is by saving its original relative position, and rotate that one each time. Passing bit 4 (unnamed, but you could e.g. "define ACTORTYPE_ROTFIXED 4") to useractor's first argument tells the game to do just this kind of rotation and assume that it will never move on its own.

[Micky C]

So basically that's what happens in the original game and it's not going to be fixed in the vanilla game?

[Helixhorned]

Actually, we already fix sprites of certain statnums in the frame of reference of the rotating sector:

// sprites with these statnums should be considered for fixing
#define ROTFIXSPR_STATNUMP(k) ((k)==STAT_DEFAULT || (k)==STAT_STANDABLE || (k)==STAT_FX || \
                            (k)==STAT_FALLER || (k)==STAT_LIGHT)

(As can be seen here, "destructible" flat sprites take on STAT_FALLER.)

The assumption here is that such sprites will never move in the x/y plane except by the rotating sector. This may be true when running the vanilla game, but it's a bit unsound when having custom CON code loaded: after all, any code could just come and move any other sprite. For this reason, I prefer having the user specify which actors will never move on their own explicitly.
Probably, what you want is some non-destructible spritework rotating without gradually shifting away, right? I guess it could be arranged that the current hard-coded behavior is augmented in some way (setting an xvel bit on the sprites? Setting some property on the SE?), but I like doing that only when there's no elegant scripting solution.

[Jan Satcitananda]

Yup, I've had the same problem with error accumulation when I tried to force a camera sprite to rotate around a certain object using a SE 0. It would be nice to have certain actors (such as the cameras) hard-coded to use a more precise rotation method. One could make some cool effects with this.

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?

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?

[Nukey]

Fox, on 19 February 2014 - 08:27 AM, said:

dummytile <tile> 65536 65536
animtilerange <tile1> <tile2> 0 0

Hackish, but it does the job...

The first one worked, so thanks for that.

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? I haven't looked much into it.

Not a big deal anyway, since Plagman reminded me that many picnums are going to have interfering code that can't be wiped so easily, but I figured I'd mention it.

[Fox]

Are you talking about the monsters walking in the map editor? That's hard-coded indeed, in fact you would notice that in-game they are static until they spot the player.

[Nukey]

Good, ya, that explains it.

[Fox]

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.

[Jblade]

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.

[Stabs]

why is it doing this now

[Mark]

Towards the top of the previous page someone else posted a pic of that same problem. They said it went away if they turned texture cache option from "compress" to either "on" or "off". I haven't seen a fix mentioned yet if it is an actual bug.

Did you try the usual delete the textures and textures cache files to see if the problem goes away or persists?

[Stabs]

cheers, fixes it, glusetexcache = 0 was the fix it was glusetexcache = 2 before

other option is to leave it at 2 and redelete the cache files every single time you run it

[TerminX]

Just committed a fix for that.

[Stabs]

[Micky C]

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.

[Stabs]

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

[Hendricks266]

As of r4343, you can now invoke a make command in the following way:

make VC_REV_CUSTOM="-Custom Awesome Build"

and, provided you are building from an active SVN or git-svn checkout, rev.h will automatically be filled like so:

EDuke32 2.0.0devel r4344-Custom Awesome Build (32-bit)

You can use the octal escape sequence "\040" to start with a space.

make VC_REV_CUSTOM="\040Mind the Gap"

EDuke32 2.0.0devel r4344 Mind the Gap (32-bit)

[Stabs]

makepalookup { pal 29 blue 13 green 7 remapself }

THANKYOU

Damn thats an awesome command so i modded the script made it keep 29 pal but with that command i can tweak up the perfect nighttime fog, and solves my npc problem

[Hendricks266]

Micky C, on 12 February 2014 - 09:35 PM, said:

Is there a mapster32 function or some code that will turn some selected sectors upside down?

Try this. Instructions included.

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