[TerminX]

That would certainly be possible, but the question is where to shoehorn the value into the existing map format in a way that it won't fuck up mods that make extensive use of reading values from arbitrary structure members (like for Duke Plus effects, etc). Maybe a simple compatibility flag could be packed into the "filler" member of sprite 0 or something, since end users really aren't supposed to be using that for anything... it only exists to pad the structure so that the members are aligned correctly for faster memory access. It's an 8-bit value, but we would only need 3 of those bits to implement something that allows a map to specify it doesn't work on classic, doesn't work on Polymost or doesn't work on Polymer.

[Danukem]

TerminX, on 21 May 2013 - 02:24 PM, said:

That would certainly be possible, but the question is where to shoehorn the value into the existing map format in a way that it won't fuck up mods that make extensive use of reading values from arbitrary structure members (like for Duke Plus effects, etc). Maybe a simple compatibility flag could be packed into the "filler" member of sprite 0 or something, since end users really aren't supposed to be using that for anything... it only exists to pad the structure so that the members are aligned correctly for faster memory access. It's an 8-bit value, but we would only need 3 of those bits to implement something that allows a map to specify it doesn't work on classic, doesn't work on Polymost or doesn't work on Polymer.

The other issue is that it would be an unreliable indicator, because polymer maps already released would not contain the flag, and only a portion of future maps would, since not all mappers would know about the feature or care.

Why not just check for SE49 and SE50 sprites? That should be a good litmus test as to whether a map is intended for polymer. There is really no test for the other renderers but with the recent changes to polymost it doesn't matter as much.

[Helixhorned]

Trooper Dan, on 22 May 2013 - 07:10 AM, said:

Why not just check for SE49 and SE50 sprites? That should be a good litmus test as to whether a map is intended for polymer.

Yeah, this seems like a reasonable heuristic. I'm against forcing a particular renderer for a given map though. Maybe EDuke32 could display a subtle message for some time and consider it done then.

[Diaz]

But perhaps it would be possible to give us modders the possibility of specifying (rather than forcing) what renderers are allowed. Maybe via the console, so the parameter could be added to the map's specific .cfg. Another cvar could be used to skip that behavior, so it's not forced. It would make even more sense for mods than for individual maps; I think a Polymer or Classic only mod looks more "professional" by running only the way it was intended to, rather than allowing the player to, let's say, run a Polymer mod in classic then get a black and incorrect art mess. Then we have to specify everywhere that the mod is not intended for classic.

[TerminX]

Checking for the presence of Polymer light sprites in a map is in no way a suitable alternative to allowing a mapper to specify that their map only runs in classic, or only runs in Polymost, or only runs in Polymer. Some people want it more so that maps can be prevented from running in Polymer due to draw distance or performance issues, or prevented from running in classic due to a lack of classic assets... it is in no way solely about making sure Polymer maps only run in Polymer, which is the only aspect your suggestion addresses. I think you're completely missing the point.

[Helixhorned]

TX: OK, I see. My point is that a modder/mapper should not have the authority to dictate a particular choice of renderer. If the user wishes to use a different than the recommended one, it should be possible.

As for the implementation, doing it via OSD commands which would presumably run from a <mapname>.cfg file is at least non-intrusive in this case, unlike overriding user preferences like r_shadescale (which are currently not reset on finishing a map, as far as I can see). It's still a bit hackish though.

EDIT: my bias has a background. As much as I admire the awesomeness of the DNF mod, that "funny" tile covering the screen when one switches into Polymer is a bit unfair IMO. Yes, voxels aren't implemented there and DNF uses quite a bit of them, but that shouldn't prevent me from trying it out just for the heck of it. Especially now with ART mapping, it should be pretty interesting.

[Diaz]

Helixhorned, on 22 May 2013 - 09:32 AM, said:

TX: OK, I see. My point is that a modder/mapper should not have the authority to dictate a particular choice of renderer. If the user wishes to use a different than the recommended one, it should be possible.

