[Plagman]

I just pushed a set of Polymer fixes, and they mostly deal with issues that have been brought up in this thread; the big three items being:

• No more vanishing TROR stacks if you move/look at it the wrong way
  
• Polymer lights now propagate correctly across TROR boundaries
  
• Masked floor/ceiling will now be drawn.

Of course there are probably more bugs, so please report anything that I might have missed; if your problem has to do with translucent mask blending problems, make sure you read the changelog for r1980 to make sure it's not a known problem first:

http://dukeworld.duk...2/ChangeLog.txt

Now since the system was originally designed with Polymer in mind, that means that all cases that didn't work right with Classic/Polymost should now work OK, such as mirrors or TROR links with holes in them:

[Helixhorned]

Sweet, will be the first thing I check out tomorrow.

[Plagman]

BTW, the rotating spotlights in the first room of the TROR test map don't seem to work anymore; I don't think it was me that broke them, so it's probably something you did. Also, all game lights seem to be spotlights these days, and wielding the shrinker doesn't emit any light anymore; could this all be a side-effect of your recent light compaction change?

[Danukem]

Plagman, on 20 August 2011 - 02:12 PM, said:

Also, all game lights seem to be spotlights these days

In my test of r1982, I encountered plenty of point lights. Which lights were wrongly becoming spotlights for you? In my test there were fires and SE49 that I had spawned after the map loaded, and they worked correctly.

[Plagman]

Weird, it doesn't happen anymore; there must be a bug that can trigger and cause that to happen somehow; in my case all the shrinkray blasts were little green spotlights that shone to the side.

[Micky C]

Thank you Plagman, all of the polymer TROR bugs in my map have been fixed.

I read the changelog but all that masking talk is confusing and I'm not sure whether you talked about this occuring:

Plagman, on 20 August 2011 - 02:12 PM, said:

BTW, the rotating spotlights in the first room of the TROR test map don't seem to work anymore; I don't think it was me that broke them, so it's probably something you did. Also, all game lights seem to be spotlights these days, and wielding the shrinker doesn't emit any light anymore; could this all be a side-effect of your recent light compaction change?

Also, since when were we able to make spotlights rotate like that?
Is it also possible to make point lights follow a sector, like in a subway vehicle?

[Plagman]

Yeah, that's kind of expected right now; though it would be greatly mitigated if all the fully transparent areas of that tree had zero alpha instead of barely zero.

[Micky C]

But what about the rotating spotlights? I know this is the wrong thread, but I've always believed that SE polymer lights were fixed in position and could not move or rotate in game. Is it the case now that SE lights' positions and orientations are relative to their position and orientation within their respective sectors? Is there any kind of special tag for this?

[Plagman]

I think they're carried by most sector effects? If you look at the TROR example map, the train has two headlights that move with it. The two spotlights in the first room are also supposed to rotate with their sectors. Note that this only applies to SE lights and not maphacks.

[Micky C]

That's interesting. I remember putting a point light on a two way train once, but instead of moving with the train, it stayed where it was, and switched off when it crossed the sector boundaries. Sounds like I'll have to make a DukePlus TROR polymer map to exploit this.

[Helixhorned]

Here are my observations:

This one shows two issues at once: first, the mirror doesn't work, and second, the glass mask is supposed to be visible only from below.




This z-fighting is likely related to the second point above:



Hm, I didn't think it would look this bad.
@notPlagman: ironically, it's harder to implement the sector masks in Polymer than it is in either of the other two renderers.



---

The lights disappear when changing renderers while playing one and the same map; when playing it with Polymer from the start, everything should be fine. This is in need of cleanup.

The SE lights that are rotated with SE0/1 and carried with the subway are a proof-of-concept I committed some time ago, it's not meant to be used in production maps. All this crap really should be cleaned up and generalised, but that's something that'll hopefully happen by the time the moon comes along. (Now what could I possibly mean by this mysterious statement?)

[Micky C]

Helixhorned, on 21 August 2011 - 03:59 AM, said:

(Now what could I possibly mean by this mysterious statement?)

That SE lights following sectors will be an official feature within a month?

[Plagman]

Ohh, if masks are drawn from angles they shouldn't be then that explains why the water looked thicker than it should be. That explains the white glass around the middle shot, but not what's happening in the rotating sector. Is there any overlapping geometry going on in this part? It does seems like the bottom of the rotating platter and the top of the room share the same space.

[Hendricks266]

Helixhorned, on 21 August 2011 - 03:59 AM, said:

All this crap really should be cleaned up and generalised, but that's something that'll hopefully happen by the time the moon comes along. (Now what could I possibly mean by this mysterious statement?)

The next full moon is September 12.

[Helixhorned]

Plagman, on 21 August 2011 - 10:23 AM, said:

