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

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

[Daedolon]

It's finally fixed? That's great news.

[Roma Loom]

Is it possible to implement a feature in mapster32 where you can highlight a sector by entering it's Number?

[Helixhorned]

You can already do that by entering

do sethighlightsector <sectnum> <set?>

in the OSD ('do' can be omitted if 'osdtryscript' is set to 1 in mapster32.cfg).

[Roma Loom]

Great, it really works Thanks.

[Hendricks266]

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

Also congradutaions on your first commit hendricks, even if you did have to go back and fix it

I made the commit but I forgot to make the announcement!

New Feature: CON/DEF Modules

This is a gradual step towards my goal of a much more user-friendly method to mix and match mods, packs, and generally anything distributed for EDuke32.

CON and DEF modules are individual, stand-alone files that are in effect included after, or from the end of the previous file, whether it's the default root file or another module.

This should make life easier for creators of small gameplay mods, as well as mappers who want to add only small things to the con files (such as an episode listing or some new sprite code) but don't want to restrict use to only a certain set of base cons.

Internally, a dynamic array stores the file names of modules, so there is no limit on the amount you can use other than available RAM.

Here's an example of the syntax: eduke32 -xgame.con -mx module1.con -mx module2.con -hduke3d.def -mh module.def

Disclosure: I used the term "module" rather than "mutator" because in the discussion in IRC channel, there were some strong opinions that mutators should not be added unless the names of gamevars were mangled by the executable to prevent conflicts. I think that's unnecessary, and there are times when you might want to change the value of a gamevar used elsewhere. Regardless, you're free to refer to them as mutators.