As for the implementation, doing it via OSD commands which would presumably run from a <mapname>.cfg file is at least non-intrusive in this case, unlike overriding user preferences like r_shadescale (which are currently not reset on finishing a map, as far as I can see). It's still a bit hackish though.

It should be possible to choose different renderers as long as the map doesn't look a mess, which is why I think it should be specifiable by modders. It's just a matter of making things cleaner. Maybe I can see someone running a Classic map in Polymer for the added dynamic lights, but I see no point in running a Polymer mod, which only uses 24-bit assets and models, in Classic mode.

For these cases, we could have a way to specify if the "choose renderer" option is grayed out in the menus, and perhaps the "Use models" option too. It looks really dirty if changed. Anyways, this is just a cosmetic thing, should not be high priority at all.

Cvars not resetting after being set from a <mapname>.cfg is not desirable behavior and should be addressed, IMO.

[Paul B]

I dont see what the big deal of allowing the mapper to dictate which renderer he wants his map displayed in by setting a map attribute.

If the attribute isn't set in the map nothing changes, meaning the map can be playable in all renderers and it breaks nothing. This would only be an option moving forward to insure future maps are played respectively in their most compatible format making people aware of the maps requirements for best overall experience and consistency.

[Danukem]

Paul B, on 22 May 2013 - 10:22 AM, said:

I dont see what the big deal of allowing the mapper to dictate which renderer he wants his map displayed in by setting a map attribute.

If the attribute isn't set in the map nothing changes, meaning the map can be playable in all renderers and it breaks nothing. This would only be an option moving forward to insure future maps are played respectively in their most compatible format making people aware of the maps requirements for best overall experience and consistency.

By the way, it's pretty easy to prevent a map from working with certain renderers by using CON code. The variable rendmode contains the rendering mode, and can linked to code that prevents gameplay and provides an explanatory message if the wrong renderer is being used. It's a simple procedure.

I agree with Helixhorned that allowing the map file itself to prohibit the player from using a certain renderer is the wrong way to go.

[Diaz]

I wasn't aware of the existence of the rendmode variable, sorry about that.

Although I still believe it's ugly to be able to easily switch rendmodes and usage of models with the menus on mods that don't have 8-bit assets.

[TerminX]

Helixhorned, on 22 May 2013 - 09:32 AM, said:

EDIT: my bias has a background. As much as I admire the awesomeness of the DNF mod, that "funny" tile covering the screen when one switches into Polymer is a bit unfair IMO. Yes, voxels aren't implemented there and DNF uses quite a bit of them, but that shouldn't prevent me from trying it out just for the heck of it. Especially now with ART mapping, it should be pretty interesting.

Why is that "unfair"? The maps are huge and exceed the distance that Polymer can currently render. They don't want their vantage points and other scenes containing far-away sectors to be ruined.

[Fox]

Helixhorned, on 22 May 2013 - 09:32 AM, said:

TX: OK, I see. My point is that a modder/mapper should not have the authority to dictate a particular choice of renderer. If the user wishes to use a different than the recommended one, it should be possible.

I am not sure what is the right answer for maps, but why would it not be reasonable for mods? I can think of good reasons to disable certain renderers in a mod. At some point it is not a matter of choosing another renderer, the renderer is not supported at all and gameplay is not possible.

[Gambini]

Helixhorned, on 22 May 2013 - 09:32 AM, said:

EDIT: my bias has a background. As much as I admire the awesomeness of the DNF mod, that "funny" tile covering the screen when one switches into Polymer is a bit unfair IMO. Yes, voxels aren't implemented there and DNF uses quite a bit of them, but that shouldn't prevent me from trying it out just for the heck of it. Especially now with ART mapping, it should be pretty interesting.

"For the heck of it" people would have ignored our instructions and played the map with Polymer. For many reasons that´s a no-no (even when I really like where´s Polymer going these days).

If you had seen the amount of people reporting the "village people" tile -which luckily gave us a chance to explain them what was wrong- you would know how many people would have played it without voxels, seeing less than half of the landscape, with terrible performance, etc.

[Mblackwell]

Sure, but you should file bugs against Polymer for it so it's not an issue in the future.