That explains the white glass around the middle shot, but not what's happening in the rotating sector. Is there any overlapping geometry going on in this part? It does seems like the bottom of the rotating platter and the top of the room share the same space.

It does explain it. Here's what happens when the floor of the upper portion is made to have the orange granite texture:



The bottom line is that masks may be different on each side, just as with walls, and Polymer is incorrectly drawing the other side. The sprite that shows through, on the other hand, should be made one-sided: here, the difference in implementation (multi-pass vs. masks) strikes again.

[Plagman]

Ahh. I just didn't realize that the middle part was also made of masks, hence my confusion. In this case, this should be fixed now with my latest push. It now seems to look the same as Polymost across the board. The mirror issue you posted above is unrelated to TROR, the code just doesn't like it very much when wall planes are between the viewpoint and the mirror.

And yeah, I just realized that the issue I was mentioning before with all dynamic lights turning into spotlights only happens if I toggle renderers on the TROR test map; must have something to do with the spotlights that are already in the level.

[Danukem]

Helixhorned, on 31 August 2011 - 04:48 AM, said:

DeeperThought, on 26 August 2011 - 03:29 PM, said:

I have a hack now that makes the platforms work in TROR. I want to emphasize that it is a hack, and that we still need a fix in the source code to the underlying problem.
Actually, it seems there are two problems:

Just saw this because MickyC pointed me here. I know the cause, but it's tricky to fix without affecting normal movement adversely. (Specifically, dying accidentally when too close to the floor or ceiling -- blame updatesectorz again).

If I understand you correctly, that would explain why the player has to jump to enter the extended sector above, but it wouldn't explain why normal actors can't do it just by moving up.

[Helixhorned]

DeeperThought, on 26 August 2011 - 03:29 PM, said:

I have a hack now that makes the platforms [WGR2 ones -- Helix] work in TROR. I want to emphasize that it is a hack, and that we still need a fix in the source code to the underlying problem.
Actually, it seems there are two problems:

1. Actors with upward velocity do not enter the extended sector, instead getting stuck on the ceiling of the lower sector.

2. The player does not enter the extended sector above unless he has an upward velocity (his poszv is negative).

This part is mostly for Helixhorned, I hope he sees it. The scenario is that the player is standing on the platform as a sprite bridge, and it is moving up, but the player does not have an upward velocity. The platform is moving up because I am subtracting from its z coord every tic (because of problem 1) It seems that the player does not (fully?) enter the extended sector in that case. (...)

Point 2 is fixed now. But remember that you'll never get an actor into another sector without some kind of sector updating. In your case, throwing an updatesectorz into the platform actor code should do the trick (it might then pass through blocking portals, but at least it won't get stuck). Actors like flying LIZTROOPs still need to be taken care of by me, though.
edit: On second thought, I might be a bit confused as to when automatic updating is actually appropriate. Those platforms seem to me like 'passive' actors, therefore my suggestion.

[Danukem]

Helixhorned, on 01 September 2011 - 10:46 AM, said:

Point 2 is fixed now. But remember that you'll never get an actor into another sector without some kind of sector updating. In your case, throwing an updatesectorz into the platform actor code should do the trick (it might then pass through blocking portals, but at least it won't get stuck). Actors like flying LIZTROOPs still need to be taken care of by me, though.

I have been using updatesectorz since my first attempted workaround. Here is the relevant part of the code (this code is in the rising platform actor that the player rides on).

This code is used when the platform is being forced up (subvar z 768) because it is at the ceiling. If updatesectorz was succeeding in changing the sprite to the extended sector, then the sprite would no longer be near the ceiling and it would go back to using its normal rising movement. But that's not what happens...

	getactor[THISACTOR].z z
	subvar z 768
	setactor[THISACTOR].z z
	ifvarvare player[THISACTOR].sbs THISACTOR
	{
		changespritesect THISACTOR player[THISACTOR].cursectnum 
		ifvarg player[THISACTOR].poszv -1
		setplayer[THISACTOR].poszv -512
	}
	else
	{
		updatesectorz sprite[THISACTOR].x sprite[THISACTOR].y sprite[THISACTOR].z mysector
		ifvarn mysector -1 changespritesect THISACTOR mysector else killit
	}

I'll test your revision and report back.

EDIT: I didn't realize that your revision had not appeared in synthesis yet, so I was testing the wrong one.

[Micky C]

Rotating a group of bunches with the < and > keys leads to some white walls reaching through extensions. See the pictures and the attached map for details (starting position is in problem room facing the problem).

Attached File(s)

•  TRORCBPbug.zip (214.21K)
  Number of downloads: 228

[Danukem]

