[Gambini]

I see, really interesting. Then Polymer seems to be more smart-designed in performancewise. I guess that with time, when it gets finally released, and properly optimized will be less demanding than polymost (lights apart).

How hard would be making an optional 8bits filter in order to turn all the awesomeness of polymer into the 8bits looking?

[Stabs]

Marked, on Jul 29 2009, 04:58 PM, said:

and people just thought polymer was pretty lights

And I have been doing that effect and ROR all over the place in my map with half a million sprites painfully sized and aligned. At least it will be easier next time around with polymer.

ahh the old sprite floor, i dont think i'll miss you

my #1 gripe with them was how lighting affected them, they could look so out of place at times, used to have an airvent running along the roof of the cinema foyer in TTA2 but i had to drop that because of how lighting affected it.

I like the sound of what gambini said, it could actually run nicer than polymost, mmmm big open levels could be back on the menu.

[Sangman]

Gambini, on Jul 30 2009, 04:07 AM, said:

How hard would be making an optional 8bits filter in order to turn all the awesomeness of polymer into the 8bits looking?

Hm? You can run - so they say - Polymer using the old 8bit textures so I don't know what you mean.

[Chip]

Quote

When I started this thread it was supposed to be about Polymer,

Due to the "and Eduke32" in the thread title, it became the generic Eduke32 thread.



Iv'e just found out that my version of Eduke32 (not a polymer build, I'm not that lucky!) no longer draws high res textures properly after once I deleted the old texture cache file generated from a previous build.
I also found out my version of Eduke32 was not the latest but after getting it, the problem still occurs - it fixed nothing, and that build "purged" my texture cache since it was considered out of date. (It generated a new one)
See the attached picture to see what's going wrong.


If I roll back to an old build, say the September 2008 then everything becomes fine.
Basically the newer (well old now) builds of Eduke32 don't work right for me. I'm using an ATI Radeon 4850 with the latest drivers (and re-installed them since I thought they could have been corrupted)

Attached thumbnail(s)

• 

[Tea Monster]

Gambini, on Jul 29 2009, 07:07 PM, said:

How hard would be making an optional 8bits filter in order to turn all the awesomeness of polymer into the 8bits looking?

Why? Ask the question as to why there isn't an 8-bit option in Doom 3 or Gears of War. The intent was to make a modern engine.

[Gambini]

Chip, on Jul 30 2009, 08:29 AM, said:

Iv'e just found out that my version of Eduke32 (not a polymer build, I'm not that lucky!) no longer draws high res textures properly after once I deleted the old texture cache file generated from a previous build.
I also found out my version of Eduke32 was not the latest but after getting it, the problem still occurs - it fixed nothing, and that build "purged" my texture cache since it was considered out of date. (It generated a new one)
See the attached picture to see what's going wrong.

That looks like a texture quality +/or anisotropic filter problem

Check in renderer setup if the hires texture quality is set up to the highest, and if it doesnt fix the problem, check your video card´s software and see if a low anisotropic or texture resolution is causing the this glitch.

Quote

Hm? You can run - so they say - Polymer using the old 8bit textures so I don't know what you mean.

Running polymer with the old textures is pretty close to be what i´m trying to say, but is NOT the same thing. Personally i used polymost for my latest maps not because the hires textures or the models but for the way polymost renders spritework, it makes the things way easier and best looking at the moment of building complex structures with spritework and/or slopped floors, aspects where the good old 8bits Build engine flags.
Still i like a lot more the classic 8bits looking, colours look different -C´MON THEY DO- shading looks different, visibility looks different and so on. And with ¨different¨ i mean better.

There was once a renderer option named 8bits polymost, that combined the 8bits looking with the z buffer (the correct perspective looking up/down) and all the features of polymost but the colours. But it just disappeared and when i asked about it TX said it were not going to be back. Well, maybe polymer can have a sort of this feature, just for the ones like me, that want the old 8bits looking with bigger range of posibilities. I know here in this forum people is more fond to the HRP and all the ultra high corky looking. But there are still alot of players and mappers that love the classic 8bits.

Quote

Why? Ask the question as to why there isn't an 8-bit option in Doom 3 or Gears of War. The intent was to make a modern engine.

I´m not asking for a CGA or monochrome aspect for Duke Nukem 3d, just as nobody would be asking for 8bits in a modern game such as doom 3. It´s just about respecting the authentic game. The search of making duke look like a modern game is good, but still there have to be room for the classic stuff, in my humble opinion of course.

[Sobek]

Chip, on Jul 30 2009, 09:59 PM, said:

*snip*
If I roll back to an old build, say the September 2008 then everything becomes fine.
Basically the newer (well old now) builds of Eduke32 don't work right for me. I'm using an ATI Radeon 4850 with the latest drivers (and re-installed them since I thought they could have been corrupted)

