[Fox]

If I resized the picture to 56px, then I can make it fit a wall with 448 units with 50% of the size. But there are other cases which resizing a tilefromtexture would have a purpose without the need of duplicated pictures.

I would prefer if it wasn't necessary to adjust the scale of the images, but unfortunately something superfluous as the size of a tile determines what you can or not do.

[Danukem]

Is there a way using CON to detect the height of a sprite in build z units? I remember there was a discussion of that being a possible feature a long time ago, but I don't know if it ever happened.

[Plagman]

Multiply yrepeat by tile height by some constant I don't remember but that should be trivial to observe on a sample sprite.

[all outta gum]

not on drugs.....BUT would it be possible to write stereoscopic 3d into eduke? just because duke nukem 3d should be in 3d, future proofing,
kind of like the re-modelling and such

[Plagman]

There's already rudimentary anaglyph mode in Polymost, you can enable it with gl_redbluemode 1. For actual shutterglass support it would only work on profesionnal cards, so the audience would be very limited.

[Mark]

Before I switched to an LCD monitor I ran Eduke with my Stereoscopic 3D glasses. It uses a small adapter between the video card and the monitor. It looked great and I kind of miss it.

[Jblade]

Just noticed that projectiles that I haven't defined an impact sound for now play KICK_HIT by default, rather than nothing as before. Is there anyway you can revert this, or was it a neccesary change for bug reasons (or whatever)?

EDIT: woah! Ok projectils are actually all kinds of screwed. Last revision I was using was 3095 and they were working fine - but in the latest one, things like rockets and grenades don't appear (but do explode) and even the default explosion doesn't appear. Just gonna test and see if normal unmodded Duke's fine.

EDIT2: Duke's normal projectiles work - I just checked WGR2 and some projectiles appeared and others didn't. From what I can, the projectiles ARE there but they're just completely invisible (and whatever it should spawn isn't visible too) There's no con code for either things I've tested in that would do that.

[Jblade]

Apart from that, I've also noticed that many ambient sounds don't seem to play - if there's more than 1 of the same sound playing than it just outright doesn't work. I know you guys did some sound changes a while back so I'm gonna take a look and see if I can isolate when this started to happen.

[Jblade]

Ok third bump (sorry) the projectiles are fixed in the latest snapshot, nice work TerminX

[Diaz]

I don't know if this would be useful for anyone else besides me (if not, please forget about the hassle), but maybe glow maps could be supported in HUD models?

They don't seem to work (well, they don't work for HUD sprites and that seems to extend to models too), and it would be great if the sights in the weapon below could glow!

Attached thumbnail(s)

• 

[Plagman]

They're totally supposed to work, so I probably fucked something up.

[Diaz]

Let me check if I did something wrong too... just in case!

Hmmmm, nope. The .def part for the sights reads like this:

skin { pal 0 surface 2 file "models/weapons/brifle/ar_c.png" }
glow { pal 0 surface 2 file "models/weapons/brifle/ar_c.png" }

Yep, it's the same file, a semi-transparent .png that should work...

[Plagman]

It's not "glow { pal 0", it's just "glow". I don't understand why you're defining the same file as diffuse and glow, though. That will make the whole thing fullbright.

[Diaz]

Yes, the whole object needs to be fullbright. The model is comprised of 3 sub-objects (sights, hands and weapon itself) and that texture is just for the sights object (surface 2). You're right I shouldn't specify a palette though, but shouldn't it still work? (glow maps I've made for enemies work fine)

It looks like the glow map itself is applied, it's just not fullbright... this is weird, maybe it's just that the .png is way too translucent.

EDIT: yeah, that was it. The .png is just way too translucent. :/

[Tea Monster]

No idea if this is of any use or not, but the people over at Sauerbratenhave released something called 'Tesseract' which is claimed to be a completely 'real time lighting effect' game.

http://cubeengine.co...&thread_id=2534
https://github.com/lsalzman/tesseract

I was wondering if, as it's open source, if we could get any hints and tips for optimising or improving Polymer?

A list of the new features:

deferred shading
HDR rendering with tonemapping and bloom
omnidirectional point-light shadowmaps
sunlight cascaded shadowmap
screen-space ambient occlusion
screen-space water reflections (no more reflection plane limits)
refractive alpha cubes
refractive glass material

[Plagman]

There isn't any hints needed, really; I know exactly what needs to be done. As usual, the problem is making time to do it.

[Helixhorned]

Trooper Dan, on 29 October 2012 - 04:05 PM, said:

Is there a way using CON to detect the height of a sprite in build z units? I remember there was a discussion of that being a possible feature a long time ago, but I don't know if it ever happened.

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.

[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