[Jblade]

Cheers, by CON is fine as I'd prefer it to be automatic (and it's for a TC anyways) thank for the help

[Jason S.]

A little while back, I posted about the framerate problems with Polymer and, while I still do believe there is an engine solution to this, given how much faster other games run under similar weight, I neglected to mention that turning the real time shadows off completely, which still leaves the spotlights and projective textures, more than doubled the frame rate to something more consistently playable, even with other lights still present.

What I was referring to earlier was with any shadows present and i'm mentioning this now because it seems to pinpoint one of the biggest catalysts for the frame rate issues for future reference, just incase it isn't as widely known. I know i'm repeating myself here, but the above information I think is an integral reminder that, while an engine issue might be existent, right now there would be decently large fps gain if a light/shadow removal or fade off point was established like in common games today.

[Helixhorned]

LeoD, on 09 February 2015 - 04:52 AM, said:

I'd strongly oppose against rendering floor-aligned models as textures by default, at least. Red4 is just an example why even flloor-aligned voxels probably don't need to be 'flattened' by default if you take a look at how the switch HRP model is rendered:
red4-model-wall.jpg red4-model-floor.jpg

I was suggesting to render floor-aligned voxels as voxels, but lying flat on the ground. Hence "just work". Drawing them completely flat by default would not be very friendly IMO. In the screenshot, do you object to the small but noticeable gap between the dipswitch model and the surrounding wall-aligned sprites? That's a bug of the model, it doesn't align perfectly.

On a related note: in r4952, I introduced a serious bug at exit when models were used. Please don't use revisions r4952--r4979 and update to r4980 instead. Sorry!

[Hendricks266]

Helixhorned, on 10 February 2015 - 12:13 PM, said:

I was suggesting to render floor-aligned voxels as voxels, but lying flat on the ground. Hence "just work".

I am in favor of this as well. In fact, this may be an opportunity to implement pitch and roll for voxels. In Polymost this would be as simple as applying the transformation to the generated model, but for Classic I believe it could work as transforming the vectors along which the squares are drawn.

Sidenote: With voxmodel now a separate file, and with VoidSW on the horizon, I really need to get voxels working in Polymer.

Sidenote: Have we established a defined order of application of angoff, pitch, roll, and md[xyz]off?

[Jblade]

Quote

In fact, this may be an opportunity to implement pitch and roll for voxels

Damn, that would be absolutely fantastic if you could - there's quite a few things that would really benefit from this in the TC. I had always just assumed it would be too expensive to perform or something so didn't ask.

Also just saw the new ability to add custom ANM cutscenes anywhere - I imagine Zaxtor will get a ton of use out of this