An update, now that I have tested the latest revision: The player works correctly now, entering the extended sector without the need to jump. But other actors still hit the ceiling where the sectors connect, and using updatesectorz does not help. Even if I query which sector is above the sprite on the ceiling, it does not return the extended sector.

For example, let's say the sprite running this code is up against the ceiling with an open portal to an extended sector directly above it:

getactor[THISACTOR].z Z
subvar Z 2048
updatesectorz sprite[THISACTOR].x sprite[THISACTOR].y.Z mysector
ifvarn mysector -1 changespritesect THISACTOR mysector

mysector will not be the extended sector, it will be the same sector the sprite is in. It looks to me like updatesectorz is not returning the correct sector.

[Tetsuo]

I got one more dumb question about the original levels and TROR:
Is there going to be a download that you can stick into the same folder as your other polymer HRP like the maphacks or music pack and have it auto load like those or is it going to have to be a seperate map pack that you have to load up like a third party map pack? I can't imagine that would even be kosher because you could then theoretically run eDuke32 without the original levels and it would be more kosher to have it so there's a file and it loads up the differences. But I'm just guessing here.

[Helixhorned]

Micky C, on 02 September 2011 - 02:29 AM, said:

Rotating a group of bunches with the < and > keys leads to some white walls reaching through extensions. See the pictures and the attached map for details (starting position is in problem room facing the problem).

It's actually red-wall connections that are being made between a wall in a layer on one height and a sector on a totally different height, so that they share no area to look through. To fix the waterfall here, for example, go 'through' it with noclip, press BACKSPACE on the inner wall that is now at your back to clear its nextwall/nextsector field (r1998+), and drag its point again in 2D view to make a red connection -- this time the desired one.

[Micky C]

Thanks Helix!

Tetsuo, on 02 September 2011 - 01:34 PM, said:

I got one more dumb question about the original levels and TROR:
Is there going to be a download that you can stick into the same folder as your other polymer HRP like the maphacks or music pack and have it auto load like those or is it going to have to be a seperate map pack that you have to load up like a third party map pack? I can't imagine that would even be kosher because you could then theoretically run eDuke32 without the original levels and it would be more kosher to have it so there's a file and it loads up the differences. But I'm just guessing here.

The only place where ROR would really be valid is in making transparent water. Yet what will eventually happen is that polymer will be made to render water transparent so you can see the underwater sections automatically, even without ROR. An added bonus to this is that the normal map would cause visual distortion which adds to the realism.

[Tetsuo]

Not "valid" anywhere else? Are you absolutely sure about that? I mean for example in E2M1 it's a multilevel space station area and TROR would make it more seamless. Or do you consider that invalid. Also that sounds like splitting hairs because in order to make the water transparent there has to be some form of portal rendering or TROR in place. I mean logically speaking. The way the old switching between sectors thing worked it just didn't draw anything or just a solid\textured color when for example you reached the bottom of an area that then switches to another sector so if you looked down you don't see into the other sector you see the solid color\texture until you move through it and then you get switched to the other sector which is in a completely different area than the one you are in in the map not directly below it. As far as I know you just can't make the water transparent because of that... you'd just see the color of the null space beneath it. If all you needed to do is automagically make that transparent TROR wouldn't be needed in the engine at all.

But in a way you did answer my question because it seems like the answer may be that TROR or something similar is going to be hardcoded for the old maps.

[Micky C]

I see your point. But usually the places where you travel between layers like that is very narrow, so you can't really look above or below too much anyway. In any case, TROR wouldn't be the way to go because the sections are physically in different areas of the map, so if anything TX's ROR should be sufficient, if anybody ever bothered to come up with a way to patch them that is.

[Tetsuo]

Yeah although on the other hand it is a noticeable transition and with the newer mouselook you can see the solid color before transition a lot more and also you can tell from the sound as well that you are going from one completely different area in the map to another. The sound doesn't propagate through the "layers" in other words. So I was wondering about what kind of plans are in place as far as modifying and retrofitting the old maps goes. But I'm now guessing hardcoding and some kind of system similar to portal rendering going by what you said.

[Helixhorned]

Cross-posting from another thread because I think everyone should see this:

Polymost TROR is very unfinished. Basically, you should be doing all the mapping either in classic if the compatibility is desired, or in Polymer if you don't care. Hopefully I can bring Polymost to the same level of support as the software renderer, but the 'convex portal' requirement would still be there.
---

In particular, do not try to use workarounds for Polymost/TROR glitches, since they are bugs!

[Micky C]

Are some more effects going to be carried over to TROR? For example, the breakable wall glass texture be made breakable when used as a floor? And although this is a lot more unlikely, but at least possible; floor mirrors?

[Master Fibbles]

Because of how mirrors are made, wouldn't that be really complicated to make? I think Mirrors would have to be changed before floor mirrors can be made.