[TerminX]

Yes, that's why the compilation instructions specifically say not to use gcc 4.4.0 on win32.

[Stabs]

 DeeperThought, on Jun 23 2009, 07:32 AM, said:

LOL, that was great.

heh happy days indeed

i could of kept that building going, as long as there is room for a window on each floor, cant overlap windows, i tried heh

[AdrianG]

 DanM, on Jun 23 2009, 04:13 PM, said:

heh happy days indeed

i could of kept that building going, as long as there is room for a window on each floor, cant overlap windows, i tried heh

What do you mean by overlapping windows? Having a window on each floor all in a column?

[Stabs]

 AdrianG, on Jun 23 2009, 09:18 PM, said:

What do you mean by overlapping windows? Having a window on each floor all in a column?

oh id make one window on one floor and another on another floor, then move them so they overlap each other making a colum, yer but that didnt work, kinda expected it not to.

hmmm now to test what T does in polymer on ceiling and walls with RoR, supposedly it is to be used in making RoR stuff, iam not to sure how. its all trial and error with no documentation atm.

[nsnake]

 TX, on Jun 24 2009, 12:12 AM, said:

Yes, that's why the compilation instructions specifically say not to use gcc 4.4.0 on win32.

Thanks TX!
Now everything works properly, and it makes me very happy.




Thank you very much!

[TerminX]

I actually just committed something that should fix building with gcc 4.4.0. I stumbled upon a newer version of Ken's image format library in some other source available on his site and decided to try MinGW gcc 4.4.0 again for shits and giggles after merging it in, and lo and behold it appears to be working fine now. As I didn't notice any other issues with 4.4.0 when I was testing it before the HRP breakage came into play, I'll be sticking with 4.4.0 in my development environment for now unless any other problems crop up.

[Danukem]

 TX, on Jun 24 2009, 01:30 AM, said:

I actually just committed something that should fix building with gcc 4.4.0. I stumbled upon a newer version of Ken's image format library in some other source available on his site and decided to try MinGW gcc 4.4.0 again for shits and giggles after merging it in, and lo and behold it appears to be working fine now.

I love it when shit like that happens. I wonder if that will fix or improve anything else.

[supergoofy]

I will still use 4.3.3 till it is verified that 4.4.0 works with eduke32.

I will test the new r1440 build later today. I already compiled it with 4.3.3

[MusicallyInspired]

