Sector_SetPortal - How to?

[Tormentor667]

Sorry, I seem to be too dumb to use it, the wiki explanation isn't very helpful either so how do I set up a floor/ceiling interactive portal through http://zdoom.org/wiki/Sector_SetPortal ?

[Graf Zahl]

What precisely is your problem. Most impotantly, have you used this to create a purely visual portal?
It's basically the same, you only have to use type 6 instead of 0, and you have to create a second portal for the opposite direction.

[Tormentor667]

The problem is that I don't even seem to be able to generate a normal portal that works

[Graf Zahl]

It works mostly the same as the portal things. But instead of linking two mapthings you are linking two lines, so one portal can span multiple sectors, because this is done with sector tags. The only thing that is different is that line-based portals are always one-way so in order to do a two-way portal you have to make two portals - one for each direction.

So, you set the origin of the portal with Sector_SetPortal(tag, 6 /* for interactive */, 1 /* for ceiling */, 0, 0) and the anchor (the part which can be seen through the portal) with )Sector_SetPortal(tag, 6, 1, 1, 0). For the backwards portal you have to do the same on some other pair of lines but change 1/* for ceiling*/ with 0/*for floor*/.

With multiple sector tags there shouldn't be any need anymore to use the 'copy portal' type at all.

[Tormentor667]

First of all, thanks for the explanation, I think I got it working now for C3M3. Unfortunately though I get crashes when travelling through the portals, but I am not sure if I set it up in a wrong way or if it is a GZDoom bug. I attached the crash report though in this thread.

If you have some time left, you might take a look on your own, it's C3M3 of Blade of Agony, the player start is directly next to the portal that leads into the cellar. I know that an "example map" might be more useful (and less data to download) but mybe you can take a look at the actual map in question anyway.

[Graf Zahl]

Can you make a version of the map with most of the other houses removed? It's just too slow for debugging. The crash occurs when a TracerSpark gets spawned at the portal boundary. What precisely happens I haven't found yet. I'll have to debug the actual shot for that but I need something that doesn't devolve into a slideshow for that.

There also seems to be another problem where it is not possible to step up out of the portal onto the upper floor.

Aside from that, you'll have to rethink this map a bit. It just gets too slow because there's no one-sided lines anywhere. 3D floors cannot be used for visibility clipping.

[Tormentor667]

Thanks for the feedback, I attached a small snippet of the map with the corresponding portal part, I hope you can work with that easier.

Concerning the performance: I already feared and/or expected this, even though I don't know what's causing the slowdown for most of the people. It runs smoothly for me and I also made sure to reduce the amount of visible sectors and details to a very low amount, but it most propably didn't help much. Travelling through the portal should at least increase the framerate as soon as entering it, doesn't it?

[Graf Zahl]

Thanks for the feedback, I attached a small snippet of the map with the corresponding portal part, I hope you can work with that easier.

Concerning the performance: I already feared and/or expected this, even though I don't know what's causing the slowdown for most of the people.

Too many sectors to draw. The only thing that really blocks processing of farther away parts is one-sided walls or closed doors. This map is nearly one large open area.

It runs smoothly for me and I also made sure to reduce the amount of visible sectors and details to a very low amount, but it most propably didn't help much.
Travelling through the portal should at least increase the framerate as soon as entering it, doesn't it?

Yes, when I go through the portal it gets better.

[Tormentor667]

Too many sectors to draw. The only thing that really blocks processing of farther away parts is one-sided walls or closed doors. This map is nearly one large open area.

Is it only sectors or also lines? I am currently reducing the amoung of sectors by removing stuff that can't bee seen anyway, but it's hard to track the performance if it is already running smoothly.

[Graf Zahl]

Lines are more costly, especially if many contain 3D floors.

If you need some info, type 'stat rendertimes' in the console. That prints a lot of numbers that tell you where most time is spent.

[Graf Zahl]

The crash will be fixed in the next devbuild. This was a really nasty one, this map was so good at triggering it because it was causing frequent garbage collections.

I still need to fix the problem with stepping out of the portal.

[Tormentor667]

Thanks for fixing the crash, concerning "stat rendertimes", is there an explanation what they mean? For a non-programmer it's hard to understand what the numbers stand for

[Graf Zahl]

What's important for you is the numbers behind 'W', 'F' and 'S'. These are different parts of wall, flat and sprite processing in milliseconds. They won't tell you precisely what kind of optimization may be useful but they can give you a hint what part is worth optimizing. For example, if the majority of time is spent processing walls there is no point optimizing sprites.

Of course in C3M3 the main problem is that there is nothing view blocking plus a skybox that really pushes the graphics hardware. I'm afraid but I really have no good idea what to do with that map. It's just the worst case scenario imaginable for the Doom engine.

The worst part of it is the multiple portal recursions that occur with the skybox. You essentially have the main skybox with the castle silhouette which in turn has both a horizon and the regular skybox. This means you have a portal which in turn contains two other portals, meaning that they create some bad stalls on each other and prevent any kind of rendering optimization.

If you only have one portal inside another, they can be handled without creating a stencil, meaning it's a lot faster.

One thing worth trying to achieve this might be to get rid of the horizon parts, especially the one inside the skybox with the castle. Although horizons by themselves are not that bad, in this case, where portals are already a factor, eliminating them might actually help a bit. It doesn't look like these parts are really visible during gameplay so just having the map end at the boundaries and make the outer part a pure sky sector (floor and ceiling) would reduce the portal load quite a bit.

[Tormentor667]

Thanks for the explanation. I took the time to do various screenshots through the path of the map and I think the main problem is the city area with the wide open space. This is where the numbers for 'W', 'F' and 'S' has been the highest.

Screenshots: http://imgur.com/a/HB7fu

I got situations where W and S reached 2.000 and I think that's a bad sign. It still ran smoothly for me but I can imagine that other computers might have problems with these areas. If I understood it correctly, the main goal for me now is - if it is not possible to add blocking lines - that I need to reduce the amount of visible sprites and visible walls (where sprites most propably also take models into account, is that right?). What valua for both would be fine? In good places I get something aorund 0.200, but I doubt that this will be possible without drastically changing the way the map works and looks. In C2M3 (the map with the curch tower and the 3dfloor houses) I also got values around 1.800 for W and S and afaik, this was fine so far.

Other than that: Is there any chance of engine-optimizations that might reduce the lag engine-wise?

BTW, I did the skybox thing but didn't notice any improvements.

[Graf Zahl]

Other than that: Is there any chance of engine-optimizations that might reduce the lag engine-wise?

Probably not. To a large degree this map is GPU-limited which you can see at the high values for 'Portals' and 'Finish'. The only thing that can increase these would be a better graphics card.
What's your system specs anyway?


I think the single biggest problem is this:

Thing #10726: 1512x (That's RandomRye, so yes the corn fields in the eastern part of the map)

Is there any way you can replace these sprites with linedefs that contain multiple plants? It may not look quite that well but it'd mean a significant reduction of data processing. The way I see it these 4 fields can make up 20% of the entire frame processing time in some situations.

Another idea: The part between those 4 corn fields and the main part of the town is completely empty (except for that huge boulder - I hope that's not important... ) This is the perfect spot for something view blocking to be put in, it'd separate two of the most heavily detailed parts of the map - even better if you could extend this beyond the windmill. And if you sacrifice a few houses on the other side of town, doing something similar there as well. I think it might just be enough to solve the problems.