[Danukem]

Helixhorned, on 05 November 2012 - 04:48 AM, said:

Yes,
height = 4*tilesizy[sprite[i].picnum]*sprite[i].yrepeat,
but I think the tilesiz* arrays are still inaccessible from CON. In case you don't need to be it tile-generic, you could just substitute the known y size value, of course.

Right, I asked because there are effects that need to work for any tile in the game of any size. If it was just a few tiles I could do it manually.

[TerminX]

The access could be pretty easily added to CONs, just need some stuff merged into the EDuke32 CON system from the Mapster32 system.

[Diaz]

How feasible would it be to make point lights have the ability to project textures too?

I'm not talking about short-term, but maybe at some point in the future.

I think of it as a very powerful tool. In fact Doom 3 lights were almost exclusively point lights with texture projections, but they were cubic instead of spherical. They could make them project a sphere anyways...

[Mblackwell]

Yeah a cube-map projection would be rather nice.

[Plagman]

That's definitely planned, along with shadows.

[Diaz]

Great! I'm guessing once Polymer is optimized we will have more room to play with shadows, and it will be nice to have them on point lights too

[Diaz]

While working with several shadow-casting spotlights on a map, I've noticed r_pr_shadowcount doesn't affect the number of shadows in the scene, but rather the number of shadows in the whole map; at least in the ones that are in the direction the player is facing, even if they're not visible. I've got an area surrounded by doors where there's only one spotlight casting shadows, yet I need to set r_pr_shadowcount to 8 for them to show consistently - otherwise they disappear randomly, and if the value is low enough, they won't show at all. It looks like disabling shadows on areas where there are no spotlights still improves performance, as if they were still there and were not being occluded properly. Wondering if you were aware of this, just in case?

[Fox]

I got a particular problem with 320 x 200 mode, everything is stretched now, instead of rendering the exact pixels. I don't think the aspect ratio should be corrected in 8:5, and there should have a gamevar that returns whenever it is being corrected or not.



And frankly the screen resolution option is quite confusing now. You should be able to select the aspect ratio first with the options <8:5> <8:6> <16:9>, and select the resolution next.

[Daedolon]

Yeah I think 320x200 should be standardized to represent the original game 1:1.

[Helixhorned]

Fox, on 10 November 2012 - 08:22 PM, said:

I got a particular problem with 320 x 200 mode, everything is stretched now, instead of rendering the exact pixels. I don't think the aspect ratio should be corrected in 8:5, and there should have a gamevar that returns whenever it is being corrected or not.

For stretching the background tile in the start menu, there's hud_bgstretch, which controls passing bit 1024 to the respective rotatesprite call. However it's unrelated to any aspect correction done when rendering a screne.
I disagree with your two suggestions: there's already precise aspect correction control using various cvars; you just have to know their names and meaning. More importantly, a mod should be resolution-agnostic and never have to assume a particular screen configuration at the user's end.
What is planned though is a finer control over CON's showview, also as far as aspect is concerned.

Quote

And frankly the screen resolution option is quite confusing now. You should be able to select the aspect ratio first with the options <8:5> <8:6> <16:9>, and select the resolution next.

It was simply the easiest way of integrating that option into the existing menu system.

EDIT: A related question is, how necessary is correction for non-square pixels in our days? It's probably somewhat useful to people that need to run EDuke32 at lower, non-native resolutions for performance reasons, but OTOH it does make life more complicated. I've been considering of deprecating that functionality, but I'd like to have some input first. (Note: the classic way of determining aspect -- assuming a 8:5 resolution is displayed on a 4:3 screen -- isn't directly touched by that.)

[Fox]

Helixhorned, on 11 November 2012 - 10:22 AM, said:

EDIT: A related question is, how necessary is correction for non-square pixels in our days? It's probably somewhat useful to people that need to run EDuke32 at lower, non-native resolutions for performance reasons, but OTOH it does make life more complicated. I've been considering of deprecating that functionality, but I'd like to have some input first. (Note: the classic way of determining aspect -- assuming a 8:5 resolution is displayed on a 4:3 screen -- isn't directly touched by that.)

Since this is still Duke 3D, there is no way around it. What is missing right now is a different vertical and horzintal zoom for rotatesprite.

Helixhorned, on 11 November 2012 - 10:22 AM, said:

More importantly, a mod should be resolution-agnostic and never have to assume a particular screen configuration at the user's end.

My mods always are, but yet I had like to have use the 320 x 200 resolution.

[Diaz]

Alright, there's something I've noticed now that I'm starting to use lots of models for details.

If the sectnum where a sprite is placed is not directly visible, the sprite won't be drawn. This is good and helps performance, but sometimes I'm using big models that span across more than one sector; and if the sector where the "center" of the model (the sprite) is located is not visible, the model will disappear, even though the player is still looking at one of the sectors the model "occupies".

Would it be possible to add some sort of .def flag so models are always drawn? I guess we could turn them into actors and code them to change cstat to visible or invisible when the player is far enough or inside a certain sector where no parts of the model are visible, so performance is not hindered much.

Below are a couple of pictures of what I try to achieve - some models disappear here when the player looks in certain directions, at certain places. It's not something terrible, but would look neater if it didn't happen!

Attached thumbnail(s)

• 
• 

[Tea Monster]

That is one reason why nobody ever did that before. You'd be in the middle of a Zeppelin hanger, when suddenly you'd be standing in the open sky. Walls flick on and off. Imagine 'texture pop' like in Rage, but with level geometry - very distracting

[High Treason]

