[Danukem]

Well, for whatever reason, your map runs like shit for me.

I don't know why, but even DNE runs better.

[Supertanker]

More polygons = more badder?

Think about it. A cube the player can walk around in has six polygons (twelve triangles). Maybe draw four sectors sharing a red line with the cube walls--twenty polygons (forty triangles).

Not too bad. Extend the center ceiling upwards. Whoops, you've just added five polygons (ten more triangles), not sure if the surface between counts or doesn't count. Extend upwards again and make four new red-line sectors for ledges--add four more polygons (eight triangles) for the center (subtracting the ceiling, which is a transition) and add another twenty polygons (forty triangles).

You've gone from fifty-two triangles for the basic box-with-four-sectors-around-it to one-hundred-and-ten by adding two layers and forming a ledge.

(e.g., from the side it looks like:)


-----------------------------------------------------------------------
|
| player can go here
|------------------------------------------------- - - - - -tror boundary - - - -
|
|
|------------------------------------------------- - - - - -tror boundary - - - -
|
| player can go here too
|
-----------------------------------------------------------------------


Parkade has four layers, doesn't it? That's a lot of extra polygons (Not a LOT a lot, but consider for a really complicated room...) And it's not nearly as simple as this. I suspect that anything that "grows" out of a floor or ceiling subdivides the map mesh something horrible. I know some maps have insane architecture and Polymer performs fine, but I'd be very curious to see what the polycount on parkade is compared to, I don't know, bobsp1.

EDIT: As someone who used to make Tremulous/Quake III maps I'm thinking that visibility makes a HUGE difference. I don't know how eduke32 culls polygons but I am imagining it's more accurate than Quake III (considering how dnclip lags the map so when the whole thing is visible). However, a wide-open map like Parkade is going to have a lot of polygons visible *at once* which may be part of the problem.

[Micky C]

What you described is kind of hard to follow, but I think it's worth mentioning that you can extend any number of sectors either up or down, and the extension itself will only be 1 sector. If there's an island in the middle, then it's two sectors. So 4 layers would only make 8 sectors in this simple case. I'm not sure whether or not triangles are relevant to the rendering speed. I mean walls, sectors and sprites definitely count for something.

If the game is boarderline playable then entering

r_pr_lighting 0

in the console to remove all polymer lights gives a noticeable fps boost.

[Hendricks266]

Before I started playing the map I fired up parkade.ogg and I instantly recognized it.

Jun Senoue - Cooperation ...for Cannon's Core ver.2
Sonic Adventure 2
from the level Cannon's Core, parts 3 (Rouge) and 4 (Knuckles)

[Supertanker]

Micky C, on 09 January 2012 - 10:59 PM, said:

What you described is kind of hard to follow, but I think it's worth mentioning that you can extend any number of sectors either up or down, and the extension itself will only be 1 sector. If there's an island in the middle, then it's two sectors. So 4 layers would only make 8 sectors in this simple case. I'm not sure whether or not triangles are relevant to the rendering speed. I mean walls, sectors and sprites definitely count for something.

If the game is boarderline playable then entering

r_pr_lighting 0

in the console to remove all polymer lights gives a noticeable fps boost.

Basically, a wall is a polygon. So is a floor. And a ceiling. I think that everything is represented with triangles, so a wall would be two triangles, etc. So each sector MUST have at least two polygons (floor, ceiling) or four triangles and up to six polygons/twelve triangles. Counting white walls only, of course. Red walls only subdivide the floor and ceiling and any white walls they touch.

So when you add the four sectors around the first sector you're adding three walls apiece (whoops, math error) minus the four walls you "knocked out", so eight walls plus four ceilings/floors = 12 polygons * 2 = 24 triangles. When you extend upwards (making four white walls for the outer edges of the ledges) you're adding four walls = eight more triangles. Then you're duplicating the first count again for the top of the ledge. I'm probably way off base. All I'm saying is; I THINK the engine goes by SURFACES (white walls and floors and ceilings) but surfaces CAN BE subdivided by white walls and boundaries. I don't know. I'm tired.

[Plagman]

