[Mblackwell]

It's already converting to polygons/tris. Polygons are also not the problem. It's lights and the number of separate objects (even if they have the same polygons). I'm sure there's some internal logic that gives it a bit of a penalty there and can be optimized out, and there's further optimizations that would allow for faster particles (things such as instancing).

[Stabs]

I think its how each red sector still sees through each other like a portal causing excessive render passes

[Micky C]

If you try r_pr_wireframemode you can see which sectors are visible at any one time.

[Stabs]

[Micky C]

If only there was a way to split/join sectors in 3D mode the process would be a whole lot smoother, plus it would help out in other things.

[Stabs]

ya lebuild had a brilliant slicer tool across multiple sectors, actually used once or twice to get perfect splits to stop lights leaking through multiple sectors, also great for SOS work

btw all my DNE maps are "off grid" now they don't appear to line up correctly with the squares in mapster anymore, perhaps this could be my door problem

[The Commander]

Micky C, on 19 March 2014 - 08:51 PM, said:

If you try r_pr_wireframemode you can see which sectors are visible at any one time.

I tried telling him this last week, guess he didn't.

[Mark]

Stabs, on 20 March 2014 - 12:13 AM, said:

ya lebuild had a brilliant slicer tool across multiple sectors, actually used once or twice to get perfect splits to stop lights leaking through multiple sectors, also great for SOS work

btw all my DNE maps are "off grid" now they don't appear to line up correctly with the squares in mapster anymore, perhaps this could be my door problem

When I messed with the doors I moved them to the grid. No difference.

[Stabs]

i found about normal 10+ sectors on the roof at the start with the mask flag, Iam assuming somehow those masked floors somehow came from the masked TROR floor nearby.

doors still kinda open shitty but dosn't seem to bomb itself into oblivion anymore, really need some kind of feature that can put a tint on masked floors that are not TROR, silent deadly bastards

just seems to be those 8 doors around the theater and alley that seem to be the trouble makers

[Stabs]

aha so after viewing the game through the wireframe it does triangulate everything, meaningless points make meaningless triangles in polymer, so kill them points you dont need.

Iam wondering if i could optimize my maps by triangulating larger areas to make sure all sector only ever have 3 sides, rather than have the computer decide a suboptimal method of choosing to triangulate

great stuff plagman, particularly on the moving sectors how their triangles morph between each other, like swing doors, new appreciation for your work you are a very clever man, i see what the problem with it is now too, it just renders way more than it needs too based on slight angle changes, like at some angles and positions from the street outside DNE01 it feels the need to render the bathroom with the hive in it.

[Mia Max]

Hallo Plagman.
Would something like AMDs Mantle improve the performance?
I know that you work for Nvidia.
Is Nvidia also planning to introduce something like that?
As I always prefer Nvidia GPUs, that would be great.

[Fox]

So, I noticed that PSX also uses the slide bar for loading, which looks kinda nice.



Wouldn't that be better than the current yellow bar?

[Tea Monster]

I offered a new progress bar around a while ago but nobody was interested.

[Micky C]

Mia Max, on 20 March 2014 - 10:32 PM, said:

Hallo Plagman.
Would something like AMDs Mantle improve the performance?
I know that you work for Nvidia.
Is Nvidia also planning to introduce something like that?
As I always prefer Nvidia GPUs, that would be great.

Plagman works for Valve.

[The Commander]

Both

[Helixhorned]

Tea Monster, on 21 March 2014 - 04:06 AM, said:

I offered a new progress bar around a while ago but nobody was interested.

That's not entirely correct. You offered "a progress bar, something like this" whose "[c]olours can be altered", but to me it wasn't clear what it was really about. Were you offering new code for the progress bar at level load time? As I said back then, patches are welcome. If it was about new art, EDuke32 isn't supposed to contain any "real" art except maybe for the startup windows and stuff.

[Jblade]

Is there a way to get screen resolution? It would be handy because I could code certain GUI elements to be of a reduced size on higher resolutions so they're still legible but don't take up as much screen estate

