[Stabs]

yes most people will see polymer as just lighting effects but the way the you can draw and make levels through polymer opens up all new possibility's for mappers and modders.

wish the new RoR & SoS would get as much love as the lights

[zchri9]

oporix, on Sep 5 2009, 01:25 PM, said:

lol i do know a bit about duke nukem...but what is polymer?

i hear in almost every duke site
is it something like a lighting syster or somethng?

Polymer is a new EDuke32 renderer.
check out http://forums.3dreal...ead.php?t=35184 for more information

Keep Polymer questions/discussion in this thread : http://forums.duke4....p?showtopic=775

[Sobek]

Ohio there,

I was just wondering... If I wanted to stop the shooters from casting polymer lights, is there any simple way of doing that? (either in the CON code or something else). I've been toying with certain scenarios involving a lot of shooters, and it runs excellent when Polymer lighting is disabled, but when enabled, the framerate dives into the single digits - even when the shooters aren't actually casting on anything. I tried making a room with nothing but shooters in it and the results were the same, so I'm positive they're the root cause of the performance drop.

To be honest, I can't really think of any particular situations where I would want shooter's casting lights, so if there was a way to stop them from doing so, that'd be great.

[Danukem]

Sobek, on Sep 29 2009, 11:55 PM, said:

Ohio there,

I was just wondering... If I wanted to stop the shooters from casting polymer lights, is there any simple way of doing that? (either in the CON code or something else). I've been toying with certain scenarios involving a lot of shooters, and it runs excellent when Polymer lighting is disabled, but when enabled, the framerate dives into the single digits - even when the shooters aren't actually casting on anything. I tried making a room with nothing but shooters in it and the results were the same, so I'm positive they're the root cause of the performance drop.

To be honest, I can't really think of any particular situations where I would want shooter's casting lights, so if there was a way to stop them from doing so, that'd be great.

Just to be absolutely clear -- you mean the PROJECTILES fired by the shooters are causing the problem, right? To answer your question: There is a sprite flag for preventing a projectile from casting a Polymer light. I could have the shooters set that flag on the projectiles it spawns. However, you are making heavy use of shooters, and for most uses it would be good for their projectiles to make lights in the normal way. I guess I could make it an extra flag that you set on the shooter which causes it to set the no light flag on all its projectiles.

[Sobek]

DeeperThought, on Sep 30 2009, 05:49 PM, said:

Just to be absolutely clear -- you mean the PROJECTILES fired by the shooters are causing the problem, right? To answer your question: There is a sprite flag for preventing a projectile from casting a Polymer light. I could have the shooters set that flag on the projectiles it spawns. However, you are making heavy use of shooters, and for most uses it would be good for their projectiles to make lights in the normal way. I guess I could make it an extra flag that you set on the shooter which causes it to set the no light flag on all its projectiles.

Sorry, that's correct, the projectiles being fired are the issue here. I had no idea there was a flag that disabled projectiles from casting lights - it was something I thought about a while back though. If you could implement that when you get the chance, I'd be grateful

[Sobek]

You're probably tired of my constant requests by now... But on the topic of shooters, I thought I'd ask about something I think I might have brought up once before. Shooter's currently have the ability to target 'bad guys' (that's enemies such as liztroops, pigcops etc, right?) or the player/player allies, but I was thinking - what about targetting other sprites that aren't any of these? Perhaps a tag (if there's any left at this stage! Heh) that if applied the same to both the shooter and another sprite, would make the shooter fire at that sprite.

It'd be a simple and easy way of making a shooter track and fire at a moving target that isn't any kind of enemy or bot or anything. For instance, if I had two ship models, one sitting still and the other on a moving sector, it would be nice to put some shooters on the stationary ship and just tag the model on the moving sector as their target... Then with some simple adjustments to the firing rate and projectile type of the shooters, it'd be a perfect bit of ship-to-ship combat.

Plausible idea, or not likely?

[Stabs]

random key placement?

Red K can make the card appear in any given place, but only one

[Danukem]

Sobek, on Sep 29 2009, 11:55 PM, said:

I was just wondering... If I wanted to stop the shooters from casting polymer lights, is there any simple way of doing that?

OK, I just uploaded a new set of unofficial CONs with one minor change for you. Add 256 to the EXTRA of the shooter, and the projectiles it fires should not emit any Polymer light (assuming they are one of the projectiles hardcoded to do that). I did not test this. If it doesn't work, it's not my fault.

[Sobek]

That appears to have done the trick, I gained a good 10fps by applying that to those shooters that I don't need casting lights. I was expecting a bigger improvement, but I think I've reached a sort of performance impass between how many shooter projectiles are firing and visible, versus the lighting they cast. The projectiles alone seem to incur quite a hefty performance loss if they don't impact and/or disappear rather quickly... Ditching any lighting being cast definitely helps, but I guess that can only affect it so much.

