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

[Helixhorned]

Fox, on 16 December 2014 - 06:16 AM, said:

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

For sprites, the following will do, assuming the attached PALETTE.DAT table is used.

gamevar tmp 0 0
gamevar cs 0 0

state setup_animatesprites
    getactor[THISACTOR].mdflags tmp
    orvar tmp 16
    setactor[THISACTOR].mdflags tmp
ends

onevent EVENT_EGS
    state setup_animatesprites
endevent

onevent EVENT_LOADACTOR
    state setup_animatesprites
endevent

// Assuming a PALETTE.DAT with e.g.:
//  blend 0: 50/50 alpha
//  blend 1: factor 1.0 additive
onevent EVENT_ANIMATESPRITES
    getactor[THISACTOR].cstat cs
    ifvarand cs 2 ifvarand cs 512
        setactor[THISACTOR].blend 1
    else
        setactor[THISACTOR].blend 0
endevent

Note how I set mdflags[].flags' bit 16 for both cases of sprite creation (premap and in-game spawn), unconditionally for all sprites.

Attached File(s)

•  PALETTE_1-addtv.zip (49.12K)
  Number of downloads: 293

[Helixhorned]

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

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.

I can't reproduce any of these problems. For the second one, the rendered view on the security screen stops panning for a second or so, but resumes then. What are your renderer settings (as shown with DNCOORDS entered twice)?

[Fox]

Helixhorned, on 20 December 2014 - 05:12 AM, said:

For sprites, the following will do, assuming the attached PALETTE.DAT table is used.

(...)

Note how I set mdflags[].flags' bit 16 for both cases of sprite creation (premap and in-game spawn), unconditionally for all sprites.

I need it for masked walls too.

You changed the default table to 50%? That will be very usefull. But then I need a way to change the hard-coded translucency values in OpenGL modes.

[Micky C]

Helixhorned, on 20 December 2014 - 05:42 AM, said:

I can't reproduce any of these problems. For the second one, the rendered view on the security screen stops panning for a second or so, but resumes then. What are your renderer settings (as shown with DNCOORDS entered twice)?

Well that hardly gave any information at all.

Rendermode 0, resolution 1024x768, widescreen on.

[Mblackwell]

Wait what? 1024x768 is 4:3, not widescreen...

[Helixhorned]

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

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.

OK, 2) is now fixed. A more precise description of the bug is that the animation on the viewscreen was suspended for as long as you had the menu open. As far as 1) is concened, I can't get the viewscreen back to its normal tile with new revisions. Whenever I exceed the tile-update threshold distance (8192 Build units), the last rendered scene remains on the tile, in contrast to resetting to VIEWSCREEN, as in Duke3D. This is a probably unintended side effect of r4445.

Fox, on 20 December 2014 - 10:27 AM, said:

I need it for masked walls too.

Assuming the translucency bits of every wall never change, just loop over all of them at map entry and set wall[].blend accordingly.

Quote

You changed the default table to 50%? That will be very usefull. But then I need a way to change the hard-coded translucency values in OpenGL modes.

Well, that has been discussed earlier, like from here on.

[Fox]

Helixhorned, on 21 December 2014 - 08:35 AM, said:

Assuming the translucency bits of every wall never change, just loop over all of them at map entry and set wall[].blend accordingly.

That structure is not avaiable.

[Helixhorned]

Oops, right, the .blend wall member is present in Lunatic builds only.

[Fox]

I may ask, why is that?

[Helixhorned]

For the sprite structure type, there used to be an unused "filler" member that was taken over for the purpose of "blend". The V7 wall structure type is already tightly packed and there are no unused fields. In the Lunatic build, the internal map format is decoupled from the on-disk one, so that members can be added arbitrarily.

[Fox]

It's not like I have deep knowledge about the map format, but I don't understand why adding new sector or wall structures would not be viable in the same way as spriteext structures and per-sector or per-wall gamearrays.

[Micky C]

Is it normal for sprites and the player to move radially inward when in a rotating sector of which the point of rotation is outside the sector?

[Fox]

It's expected for the position of a sprite to change gradually in relation to the pivot point due to some imprecision in the calculation.

[Micky C]

Damn, so there's no way around it? Even with con code?

[Fox]

With CON code there is. If I am not wrong a statnum was created for that?

[Hendricks266]

htflags & 131072

With this flag you may never move the actor from its starting point.

[Helixhorned]

Fox, on 23 December 2014 - 06:57 AM, said:

It's not like I have deep knowledge about the map format, but I don't understand why adding new sector or wall structures would not be viable in the same way as spriteext structures and per-sector or per-wall gamearrays.

Ultimately because it means the existence of a new on-disk map format which would have to be maintained, together with conversion code from at least the preceding version. So, each time a field were added to sprite/wall/sprite in the non-Lua setting, we'd bump the map format to V10, V11, V12, ... not cool. The situation is different for structures like spriteext[] because they're not exposed in this way. Still, we need to bump BYTEVERSION (breaking older savegames) whenever we change these.

[Helixhorned]

Hendricks266, on 24 December 2014 - 01:57 AM, said:

htflags & 131072

With this flag you may never move the actor from its starting point.