[Gambini]

Are you suggesting we should have made our maps three times smaller and removed all voxels just to make the mod Polymer compatible? There is still the performance problem. Maybe we should get rid of half the content of the mod in order to increase performance in Polymer?

Polymer offers advantages that we didn´t need, considering the nature of the mod. But, instead, has drawbacks that negatively affect the mod. There was no single reason to use it. The shadetables support came later, but still there are many problems with it that make its use with the mod not compatible.

[Fox]

By the way, wasn't Polymer meant to have better performance than Polymost?

[Mblackwell]

Gambini, on 22 May 2013 - 07:53 PM, said:

Are you suggesting we should have made our maps three times smaller and removed all voxels just to make the mod Polymer compatible? There is still the performance problem. Maybe we should get rid of half the content of the mod in order to increase performance in Polymer?

Polymer offers advantages that we didn´t need, considering the nature of the mod. But, instead, has drawbacks that negatively affect the mod. There was no single reason to use it. The shadetables support came later, but still there are many problems with it that make its use with the mod not compatible.

Reread what I said:

Mblackwell, on 22 May 2013 - 05:32 PM, said:

Sure, but you should file bugs against Polymer for it so it's not an issue in the future.

Now I'll bold part of it:

Mblackwell, on 22 May 2013 - 05:32 PM, said:

Sure, but you should file bugs against Polymer for it so it's not an issue in the future.

In other words because it's a bug (since Polymer is supposed to be a replacement for Polymost and even Classic to some extent) it should be made known and fixed by EDuke32/Polymer engine developers, obviously.

[TerminX]

I think at this point the problems with Polymer that affect the DNF mod are pretty well known by just about everyone involved. Nothing short of majorly boring restructuring will remedy the performance issues, and the draw distance isn't going to be able to be corrected until that happens (because extending the draw distance with things as-is will just plummet performance further).

[Fox]

Is it possible to add a cstat flag to control the sprite skewing? By default all sprites are given a perspective view in Polymost and Polymer. However that doesn't work in some cases, in particular enemies practically disappear when looking up or down.

In comparison, Duke 64 seems to have a different display for different sprites. Pictured below, the trees are seen in perspective, while the hydrant or Assault Trooper don't.

[Diaz]

Polymer is still slower than Polymost, even with no lights. That and the draw distance is enough to justify not using it in the DNF mod.

However, if the draw distance was adressed, the maps in the DNF mod could have been made with full-blown Polymer lighting and still have decent performance with creative use of models (for example, if all non-accessible buildings in the first map were made of models). Yeah, it would require a modern system, but the current maps, with all the sector detail, would not even run well on such a system if Polymer lights were added. Not trying to say the mod authors should have done that (because it obviously wasn't their goal); I just try to say that it's definately possible. Models are very, very cheap to render on modern systems.

The Slick Willy map I'm working on, while not stellar in terms of performance, is currently running much better than my new Fusion maps, even though it's actually more detailed and a rather large open space. That's because the desert rocks, for example, are models. If you remember those jungle screenshots I've posted in the past, that's the best looking stuff I've made for Polymer; it runs at 70FPS on my machine. And I think it could be optimized even further.

And if this is possible with an unoptimized renderer, I dream of what could be done if it's ever optimized... yay

[Hendricks266]

Fox, on 22 May 2013 - 09:43 PM, said:

Is it possible to add a cstat flag to control the sprite skewing? By default all sprites are given a perspective view in Polymost and Polymer. However that doesn't work in some cases, in particular enemies practically disappear when looking up or down.

In comparison, Duke 64 seems to have a different display for different sprites. Pictured below, the trees are seen in perspective, while the hydrant or Assault Trooper don't.

I think the issue you're thinking of is billboarding. I know there is a global cvar that controls it, at least for Polymer. However, I could see two mdflags bits: one to prefer the perspective view, one to prefer the screen-facing view, and when you set both, it prefers the opposite of whatever is set by the cvar.

[DavoX]

I didn't know Polymer had draw distance issues... wow

[Mateos]

DavoX, on 23 May 2013 - 10:02 AM, said:

I didn't know Polymer had draw distance issues... wow

You should have a super-config then x)