TROR was specifically designed for Polymer; my idea to have physically contiguous sectors (as opposed to all the other ROR approaches so far) was exactly for that reason; it allows Polymer to walk TROR boundaries just like any other sector boundary, without another rendering pass. It shouldn't incur a specific performance hit in this case, but bugs are certainly possible. Is there a specific area in the map that's causing problems? I should probably take a look.

[Forge]

Micky C, on 09 January 2012 - 06:09 PM, said:

Mikko didn't do the bed thing? Now I'm really glad he didn't give it a score! That had never been done before, and so would have required the player to give it an extra few seconds of thinking rather than "ooo a crack; I'll blow it up". And when the player finally does use explosives on the bed, the room transforms from a pretty darn ordinary bedroom into a room with a massive gaping hole in the floor where the bed used to be, all without the use of sprites (except to hide the visual glitches). Btw Paul the bed wasn't laced with dynamite, the message was innuendo.

I knew about both exploits Mikko mentioned. There are also other windows the player can duck-clip through. I also know where the player can get squished at the map border. (now maybe a few things I mentioned in the review might make more sense)

[Micky C]

Well that's a bummer, I never came across any of those issues on any of my playthroughs, and I'm guessing neither did Paul. Although your review suggests that these things are hard to come across unless you're actually looking for them, which is something at least. Given the non-linearity of the map, it doesn't really bother me too much if people can exploit the map in some ways (unless they end up missing some nice effects, but even then it's their loss). Afterall, part of the fun is seeing how far off the beaten track you can get and still arrive at your destination.

[Mikko]

Paul B, on 09 January 2012 - 05:00 PM, said:

In the closet you'll find pipe bombs and a message that says the bed is laced with TNT. Drop a pipe bomb on the bed to blow up the bed and lower yourself down into that room where the red key card is.

Lol, for some reason I had read the message as "dynamite in the red". This happened during both playthroughs even though I now clearly see it saying "bed". So I kept trying to find something red that I'd have to blow up (including the room on fire, where I tried to toss a few bombs).

Paul B, on 09 January 2012 - 05:50 PM, said:

Therefore this map has once again been changed to prevent Mikko from cheating when trying to get the red key card from the East building. Shame on you! =)

Well, technically what I did was not cheating. I even entertained the possibility that you intended the player to push the button through the tiny opening on the right side of the door.

[Mikko]

Micky C, on 10 January 2012 - 04:03 AM, said:

