[Jason S.]

Forgot I even had an account on here!

Anyways, i'd just like to bring up the obvious efficiency issue plaguing Polymer due to a lack of graphical options and sliders. Skyrim, other Bethesda games (even a few with ENB), Serious Sam HD and other more complex games run so well on my older ATI Radeon HD 6670 (25-60fps on average) at full resolution (1600x900) under some really great settings, yet this low poly sector based game doesn't with Polymer at any resolution or setting, becoming unplayable very quickly even at 640x480 under the lowest texture setting. To note, Polymost runs at hundreds of frames per second with the highest available settings (that is just the two, screen and texture resolution ).

Its the number of lights that does it (Duke Burger is a nightmare), so i'm wondering if there's a way to make Polymer more efficient with more "advanced" menu options and sliders in the future, such as limiting the draw distance of real time lights, specular and shadow effects, turning off parallax and specular mapping separately, and changing the shadow resolution itself. The "advanced" menu has a massive empty space where these options could be placed, and i'm pretty sure this doesn't require a huge restructuring of the engine to implement.

The problem is that, the core effect of Polymer should run more or less as it appears it should, and perform the same or better than the above games. Polymer should not be left to the those with the best of cards when the core effect doesn't need them. I think this should be a must if more effects are going to be implemented in the future, as everyone's going to run into this problem sooner or later, and i'm sure only a few adjustments will have Polymer running way better on everyone's hardware, without too much quality degradation.

Thanks.

[The Commander]

Most of the variables you asked about can be changed in the console at the moment using r_pr_ followed by the name of the variable.

[Micky C]

Jason S., on 24 January 2015 - 11:18 PM, said:

The problem is that, the core effect of Polymer should run more or less as it appears it should, and perform the same or better than the above games. Polymer should not be left to the those with the best of cards when the core effect doesn't need them. I think this should be a must if more effects are going to be implemented in the future, as everyone's going to run into this problem sooner or later, and i'm sure only a few adjustments will have Polymer running way better on everyone's hardware, without too much quality degradation.

It's no secret that polymer has long been unoptimised. The good news is that it should run much, much faster when it's closer to finished. I've heard that someone may be working on improving it at the moment, however what the end result of this is or when it'll be made public could be anyone's guess.

[Hendricks266]

Fox, on 13 January 2015 - 03:41 PM, said:

Edit: Previous/next weapon keys are broken when using the Pipebomb trigger.

Fox, on 17 January 2015 - 01:46 PM, said:

The Shrinker is not being selected with Next Weapon if subweapon is set.

Fixed.

[Fox]

Fox, on 13 January 2015 - 03:41 PM, said:

Edit: Previous/next weapon keys are broken when using the Pipebomb trigger.

I was referring to a different problem, which appears to have been fixed since then. The rest was just like the DOS version, but the change is welcome.

Now a minor remaining problem with previous/next weapon keys. When you have no pipebomb ammo left, but there is still a pipebomb in the ground, you still can switch to the pipebomb trigger by pressing 6, but not with next/previous weapon.

[Jason S.]

The Commander, on 24 January 2015 - 11:44 PM, said:

Most of the variables you asked about can be changed in the console at the moment using r_pr_ followed by the name of the variable.

Thanks for the info. Found the list of Polymer commands too and tested it a bit. Of course, the console only allows you to change the number of overall lights and passes in total, yet the framerate still doesn't compare to Polymost's or my other games, and can still hit 12-20fps and just stay there for a long while. Most games use a draw distance for the effects, and i'm pretty sure that many super smooth games like Uncharted 2/3 would run like crap too if they extended the shadow and lighting draw distance almost to infinity like Polymer does at the moment.

It did help to an extent, but it wasn't the performance boost I expected. Removing certain effects didn't do as much as I expected, either. In the end, i'm betting on there also being an overall engine and/or shader usage efficiency problem which will have to be isolated later on. In detail, beforehand, the game would get up to 30-60fps with VSYNC on at maximum, even during Critical Mass's explosive ending or under a large shadow spotlight or two, its just that it's way too easy for it to begin lagging badly too, in either big areas or just in general too.