I actually had this exact same problem up until a short while ago. Though honestly I don't recall what fixed it or when that happened. This was only a problem for me in Mapster though, and I noticed that the textures gradually return to normal the closer you get to them... But Eduke32 didn't show this issue. I just chalked it up to more bugs with ATi cards (I'm using a 4870 at the moment), and ignored it for the time being. Then one day it just went away I'm running the Catalyst 9.6 RC3's, as I haven't bothered to upgrade to the 9.7's yet.

I can't offer any real help there sorry, all I can think is that it may have been related to some fixes from the more recent builds of Polymer, but that's just a wild guess at this stage.

[Stabs]

well heres a demo level of that new poly ROR stuff, how i did it anyway, iam assuming all that stuff will get solid in the future and not vanish at certain angles.

plagman & tx am i "doing it right?" is this how you intend to implement it? if so, i'll start incorporating it into eternity.

[TerminX]

Considering there's no ROR in Polymer yet, no, there's not really any way to be "doing it right."

[Chip]

As for my problem, I have found a crappy and temp solution.
In each map (each and every map) go into the options and take down the high res texture quality.....then put it back up. Everything goes fine with the exception of wall blood sprites but they go better.
Problem with this is that it forces Eduke32 to re-render all textures again which means I have horrid jerky frame rate each time I see a new texture but I can counter this by saving the game that instant then reloading it as that'll do all the loading in the loading screen. But I don't really want to have to sit through a 3 minute or so loading screen for each map nor mess around with options.


I only have this problem with the latest 2 builds I downloaded. They are the very latest (non polymer) one and one I downloaded on 3rd Feburary. The one before that I downloaded works fine, that was downloaded on 28 Septmber 2008.
Oh and I've got no problems with Master32 - with any builds.


Here's a thought, I run Mapster32 in a window where I can see my desktop. I run Eduke32 in a full screen. When I change the high res textre detail through Eduke32 in game, as the screen is re-drawn I can quickly see my desktop for a split second, after which the texture errors are gone.
I'll try running Eduk32 in a window and see if the problem occurs and try Mapster32 in full screen to see if that gets effected.

[Plagman]

DanM, on Jul 31 2009, 09:48 AM, said:

plagman & tx am i "doing it right?" is this how you intend to implement it? if so, i'll start incorporating it into eternity.
POLYROR.zip

No, that's most definitely not it. This is just a corrupt map that happens to display differently in polymer. Don't overlap sectors if the overlapping parts can be seen from the same spot. Also, never intersect a white wall with a red wall from the same sector like you said you were doing with a door earlier on. Even it displays properly, the engine doesn't support it. You'll be able to make the same map with proper RoR, though, so just wait for a while.

[Stabs]

ta just needed to know, although, used carefully i may be able to use such an effect to make roof details like girders and vents

[Helixhorned]

Plagman, on Jul 31 2009, 01:00 PM, said:

Don't overlap sectors if the overlapping parts can be seen from the same spot.

Hm, isn't that restriction relaxed for certain constructs when they don't break the gameplay (clipping, etc)? I've attached an example of something I would've loved to do in the old days but which rendered incorrectly (without apparent geometric reasons).

Also, I can't seem to get the SE lights working.. has something about the way they're defined changed at some point?

Attached File(s)

•  notambi.zip (476bytes)
  Number of downloads: 1138

[Sangman]

Gambini, on Jul 31 2009, 01:23 AM, said:

There was once a renderer option named 8bits polymost, that combined the 8bits looking with the z buffer (the correct perspective looking up/down) and all the features of polymost but the colours. But it just disappeared and when i asked about it TX said it were not going to be back. Well, maybe polymer can have a sort of this feature, just for the ones like me, that want the old 8bits looking with bigger range of posibilities. I know here in this forum people is more fond to the HRP and all the ultra high corky looking. But there are still alot of players and mappers that love the classic 8bits.

Disable the HRP def files and you'll be able to play Polymost (and Polymer, I guess) with the 8bit textures, even though you'll be playing in 32-bit mode. Or is that not what you're getting at?

[Stabs]

helix that kind of stuff is perfectly ok, ive been using it for months now without any problems

[TerminX]

Sangman, on Jul 31 2009, 08:25 AM, said:

Disable the HRP def files and you'll be able to play Polymost (and Polymer, I guess) with the 8bit textures, even though you'll be playing in 32-bit mode. Or is that not what you're getting at?

Nah, he's talking about the software driven test code Ken wrote to make sure his Polymost algorithms were going to work out properly before committing to writing an actual OpenGL renderer.

It was:

a) buggy
b) very slow
c) unfinished
d) completely broken by changes made to how EDuke32 renders scenes
e) all of the above

It was never anything designed to actually be playable AFAIK. I don't even know why it was ever made a menu option in JFDuke3D in the first place... that thing had to have been one of the biggest single causes of strange bug reports. I imagine it also drove anyone who managed to see it as their first exposure to EDuke32/JFDuke3D away from the community due to how bad it was. For the last few months it was in there (after the menu option was removed but before it was disabled completely) I think it was even rendering sprites in front of walls they were behind.

