[Oliosis]

TX, on Jul 16 2010, 09:06 AM, said:

Maybe. I thought about it at one point and I think I decided against it because the light would need to be a spotlight (more resource intensive) and it would be horrible in usermaps where you have a bunch of those sprites going around a helipad or something like that.

You could just add a tag to the engine to make it so that it either will have the effect, or it won't.

Or make it use a specific palette number.

I dunno, just my suggestion.

[TerminX]

Right, but that would defeat the purpose of automatically adding lights to specific sprites found in maps.

[Tetsuo]

Speaking of lights I noticed in eDuke32 when working properly things get brighter around a certain area around Duke like he has some kind of illumination. On my system there's a bug which makes this happen in reverse where things get darker as he gets near them. I don't think Duke should illuminate the level at all unless he had a flash light. Any chance of removing that or making it togglable?

[Micky C]

Are you using eduke32 on windows? because I have that bug on my mac version of eduke32, although it might be because it has an ATI card. I also second making that 'illumination' optional, as things can look great at a distance in polymer with dynamic lights, but when you want to have a better look and get close the lights fade out and it doesn't look anywhere near as good

[path0s]

This is my first loadup of polymer and eduke32, so newb here.. I do have to ask if the slow and choppiness with polymer turned on is normal or if it's some kind of a system problem. Here's as much specs as I can think of:

Software:
Win7 x64
Directx v11, OpenGL 3
eduke32 win32 20100831-1705
polymer hrp 132

laptop's hardware:
Nvidia GTX 260M - Driver version: 258.96
Mobile Intel Core 2 Quad Q9000 @ 2ghz
6G Ram

Eduke while it's running with polymer never tops out any core at above 50%, so I'm assuming it's something to do with the nvidia driver. Turning off polymer and just loading the hrp lets me run at well over 60fps, with polymer on it's probably averaging 10fps overall, if that. Definitely not playable by anyone's standards, impossible to aim/etc.

Here's the eduke32.log file:

EDuke32 2.0.0devel 20100727
Using C:/Games/Duke Nukem 3D/ for game data
Windows 7 (build 6.1.7600) w/ nedmalloc.dll
Initializing DirectDraw...
Searching for game data...
Using 'duke3d.grp' as main game data file.
Using file 'autoload/polymer_hrp132.zip' as game data.
Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
GAME.CON: In actor `ORGANTIC':
GAME.CON:3968: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5891: warning: found `else' with no `if'.
Found 2 warning(s), 0 error(s).
Resizing code buffer to 16187*4 bytes
Script compiled in 20ms, 16179*4b, version 1.4+
1918/11264 labels, 321/2048 variables
125 quotes, 207 actors
Initialized 24.0M cache
Loading 'duke3d.def'
warning: defined hightile replacement for empty tile 9000. Maybe some tiles???.art are not loaded?
warning: defined hightile replacement for empty tile 9001.
Definitions file 'duke3d.def' loaded.
RTS file DUKE.RTS was not found
Initializing OSD...
Initializing DirectInput...
  - Enumerating attached game controllers
  - No game controllers found
Uninitializing DirectInput...
Executing "settings.cfg"
Disabling desktop composition...
Setting video mode 1600x900 (32-bit fullscreen)
OpenGL Information:
 Version:  3.3.0
 Vendor:   NVIDIA Corporation
 Renderer: GeForce GTX 260M/PCI/SSE2
Unable to open cache index: No such file or directory
Initializing Polymer subsystem...
PR : Initialization complete.
Initializing music...
Initializing sound...
PR : Board loaded.
Loaded map hack file '/E1L1.mhk'
Cache time: 52926ms
E1L1: HOLLYWOOD HOLOCAUST
LARGE MEDKIT: +30
 
Wrote eduke32.cfg
Wrote settings.cfg
Uninitializing DirectDraw...

[Master Fibbles]

Do you have any major process hogs running the background? Your system and such seems like it should run polymer without any major problems.

[Tetsuo]

Micky C, on Sep 6 2010, 02:35 PM, said:

Are you using eduke32 on windows? because I have that bug on my mac version of eduke32, although it might be because it has an ATI card. I also second making that 'illumination' optional, as things can look great at a distance in polymer with dynamic lights, but when you want to have a better look and get close the lights fade out and it doesn't look anywhere near as good

Yes that's right, it's with the Mac version. It doesn't have the same set of bugs I notice people with ATI cards have on Windows but it has a couple of bugs... that one and another one that seems to be a memory leak where after a while sectors outside the one you are in stop drawing.