Perhaps in the future, I'll get something like 20-30fps on average.

Micky C, on 25 January 2015 - 02:21 AM, said:

It's no secret that polymer has long been unoptimised. The good news is that it should run much, much faster when it's closer to finished. I've heard that someone may be working on improving it at the moment, however what the end result of this is or when it'll be made public could be anyone's guess.

I kinda forgot this thing was unfinished as its been out for several years now.

As for what this other person might be doing, i'm hoping it is some sort of tweak or the addition of advanced graphics options at least (so people don't have to use the console). Maybe it's just a set of maphack files which decreases the number of lights save for the shadow map spots. Seems like good news if it happens.

[Fox]

Since the previous/next weapons code has been changed, is there any intent to make both default Duke 3D small status bar and Eduke's custom HUD selectable with + or -?

It shouldn't break any existing mod, since .screen_size would remain the same and what would change is .althud (the menu option being removed).

[DavoX]

Any reason why the newest snapshot of mapster32 whenever I use ALT it plays an annoying sound? it's irritating since I use that for hitags, lotags, well mostly everything!

[Jblade]

Would there be a possibility of adding a member to userdef or something that lets me know if the player has music disabled? I've coded a dynamic sound system using sounds and I want to disable it if the player has music disabled automatically (you could make it read-only if you don't want people to be able to force music on or something)

[Hendricks266]

DavoX, on 30 January 2015 - 05:12 PM, said:

Any reason why the newest snapshot of mapster32 whenever I use ALT it plays an annoying sound? it's irritating since I use that for hitags, lotags, well mostly everything!

It's the OS playing the sound, right? It's probably an SDL2 issue. I'll see if there's anything I can do.

Jblade, on 02 February 2015 - 01:45 AM, said:

Would there be a possibility of adding a member to userdef or something that lets me know if the player has music disabled? I've coded a dynamic sound system using sounds and I want to disable it if the player has music disabled automatically (you could make it read-only if you don't want people to be able to force music on or something)

Sure, that will be no trouble.

[Jblade]

Cool - much appreciated. Just another quick question/query - can you guys code voxels so they're disabled if it's a flat sprite? I'm not sure if setting SPREXT_NOTMD to 1 will disable a voxel as well as a model, but if you have a voxel switch and it's used as a flat sprite it still appears as an upgrade voxel (of course if it can be done in con that's not a problem)

[Fox]

Jblade, on 04 February 2015 - 01:34 PM, said:

I'm not sure if setting SPREXT_NOTMD to 1 will disable a voxel as well as a model,

It should be.

[Micky C]

In mapster scripting, how do you detect if a member has a certain cstat applied if it's a bitfield (for conditional clauses)?

[Hendricks266]

ifand

[Helixhorned]

Fox, on 15 November 2013 - 01:55 PM, said:

From actors.c:

        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)))
                )

What's the reason for that line being commented out? That's what is causing the issue with Troopers and Enforcers walking in water sectors.

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.

[Helixhorned]

Jblade, on 17 January 2015 - 01:22 AM, said:

I tracked down the L5 corruption error to the event analyzesprites in my M32 script file, here's what it looks like:

onevent EVENT_ANALYZESPRITES
(...)
    for i drawnsprites
    {
        set j tsprite[i].owner
        switch sprite[j].picnum
        case 1404 // FAKE PLAYER
		ife sprite[j].extra 0 set tsprite[j].picnum 5245 // James          // Helix: NOTE THIS LINE
(...)
        endswitch
    }
endevent

You want to write

tsprite[i]

,
not

tsprite[j]

.

I haven't been able to reproduce the L5 corruption, though, which would clearly be a Mapster32 bug.

[Fox]

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

What are the limits?

[Micky C]

Micky C, on 05 February 2015 - 02:32 AM, said:

In mapster scripting, how do you detect if a member has a certain cstat applied if it's a bitfield (for conditional clauses)?

Hendricks266, on 05 February 2015 - 06:03 AM, said:

ifand