Well that's a bummer, I never came across any of those issues on any of my playthroughs, and I'm guessing neither did Paul. Although your review suggests that these things are hard to come across unless you're actually looking for them, which is something at least. Given the non-linearity of the map, it doesn't really bother me too much if people can exploit the map in some ways (unless they end up missing some nice effects, but even then it's their loss). Afterall, part of the fun is seeing how far off the beaten track you can get and still arrive at your destination.

Yeah, I wouldn't worry about minor glitches. Speedrunners are bound to find a billion of these from any map.

[Forge]

Mikko_Sandt, on 10 January 2012 - 05:23 AM, said:

Yeah, I wouldn't worry about minor glitches. Speedrunners are bound to find a billion of these from any map.

this

[Paul B]

Plagman, on 10 January 2012 - 12:14 AM, said:

TROR was specifically designed for Polymer; my idea to have physically contiguous sectors (as opposed to all the other ROR approaches so far) was exactly for that reason; it allows Polymer to walk TROR boundaries just like any other sector boundary, without another rendering pass. It shouldn't incur a specific performance hit in this case, but bugs are certainly possible. Is there a specific area in the map that's causing problems? I should probably take a look.

I think the only people that are complaining about the maps performance are those on dial up internet connections and running a 10 year old computer with an ATI video card.. I mean seriously is there any other type of graphics card besides Nividia? I think not! Just another reason to not run ATI. The actual map size is under 1 mb. The sound file is what basically adds overhead to the download. I guess we should have given the people the choice whether to play the map with music or without. I actually prefer it without music as the ambient sounds in the map provide enough of an atmosphere why have an annoyingly repetitive looping sound track? But that's just my opinion. I can always just post the map and readme file in a separate download for those interested in just playing the map too. Maybe with the sound track removed it will improve your FPS and you can actually run the map as it was intended to be run using Polymer.. =)

[Danukem]

Paul B, on 11 January 2012 - 01:29 PM, said:

I think the only people that are complaining about the maps performance are those on dial up internet connections and running a 10 year old computer with an ATI video card.. I mean seriously is there any other type of graphics card besides Nividia? I think not! Just another reason to not run ATI. The actual map size is under 1 mb. The sound file is what basically adds overhead to the download. I guess we should have given the people the choice whether to play the map with music or without. I actually prefer it without music as the ambient sounds in the map provide enough of an atmosphere why have an annoyingly repetitive looping sound track? But that's just my opinion. I can always just post the map and readme file in a separate download for those interested in just playing the map too. Maybe with the sound track removed it will improve your FPS and you can actually run the map as it was intended to be run using Polymer.. =)

I'm sure that post was 95%-100% joking, but just in case here are my specs:

GeForce GTS 450 with latest driver
Athlon II x2 at 3.3 GHz
4 GB RAM

Also I was not using the HRP and was not using the ogg. I was getting no more than 30 fps most of the time, and it would frequently drop below 10 and often hitch when any kind of action was going on. Granted my rig is not great, but it is good enough to run most modern games with no problems.

[Paul B]

[quote name='DeeperThought' timestamp='1326321785' post='116350']
I'm sure that post was 95%-100% joking, but just in case here are my specs:

Yea... I'm just trying to ruffle Mikko's feathers.

[Helixhorned]

I had a great time with this map since the initial release, but not the way you'd think... because it disregards the maxim "fps is god", it's awesomely suited for debugging/profiling/stress-testing the hell out of EDuke32. That said, what follows is mostly aimed at Plagman.

There's one observation that I find especially peculiar, and it has to do with the hitching that DT also mentioned (which may be worse that merely constantly low FPS, since it interrupts the flow of things).

Two causes of that hitching are hightiles loading and shaders compiling at runtime, and well known. With Parkade, I'm seeing a third symptom but can't get behind it because it's transient: when passing through door frames, one or more frames need a very long time to draw (in the order of one second). For me, it happens every time I pass the masked door behind the first crack you have to blow up. Standing still inside the door frame makes nothing extraordinary happen, but the wireframe view looks very different then. This all is without any of the advanced Polymer features (lighting, normal mapping, ...) enabled and reflects only the performance of drawing the main geometry.

I couldn't find your post about what you consider the main Polymer bottlenecks, but it seems to me that there may be an inefficiency in something very basic. Another thing I find strange in that respect is that DoomCity, a map released in 1998, runs very slowly in the outside areas -- on my brother's AMD/ATI system, though (which I "hijacked" for testing EDuke32 ).

[Paul B]

Helixhorned, on 12 January 2012 - 02:15 PM, said:

I'm seeing a third symptom but can't get behind it because it's transient: when passing through door frames, one or more frames need a very long time to draw (in the order of one second). For me, it happens every time I pass the masked door behind the first crack you have to blow up. Standing still inside the door frame makes nothing extraordinary happen, but the wireframe view looks very different then.

Hi Helix, Thanks for your reply I was patiently waiting to hear what you'd have to say and funny you should mention that lag when passing through doors. I noticed that too and its quite obvious... enough to totally throw a player off in a completely different direction. I just didn't know how to explain what was happening or why it was happening because it didn't seem like it should have any impact on the graphic performance at all.

Thanks for taking the time to play test it and comment. =) Hopefully Plagman can identifiy some of these mysteries.

[Hendricks266]

Helixhorned, on 12 January 2012 - 02:15 PM, said:

when passing through door frames, one or more frames need a very long time to draw (in the order of one second).

I get this all the time when turning corners in any map.

[Plagman]

I'll bet it's because the engine thinks it's null-space for a split second; that triggers the external view code, which draws _everything_ in the map in the same frame. That will be very slow and run without any hidden surface removal, and can potentially load previously unseen textures as well (not if precaching works right).

[Paul B]

Plagman, on 12 January 2012 - 08:05 PM, said:

I'll bet it's because the engine thinks it's null-space for a split second; that triggers the external view code, which draws _everything_ in the map in the same frame. That will be very slow and run without any hidden surface removal, and can potentially load previously unseen textures as well (not if precaching works right).

So in english does that mean its fixable?

[Danukem]

Paul B, on 12 January 2012 - 08:47 PM, said:

So in english does that mean its fixable?