An interesting note here. Daedolon seems to have a very similar problem to my issue where sprites are seen through walls and FPS extremely low (only his sprites aren't garbled and the transparency is intact instead of all black).

[Plagman]

Yeah, I noticed that as well when he mentioned that issue to me.
Are there any ATI X1x00 users without that problem?
I'm pretty sure it's related to non power-of-two textures combined with repeating (as I know R520-class hardware doesn't support that), but the fact that it only happens in polymer and only with sprites is a bit puzzling. Maybe the driver has workaround paths that do not work with the way polymer renders sprites. I'll ask around.

[The Commander]

I could install my old X1650 Pro again and see what happens on my end.

[HellFire]

Posting here to just thank the developers of this new render, it kick ass.

[Micky C]

I've got 2 questions.

1. Does polymer support model textures?
2. Eventually when people get more powerful computers, will all the point lights be replaced with a spot light equivalent?

In fact, is there a polymer FAQ somewhere?

[zchri9]

Are there any plans to optimize Polymer a bit?
Using Polymer and DukePlus together on one of the DukePlus maps (called Called to Action?) I get less FPS in some parts of the map then I get in Crysis.
In some parts of the map I was getting a FPS as low as 20FPS while in Crysis even on the most graphical levels (the ice levels) I get around 30 - 40 FPS Maxed out 1440 x 900 with no AA

[Stabs]

i think optimization will be the last thing on the list
once it all sits right they they will probably begin getting it optimized

the way light hits surfaces in places is a bit funny
point lights really light up walls in places but neglect the floors and ceilings alot as an example

spotlights that change through level changes like a door opening can also sometimes affect a point lights brightness in other rooms aswell.

[Danukem]

I don't know much about how it works, but I do know build is fundamentally different from other more modern engines in ways that present unique challenges. Build maps don't have to be compiled because they contain zero lighting information. All that stuff has to be calculated on the fly in polymer. If build worked more like a modern engine, frame rate would be higher but it would sacrifice the ease of use for mappers that makes it so attractive in the first place.

I'm sure more optimizations can be done --maybe dramatic ones-- but don't be surprised if frame rate still remains low in some maps/mods for the current crop of hardware. The good news is that if hardware continues to improve at the usual pace, frame rates will eventually go up to decent levels even without huge optimizations.

[Tea Monster]

I'm not a coder, but remember that any new features are bolted onto the code for an old 2.5D shooter. I know that walls and floors are completely seperate entities and are treated as such by the original code. Its only 'real' 3D games that have actual walls and floors!

Duke has Polymost and Polymer to make 'real' 3D but its creating the geometry from information used to create 2D levels, so you are going to get some strangeness.

[Jimmy]

I think the point of not releasing Polymer was because the team already knew about most of this.

[Parkar]

 zchri9, on Jun 27 2009, 01:01 AM, said:

Are there any plans to optimize Polymer a bit?
Using Polymer and DukePlus together on one of the DukePlus maps (called Called to Action?) I get less FPS in some parts of the map then I get in Crysis.
In some parts of the map I was getting a FPS as low as 20FPS while in Crysis even on the most graphical levels (the ice levels) I get around 30 - 40 FPS Maxed out 1440 x 900 with no AA

You have to remeber that Crysis is built from the ground up to do what it does while Polymer is built ontop of an engine where no thought was put into supporting what polymer does.

Unless stuff has changed since I tried Polymer last the CPU is the botle neck on a modern PC at the moment due to the pre caclulations thats done before rendering.

 DanM, on Jun 27 2009, 01:39 AM, said:

i think optimization will be the last thing on the list
once it all sits right they they will probably begin getting it optimized

the way light hits surfaces in places is a bit funny
point lights really light up walls in places but neglect the floors and ceilings alot as an example

spotlights that change through level changes like a door opening can also sometimes affect a point lights brightness in other rooms aswell.

Thats due to the max ligths per surface being to low to show all lights hitting the floors. With a powefull enough machine you should be able to upp that limit. I think I have mine set around 12 or 16 while default is 5 I think. Note that this will affect framerate though.

[Stabs]

for the moment optimization for me is splitting large sectors that may share multiple point lights, like roads and long hallways

usually try to keep a halfway sector in between lights with no light SE's in it, seems to work better for larger lights distributing the light properly.

come on flashing SE51 i want you so bad heh

making the light textures work as breakable light sprites that turn into flashing light would be a feature most awsome, imagine the absolutley insane crazy light breaking, glass smashing action scenes you could create with that, combine that with a nice polymer texture marble foyer with the new RoR and oh yes it might not be DNF but its close enough.

props to Plagman & TerminX for this stuff, its just totally of the scale.

edit : whats that console command parker?

[zchri9]

 Parkar, on Jun 27 2009, 01:59 AM, said:

You have to remeber that Crysis is built from the ground up to do what it does while Polymer is built ontop of an engine where no thought was put into supporting what polymer does.

Unless stuff has changed since I tried Polymer last the CPU is the botle neck on a modern PC at the moment due to the pre caclulations thats done before rendering.



Thats due to the max ligths per surface being to low to show all lights hitting the floors. With a powefull enough machine you should be able to upp that limit. I think I have mine set around 12 or 16 while default is 5 I think. Note that this will affect framerate though.

Polymer runs fine.
It was just the called to action map that lagged like hell.
With E1, E2, E3, E4 the frame rate is fine. I was just playing through called to action map thinking 'Oh god, this is unoptimized'

[Stabs]

zchri9, on Jun 27 2009, 03:08 AM, said:

Polymer runs fine.
It was just the called to action map that lagged like hell.
With E1, E2, E3, E4 the frame rate is fine. I was just playing through called to action map thinking 'Oh god, this is unoptimized'

thats probably my map, iam yet to convert that over to work fine with polymer, its probably the
fact its massive e1 e2 e3 e4 are all about 3 - 400 hundread secotrs i think, that map is around 1600 and there is alot of dynamic fire sprites.

might have to use a hub system to split it on the subway, so the destroyed city is on its own map.

[zchri9]

This just came up as a random thought.

What if the water from the fire hydrant formed a puddle? With Polymer the water would look very good and be reflective.
Sure the hydrant forming a puddle would be a completely useless feature but it would make Duke 3D appear more modern.
The only problem I can think of with this idea is that a timer would have to be put in so the whole map doesnt flood with water and from my guess a timer would probably involve con editing.

[Stabs]

zchri9, on Jun 27 2009, 02:49 AM, said:

This just came up as a random thought.

What if the water from the fire hydrant formed a puddle? With Polymer the water would look very good and be reflective.
Sure the hydrant forming a puddle would be a completely useless feature but it would make Duke 3D appear more modern.
The only problem I can think of with this idea is that a timer would have to be put in so the whole map doesnt flood with water and from my guess a timer would probably involve con editing.

could just make hydrants spawn a translucent blue blood puddle like on bodys and make it grow like them, sounds like it should be more of a dukeplus feature than a polymer one.

[zchri9]

DanM, on Jun 27 2009, 03:53 AM, said:

could just make hydrants spawn a translucent blue blood puddle like on bodys and make it grow like them, sounds like it should be more of a dukeplus feature than a polymer one.

Yeah, Probably should be a DukePlus feature. Would still be a nice feature in EDuke32 though. Awesome reflective water puddles.

After all awesome reflective water puddles are the way of the future.

[Chip]

2 questions (not really aimed at polymer but its Eduke32 related)


1. Will there ever be support for model sticking or what ever its called (allowing 2 models to attach to each other) someone said that MD3's support this feature but its not implimented into Eduke32. I would like to know if its something that may be thought about in the future or if it will just be ruled off as there's not enough dmand for it at the moment? (Since I'm probably the only person who wants it )

2. Will the "move" commands ever be able to support game-vars for their number so we can have an easy changeble movement number without needing to define like 200 odd move commands for different varying speeds?

[Danukem]

DanM, on Jun 27 2009, 03:07 AM, said:

come on flashing SE51 i want you so bad heh

But where on the sprite is the information defining the flashing going to go? Pretty much everything is already taken (hitag, lotag, xvel, yvel, zvel, extra, shade). I guess the only thing left is pal. Maybe pal 1 could be random flashing, and the other pals (2-255) could be for different cycler rates? Or there could be 8 pals set aside for different kinds of random flashing, and the rest for cyclers.

I could add that effect with CON right now, but I suspect that TerminX will be adding something like that, which would be better.

[Tea Monster]

Chip, on Jun 27 2009, 05:28 AM, said:

1. Will there ever be support for model sticking or what ever its called (allowing 2 models to attach to each other) someone said that MD3's support this feature but its not implimented into Eduke32. I would like to know if its something that may be thought about in the future or if it will just be ruled off as there's not enough dmand for it at the moment? (Since I'm probably the only person who wants it )

That would be cool. + 1 on this.

You'd have to break the model into sections with the arms being separate entities so that the hands can stick to the gun and the 'shoulders' can pivot to allow this. I actually tried making the current player model support holding different weapons and its pretty much pointless unless you try to implement something like this. You'd need to cycle all the different animations with the model in the position for each weapon, which is a pain in the ass, and kinda silly really.

The other problem with that is that nobody said that they wanted to do the coding part of this so it kind of went nowhere.

I don't know how its done in modern games, but it may be that with modern 'skeletonized' mesh formats such as (plug plug plug) MD5, the attach points are in the wrist or hand bones and you don't need to detach anything as the skeleton will have some kind of IK system that will just move the other bones of the arm so it works without looking like hes dislocated his shoulders.

[Plagman]

Polymer will support model attachments to MD3 tags through CON code; it's been planned for a while.
Also, tying polymer dynamic lights to flickering lights and/or light switches has been possible for a while. Lighthacks had maxshade/minshade members to tie the intensity of the light to a range of shades on the sector it belonged to. This allowed Parkar's E1L1 lighthacks to function properly with flickery polymer lights and lightswitches. However, I forgot to reimplement it when overhauling the light management code in polymer a while ago, so it doesn't work as of right now; it's easy to put back in, though.

[Fox]

Wow! I tested it, quite (very) impressive.

1 - Does the shading on wall borders are present only if there are light sources in the current map? I would like to see it always present on every wall, much like Duke for Saturn.

2 - The hard-coded light effects are only temporary, and eventually will be set through DEFs, right?