When you drop from 50 to 2 FPS while opening a door to the outside, I think you suspect something related to the rendering distance

[Mikko]

Diaz, on 22 May 2013 - 10:07 PM, said:

The Slick Willy map I'm working on, while not stellar in terms of performance, is currently running much better than my new Fusion maps, even though it's actually more detailed and a rather large open space. That's because the desert rocks, for example, are models. If you remember those jungle screenshots I've posted in the past, that's the best looking stuff I've made for Polymer; it runs at 70FPS on my machine. And I think it could be optimized even further.

I would be very surprised if any of your upcoming maps were even playable. And I have a good computer.

[Diaz]

Mikko_Sandt, on 23 May 2013 - 10:14 AM, said:

I would be very surprised if any of your upcoming maps were even playable. And I have a good computer.

the thing is that I try to make scalable quality. you can use cstat 2 and 512 on SE50's and SE49's to change their priority, then use the r_pr_maxlightpriority cvar to control how many lights are drawn. I've made a small app that does that for you. my stuff is perfectly playable on any core2 with a geforce 8800gt and even slower cards. if you have ATi you're screwed though, but that's inherent to the polymer+ati combo.

Don't think of things like duke nukem eternity (without the performance patch) when you think of polymer maps. that stuff looks much better than mine ever will but as a tradeoff, it's unplayable even on my computer. my maps are not even close to that.

[Mblackwell]

Hendricks266, on 23 May 2013 - 09:36 AM, said:

I think the issue you're thinking of is billboarding. I know there is a global cvar that controls it, at least for Polymer. However, I could see two mdflags bits: one to prefer the perspective view, one to prefer the screen-facing view, and when you set both, it prefers the opposite of whatever is set by the cvar.

It's a dirty broken buggy hack according to Plagman.

[3D Master]

Okay, so it's been a while since I played Duke, so I figured let's download the new HRP pack again.

Now there's a problem; eduke32 will no longer start up in full screen mode. All I get is a black screen requiring a hard reset. In windowed mode it seems to run just fine though.

I attached my .log if there is anything to be gleamed from it.

Attached File(s)

•  eduke32.log (1.3K)
  Number of downloads: 538

[TerminX]

Update your drivers. That log seems to show that the driver hung during video mode setting or OpenGL initialization and never actually failed out and returned control to EDuke32.

[Helixhorned]

Fox, on 22 May 2013 - 09:43 PM, said:

Is it possible to add a cstat flag to control the sprite skewing? By default all sprites are given a perspective view in Polymost and Polymer. However that doesn't work in some cases, in particular enemies practically disappear when looking up or down.

In comparison, Duke 64 seems to have a different display for different sprites. Pictured below, the trees are seen in perspective, while the hydrant or Assault Trooper don't.

That's an interesting suggestion. I added it to the future list.

Hendricks266, on 23 May 2013 - 09:36 AM, said:

I think the issue you're thinking of is billboarding. I know there is a global cvar that controls it, at least for Polymer. However, I could see two mdflags bits: one to prefer the perspective view, one to prefer the screen-facing view, and when you set both, it prefers the opposite of whatever is set by the cvar.

Yes, I think mdflags (spriteext[].flags in C) is the right place to put it, because

• such a flag would be most interesting on a per-tile basis (i.e. set from CON) rather than setting it in the map itself, and
  
• it's pointless for the classic renderer due to its ortho projection in the up/down direction.

I'm less sure about the case with both bits set, though it's neatly symmetric. In the screenshot posted by Fox, the tree trunk must be projected like a wall sprite, while sprites like pickups (and mosters, to a certain degree) are a matter of preference or artistic choice.

[3D Master]

I figured out the problem; the drivers weren't the problem; it's running smoothly down. Such a delight to play Duke3D after forcing myself through forever.

Still wondering if I should pony up the cash for the DLC; on the one hand, this game his horrible, on the other I'll get to see the completion of the god damn cliffhanger ending.