I wonder if changing the model's sectnum to the player's sectnum would work? You could limit the range with ifpdistl to make it more efficient.

[Fox]

Diaz, on 16 November 2012 - 04:42 AM, said:

Alright, there's something I've noticed now that I'm starting to use lots of models for details.

If the sectnum where a sprite is placed is not directly visible, the sprite won't be drawn. This is good and helps performance, but sometimes I'm using big models that span across more than one sector; and if the sector where the "center" of the model (the sprite) is located is not visible, the model will disappear, even though the player is still looking at one of the sectors the model "occupies".

Would it be possible to add some sort of .def flag so models are always drawn? I guess we could turn them into actors and code them to change cstat to visible or invisible when the player is far enough or inside a certain sector where no parts of the model are visible, so performance is not hindered much.

Below are a couple of pictures of what I try to achieve - some models disappear here when the player looks in certain directions, at certain places. It's not something terrible, but would look neater if it didn't happen! />

First of all, these screens are very impressive. There is a quality standard, and everythings fits together, and on top of it the atmosphere.

About the sector problem, it doesn't relate much with performance as it does with how the structures are rendered. The game will first determine whenever the sector is visible or not to determine if it should draw the sprites.

But I agree that there should have a cstat so a model won't depend on the sector. However keep in mind that it won't work well with "false ROR", since two sectors would occupy the same space.

[Plagman]

This is also going to be fixed in the future, but an "always draw" flag isn't the answer here. Technically it's an error to make a static model that extends outside the bounds of its sector, but I know that it's too restrictive in practice so I'll implement more zealous discovery of sprites based on the model bounding boxes.

[Diaz]

As always, great stuff to hear, Plagman. So many things planned for the future, the engine's gonna rock more than it does already

That and some per-poly collision (or simpler collision meshes, as most engines use) and we will have total artistic freedom.

[RichardStorm]

I don't know if it's a known bug, there is something new to know on polymer spot lights, or is an issue by my video card drivers, but i noticed that from a certain release (a couple of months ago) polymer lights don't cast shadows properly: for example lotag 50 SEs i put in some test maps no longer work, and light from maphacks don't work well (like in front of the cinema in E1L1, it cast shadow only when the player is in certain sectors).
Anyone noticed the same thing ?

/EDIT: This happens while running the vanilla duke without HRP, doesn't matter if with/without CON or DEF modifications.

[Diaz]

Not sure about your test maps (you could check if you have pressed "1" on them to make them one sided, that disables shadows now) but the HRP maps seem fine to me.... the light in front of the cinema was fine.

[Diaz]

Keyboard input is broken as of latest snapshot - I can't move!

EDIT: Alright, it's fixed!

[Fox]

Is it possible to add a command that calculate the area of a sector? I suppose the value could get a little too big, so even the square root of it would be good.

[Plagman]

DT posted code to do that a few days ago, so I suggest doing some archeology.

[Danukem]

Plagman, on 21 November 2012 - 08:02 AM, said:

DT posted code to do that a few days ago, so I suggest doing some archeology.

I do have some code that sort of does that, but I don't recall ever posting it. Maybe it was Mblackwell?

EDIT: Here is a formula that does it properly, which can be implemented in CON

http://www.mathopenr...olygonarea.html

[Plagman]

Yes, it was MB, and it was to calculate the sector's center.. my memory clearly isn't what it used to be.

Now, you'd also need to calculate the area of any islands inside the sector and substract it from the area of the outer edge.

[Diaz]

A quick question about Polymer - are soft shadows calculated on the CPU?

It seems areas that relied heavily on shadow are as slow on my new videocard as they were on the old one. Resolution, normal and parallax mapping performance have obviously improved, but not shadows...

[Plagman]

Not on the CPU, but walking the map to be rendered from the point of view of the shadow is pretty costly. That's the main weak point of the renderer perf-wise, and the first thing I intend to tackle.

[Diaz]

And rendering the map from the point of view of the shadow is like rendering it multiple times (just like lights do), I assume? So it puts stress on both the CPU and GPU depending on the amount of load the scene has on either?

[Mark]

Some of you may have already discovered this. But if you haven't, I was messing around with different settings of various things to increase framerate. Using Polymer, one thing I found out is there is little or no difference between enabling or disabling all the normal and spec maps for my 40 custom texures and models. There are a few HRP textures with normal and spec maps still running because it was too much trouble to disable those too. But I think there would still be no difference with those shut off too. Just something to keep in mind when mapping.

[Hendricks266]

^ Yeah, maps themselves were designed to be ultra cheap, perf-wise.

[Plagman]

Diaz, on 24 November 2012 - 01:07 PM, said:

And rendering the map from the point of view of the shadow is like rendering it multiple times (just like lights do), I assume? So it puts stress on both the CPU and GPU depending on the amount of load the scene has on either?

Lights need to redraw stuff that's already known to need to be rendered. Shadows need a full new scene from another point of view, so you have to figure out what to render all over again; that's why it's so painful. Right now all planes on the map are in disjoint buffers so each rendered wall is a different draw call, which is pretty heavyweight on the CPU. I have a local tree where the whole map lives in the same buffer, so you can render several planes in a single draw call by constructing the right index buffer, assuming they share the same material. That means for regular map rendering it'll do all the walking without drawing anything at first, then sort planes by material used and render them as batched, which should be a lot better. For shadows you don't need materials at all (unless you want "cardboard cutout" shadows for sprites, so these will have to have a special flag and be rendered in their own call, still), so we'll be able to do shadows in a single draw call, which should help tremendously.