[Helixhorned]

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

Speaking of TROR, sprites don't do well in 8-bit, since they are clip through walls.

TerminX, on 17 March 2014 - 12:24 PM, said:

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.

Actually, the classic TROR code duplicates tsprites that cross a bunch into the neighboring sector, if that's what you're referring to. Otherwise, the portion in the "other" sector wouldn't even be shown.

In Fox's screenshot there are two separate issues at work. First, that too much of the cactus is drawn to its left. This is not related to TROR, see this shot:


Second, the triangular portion that is wrongly not drawn. This is a consequence of the horizontal clipping boundary due to the upper sector's floor. It also shows that the tsprite gets split up: the lower portion is only drawn where there are water pixels.

[TerminX]

Shit, I couldn't even see the lower portion here due to monitor settings and room lighting. Now I feel like an idiot... or at least blind.

[Stabs]

So plagman is your grand plan for polymer to have it render a map file as massive 3d model instead of seeing it as sectors / vector which are more intensive, so basically a map has max of 16000+ walls so converted to a model that only 16000 surface which is a stack easy to render?

your problem right is it would have to triangulate / the level and have clipping issues ( fall through the map ) , and with all the weird shapes sectors it would be very hard to make its logic make the lest amount of triangles from one shape, like a carve in a hammer editor makes a wall 10 surfaces instead of 6.

also is there a shape polymer likes most, should i try be mostly trying to triangulate sectors in a way?

[Fox]

Getting rid of the Build map format is probably the best case of "it would be better to start using another engine".

[The Commander]

I don't understand what Stabs says any more...

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