[The Commander]

Yes, at first I thought having Polymer as the default render may have been a good option but then the people who are not to smart/don't bother reading shit may not bother to disable it even if they are not using the HRP.
Then what if one of them people go and load a user map that takes certain little effects like the "FIRE" sprite wall aligned and pasted like 16x at slight angles to give the effect of a cool 3D fire, even with out the HRP thats a ton of lights in one spot and would look like complete shit for the users who are not so smart to read and turn things off, then they come here and complain.

So now I agree that Polymer should be made default any time soon.

[TerminX]

DeeperThought, on 15 June 2011 - 08:09 PM, said:

While we are on this subject, one thing I would like --and have requested several times now-- is some way to detect in CON code whether models are being used for sprites. If there were an mdflag for it, that would be very useful. In DukePlus, I could use this to make an informed guess as to whether the player is using the HRP, and then I could have a message pop-up if Polymer is not being used. It would have other uses as well.

Would something like "ifmd3" suffice?

[Awesomebob]

DeeperThought, on 16 June 2011 - 06:34 AM, said:

People with ATI cards are completely fucked, from what I've heard

I don't know if something was done in polymer itself, or if it's in one of the AMD patches, but I can run duke in polymer with no crashes and only a slight FPS drop during busy times.

[The Commander]

Awesomebob, on 16 June 2011 - 11:03 AM, said:

I don't know if something was done in polymer itself, or if it's in one of the AMD patches, but I can run duke in polymer with no crashes and only a slight FPS drop during busy times.

Is that using the HRP 5.0?

[gt1750]

My ATI HD4850 512MB died a week ago after 2,5 years of service so I replaced it with a nice new GTX560 Ti 1GB. I've just tried it with Polymer + HRP 5.0 and ran through Episode 1. I must say I'm really pleased with the difference - no more random crashes, all shadows and lights work and the game runs smoothly (with the exception of the beginning of E1L1).

[Awesomebob]

The Commander, on 16 June 2011 - 11:36 AM, said:

Is that using the HRP 5.0?

Yes it is. Sorry for the late reply. After months of not doing anythign with duke, I downloaded the new HRP, got caught up on snapshots and played through all of ep 1 with out a single problem. Frame rate would dip in the low 20's in really intense parts but other than that, flawless.

[Hendricks266]

gt1750, on 20 June 2011 - 06:55 AM, said:

My ATI HD4850 512MB died a week ago after 2,5 years of service

If you want to get some more life out of it, Google "graphics card baking".

[gt1750]

I've read about that "technique" at local HW forums. My system refused to turn on when that 4850 was in place, so I'm not really sure if that would help. But it's still under warranty, so I'm getting it repaired.

[Danukem]

Quote

* Thin out models in memory by removing unused frames. This saves 200MB with DNE on Polymer.

I just noticed this was in a recent revision. Good job Helixhorned! It seems like you fixing bugs and making improvements on a daily basis. Awesome work.

[Stabs]

I noticed the tror has been updated too, i just get colored bands instead of the HOM glitch now with my test map.

[Danukem]

DanM, on 21 June 2011 - 07:39 PM, said:

I noticed the tror has been updated too, i just get colored bands instead of the HOM glitch now with my test map.

true rainbow over room

[Stabs]

lmao

when that rainbow changes to room i can map again! YAY

but no sorry... iam not risking spending a ton of time on a map with a glitch that might not ever be fixed properly

[Arti9m]

Textures don't cache on disk. I have pretty weak PC (for Polymer) so caching would help a bit. It just quit while loading any level. Also, the game stops while playing recorded demo. (should I post .log?)

[Micky C]

Arti9m, on 24 June 2011 - 02:31 PM, said:

Textures don't cache on disk. I have pretty weak PC (for Polymer) so caching would help a bit. It just quit while loading any level. Also, the game stops while playing recorded demo. (should I post .log?)

Yes, but not in this thread. Do you see the words crash/bug/problem anywhere in the title of this thread? Oh look, there's a whole other subforum devoted to this sort of thing and might be the better place to ask for help
http://forums.duke4....elp-me-threads/

If you're saying the game is crashing when you try to load a level, use this thread: http://forums.duke4....e-crash-thread/

And IIRC, ATI cards have texture caching disabled because it caused an easily fixable bug that nevertheless caused a never ending flow of people asking about 'white boxes' which drove everyone insane. So you can blame people who don't look around before they post, and who don't post in the right place for that one

DO NOT REPLY TO MY POST HERE!!!

[Hendricks266]

Quote

Make the minimum resolution possible 640x480. Sometimes you'd accidentally enter something like 'vidmode 800 60' and crashes would ensue...