Does someone need to make one of those stupid inspirational poster type image macros with a software mode Polymost screenshot and the text "useless renderer is useless" before people stop asking about it? It's never coming back!

[Jimmy]

Do you mean 16 bit? I hated that mode.

[Gambini]

You TX told me once it was buggy, i know. I just wanted to know if you would do a hack to make polymer look like 8bits but nevermind.

There IS a difference between ¨32 bits with 8bits art¨ and ¨plain 8bits¨ Sang-Man! But nobody seems (or wants) to understand me.

A simple example that comes to my mind right now is one of the Source Engine´s shaders. There is an effect that makes the world turn cephia colour in some scenarios, it´s still being the same engine, just the tint or palette or whatever changes to make the screen look like something in particular. Well the same trick could be used to make Polymer look like 8bits, that´s it.

In other news, Polymer inherits from Polymost this issue with transparent sprites/maskwalls. Those basically cancel other sprites or maskwalls that are behind, somebody told me this is very hard to fix.

My idea is this: There are some highres sprites that look transparent not because they have transpacency but because they have a mesh of alpha pixels combined within the entire bitmap. A good example is those shade sprites that some hires mods were using sometime ago.
Well, those fake transparent tiles dont cause this glitch in polymost because they´re not really transparent although they look like. So, if somehow, Polymer could deduce every transparent sprite/maskwall and automatically generate a solid tile with this alpha mesh and store it in the textures cache, the problem should be history I have no idea about how hard would be doing it but i´m pretty sure it will work.

[Jblade]

Quote

There IS a difference between ¨32 bits with 8bits art¨ and ¨plain 8bits¨ Sang-Man! But nobody seems (or wants) to understand me.

I understand you; and I agree, there is a clear difference between the two. It's far more noticable in dark maps than anything else. The way shading and translucency worked in 8bit gave the graphics a certain grittyness that's missing in the new renderers.

[Chip]

As for my texture problem - fixed it!
Apparently the "GL texture compression" causes the problem when enabled...... for my graphics card anyway. I disabled that and I have no problems.


Now, the Eduk32 builds that did work wrote the textures into a folder. These newer builds that don't work write textures into a file (not a folder) so what ever was changed involving that causes the problem for me.

[Fox]

Gambini, on Jul 31 2009, 10:40 PM, said:

Well, those fake transparent tiles dont cause this glitch in polymost because they´re not really transparent although they look like. So, if somehow, Polymer could deduce every transparent sprite/maskwall and automatically generate a solid tile with this alpha mesh and store it in the textures cache, the problem should be history I have no idea about how hard would be doing it but i´m pretty sure it will work.

Heh, such obvious solution. If there can be rendered transparent areas of images, I don't see why that woudn't be possible.

[High Treason]

I have a "better"? iodea about this transpoarency, how about you can state a different image file for each stage of transparency? i'm sure it would be less complicated to code.

That is, of course, if such a feature were included or needed (as polymer might be going to fix it anyway for all we know).

[Gambini]

do you have thick fingers that can´t hit the ¨I¨ or the ¨P¨ key without pressing O?

Your idea would not do a change unless the ¨transparent¨ versions of the image are made the way i mentioned. The transparency problem is not just with the tiles that you set transparent pressing T in Mapster32 but with all the transparences (skin models included).

[High Treason]

Nah, my fingers are fine, i had something stuck between the keys, that might be why.

If i remember rightly, this problem went away in JFDuke3D if you entered "usegoodalpha 0" into the console if it's the one i think we are on about now, but i've already been wrong once by the looks of things.

But the only drawback with that was that it made the edges of some images with transparency look a bit odd, you could play with the alpha related option in SWP in front of some glass to see what this option changed.

[Gambini]

I will try that command, maybe it still works. I prefer myself to have odd borders in transparent tiles that the ugly clip that happens now

[Stabs]

is it possible to code in some experimental flashing for point lights?, they have an extra & shade bit free that could be used

[Razzy]

Wow, the pictures here look increasingly more awesome. o.O I can't believe I almost missed this development.

One request, though... Could someone post a simple map, maybe even just two rooms connected with a corridor, that uses both polymer lights sectoreffectors? Just so that I can check if the spotlight not working is caused by me being a moron and doing something wrong or some compiling error I haven't noticed initially.

cya
Raziel-chan

[Ryan Cordell]

Well, it could be you don't have the Polymer built in version of EDuke32, or you didn't define a specific lotag/hitag (I think it was lotag..) to make the SE be either a Spotlight or a Pointlight. =P

[Danukem]

Two of the new Duke Plus maps already have Polymer lights (Haunted Castle and DPCBP). There might be some in Tribute to Action II as well, but I'm not sure about that one.

[Stabs]

tta2 has plenty of poly light fires in it too kill your framerate, it manages that quite well

i want to do a proper conversion but i need to make all shade values uniform, the new mapster needs 2 features

1) Shade of Selected Sectors

2) Shade of sky, you need the sky to be brighter than the level to make it look right, or just make alt+c carry the shade value over aswell.