Example? What I'm trying to do is change the visibility of sectors under a sky.

[Hendricks266]

I want to test if the current sprite is wall aligned.

ifand .cstat 16 <do whatever>

I want to test if sector #k has a parallax sky.

ifand sector[k].ceilingstat 1 <do whatever>

[Fox]

Was .wantweaponfire disabled as a means of prevent the player from switching the weapon before reloading? It feels a bit weird to not have that feature when switching weapons. I assume it could be done without disabling .wantweaponfire by changing when P_CheckWeapon is called.

I took a look at the source. If I understand it, the issue would be solved by replacing this:

            if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_CHECKATRELOAD)
            {
                if (PWEAPON(snum, p->curr_weapon, WorksLike) == TRIPBOMB_WEAPON)
                {
                    if ((*kb) >= PWEAPON(snum, p->curr_weapon, TotalTime))
                    {
                        (*kb) = 0;
                        P_CheckWeapon(p);
                        p->weapon_pos = WEAPON_POS_LOWER;
                    }
                }
                else if (*kb >= PWEAPON(snum, p->curr_weapon, Reload))
                    P_CheckWeapon(p);
            }
            else if (PWEAPON(snum, p->curr_weapon, WorksLike)!=KNEE_WEAPON && *kb >= PWEAPON(snum, p->curr_weapon, FireDelay))
                P_CheckWeapon(p);

With this:

            if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_CHECKATRELOAD && PWEAPON(snum, p->curr_weapon, WorksLike) == TRIPBOMB_WEAPON)
            {
                if ((*kb) >= PWEAPON(snum, p->curr_weapon, TotalTime))
                {
                    (*kb) = 0;
                    P_CheckWeapon(p);
                    p->weapon_pos = WEAPON_POS_LOWER;
                }
            }
            else if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_RELOAD_TIMING && *kb >= PWEAPON(snum, p->curr_weapon, Reload))
                P_CheckWeapon(p);
            else if (PWEAPON(snum, p->curr_weapon, WorksLike)!=KNEE_WEAPON && *kb >= PWEAPON(snum, p->curr_weapon, FireDelay))
                P_CheckWeapon(p);

[Helixhorned]

Fox, on 10 January 2015 - 09:22 AM, said:

Helixhorned, on 10 January 2015 - 08:57 AM, said:

^[1]Quiz: which of the following commands can be removed without decreasing functionality: sound, soundonce, globalsound?

I assume ifsound does the exact same check as soundonce.

Correct, but incomplete. The other command that's technically redundant is globalsound. Contrary to what its name suggests, it doesn't start playing a special kind of sound, but rather a normal 3D sound from the position of the current player's sprite, provided that the current player is the one whose scene is currently displayed on the screen, or there's a coop game in progress:

        case CON_GLOBALSOUND:
// (checking omitted...)
// (#ifdef SPLITSCREEN_MOD_HACKS omitted...)
            if (vm.g_p == screenpeek || (GametypeFlags[ud.coop]&GAMETYPE_COOPSOUND))
                A_PlaySound(*insptr, g_player[screenpeek].ps->i);

[Helixhorned]

Fox, on 16 January 2015 - 10:36 AM, said:

Is it possible to set THISACTOR for "globalsounds" in EVENT_SOUND?

The globalsound command does not act differently depending on the current actor. (It does depending on current player, as explained in my preceding post.)

Maybe it would be helpful to phrase your request as what feature you're trying to achieve directly, not how. See XY problem.

[Fox]

The how is the feature. It would be more usefull if THISACTOR returned the actor which called the sound, rather than the one that is playing the sound, since the second one is a hack of the game.

Practical example:

onevent EVENT_SOUND
  ifvare RETURN BOS1_RECOG
    ifactor BOSS1
      ifspritepal 0
        setvar RETURN BOS1_SPEECH
endevent

This is not possible because BOS1_RECOG is a "globalsound". Since the primary purpose of EVENT_SOUND is to manipulate hard-coded sounds, this would make sense in my opinion.

[Hendricks266]

Some of the original considerations for EVENT_SOUND included a sound struct that allowed you to modify owner, flags, position, etc.