This should be 320x200, for classic goodness and really easy debugging of rotatesprite (maybe not any more since TX's widescreen awareness change).

[Tetsuo]

People actually ran Duke3D at 320x200? Sure if they had computers that where already outdated at the time but by the time Duke3D came out I had a Pentium and was rocking the VESA SVGA.... SciTech Display Doctor FTW.. I back then I played it mostly at 800x600. I figured most people played it at 640x480 minimum. Now Rise of The Triad on the other hand... it needed a "fast 486" and was limited to 320x200. That was practically their last FPS game that was made\designed for that resolution. Although I find replaying it at that resolution even with that game doesn't do the artwork justice and it's harder to see than playing a newer port at at least 640x480. But yeah I digress, I don't think Duke3D was designed with 320x200 in mind. To me that's like saying for classic goodness play Duke3D with PC speaker sound instead of sound card (sound blaster, GUS, etc.) sound.

[Daedolon]

Hendricks266, on 26 June 2011 - 04:21 PM, said:

This should be 320x200, for classic goodness and really easy debugging of rotatesprite (maybe not any more since TX's widescreen awareness change).

I still don't understand why the hack applies to 320x200 as well as it makes all classic (and from mods) weapons and on-screen elements crushed horizontally to a 267x200 area (it reads them as 320x240 artwork and resizes it them to the vertical 200px limit). My biggest problem with it that showview still uses 320x200 and is stretched along with the screen, it should accept an orientation argument.

It should only change stuff in 4:3 and 16:9, but alas.

Tetsuo, on 27 June 2011 - 02:09 AM, said:

People actually ran Duke3D at 320x200?

That's what anything displayed on screen defaults (defaulted) to, on 4:3 the pixel aspect ratio of the artwork is not consistent (polymost and polymer do fix this though). That's what the game was made for.

[Jblade]

Can you guys add a 'addammovar' command? There's already a addweaponvar command but no ammo equivilent - I know you could just use the player member ammo_amount but that would ignore what you set the player's max ammo to and than that'd require more code to make sure it doesn't go over the limit. the addammo command doesn't do that so having access to one that'd take a variable would help me a great deal. Thanks

[Radar]

At the end-level stats, why does EDuke32 tell me my "best time" on a map that it's my first time playing through? I've never even played that map to have a best time. The line should be deleted to look cleaner.

[rasmus thorup]

What about a command that centers screen position at horiz and ang levels.

[Mblackwell]

rasmus thorup, on 12 July 2011 - 10:34 AM, said:

What about a command that centers screen position at horiz and ang levels.

Huh?

[Hendricks266]

rasmus thorup, on 12 July 2011 - 10:34 AM, said:

What about a command that centers screen position at horiz and ang levels.

You can get the default values and reset them yourself.

[Helixhorned]

I'm attaching a map that I've been using to tweak the visibility so that it looks approximately the same across the different renderers. (r_usenewshading cvar). Here's what it's all about.

Attached File(s)

•  shadetestror.zip (2.29K)
  Number of downloads: 601

[Micky C]

Just tried out the latest commit, and well done Helix! The transition to dark in polymost looks a lot smoother and less sudden. I could run towards a wall from a distance and watch it slowly get darker. I can't remember exactly how it was before, but this feels much better.

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it
That's some nice work with the BROKEHYDROPLANT and REACTOR2 sprites.

[Daniel]

Micky C, on 24 July 2011 - 06:55 PM, said:

Just tried out the latest commit, and well done Helix! The transition to dark in polymost looks a lot smoother and less sudden. I could run towards a wall from a distance and watch it slowly get darker. I can't remember exactly how it was before, but this feels much better.

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it
That's some nice work with the BROKEHYDROPLANT and REACTOR2 sprites.

im very glad Helix fix this issue, it takes lots of emails with my cr*p English so i draw him pictures how shading should look like and what was wrong with it

pre-1940 builds code:





Proposed version:



1943+ Builds:



i tried contact TerminX in first place but seemed he dont cared about my issue with shading

[TerminX]

It's not a matter of not caring, it's a matter of having 20 million things to do every day and very very little time to spend on EDuke32 anymore currently.

Helixhorned did do a nice job of tweaking my crappy shading algorithm, though.

[Fox]

Hmm, I assume there really isn't a perfect way of doing that, since it's not a question of a mathematic formula for the shading, but it is based on a lookup table that is more artistic.

[TerminX]

You assume correctly. The whole implementation of sector visibility in Polymost and Polymer is just a bullshit hack I came up with that alters the GL fog depth for every object or surface drawn to approximate the results of that lookup table you mentioned. It still looks a LOT better than the original Polymost from JFDuke3D though!

[Tea Monster]

That is so cool

[DavoX]

Awesome!!!