EDIT: on a different note, the latest snapshot doesn't pick up the game.con in it's directory. I'm assuming that's related to the android tweaks mentioned in the changelog.

[Helixhorned]

James, on 22 March 2014 - 03:14 AM, said:

Is there a way to get screen resolution?

You mean from scripting? It's xdim and ydim in CON.

Quote

EDIT: on a different note, the latest snapshot doesn't pick up the game.con in it's directory. I'm assuming that's related to the android tweaks mentioned in the changelog.

What is "its" directory? This works for me on Linux:

$ echo error > ~/.eduke32/game.con
$ ./eduke32
(...)
Compiling: GAME.CON (6 bytes)
GAME.CON: At top level:
GAME.CON:1: error: expected a keyword but found `error'.
Found 0 warning(s), 1 error(s).

[Jblade]

I have the eduke32.exe and the game.con in the folder C:/amc_tc and Eduke32 spits out an error saying it can't find it. I can drag and drop getting it to work fine but I didn't need to do that before the latest revision.

(Thanks for pointing out the screen res commands, I did a search on the wiki but not exhaustive enough it seems)

[Fox]

Latest snapshot (4388) is not loading EDUKE.CON, instead it says "CON file 'EDUKE.CON' missing". It's working fine with 4384.

[Helixhorned]

Try r4391. One of the preceding changes introduced a typo that led to an access out of the MAXQUOTES bound. Note how this has no apparent relationship with the produced observable issue: undefined behavior at its best .

[Helixhorned]

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.

Fox, on 08 March 2014 - 08:49 AM, said:

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

That seems merely like a perceptual glitch with the HRP pipebomb model to me. Note that it has two sides, a shiny one and a dark one. The HUD model shows it from the shiny side, but when it's thrown, it ends up with the dark side toward the player.

[Fox]

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

[Danukem]

Fox, on 22 March 2014 - 12:33 PM, said:

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

It looks like the 8-bit tiles have higher contrast.

[Fox]

That's because the shade for each color is different in 8-bit, but that's part of using "highres" textures.

My point is that the shade of HUD sprites are brighter than game sprites. While the Pipebomb of the HUD and game have the same shade in 8-bit mode, that's not the case in polymodes.

[Micky C]

In the classic renderer, textures on highly sloped surfaces at a distance become warped and fullbright. The warping is obviously a limitation of the renderer, but is there anything that can be done about the fullbright? I mean I have sectors whose textures only become warped at such a large distance that it'd be much better for them to be pitch black when this happens.

[Helixhorned]

Fox, on 22 March 2014 - 12:33 PM, said:

There is a noticeable difference beetween the shading of HUD sprites and game sprites if not using 8-bit tiles.

First, let's not conflate terminology here. You're using "8-bit tiles" in both cases. Sure, in the OpenGL modes, they're uploaded as RGB textures, but it's certainly inappropriate to start calling them "highres" just because of that. Second, it's important to specify the exact renderer settings you're running with. I had to experiment a bit and it looks like you're running either Polymost with r_usetileshades 0, or Polymer with r_pr_artmapping 0. And most likely, therein lies the problem.

In the classic renderer, shading it done via lookup into a table, as described in some detail in the Lunatic manual. Take a look at the second "ramp" of colors with indices 32-63, which is used for skin and note that the yellow (perceptually most significant) and blue components have a convex shape. Thus, at higher shades, they are darker than the linear blending with black. But linear blending is exactly what the "original" GL modes do.

[Fox]

Alright, I will try to make a appropriate report:

Classic mode:



Polymost (r_usetileshades 0)



Polymer (r_pr_artmapping 0)

Attached File(s)

•  hudshade.zip (242bytes)
  Number of downloads: 321

[TerminX]

You need to set those vars to 1 to get it to look similar...

[Helixhorned]

OK, I see it now -- the shades also differ in the GL modes with table lookup.

Edit: even with having full visibility in the sector.
Edit 2: the shades also differ in classic. Take a very close look at the exact pixel values!
Edit 3: see r4392