If I recall correctly, didn't you make it so that some of the projectiles (FIRELASER, for instance) were actually just one sprite, repeated several times per shot? I wonder if that could be why they ditch performance so bad - just too many sprites being drawn at once.

Regardless, thank you. I've got a few spots where I use shooters that simply do not need to cast any lighting, so this will help

[Danukem]

Sobek, on Oct 5 2009, 06:26 PM, said:

If I recall correctly, didn't you make it so that some of the projectiles (FIRELASER, for instance) were actually just one sprite, repeated several times per shot? I wonder if that could be why they ditch performance so bad - just too many sprites being drawn at once.

FIRELASER has always been like that, even in vanilla Duke. It is composed of several sprites linked together.

[Sobek]

Ahh ok, cool. I thought it was originally just a single sprite with 3 laser dots of increasing size...

That's an interesting way of rendering it though, do you know why it's done that way and not just made of a single sprite? If I had to guess, would it have something to do with making sure the projectile always looks like it's following the correct trajectory?

[Danukem]

Sobek, on Oct 5 2009, 07:50 PM, said:

Ahh ok, cool. I thought it was originally just a single sprite with 3 laser dots of increasing size...

That's an interesting way of rendering it though, do you know why it's done that way and not just made of a single sprite? If I had to guess, would it have something to do with making sure the projectile always looks like it's following the correct trajectory?

It's a way to make the laser bolt elongated. There's really no better way of doing it without the use of models.

[Headless_Horseman]

As currently I'm unable to run Polymer, I'm replaying some maps with the last stable Eduke32 released before Polymer.
However, I found out that's quite impossible to finish "Last Pissed Time" by Criag Fatman (the latest revision) using DukePlus, as eveytime the game quits with the "Too many sprites spawned" error. I tried removing "weapons effect" from the effects menù, but the problem is still there.
I don't know, is there a way to implement a "counter" that prevent the game from spawning too many sprites ? Also, it's possible to make optional the feature that makes gibs & corpses remain on the ground until the map is finished ?

[Danukem]

Headless_Horseman, on Oct 10 2009, 03:09 AM, said:

As currently I'm unable to run Polymer, I'm replaying some maps with the last stable Eduke32 released before Polymer.
However, I found out that's quite impossible to finish "Last Pissed Time" by Criag Fatman (the latest revision) using DukePlus, as eveytime the game quits with the "Too many sprites spawned" error. I tried removing "weapons effect" from the effects menù, but the problem is still there.
I don't know, is there a way to implement a "counter" that prevent the game from spawning too many sprites ? Also, it's possible to make optional the feature that makes gibs & corpses remain on the ground until the map is finished ?

Do you know how many sprites that map has in it to begin with?

To answer your question, I think there should be an option for all jibs and blood to disappear over time, and it should be the default setting. But I'm not convinced that those sprites are what is pushing it over the edge.

[XThX2]

DeeperThought, on Oct 10 2009, 08:22 AM, said:

Do you know how many sprites that map has in it to begin with?

To answer your question, I think there should be an option for all jibs and blood to disappear over time, and it should be the default setting. But I'm not convinced that those sprites are what is pushing it over the edge.

This might not be a right place to ask but, is 16384 a dead-end for sprite limit ? (About the map, it must be sprite-bridges and stuff)

[Danukem]

Yes, and in my opinion it's a bad idea for a map to have more than about 8000.

[Headless_Horseman]

DeeperThought, on Oct 10 2009, 09:22 AM, said:

Do you know how many sprites that map has in it to begin with?

To answer your question, I think there should be an option for all jibs and blood to disappear over time, and it should be the default setting. But I'm not convinced that those sprites are what is pushing it over the edge.

I dont' know how many sprites are in the maps, however here's the link to the latest revision : http://lezsite.narod...files/lpt10.rar
Also, now I remember Craig mentioned that his map doesn't work well with MODs, but he was speaking about the first version.

For implementing that option, I think is an excellent idea !

[Gambini]

That map has about 16000 sprites if not more, neither i was able to finish that one due to the same problem than Headlesshorseman, but again with so many sprites there is not much that DT could do.

Quote

Yes, and in my opinion it's a bad idea for a map to have more than about 8000.

There is no risk on using 10.000 sprites THESE days. DPCB was pretty stable and ran over that limit.

[KillerBudgie]

So... is there going to be a new release of DukePlus. Or is one not coming out until WGRealms2 is released?

[Danukem]

KillerBudgie, on Oct 27 2009, 07:24 AM, said:

So... is there going to be a new release of DukePlus. Or is one not coming out until WGRealms2 is released?

I don't know. For a long time I have not worked on DP, except for a few minor code patches, and WGR2 has been the main reason for that. It's important to maintain momentum if you want to get a big project finished, and going back to DP would have stopped the momentum. But now the first release of WGR2 is 99% finished so that's not so much of an issue.