Getting back to the illumination thing I think it's also unrealistic for Duke to for no reason have his own illumination in general. No other game with similar rendering does that as far as I know.

[path0s]

Mr.Flibble, on Sep 6 2010, 05:36 PM, said:

Do you have any major process hogs running the background? Your system and such seems like it should run polymer without any major problems.

Nothing major, no. CPU history graph on the cores dont show any usage higher than 50% on any core while it's running, which leads me to think it's some kind of driver incompatibility or something with the gpu. The gpu does heat up pretty well though, goes from ~70c idle to 80-85c while chuggin in duke. I dont have any other way to guage the load on the gpu, but I'm guessing it's at 100% or so
-------------

Ok.. Very odd. Works like a champ now. I rebooted, tossed the roland sc55 pack into autoload, and turned the fps counter on. Now I'm getting 40-90fps with no problems. Got no idea, I'm sure the reboot fixed it, but I didn't change anything with my gpu settings or the game settings. I dunno, I'm happy that works great now, but if there's anything I can do to try to get to the bottom of it, let me know

[Mark]

EDIT:

Almost 900 views and no responses. I will post it in a more proper area of the forums and hope for better luck.

[Hendricks266]

Could you add a command-line parameter, "-rts"? I want the major source ports to support this, so YANG could add ability to transfer RTSs like it does user maps. Viva la RTS!

[DavoX]