[Hendricks266]

Fox, on 25 January 2015 - 05:23 AM, said:

Now a minor remaining problem with previous/next weapon keys. When you have no pipebomb ammo left, but there is still a pipebomb in the ground, you still can switch to the pipebomb trigger by pressing 6, but not with next/previous weapon.

Fixed.

Jblade, on 02 February 2015 - 01:45 AM, said:

Would there be a possibility of adding a member to userdef or something that lets me know if the player has music disabled? I've coded a dynamic sound system using sounds and I want to disable it if the player has music disabled automatically (you could make it read-only if you don't want people to be able to force music on or something)

I've added a "musictoggle" member of the userdef structure.

Jblade, on 04 February 2015 - 01:34 PM, said:

I'm not sure if setting SPREXT_NOTMD to 1 will disable a voxel as well as a model, but if you have a voxel switch and it's used as a flat sprite it still appears as an upgrade voxel (of course if it can be done in con that's not a problem)

It looks like this is already set up in the source. Have you tested it and found it to not work?

[Jblade]

Sorry, I got kind of side tracked and didn't actually test it. I do think it should probably be forced at least that voxels set to flat switch back to 2D rendering as a lot of usermaps utilize switches and people using voxel packs will see some funky errors (like the start of Red4 for instance which has a bunch of floor aligned dipswitches) but of course I understand that hard-coding stuff is seen as a last resort if it can be done with con, it's not a problem for me to do it that way regardless.

[Hendricks266]

We already have special handling to stretch voxels horizontally when they are wall-aligned, so they could be used for switches like in SW.

[Jblade]

Sorry I should of clarified a bit more, I meant horizontally flat on the floor (as a floor aligned sprite)

EDIT: also just a thing, thanks for making this change - the translucent background covered up the menu display code I did which caused ugly clashes with colours which is now fixed in the latest snapshot:

Quote

Move EVENT_DISPLAYMENU to after the black translucent background is drawn when in-game.

[Helixhorned]

Jblade, on 04 February 2015 - 01:34 PM, said:

Just another quick question/query - can you guys code voxels so they're disabled if it's a flat sprite? I'm not sure if setting SPREXT_NOTMD to 1 will disable a voxel as well as a model, but if you have a voxel switch and it's used as a flat sprite it still appears as an upgrade voxel (of course if it can be done in con that's not a problem)

Yeah, SPREXT_NOTMD will disable rendering a sprite as a voxel. Unfortunately it can only be set from maphacks or from CON. Is the following good enough for you?

gamevar tmp 0 0

onevent EVENT_SPAWN
    getactor[THISACTOR].cstat tmp
    andvar tmp 48

    ifvare tmp 32  // if it's floor-aligned
    {
        getactor[THISACTOR].mdflags tmp
        orvar tmp 1  // SPREXT_NOTMD
        setactor[THISACTOR].mdflags tmp
    }
endevent

Otherwise, I agree that it would be better for floor-aligned voxels to "just work", but I'm not sure about rendering them as non-voxels by default then.

[Helixhorned]

Fox, on 07 February 2015 - 10:58 AM, said:

The how is the feature. It would be more usefull if THISACTOR returned the actor which called the sound, rather than the one that is playing the sound, since the second one is a hack of the game.

Agreed, that would be preferred.

Quote

Practical example:

onevent EVENT_SOUND
  ifvare RETURN BOS1_RECOG
    ifactor BOSS1
      ifspritepal 0
        setvar RETURN BOS1_SPEECH
endevent

This is not possible because BOS1_RECOG is a "globalsound". Since the primary purpose of EVENT_SOUND is to manipulate hard-coded sounds, this would make sense in my opinion.

In this particular case, I think a workaround would do fine. With a vanilla setup, BOS1_RECOG is only ever played when recognizing that boss, so the "ifactor BOSS1" check is redundant. Then, you could just search for a non-sleeping BOSS1 sprite in the map and assume that that one has just awoken. The assumption here is that no pal-0 boss is active at the same time as a colored one.