There's a ton of different things I could fix, improve or add to DP and I'm not sure where to start. It would be helpful if people could remind me of longstanding requests -- especially stuff that I said I would do and haven't done yet. That stuff will have top priority. I'm not promising that I will have a release ready any time soon.

[KillerBudgie]

That's quite alright. I still love playing Duke Nukem 3D w/ DukePlus anyway. So I wouldn't be the least bit surprised if WGR2 was taking up so much of your time.

[Headless_Horseman]

For what I remember :
1) introducing the minigun, dropped by miniboss. Perhaps getting it will result in a loss of speed (too much weight).
2) gibs recoded as projectiles, like you mentioned on WGR2 topic.
3) making optional that gibs and corpses stay on the ground.
4) this one is an idea of mine : giving a custom code to the unused ORGANTIC and SCORPIO TANK enemies.

When I'll remember some other, I'll tell you.

[Danukem]

Headless_Horseman, on Oct 27 2009, 11:17 AM, said:

For what I remember :
1) introducing the minigun, dropped by miniboss. Perhaps getting it will result in a loss of speed (too much weight).

Someone has to give me a working model first. It has to have both a hud version with animation, and a pickup version.

Headless_Horseman, on Oct 27 2009, 11:17 AM, said:

2) gibs recoded as projectiles, like you mentioned on WGR2 topic.

Sure, but that's something that was recently brought up, not an old request.

Headless_Horseman, on Oct 27 2009, 11:17 AM, said:

3) making optional that gibs and corpses stay on the ground.

Gibs, yes. Those should disappear by default. Corpses have always stayed on the ground forever and I see no reason to change that.

Headless_Horseman, on Oct 27 2009, 11:17 AM, said:

4) this one is an idea of mine : giving a custom code to the unused ORGANTIC and SCORPIO TANK enemies.

No, but I do plan to add the pigcop tank as a vehicle, if I can get both 8-bit art and a model for that purpose (I know I have at least one or the other, maybe both).

Bug fixes are higher priority than adding new features, though.

[Gambini]

Iron sight

[Sobek]

Well, I think you understand my stance on demanding more and more... But really the only thing I can think of at the moment that I 'need', is some additional versatility with shooters. Namely, if possible, to allow them to target any sprite, perhaps by way of a certain unique tag. That way, a shooter can track a moving object that isn't necessarily setup as an enemy or a friendly, but rather just a plain old sprite/model (perhaps by way of having a tag or EXTRA or... something... that would be unique to the sprite/model and shooter/s in question - effectively 'linking' the two together). I have no idea if that made sense.

Beyond that, you're already working on some other cool stuff, so I'm quite happy to wait and see.

[Stabs]

a more versatile quote system, dormant quotes / activation by dukebot waypoints / killing monsters,

dormant ones would lay dorment untill activated by a touchplate, then they would have to be told whether to display by entering the sector they are placed in or just displayed straight after activation by the touchplate.

[High Treason]

I'm still gonna ask for kickable doors.

Apparently this works on some door tiles already, so maybe there is a way to make the door move faster if kicked instead of "used" and perhaps for it to play a different sound as well.

I don't know why, I just like kicking doors in.

Though you said you would only work on long standing stuff and things you said you would already do - so I don't know why I am typing this, one thing did come to mind that I would find cool. Lets face it, the Holoduke is useless, I often wondered if it could be given AI of any sorts - basically making it a lot like the effect of the "Ripper Heart" from Shadow Warrior.

[Danukem]

High Treason, on Oct 28 2009, 12:35 AM, said:

I'm still gonna ask for kickable doors.

Apparently this works on some door tiles already, so maybe there is a way to make the door move faster if kicked instead of "used" and perhaps for it to play a different sound as well.

I don't know why, I just like kicking doors in.

Though you said you would only work on long standing stuff and things you said you would already do - so I don't know why I am typing this, one thing did come to mind that I would find cool. Lets face it, the Holoduke is useless, I often wondered if it could be given AI of any sorts - basically making it a lot like the effect of the "Ripper Heart" from Shadow Warrior.

Have you used the Duke Plus Holuduke? It's not useless.

Making the Holoduke summon another Duke to help is exactly what I did in my first mod, Duke Nukem: Weapon of Mass Destruction. When I started Duke Plus, I felt like I needed to do something different...but maybe I should add summoning a Dukebot as an option. It would be a good way to use my bot AI that doesn't feel like cheating.

I have nothing against the idea of kickable doors, but I have to do a little research on how to make the kick trigger them, and I would rather do the stuff I already understand first.

[Headless_Horseman]

Hey, I just found out a funny bug playing the latest version of "Rush Back" by Gambini with DukePlus : the Cola Tubes !



http://img502.images...dukeplusbug.jpg

[Headless_Horseman]

Also, I have a request : it'st possible, perhaps with Advanced AI on, to add a flag to the assault trooper and commander "playing dead" so if you shot them they'll never wake again ? I just hate to have them reviving when I turn around !