[Helixhorned]

Fox, on 05 March 2014 - 05:08 PM, said:

The shade table really doesn't match a regular algorithm for shading multiplication...

Recall that the base palette -- that is, all colors that are ever displayed in a single scene -- has 256 colors in total. One particular "ramp" has less colors at its disposal. In the case of the gray ramp, there are 32 colors of those. So, the left picture looks a lot like the right one quantized to 32 levels.

Spoiler

Some quick Octave code demonstrates this.

a = repmat((0:31)/32, 32, 1) .* repmat((0:31)'/32, 1, 32);
imagesc(a); colormap(gray); colorbar; set(gca,'YDir','normal')
% ^ looks like the right picture

b = floor(32*a)/32;
imagesc(:blink:; colormap(gray); colorbar; set(gca,'YDir','normal')
% ^ looks like the left one

I'm attaching a ZIP with four images showing the colors of the whole shade table, for the original one, my two attempts, and the one generated by 'transpal'.

Summarizing, my formula ("attempt 2") produces a similar result to the original one for the five ramps of 32 colors each (gray, brown, blue, green, red), but doesn't work well for the remaining three ramps of 16 colors each. Using color indices whose colors are close to linearly-blended ones ("attempt 1", "transpal") produces visible artefacts, most noticeably the fact that colors "leak" into foreign ramps, such as with the brown and red ones. Note that I'm using a color index rearrangement, as documented on the wiki.

Edit: also, just in case you have missed that, I should point out that my formula makes no reference to the actual color components of particular color indices.

Attached File(s)

•  shtab_comparison.zip (92.95K)
  Number of downloads: 437

[Tea Monster]

James, on 06 March 2014 - 07:58 AM, said:

'we' he says, it's pretty much down to Plagman as far as I'm aware and I imagine he's probably very busy with life to dedicate the time to start coding in the theoretical performance enhancements.

I meant we. Plagman would be doing all the work, but In the past, I've suggested we have a kickstarter or similar so that he has more incentive to do it.

Glad its running better. I know it was a big bottleneck when the mod first came out.

[Fox]

Since we are talking about shading, why is the shading of HUD sprites different in OpenGL? Map structures are relatively similar to 8-bit, while HUD sprites are not. Most notable when you are throwing a Pipebomb, which changes from the HUD to a spawned sprite.

[Helixhorned]

DanM, on 06 March 2014 - 05:33 AM, said:

well it appears any swinging door with a custom speed bombs the FPS in polymer now, like 1-2 fps once the cache gets big enough, it's not as bad with a clear cache.

DanM, on 06 March 2014 - 08:49 AM, said:

its running pretty much fine now and better than ever, i think it could be something to do with the DNE01 map itself, (...).

edit : fixed that (...), also notice substantial increases in FPS with every floor with a translucency on it stamped out, (...).

Wait, you mean you have worked around the original issue so that it won't show up in the latest DNE any more? I was interested into looking into it, especially because the suggested causal relationship sounds so incredible. Why should a property of a game-side object such as a door have an influence on the performance of a renderer, which is part of the engine? Also, when is the cache (assuming you mean the hightile one, residing in 'textures' and 'textures.cache') "big enough"? When it approaches the gigabyte range?
Your solution seems to imply that the swinging door speed had nothing to do with it though. My guess is that when Polymer encounters a translucent ceiling or floor that does not have another sector at the other side, it sort of thinks that the rest of the map is visible through this ceiling/floor and starts loading all textures that are "visible" this way.

Fox, on 06 March 2014 - 11:09 AM, said:

Since we are talking about shading, why is the shading of HUD sprites different in OpenGL? Map structures are relatively similar to 8-bit, while HUD sprites are not. Most notable when you are throwing a Pipebomb, which changes from the HUD to a spawned sprite.

Test case + specifics? I quickly looked at the pipebomb HUD in E1L1, once while on the outside and once in a shaded sector, and didn't find any difference between either the HUD and in-world sprite, or classic and Polymost.

[Micky C]

I was thinking, maybe making floors and ceilings transparent without TROR should be restricted to expert mode? I've come across transparent floors in maps such as the Metropolitan Mayhem episode which must have accidentally had their transparency set, and which only made a difference in polymer.

[Helixhorned]

TerminX, can we resolve the paletted enemy issue? Besides changing the initial health for monsters in various user maps, it apparently greatly affects released mods. I'm quoting from a PM conversation about DNE (not sure if you want to read the whole thing). What do you think about reverting the change and making it available as a mutator?

Trooper Dan, on 07 March 2014 - 12:09 AM, said:

DanM, on 06 March 2014 - 11:46 PM, said:

(...)
btw the monster thing is an eduke32 thing that was added recently, (...).

Yeah I'm aware of it, I have posted about it myself. I'm sure it has had a big effect on the gameplay of my Attrition mod -- when it is reverted I will probably have to beef up enemies since almost all of them have pals.

[Stabs]

 Helixhorned, on 07 March 2014 - 03:57 AM, said:

TerminX, can we resolve the paletted enemy issue? Besides changing the initial health for monsters in various user maps, it apparently greatly affects released mods. I'm quoting from a PM conversation about DNE (not sure if you want to read the whole thing). What do you think about reverting the change and making it available as a mutator?

yeah kinda throws off the balance when dukeplus monster with extra health via DP's system combined with this new PAL/HEALTH system is causing EDF pigs to take 3 x point blank double barrrel shots, that technicaly is 6 shells for one pigcop its really throwing of the balance iam noticing my balance going way off with this and ammo supply issues are arising

basically 99% think only a pal 21 trooper should be more powerful and thats it, whats the time between 1.3d maps and pluto maps, i'd have to say a far larger ammount are pluto only which had none of this extra health pal business

i can even remember an instance while polishing DNE for the new patch that a pigcop wouldn't die in far away land which made a script flow correctly purely becuase the pigcop was a pal 23 monster and the shooter couldn't cause enough damage to kill it, ruining the script

[Helixhorned]

For those who don't follow EDuke32 SVN obsessive-compulsively, in r4366

TerminX said:

Make non-pal 0 enemy health doubling depend on running 1.3D or earlier

That is, all non-pal-0 enemies in the following list will get their strength doubled only if running 1.3D:

Spoiler

        case OCTABRAINSTAYPUT__STATIC:
        case LIZTROOPSTAYPUT__STATIC:
        case PIGCOPSTAYPUT__STATIC:
        case LIZMANSTAYPUT__STATIC:
        case BOSS1STAYPUT__STATIC:
        case PIGCOPDIVE__STATIC:
        case COMMANDERSTAYPUT__STATIC:
        case BOSS4STAYPUT__STATIC:
            actor[i].actorstayput = sp->sectnum;
        case BOSS1__STATIC:
        case BOSS2__STATIC:
        case BOSS3__STATIC:
        case BOSS4__STATIC:
        case ROTATEGUN__STATIC:
        case GREENSLIME__STATIC:
            if (sp->picnum == GREENSLIME)
                sp->extra = 1;
        case DRONE__STATIC:
        case LIZTROOPONTOILET__STATIC:
        case LIZTROOPJUSTSIT__STATIC:
        case LIZTROOPSHOOT__STATIC:
        case LIZTROOPJETPACK__STATIC:
        case LIZTROOPDUCKING__STATIC:
        case LIZTROOPRUNNING__STATIC:
        case LIZTROOP__STATIC:
        case OCTABRAIN__STATIC:
        case COMMANDER__STATIC:
        case PIGCOP__STATIC:
        case LIZMAN__STATIC:
        case LIZMANSPITTING__STATIC:
        case LIZMANFEEDING__STATIC:
        case LIZMANJUMP__STATIC:
        case ORGANTIC__STATIC:
        case RAT__STATIC:
        case SHARK__STATIC:

(Yes, non-default-color slimers will be twice as strong too, which probably won't have any impact at all though. The bosses have their strength overridden from CON, IIRC.)

I think the majority of users can agree with this definition.

[Fox]

 Helixhorned, on 07 March 2014 - 03:42 AM, said:

Test case + specifics? I quickly looked at the pipebomb HUD in E1L1, once while on the outside and once in a shaded sector, and didn't find any difference between either the HUD and in-world sprite, or classic and Polymost.

Color me stupid, I forgot to mention it's with highres tiles.

[Stabs]

so i maybe have made some kind of break through with polymer performance it seems for some unknown reason mask / translucency can be pasted into textures that dont even need it causing PNG issues and FPS issues . simple removing 3 of them from one level took out a huge stutter at the start of the level.

maybe there should be a check for version of maps before TROR for certain sector flags and resave them all without containing these flags, the performance increase is undeniable, polymer seems to be fine its just when sectors sneak in with funny flags that seem to be the problem

[Jblade]

Will there be blend support for masked walls at some point? I've got some cool texture effects that could benefit from it

[Helixhorned]

r4368 now has a wall 'blend' in the Lunatic build. The editor support is very rudimentary: currently, you have no option to save a map-text map, and you'll have to set wall[].blend by typing Lua code into the console, like this:

lua "wall[242].blend=255"

There are no plans for wall[].blend in the non-Lunatic build, as V7's walltype doesn't have a 'filler' member like the sprite did.

[Fox]

If wall doesn't have a filler member, I don't think it was a good idea to use the sprite filler for blending in the first place since it's only partially acessible.

Instead the alpha member should be added in CON for walls, floors and ceilings. Plus alpha would support blending by shifting left the value by 8.

This is my personal oppinion, but I think it's consistent and logical.

[Stabs]

I know i put it before in another thread but this is very serious

Iam really not joking about these masked floor sector tags that came from nowhere guys

I think when tab copy/paste its not checking if you say took properties of a mask wall / or a transparent sprite and pasting funny flags onto sectors, causing them to make PNG's display glicthes on any floor with the mask flag even though it has nothing to do with TROR, i've found floors affected by this bug in maps since DNE's first release 2 years ago, I am assuming all these weird flags where the cause of a lot of FPS issues when polymer was turned on and i guarantee any polymer map that has a script run over it that corrects the sectors flags would make a lot of polymer based maps run a stack faster. Literally removing even small numbers of these glitches increases the FPS hugely

naturally its going to have to have checks for if the "e" large/small bit was on and relativity and if its NOT tror based but i really need a script that gives sectors its proper flags

[Stabs]

fix guys thanks to hendricks

http://forums.duke4....post__p__189465

copy that text to a file name

mapfix.m32

and once in mapster drop the console and type

do state FixPolymerFC

we never needed to optimize polymer guys it was fine! i think it was these flags

[Jblade]

People keep saying 'we', it's Plagman who's done all the hard work on Polymer. I've tried that script and got no increases on performance so maybe you should calm down a bit before saying there was never a problem in the first place.

[Stabs]

I don't care script or not, you find these sectors and nail them I've noticed huge stutters at the start of levels go away and just general levels of performance has increased with each sector fixed and its been happening for a very long time, maps i haven't touched in years show up these mask floor glitches now, PNGs look like shit on them.

K think of it this way, say one floor that is not TROR has the mask flag, behind that floor/ceiling its rendering the whole fucking level, it why i could turn 30 degrees and get 2 fps vs 60 fps
masking still renders shit behind it whether you can see it or not, how else could monsters know how to fire at you from behind a masked wall?

[Jblade]

But the majority of people don't make their floors masked though dude? I mean I don't want to rain on your parade too much but Plagman is a Nvidia engineer, if it was that simple he would of fixed it a long time ago. There's no silver bullet solution when it comes to optimisations, it's a case of knuckling down and having to do a bunch of hard, tedius work.

[Stabs]

I know man, i never intentionally made all these floors masked or transparent, it didn't even exist in DNE's dev schedule

my theory is that masked walls flags and / or transparency on sprites that gets copied via TAB is pasting into sectors making weird sector flags

[Micky C]

James, on 13 March 2014 - 01:46 AM, said:

But the majority of people don't make their floors masked though dude?

It's not too hard to set transparency on floors/ceiling accidentally. Perhaps you're not aiming quite right when you hit the t button, or perhaps the t button was randomly pressed without you knowing it, and since the sector would look the same, you'd think nothing happened.

[Jblade]

Can't say I've ever done that, but I normally take my time when mapping. If you're not too sure than it can't hurt to run that script.

[Stabs]

a good way to detect these sectors is to make a mask wall over a large area and make it transparent, the glitches will instantly show themselves.

[Fox]

Interesting, Lunatic executable has the glitch of monsters walking on submersible (lo-tag 1) sectors fixed.

[Fox]

The code I use to get the name of a specific level:

    getuserdef .volume_number TEMP
    getuserdef .level_number TEMP2
    setuserdef .volume_number NEXTVOLUME
    setuserdef .level_number NEXTLEVEL
    qgetsysstr 255 STR_MAPNAME
    setuserdef .volume_number TEMP
    setuserdef .level_number TEMP2

The problem is, if the level has not been defined with definelevelname, the program abruptly ends... although I understand where the error is coming from, I don't like a code like that having the power to ends the program like that. Is it possible to make qgetsysstr write a blank quote if the level is not defined, or at least make it possible to check if a level has been defined?

[Helixhorned]

Fox, on 15 March 2014 - 10:28 AM, said:

Interesting, Lunatic executable has the glitch of monsters walking on submersible (lo-tag 1) sectors fixed.

Thanks for reporting this. Actually, it was a bug in the Lunatic build, but it exposed why the glitch was happening. It's fixed with r4378.

[Helixhorned]

Fox, on 15 March 2014 - 02:12 PM, said:

The code I use to get the name of a specific level:

    getuserdef .volume_number TEMP
    getuserdef .level_number TEMP2
    setuserdef .volume_number NEXTVOLUME
    setuserdef .level_number NEXTLEVEL
    qgetsysstr 255 STR_MAPNAME
    setuserdef .volume_number TEMP
    setuserdef .level_number TEMP2

The problem is, if the level has not been defined with definelevelname, the program abruptly ends... although I understand where the error is coming from, I don't like a code like that having the power to ends the program like that. Is it possible to make qgetsysstr write a blank quote if the level is not defined, or at least make it possible to check if a level has been defined?

Unfortunately, C-CON is replete with missing safety checks like these. I added these particular ones to C-CON, but more issues remain, especially in the string handling code. It's not without a reason that I'm advocating to check user CON code by running it under LunaCON. (Even better, with -Lopts=strict.)

[Stabs]

is there a way to fix the hit detection for monsters between TROR layers, particularly sloped TROR lower the ground, say the monster is at the lowest end and lowest point of the TROR slope, you basically have to shoot at their feet for hits to register, if you aim for the head it will miss.

wouldn't the monster technically have to duplicate its hitbox if under a sloped TROR layer with a certain height and just offset the duplicate to add a hitbox to the monster in the upper layer of the sloped TROR

this is apprarent to in say knee level water, where you need to go underwater to actually be able to hit the monster

[Fox]

Interesting, I didn't knew that. But yeah, the hitbox should extend to the whole set of RORs.

Speaking of TROR, sprites don't do well in 8-bit, since they are clip through walls. I have no idea how to solve that without changing the way sprites are displayed in classic...

[Kyanos]

Yeah Fox, also the top half of that sprite will disappear if you look up so that you can't "see" the water sector the sprite originates in.

The same issue with sprites or models that go horizontally outside of their sectors, nevermind TROR. Sprites and/or models only get drawn while the player can see the sector the sprite originates in.

[TerminX]

Fox, on 17 March 2014 - 07:57 AM, said:

Interesting, I didn't knew that. But yeah, the hitbox should extend to the whole set of RORs.

Speaking of TROR, sprites don't do well in 8-bit, since they are clip through walls. I have no idea how to solve that without changing the way sprites are displayed in classic...

I think the fix here for classic is to actually do something similar to the sprite mirroring done by the ROR code that uses sector effectors.