[Fox]

I don't understand what you did. I use animtilerange as an lonely command, not inside an specific { }. That isn't supposed to work, is it? =/

[Sobek]

Seems to work fine for me...

Basically I first define all the frames of the textures I want using DUMMYTILERANGE. Then, immediately after that, I throw my ANIMTILERANGE in to animate the previously defined tiles, exactly as shown in the code there.

Other than these issues getting normal maps to work on the animated tiles, I have no other problems, and the animations play just fine. I don't know if that's any easier to understand

[Plagman]

Sobek, on Jul 29 2009, 06:01 AM, said:

I initially tried creating a normal map for each frame and simply inserting it in the DEF below each texture, just as you would on any other, but that didn't work.

 texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress }
	normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }

You can't do that. You define the normal map as you would with any alternate pal. How is the DEF code supposed to know to which texture the normal map applies with your code? Do:

 texture 9948 {
  pal 0 { file "highres/textures/water/1.png" nocompress }
  normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 }
}

Please also note how I moved nocompress to where it belongs. To answer your initial question, you can't define a normal map with animtilerange like what you were trying to do.

[Stabs]

TX, on Jul 28 2009, 03:26 PM, said:

So, back on topic... anyone still having trouble compiling current svn with MinGW?

i can get 1476 working (the earlier ones wouldnt compile), classic mode only, HRP or dukeplus have no sound & causes it to freeze after you select episode and difficulty

i tried clearing cache and cfgs as a solution but no luck

[Piterplus]

TX, on Jul 29 2009, 03:26 AM, said:

So, back on topic... anyone still having trouble compiling current svn with MinGW?

1476 compiled OK (MinGW gcc-4.3.3), no issues with sound , or Polymer mode.
Although there was some warnings while compiling.
Here is the log:

Attached File(s)

•  log.txt (6.99K)
  Number of downloads: 1071

[supergoofy]

all bugs reports for eduke32 svn builds should reported here:
http://forums.duke4....?showtopic=1180

[Piterplus]

I know that, but it was not a bug report, it was answer to TerminX's direct question.

[supergoofy]

most of the warnings are defined parameters that are not used. this is of no importance.

[Sobek]

Thanks Plagman, you learn something new every day

[themaniacboy]

Can i play this on a Sapphire 4770 HD ?

[Stabs]

wow just fucking wow, its not solid but damn when it is


and people just thought polymer was pretty lights

[TerminX]

DanM, on Jul 29 2009, 07:16 AM, said:

and people just thought polymer was pretty lights

Nope, Polymer is a completely new system of dynamically generating static 3d architecture based on "2.5d" map data. A lot of stuff that would give you the "hall of mirrors" in classic or Polymost will just work in Polymer, simply based on how it operates.

[Sangman]

Okay wow. I didn't know about that, so
mind = blown

[Mark]

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.

[Gambini]

TX, on Jul 29 2009, 04:16 PM, said:

Nope, Polymer is a completely new system of dynamically generating static 3d architecture based on "2.5d" map data. A lot of stuff that would give you the "hall of mirrors" in classic or Polymost will just work in Polymer, simply based on how it operates.

Is not polymost also a ¨system of dynamically generating static 3d architecture based on "2.5d" map data¨? That´s what i always thought at least


(yeah, i know that what Damn did is not possible in polymost)

[TerminX]

The difference is that Polymost tessellates only what you can see, on the fly, every time you draw a frame (e.g non-static 3d geometry), whereas Polymer maintains an actual 3D representation of the 2.5D map in memory at all times.

[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: 970

[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?