The flag is ineffective when set during the game for an actor, though. The proper way is to mark an actor tile potentially "rotation-fixed" by adding bit 4 to its actortype. At map load time, sprites of that tile number contained in SE0, SE6 or SE14 sectors will be set up for prevention of roundoff error accumulation during the game. Sprites of the following statnums will be set up this way by default: DEFAULT, STANDABLE, FX, FALLER, LIGHT.

Note that in the wiki's htflags documentation, some flags have no CON labels. These flags are not really supposed to be used directly.

[Jblade]

The save command seems to be crashing the game on the latest snapshots. Wish I could give more info but the game just hangs when the command is used. Here's the code:

ifvarvare SAVEGAME THISACTOR
{
readgamevar SAVEGAME
ifvare SAVEGAME 0 killit
save 9
setvar SAVEGAME 0
savegamevar SAVEGAME
killit
}

ifvare AUTOSAVE_ENABLED YES
ifvare SAVEGAME 0
{
ifvarn HITAGSAVED 0
	{
	checkactivatormotion HITAGSAVED
	ifvare RETURN 1
		{
		userquote 243
		setvarvar SAVEGAME THISACTOR
		}
	}
else
	ifpdistl 1024
	{
	userquote 243
	setvarvar SAVEGAME THISACTOR
	savegamevar SAVEGAME
	}
}

It's convoluted to fix the issue where the game would autosave immediately again upon loading the save back up.

[Fox]

Helixhorned, on 24 December 2014 - 02:05 AM, said:

Ultimately because it means the existence of a new on-disk map format which would have to be maintained, together with conversion code from at least the preceding version. So, each time a field were added to sprite/wall/sprite in the non-Lua setting, we'd bump the map format to V10, V11, V12, ... not cool. The situation is different for structures like spriteext[] because they're not exposed in this way. Still, we need to bump BYTEVERSION (breaking older savegames) whenever we change these.

What prevents the addition of sectorext[] or wallext[] structures, other than bumping BYTEVERSION?

Edit: Where am I supposed to add SFLAG_NODAMAGEPUSH so it take effect? It doesn't work by changing the .htflags or using spriteflags outside the actor code.

[Hendricks266]

Touch menus have landed in synthesis. Feedback?

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

Also, not working ending movies after 2nd and 3rd bosses.

This is fixed.

[sergey808a]

Hendricks266, on 27 December 2014 - 02:14 PM, said:

sergey808a, on 17 December 2014 - 09:24 AM, said:
Also, not working ending movies after 2nd and 3rd bosses.

This is fixed.

Thanks for this.

Unfortunately glitch with Cycloid is still exist in eduke32_win64_20141227-4859.
This bug occurs if the autoload folder contains custom packs except duke3d_hrp.zip (even duke3d_music.zip).
If there is no custom packs in autoload folder - everything works good.
First log with no custom packs (no glitches).
Second log with added duke3d_music.zip in autoload folder, without other changes. Bug is exist.
I found this string in second eduke32.log:

Failed loading skin file "highres/sprites/monsters/2710_body_d.png": error -2

Maybe it helps fixing this bug.

Thank you for works.

Attached File(s)

•  eduke32.log (21.21K)
  Number of downloads: 260
•  eduke32.log (21.05K)
  Number of downloads: 252

[Helixhorned]

Jblade, on 24 December 2014 - 02:25 AM, said:

The save command seems to be crashing the game on the latest snapshots.

Fixed in r4838. The perpetrator thanks you for reporting and is happy for not having to fix it himself. (Probably. I didn't ask. )

Fox, on 24 December 2014 - 03:31 AM, said:

What prevents the addition of sectorext[] or wallext[] structures, other than bumping BYTEVERSION?

Nothing except bumping it, and the fact that nowadays the folks working on the embedded versions will likely frown upon the addition of a couple of KB of a mostly unused array. In other words, something like wall_blend[] for the non-Lua build is a good idea for maintaining some degree of compatibility, but said folks would probably like to see it tightly allocated. (Slightly more work for whoever implements this.)

Quote

Edit: Where am I supposed to add SFLAG_NODAMAGEPUSH so it take effect? It doesn't work by changing the .htflags or using spriteflags outside the actor code.

With the spriteflags directive. Starting with r4841, you may pass multiple flags to it, which will be bitwise-ORd. A somewhat sub-optimal example of a root CON file is this:

// 4610 is NEWBEAST
spriteflags 4610 SFLAG_NODAMAGEPUSH SFLAG_SMOOTHMOVE
include GAME.CON

Note that spriteflags is supposed to be used before the definition of the useractor of the same tile, any other sprite* directives or precache, the reason being that it assigns (i.e. overwrites) the 'flags' value instead of bitwise-ORing it into the old one. For code entirely under your control, this is not an issue.

[Fox]

SMOOTHMOVE works, NODAMAGEPUSH not.

[Helixhorned]

Fox, on 28 December 2014 - 10:50 AM, said:

SMOOTHMOVE works, NODAMAGEPUSH not.

You mean with the exact example I posted or some other case? For the former: works fine here. For the latter: I'd have to see the code, and potentially some context like the order in which useractor and sprite* directives appear. LunaCON warns you if you violate the rule stated earlier. (Except that it considers actor but not precache -- might need to fix that.)