Any idea why this might be happening? it seems Mapster32 now can have even bigger maps (Probably everyone knows this already, but I haven't touched it in a year or more) So I'd like to place my map at the middle again, so I can finish this damn thing, how to do that?

[img width=150 height=94]http://img832.imageshack.us/img832/6851/problemjl.th.jpg[/img]

[HellFire]

First you need to change the grid extent, to do that open mapster.cfg and edit the value of "editorgridextent" with an higher value.

[Helixhorned]

A while ago, TerminX reverted the maximum editorgridextent to 262144 from 524288 (probably due to overflow issues?), so some maps which were built with old limits may now lie outside the boundaries. For your problem, entering

do for i allwalls sub wall[i].y 16384, for i allsprites sub sprite[i].y 16384

a few times in the console should do fine. Note that you shouldn't usually change wall x/y values in this direct way.

[Daedolon]

Wouldn't it be safer to open the map with a previous version and move it?

[DavoX]

Already done that and fixed it, thanks!

[Hera]

EDIT: Damn, I think I posted this in the wrong thead... :|

Hi Newb with major issues here,

This is most likely a know bug, but eduke32 has major memory use issues. (I have the latest eduke32 aquired from eduke32.com)
These issues appear with the High Resolution Pack enabled. I also have dukeplus, but that most likely is not the issue...

To reproduce,
1. Make sure that you have like ~1.3GB free memory. (2GB minus allocated video memory minus Windows 7 overhead)
2. Run eduke32 with the HRP. (1080p)
3. New Game L.A. Meltdown
4. New Game The Birth
5. Low Memory Crash
6. Restart eduke32
7. New Game The Birth
8. No Crash.
9. Restart eduke32
10. Set textures to low (they on medium by default. logic: low textures = less memory = less crashes)
11. New Game The Birth
12. Holy Mother of God Low Memory Crash

So low textures make things worse.
And some memory is not de-malloc-ed that was malloc-ed.

A few things I noticed,
1. Windows complaints of low memory when eduke32 loads. (This makes no sense, playing intro video and loading the menu shouldn't use lots of memory or take a long time to load.)
2. The high resolution atomic logo flickers when loading.
3. Text is blurry when loading, it like one character is blurry other is not.
4. There are visual hints that eduke32 will crash. The loading screen becomes corrupted, the loading bar becomes some other texture, and so on.
5. By low memory crash, I mean just that. eduke32 eats up all memory, crashes. Windows brings up warning.
6. By Holy Mother of God Low Memory Crash, I mean the closes you can come to a BSOD before the BSOD. The Nvidia driver crashed, Task Manager did not have enough memory to load itself - had only two tabs - showed 0% RAM and 0% CPU (I think it couldn't load those due to low memory). There was some other error as well from eduke32... Killing eduke32 which showed a black screen set everything baleaks.ck to normal. I had this happen with FF4 when FF4 D2D had massive memory leaks.

Help would be appriciated.

Also other things not so related,
1. Loading HRP content doesn't actually load all the HRP content necessary. There is minor pause before the first kick, before the first dead enemy, so on. So some things get loaded on the fly?
2. eduke32 runs ~200FPS, a monitor can display anywhere form 60 to 120 frames per second. Any reason for the FPS cap-less-ness ?
3. HRP performance seems to suffer just as is, sure FPS is always above 60, but still lower than I would expect considering I am not using the new lighting code...

Specs and other Information,
Intel Atom N270 @ 1.6Ghz
2GB DDR3
Nvidia ION
Windows 7 x86_32

I assure you, it is up to date.

[Sebastian]

Just wanted to post some shots again.

[KillerBudgie]

Ooh. That looks very nice. Duke Nukem: War of Attrition + Polymer = Absolutely brilliant!

[Night Wolf]

Been getting a weird problem lately, when exiting the game from E3L1 eduke crashes, have to go to task manger to close it.
The worst thing is, when I launch eduke again all my setting are then set to default, which is frustrating.
Haven't had this problem with any other levels.

[Mr.Deviance]

The problem with polymer and Duke3D is that no matter what you do to it, it will never look right until you start remaking the levels entirely.
High res textures + bump maps and other cool effects, simply don't go well on those low quality limited maps.
If somebody would be talented enough to remake the Duke 3D maps in a way so they feel exactly the same like the originals but look more detailed, so that higher res textures with bumpmaps don't look so strange in the game.
Polymer + high res textures + old maps are like taking quake 1 character models and adding bump maps and high res textures to them thinking that you can make them look realistic even though their heads and other body parts are perfectly cubical.

[Danukem]

Mr.Deviance, on Oct 4 2010, 10:27 PM, said:

If somebody would be talented enough to remake the Duke 3D maps in a way so they feel exactly the same like the originals but look more detailed, so that higher res textures with bumpmaps don't look so strange in the game.

There's actually plenty of people in the community who have the skills to do that, but so far those people have been more interested in their own new projects. The closest thing to what you want is Duke Nukem Eternity with maps by DanM, his levels are supposed to be inspired by the original ones (e.g. the first level has a movie theater like E1L1) and they use Polymer with models etc. But the original levels are only loose inspiration and DNE feels very different, not much like the original levels at all.

As I have said in a different thread, this would be a good idea and it would get people excited about the HRP again. It might be kind of boring and limiting for the level designers, though, I'm not sure.

[Tea Monster]

DeeperThought, on Oct 4 2010, 10:41 PM, said:

There's actually plenty of people in the community who have the skills to do that, but so far those people have been more interested in their own new projects. The closest thing to what you want is Duke Nukem Eternity with maps by DanM, his levels are supposed to be inspired by the original ones (e.g. the first level has a movie theater like E1L1) and they use Polymer with models etc. But the original levels are only loose inspiration and DNE feels very different, not much like the original levels at all.

As I have said in a different thread, this would be a good idea and it would get people excited about the HRP again. It might be kind of boring and limiting for the level designers, though, I'm not sure.

I think most people are waiting for DNF to come out (particles, proper animations, mature renderer) before they start something like that. A quick poll of some pro-level modellers came back with a general feeling that they would be wasting thier time producing stuff for EDuke due to the amount of sector based props which would clash with the next-gen feel of any new props and models. Previously, I've advocated that we move away from sector based props and there was a general feeling from others here that this would 'ruin the feeling of Duke'.

That is another problem with this forum in general. A lot of the people here sneer at any kind of change. They very vocally deride the HRP and the people who work on it. There are stilll mods being issued that use 8-bit art. That in itself isn't a bad thing, but whenever you try to move the look of the HRP forward, you have to fight all these people to get any change done. I've been advised by a number of people outside the project that I'm wasting my time here and I'm beginning to agree with them.

[Danukem]

Tea Monster, on Oct 5 2010, 12:35 AM, said:

I think most people are waiting for DNF to come out (particles, proper animations, mature renderer) before they start something like that. A quick poll of some pro-level modellers came back with a general feeling that they would be wasting thier time producing stuff for EDuke due to the amount of sector based props which would clash with the next-gen feel of any new props and models. Previously, I've advocated that we move away from sector based props and there was a general feeling from others here that this would 'ruin the feeling of Duke'.

That is another problem with this forum in general. A lot of the people here sneer at any kind of change. They very vocally deride the HRP and the people who work on it. There are stilll mods being issued that use 8-bit art. That in itself isn't a bad thing, but whenever you try to move the look of the HRP forward, you have to fight all these people to get any change done. I've been advised by a number of people outside the project that I'm wasting my time here and I'm beginning to agree with them.

People object to editing the original levels to replace sector based props with models, and for good reasons. Models in Eduke32 currently cannot be made to block/clip accurately, since no matter what they look like they are all essentially just squares with a blocking sphere as far as the game is concerned. Also, they can't have buttons/switches/doors etc. on them because they do not have walls. Those are my objections, and I stated them at the time it was brought up. But these objections only apply to editing the old levels. If one were remaking the levels from scratch, then of course one could use modeled props all over the place with no loss, because the levels would be designed a bit differently. If you want to make a modern looking game, then obviously you can't rely on sector based props. Sectors are good for floors, ceilings, walls, doors, and many other things that are rooted to the ground, but not for detailed objects with the potential for independent movement.

Working on EDuke32 might very well be a waste of time for you and other modelers, depending on your long term goals. But if that's true, it's certainly not because there are some people around who "sneer at change". No one is stopping anyone from remaking the old levels for Polymer and trying to make it more like a modern game. If some people don't like it or aren't interested, then that's within their rights, and it's within your rights to ignore them. If the project is good it will attract people from outside the community and it won't matter what the naysayers think. So really what it comes down to is whether the imminent release of DNF makes such a project irrelevant and unworthy of the effort required to complete it. I have to admit, I'm not sure. In any event, I would like to see DanM release a completed version of Duke Nukem Eternity before DNF is released, and I'll try to help him with code as much as I can.

[Hank]

DeeperThought, on Oct 5 2010, 01:41 AM, said:

There's actually plenty of people in the community who have the skills to do that, but so far those people have been more interested in their own new projects. The closest thing to what you want is Duke Nukem Eternity with maps by DanM, his levels are supposed to be inspired by the original ones (e.g. the first level has a movie theater like E1L1) and they use Polymer with models etc. But the original levels are only loose inspiration and DNE feels very different, not much like the original levels at all.

As I have said in a different thread, this would be a good idea and it would get people excited about the HRP again. It might be kind of boring and limiting for the level designers, though, I'm not sure.

Maybe just maybe – why not un-dust the best maps from the community, and make them into 2010 look-a-likes? Who is gonna play those Duke Nukem 3D maps? Honest. I am very impressed with what you guys did, but playing Duke Burger again? Or re-doing 3DRealms tiles? Unless there is a gravity environment, or something to remind one, that one is on the moon, eleven of those Duke maps are not worth it.
Also. The Duke Aliens – even Harry Potter books said(wrote) Aliens are boring’. I agree. There are a horde of enemies, of older TCs worth doing. Platoon, Zero Hours etc. How about Killer Bees, snipers ( hated to death ), poltergeists and what not? Since we got the source and a shitload of hidden treasures why not combine that instead of promoting Duke?

@ the post after the quote: As for people worried about they wasting their time – well, if you plan to make commercial games, yes you are. The latest available engines overshadow even the older ( a year ago ) engines let alone the upgraded Build engine. So what, where is your heart? If you know how to make models, do them in 3D Max or True Space and port them to whatever engine it needs to go into. The models are always yours! You can charge cash for them if someone wants them! If no-one wants them, well, maybe your model sucked!

As always, all my posts should be taken with a grain of salt.

[Searinox Navras]

I know it's a bit sudden, likely off whatever you're discussing, and easier said than done. But would it be possible to modify EDuke32 in such a manner that it stops using or needing the on-disk texture cache at all?

That thing's always been slow, space-consuming, and has bugs with compressed NTFS, which I have on all my drives except the OS drive. It has always been sluggish, even when all texture levels are loaded it never loads the HUD weapon graphics or their palette swaps which happen under certain lighting, gibs, frozen enemies, and a few other circumstances. This results in unexpected lag during some parts of the game as it still needs to load some textures in gameplay. Also it's got some serious compatibility issues with DukePlus, and some of those levels load corrupt textures which end up lagging the graphics TONS, by tons I mean one frame per 10 seconds! They also outright crash loading some levels unless preload level textures is off.

But the point here isn't what bugs the ODC has. The point is on-disk texture caching is an old and outdated concept, and the engine would be much better off without it. Currently its in-memory texture loading is slow and has oversights on loading some textures at load time just like ODC. I really think this mode should be optimized and the ODC thrown out the window. I've had the chance to play with the Doomsday Doom engine lately and I've seen how quickly it loads stuff without the need of an ODC. And Doomsday has hires texture and model packs just like EDuke32, I don't see why it couldn't be done.

The EDuke32 engine has come a long way and some of the things I see being implemented in latest builds push the graphics to literally contemporary standards! Most of the game's textures are... "cartoony", that is to say their colors and shading are poppy and not too realistic. But when I used the most recent HRP and EDuke32 binary to go into the bank vault in E3M2 I saw exactly what this thing is capable of! It was surreal, and beyond anything I've seen in other parts of the game! With graphics this good being loaded and cached in such an old way, something really feels wrong.

You're probably all busy working hard on light upgrade for the original DN3D levels or bugfixing the engine, but give the ODC a look please. It would REALLY be worth it!

[Micky C]

Well you can switch off 'pre-load map textures' in renderer setup, which lets you skip right to the game instantly. It does tend to cause a bit more lag at the start of the level, and when you come across new textures, but that hasn't been so bad for me, and I only preload map textures when making an ingame video with fraps and polymer (very power hungry)

[Searinox Navras]

This is the only mode that should be left in the engine, and be as fast as other game engines with it. The team is putting so much effort into optimizing the engine, new features, making sure it stays fast, yet texture loading remains a bottleneck. Again, even with ODC enabled not all textures load, and sometimes firing a new gun under a new lighting for the first time chokes the game, and this unearths the problem's core - the ODC exists to quicken a memory texture loading that is very slow. And both memory loading and ODC have the problem that they do NOT anticipate ALL the types of textures that might be loaded during the level. From HUD weapons, menu font textures, frozen enemies, and variations of all of the above under color-changing lights, it should all be precached.

[Tea Monster]

Thats the big problem with EDuke though. If I run into a problem, or I think we could make some really cool maps if we had (using your example DT) clipping, the devs response is that if I want that feature, I should go "use another engine".

Thats fine if you want to make models for Crises, or Unreal Tournament, but for Duke, you are screwed. There are signs that Gearbox will be a lot more lenient towards mods using other engines, but that doesn't change the perceived attitude here.

With Polymer in place, there is little to stop the HRP looking damn-near like what you find in a modern game. As an artist and a modeller, I can picture in my head what it could look like and how kick-ass it would be. When nobody else gives a f*ck when you try to convince them, it's very disheartening.

[Plagman]

What problems or features are you specifically referring to here?

Searinox: the point of a primed texture cache is to _reduce_ loading times, and it does just that as far as I can tell. Playing without precaching of any kind results in the game running choppily all the way through the level as it finds new textures to load. Playing with precaching but no on-disk texture cache results in precaching taking _very long_ because all textures have to be compressed on the fly. Playing with precaching and the on-disk cache enabled and primed is the optimal case, as it only takes a few seconds to load a level and the only choppiness you get is whatever the caching logic is missing, currently I think alternate texture maps for HUD models and maybe some other cornercases. Of course there are bugs (albeit long-standing) but detailed reports are welcome. :-)

[Searinox Navras]

Okay it doesn't matter as much to me what ODC does since I can always swap to memory if I want to. The big problem, that affects both modes, is indeed that caching logic is missing for quite a number of things including HUD weapons, menu and UI textures including that of fonts, blood and gore effects, explosions and shrinker/expander hit effects, sprited projectiles such as shrinker, expander, and tripbomb lasers, bullet marks, explosion marks, flames, squish-generated stringy guts, glowing enemies and other nightvision-triggered glow, frozen enemies aswell as their frozen gore, textures for some toggled switches such as access card panels.

ALL of this stuff is omitted from precaching and should be part of the loading. Additionally, it seems that ALL textures need to be re-cached when subjected to hue-changing lighting. For example in the stripper bar all weapons, wall textures, monsters, explosions, everything needs to be recached under the new lighting. As far as lighting logic goes, I would REALLY really recommend that some game engine logic be changed, and the textures be CAST LIGHTING of that color onto them instead of modifying the texture's data and thus requiring a separate caching for color-changed textures. This would not only prevent all of that infernal re-caching but also add more realism, I still go WTF when I see blue or green explosion plumes in certain areas just because there's a slight blue/green tint in the lighting. Believe me removing the alternate coloring from textures would remove a LOT of nasty in-level precaching instances and much of that unexpected sudden choppiness and would visibly result in a GREAT improvement in performance.

I know ODC is supposed to make things faster, but I was trying to stress that it's a dated concept, and most engines nowadays can do it fast and put all of it in the memory.

EDIT:

@Hera "4. There are visual hints that eduke32 will crash. The loading screen becomes corrupted, the loading bar becomes some other texture, and so on."

Got that problem too, especially when loading some DukePlus levels. Again this is in the precaching stage and is what I meant in the earlier post where I said ODC is buggy.