If Plagman's hunch is correct, then that particular cause of hitching is fixable, and is not even a renderer bug per se. Someone would need to make sure that the player is correctly assigned a sector at all times, and is never wrongly considered to be in null space, even if on the border between small sectors or whatever is causing the mistake.

[Plagman]

Yeah; even if the logic that ends up making the engine think it's in null-space is tricky to fix because of limitations, I can either optimize the external view code to not draw everything or just remove it altogether outside of the editor, which would mean a black flash instead or something like that (but no hitching). I'm guessing black flash is probably what other renderers do, but I'm not sure.

[Hendricks266]

Plagman, on 12 January 2012 - 10:38 PM, said:

I can either optimize the external view code to not draw everything or just remove it altogether outside of the editor

I vote for making the code controlled by a cvar, disabled by default.

[Forge]

Plagman, on 12 January 2012 - 10:38 PM, said:

Yeah; even if the logic that ends up making the engine think it's in null-space is tricky to fix because of limitations, I can either optimize the external view code to not draw everything or just remove it altogether outside of the editor, which would mean a black flash instead or something like that (but no hitching). I'm guessing black flash is probably what other renderers do, but I'm not sure.

If I'm on the same page as everyone else, this hitch or flash occasionally happens in software mode when entering new rooms. it's over in a split second, but it looks like the screen flashes from 256 bit color to 8 bit color

[Gambini]

Quote

it looks like the screen flashes from 256 bit color to 8 bit color

That´s one hell of a video card you must have to display 256 bit colors!!!

[Forge]

Gambini, on 13 January 2012 - 04:37 PM, said:

That´s one hell of a video card you must have to display 256 bit colors!!!

ha! i meant 256 colors to 8 colors (kinda like your video card maxed - which would explain this comment:

Gambini said:

In my defence i have to say that she didn´t look that young. Also, i was sure it was a bear and not a dog (which would explain the size proportion).

[The Commander]

Lol

[Gambini]

Gave this map a go. It is not bad, and as a standard Duke map it performs well. But i don´t think it is a good broadcast for TROR. While playing it I had the feeling most things could look similar or better (better in the sense of keeping things easier) by merely using spritework. Latest Loke´s little map takes more advantage of the feature, there are arches and roofwork that makes you think "wow! we reached a new milestone" but here it feels overused, like in tables and trucks (where unneeded) and not applied where it should be, like bridges, roofwork or other things not doable in the usual way. Still, i have to say that, unlike most people, I didn´t find too many performance problems.

If you allow me to give you an advice, guys: Check your scales when mapping, most doors was about the same width than height and that´s not right. Real doors are usually 0.80 x 2 meters but it is granted to make them equally bigger in games to allow players get by freely.

[Micky C]

You could also argue that a lot of the TROR was done in such a way that most people wouldn't even notice it, which is a good thing IMO. I mean when how often in the past were people able to make "ordinary four story buildings"? It's true that things like tables could easily be done with sprites, but when I made those, I wanted to show what can be achieved at the basic level, and perhaps myself or someone else will take the concept and do it in a stunning and funky way that could never be achieved with sprites. The map has a good mix of subtle and in-your-face TROR.

As a sidenote, the catwalks to the parkade were originaly sector based using TROR, but we changed them to sprites for several reasons. They would have looked similar to the ones after the yellow keycard going to the north building near the end of the map.

[High Treason]

I finally decided to check out the releases (I'd left releases alone because there are too many uninspired and backwards TC's coming out....) and downloaded this, I was unable to play it, even with the latest EDuke32 the whole thing just bugs out for me - but this could be a good thing, as far as I am concerned, TROR is too limited anyway, but I could never get it to work properly as it resulted in these problems and I simply assumed I was doing something wrong... Apparently it was just TROR not liking something with my setup.

Still, from what I could see, my framerate was fine, even with Polymer and the HRP I found it perfectly acceptable, and my computer will be 7 years old in March. As a result of the glitches though I am not going to state any opinions on the map other than I like to see people "doing something different or new" so I take my hat off to you on that one.

[Paul B]

WOW! Thanks Helix!!! What ever you have done to the new EDUKE I'm getting 350fps to 400 fps constantly... The game is smooth from room to room its great! What a massive improvement!