On a different note, we get sporadic crashes with rotscrnang after a while of gameplay - it seems to be some kind of conflict with horiz but it's fairly random (but normally after a specific amount of time) I'm going to try and narrow down when it occurs to give more information (although I'm pretty tight on time at the minute)

EDIT: after looking at it in a bit more detail, I think rotscrnang doesn't like using 1024 (which is 180 upside down) since there's a graphical glich in the center of the screen when this value is used. It's not a problem to work around it on my part but it might be worth looking into anyways.

[LeoD]

Helixhorned, on 10 February 2015 - 12:13 PM, said:

I was suggesting to render floor-aligned voxels as voxels, but lying flat on the ground. Hence "just work".

One more time I didn't understand what people are taking about in this thread ...

Helixhorned, on 10 February 2015 - 12:13 PM, said:

In the screenshot, do you object to the small but noticeable gap between the dipswitch model and the surrounding wall-aligned sprites? That's a bug of the model, it doesn't align perfectly.

No issue for me. Maybe intentional to improve hiding of 180° turned switches. Lots of models have far more serious outline/offset issues, maybe to fit their occurrences in the original levels. Some of the are listed in hrp_todo.txt.

Hendricks266, on 10 February 2015 - 12:34 PM, said:

In fact, this may be an opportunity to implement pitch and roll for voxels. In Polymost this would be as simple as applying the transformation to the generated model, [...]

Yes, please!

Hendricks266, on 10 February 2015 - 12:34 PM, said:

Sidenote: Have we established a defined order of application of angoff, pitch, roll, and md[xyz]off?

In maphacks I've established alphabetical order: angoff, mdxoff, mdyoff, mdzoff, pitch, roll. For 99.9 (or 100?)% of all cases the order doesn't matter anyway. If possible I attach negative values to the pitch and roll parameters only, instead of md[x|y|z]off.

[Darkus]

I don't know if it was posted before, but I found an old bug concerning the holoduke.

The monsters does not behave with the holoduke like they should.
In the DOS version, the monsters go after the holoduke only if the player is not closer than them.
But in EDuke32, the monsters always go after the holoduke, even if the player is closer.

I was also about to report a SFX volume issue, but it was already posted here

One last thing, it is possible to enable vsync in classic 8-bit mode in fullscreen?

[Jblade]

I remember asking something like this before, but I can't remember - is/was there a way to add a less demanding version of rotatesprite, for mostly static display elements? I do remember being told that the game cycles through whatever rotatesprite is used before continuing the game which can lead to slowdown. I've got a mission interface that uses a lot of rotatesprite for mission markers and stuff, however the graphics are completely static once displayed on screen - is there a way to code a variant of rotatesprite that only updates/refreshes after a certain amount of tics?

EDIT: also noticed that enemies seem to clip through sprite 2D floors now - I'll check to see if it occurs all the time or under specific circumstances.

[Fox]

Helixhorned, on 05 February 2015 - 08:44 AM, said:

That was not the reason for enforcers wrongly walking on water. First, note that the condition effectively checks whether an actor should stay put in its sector in the second line; the following ones are just special cases (Cycloid Emperor not leaving arena, other bosses not walking into water sectors). This has nothing to do with "dipping" into water or not. The line was commented out because otherwise, lizmen and z-stationary liztroops are prevented from leaving an ST1 sector by A_MoveSpriteClipdist().

The reason for the enforcers -- and maybe other actors -- wrongly walking on water was that there was that the z position of a sprite was updated in at least two locations, and in an inconsistent manner. First, in MV_Fall(), there is a check for whether an actor should dip into water: this is only the case if

• it's allowed to do that (more on that below),
  
• has jumptoplayer_only (bit 512) movflag clear, and
  
• currently has a zero vertical velocity.

Second, there was z updating in VM_Move(), but without handling the dipping special case.

The recent revisions check whether an actor may dip into water in VM_Move(), too, fixing the above-mentioned issue. While this is yet another departure from original behavior, having things consistent seems to outweigh this concern. I have also added a new spriteflag, SFLAG_NOWATERDIP, doing what it sounds like.

I'd be curious to hear whether it fixes any (or preferably, all) real problems.

That's a bug. If an enemy is moved after being hit by a weapon (which excludes the bosses), it ignores the conditions which prevents the enemy from leaving its sector.

However that shouldn't be a reason to exclude the condition from the Troopers or Enforcers. Instead of having a rare occurrence of a Trooper or Enforcer getting stuck in a sector with lo-tag 1 – which already happens with all stayput enemies – now the levels are populated by Troopers and Enforcers underwater. IMHO that drastically changes the gameplay and is not worth it.

Given the fact that only enemies like Octabrains or Protector Drones are found underwater in the stock maps, it doesn't seems that the other enemies are supposed to breath underwater, evidenced by the Enforcer corpse in E2L8. Technically the game doesn't prevent a mapper from placing these enemies underwater, but that's not different from making a Shark fly by placing it out of water.

But if you want to keep it this way, instead of commenting out that line, you can solve the problem by checking if the sprite is not already in a sector with lo-tag 1.

[Helixhorned]

Fox, on 05 February 2015 - 09:12 PM, said:

Line 252, rotatespritea: invalid coordinates: -21430272, 3145728

What are the limits?

                if (EDUKE32_PREDICT_FALSE(x < -(320<<16) || x >= (640<<16) || y < -(200<<16) || y >= (400<<16)))
                {
                    CON_ERRPRINTF("invalid coordinates: %d, %d\n", x, y);
                    continue;
                }

I do agree that they are somewhat arbitrary and should be purged. The classic rotatesprite routines don't behave very well as far as extreme cases are concerned, though.

[Helixhorned]

LeoD, on 11 February 2015 - 09:20 AM, said:

No issue for me. Maybe intentional to improve hiding of 180° turned switches.

I meant the gaps at three of the four edges of the switch:



The one on the far right is really minor, but still noticeable. This is just kind of an appeal to modelers to create these kinds of assets based on an exact grid.

Jblade, on 13 February 2015 - 12:46 AM, said:

EDIT: also noticed that enemies seem to clip through sprite 2D floors now - I'll check to see if it occurs all the time or under specific circumstances.

Apparently, my recent round of game-side clipping changes was suboptimal. We are discussing this privately and will hopehully come up with something better.

[Fox]

Helixhorned, on 17 February 2015 - 05:31 AM, said:

                if (EDUKE32_PREDICT_FALSE(x < -(320<<16) || x >= (640<<16) || y < -(200<<16) || y >= (400<<16)))
                {
                    CON_ERRPRINTF("invalid coordinates: %d, %d\n", x, y);
                    continue;
                }

I do agree that they are somewhat arbitrary and should be purged. The classic rotatesprite routines don't behave very well as far as extreme cases are concerned, though.

Thanks. The real problem is the error message, which is not very useful in this case.

[Helixhorned]

Jblade, on 11 February 2015 - 02:25 AM, said:

On a different note, we get sporadic crashes with rotscrnang after a while of gameplay - it seems to be some kind of conflict with horiz but it's fairly random (but normally after a specific amount of time) I'm going to try and narrow down when it occurs to give more information (although I'm pretty tight on time at the minute)

EDIT: after looking at it in a bit more detail, I think rotscrnang doesn't like using 1024 (which is 180 upside down) since there's a graphical glich in the center of the screen when this value is used. It's not a problem to work around it on my part but it might be worth looking into anyways.

Thanks for pointing out this issue and narrowing down its cause! Fixed in r5009.

[Fox]

Quote

r4903 | terminx | 2015-01-10 20:56:38 -0800 (Sat, 10 Jan 2015) | 1 line

Introduce "twalltype" for temporary uses of walltype where using wall_tracker_hook() would be invalid. This is similar to "tspritetype" and fixes a bunch of problems in the editor that cropped up when changing the tracker sanity checks to an assert that only exists in debug builds (branching upon any write to a sprite, sector or wall had an unacceptable impact on performance).

How feasible would it be to add tsectortype and twalltype to the game?

[TerminX]

I think you're a bit confused, it's like tspritetype in that it doesn't trigger some internal modification tracking stats, not like the "tsprites" that are generated from and control sprite rendering.

[Helixhorned]

Fox, on 16 February 2015 - 07:55 PM, said:

That's a bug. If an enemy is moved after being hit by a weapon (which excludes the bosses), it ignores the conditions which prevents the enemy from leaving its sector.

What does "That" refer to?

Arguably, enemies leaving their designated "stay put" sector is a bug, but one that is likely to occur infrequently.

Quote

However that shouldn't be a reason to exclude the condition from the Troopers or Enforcers. Instead of having a rare occurrence of a Trooper or Enforcer getting stuck in a sector with lo-tag 1 – which already happens with all stayput enemies – now the levels are populated by Troopers and Enforcers underwater. IMHO that drastically changes the gameplay and is not worth it.

The quoted code snippet has nothing to do with Enforcers appearing underwater by submerging. I'm attaching a map lzwtrtst.map (for "liz water test") which can also be run in Duke3D. It contains a water sector (above and underwater) with an Enforcer in it. It will submerge at the first attempt to jump, and it will do that in a pretty ugly fashion: not when hitting the water after the jump, but on initiating it!

Note: when you change the water to TROR water without SE7, the Enforcer can now jump on it, but will still submerge -- now, on hitting the water surface.

Quote

Given the fact that only enemies like Octabrains or Protector Drones are found underwater in the stock maps, it doesn't seems that the other enemies are supposed to breath underwater, evidenced by the Enforcer corpse in E2L8. Technically the game doesn't prevent a mapper from placing these enemies underwater, but that's not different from making a Shark fly by placing it out of water.

I agree that from a gameplay point of view, it might be preferable to force lizmen to stay on the surface. However, that would be a departure from classic Duke3D, as just shown.

Quote

But if you want to keep it this way, instead of commenting out that line, you can solve the problem by checking if the sprite is not already in a sector with lo-tag 1.

Won't help. If I change the check to "old sector was above water, new one is underwater", there's no noticeable change as far as this issue is concerned. The reason is that this particular code snippet, shown here once again, is supposed to prevent sector change due to horizontal movement, not submersion.

Spoiler

    if (badguy)
    {
        // Handle potential stayput condition (map-provided or hard-coded).
        if (dasectnum < 0 ||
                ((actor[spritenum].actorstayput >= 0 && actor[spritenum].actorstayput != dasectnum) ||
                 (spr->picnum == BOSS2 && spr->pal == 0 && sector[dasectnum].lotag != ST_3) ||
                 ((spr->picnum == BOSS1 || spr->picnum == BOSS2) && sector[dasectnum].lotag == ST_1_ABOVE_WATER)
//                 || (sector[dasectnum].lotag == ST_1_ABOVE_WATER && (spr->picnum == LIZMAN || (spr->picnum == LIZTROOP && spr->zvel == 0)))
                )
            )
        {
            spr->x = oldx;
            spr->y = oldy;

            // NOTE: in Duke3D, LIZMAN on water takes on random angle here.

            setsprite(spritenum, (vec3_t *)spr);

            if (dasectnum < 0)
                dasectnum = 0;

            return 16384+dasectnum;
        }

        if ((retval&49152) >= 32768 && actor[spritenum].cgg==0)
            spr->ang += 768;
    }

The value returned from this function when the condition is hit (16384+sectnum) is used to determine potential submersion later.

Attached File(s)

•  lzwtrtst.zip (719bytes)
  Number of downloads: 309

[Fox]

Helixhorned, on 18 February 2015 - 10:47 AM, said:

It contains a water sector (above and underwater) with an Enforcer in it.

The point is that a mapper is not supposed to do that. What bug may occur from that misstep doesn't matter, it's an undefined behavior.

[Helixhorned]

Fox, on 18 February 2015 - 06:18 PM, said:

The point is that a mapper is not supposed to do that.

Just so we understand each other, a mapper is not supposed to place Enforces into ST1 (above water) sectors?

Quote

What bug may occur from that misstep doesn't matter

Then what was your complaint about?

[Fox]

Helixhorned, on 19 February 2015 - 10:21 AM, said:

Just so we understand each other, a mapper is not supposed to place Enforces into ST1 (above water) sectors?

Yes.

Helixhorned, on 19 February 2015 - 10:21 AM, said:

Then what was your complaint about?

That the gameplay has been drastically changed to fix that undefined behavior.

[Helixhorned]

Fox, on 19 February 2015 - 07:38 PM, said:

Helixhorned, on 19 February 2015 - 10:21 AM, said:

Just so we understand each other, a mapper is not supposed to place Enforces into ST1 (above water) sectors?

Yes.

OK, it finally dawned to me that what you objected to was Enforcers and Troopers changing into ST1 sectors from non-ST1 sectors.

r5021 said:

actors.c: make Enforcers and Troopers avoid ST1 sectors as in Duke3D.

That is, resurrect the stayput condition for LIZMAN and non-flying
LIZTROOP, but only if changing from a non-ST1 sector.

I hope everyone can agree with that: it restores the Duke3D behavior while allowing enemies which strayed into the water in some way (such as a flying Trooper) to move freely into adjacent water sectors^[1]. Actually, I'm not so sure anymore why the condition was commented out in the first place. It does not prevent enemies leaving water sectors (the check looks at the updated sector number).

^[1] In case of non-submergible water. Otherwise, they submerge in the aforementioned ugly way on contact...

Edit: OK, the reason it was originally commented out is: because they would stay at the same (x, y) position once on the water? Well, the additional condition in my commit fixes that.

[Fox]

THANK YOU.

Helixhorned, on 20 February 2015 - 02:19 PM, said:

Edit: OK, the reason it was originally commented out is: because they would stay at the same (x, y) position once on the water? Well, the additional condition in my commit fixes that.

As I explained above, I assumed the reason was because if an actor moves after being shot, it will ignore the stayput condition. That's the only reason I can think of for the Trooper and Lizman being commented out but not the bosses (since these don't move from damage).

[Fox]

Small issue with screentext. If I use 16 bits precision, center aligned texts are offset with precision, making it harder to reproduce the default status bar scaled.

[Fox]

I realized that it's possible to play the intro/briefing/loading tracks by changing the volume to 7. Given that, is it possible to expose MAXVOLUMES to CON?

[Helixhorned]

Fox, on 20 February 2015 - 02:45 PM, said:

THANK YOU.

Hey, you're welcome! But... it would have been awesome if you just said what I said from the start .

Quote

As I explained above, I assumed the reason was because if an actor moves after being shot, it will ignore the stayput condition.

It won't ignore the condition, though. Check it out yourself: set LIZSTRENGTH to 1000 in USER.CON and empty a chaingun burst on him which he's at the brink of a water sector.

Fox, on 20 February 2015 - 02:54 PM, said:

I realized that it's possible to play the intro/briefing/loading tracks by changing the volume to 7. Given that, is it possible to expose MAXVOLUMES to CON?

Actually, I'm in favor of exposing all of the relevant "manifest constants", partly because they're sometimes not that constant -- such as sector/wall/sprite limits depending on EDuke32 build options. However, I'd like to be reasonably sure that introducing these won't semantically clash with user defines in the wild, and my large collection of CON mods and TCs currently resides on a (physically, as it turned out) damaged disk.

[Hendricks266]

Fox, on 20 February 2015 - 02:52 PM, said:

Small issue with screentext. If I use 16 bits precision, center aligned texts are offset with precision, making it harder to reproduce the default status bar scaled.

I don't understand.

[Fox]

If I understand what the quick weapon switch option is for, it's not working.

[TerminX]

Fox, on 21 February 2015 - 10:00 AM, said:

If I understand what the quick weapon switch option is for, it's not working.

It works properly, I just forgot to remove it from the PC version.

[Fox]

Nah, I thought it was an option make switching weapons work like in the DOS version. Which would not be a bad idea.

[Micky C]

Has anyone noticed that the engine seems to overestimate the clipping of floors with relatively large slopes? Like if it's sloped upwards, you'd be positioned higher then you should be at the peak of the slope? Is that normal?

[Fox]

I believe that's because the engine calculates the clipping height based on the sprite center, not the highest point of the sloped sector.