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

[Mblackwell]

I believe there's a set of con commands that allow you to precache things that aren't present in the map.

Mods like Attrition or DP could use it, but other than that you're SOL since there's no way of knowing everything that might end up being shown in a level/mod.

[Mblackwell]

Tea Monster, on Oct 6 2010, 04:17 AM, said:

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.

Not talking Duke, but I've been using EDuke32 to produce very model heavy mods, with only limited sector props (where it makes sense) and it's quite easy to make something that looks at least as good as HL2 (or better) without even using Polymer. With Polymer it's possible to do better still, but that relies on the quality of assets you have.

People that think there's no point in working on something more modern using the engine don't have much to stand on.

[Daedolon]

I just wish clipdist could be given three dimensional values.

[Mblackwell]

Well, even a box shaped clip rather than a sphere (as an option) would be helpful.

[Hendricks266]

There should definitely be options between spheres, cylinders, and boxes.

[Helixhorned]

I'm pretty certain that by default, sprites are clipped by a square in the xy plane due to how clipmove works. Moreover, the bounding box is always aligned parallel to the grid lines. Here's a picture of an experiment carried out in Mapster showcasing how the clipdist values of two sprites affect the clipping when the green one is moved against the purple one (note: the current revision uses a constant clipdist).



First, note that the angles of the sprites don't play a role. Also you can see that the clipdist value is interpreted differently depending on whether it's the moved or stationary sprite: in the latter case, the distance is multipled by 4. Finally, whether the actual clipdist value of the sprite will be used depends on its type. Enemies for example use hardcoded values in most of the cases (search actors.c for "clipmove"). But back to topic, the wish for different clip types is probably for architecture, no? I think the best way to simulate, for example, a cylinder clipping for immobile structures such as a column would be to surround it with blocking, invisible, wall-aligned sprites around the perimeter.

[Mblackwell]

Yes, this is what people do currently. It works mostly but it makes building much more difficult. There are some objects that it becomes nearly impossible to do it correctly for. Additionally there are certain types of objects that you may want to move in-game which starts making the whole thing fall apart without a lot of terrible hacks and some praying.

[Helixhorned]

What kind of objects?
There's one kind of extension I can think of that would be relatively easy to code, namely specifying the clipping boundary by a closed loop of line segments around a sprite. Having more sophisticated clipping for the z plane would be tricky. However, there's the problem of the interface and (backward) compatibility. After all, it must not depend on the rendering options due to sync.

[Danukem]

Helixhorned, on Oct 11 2010, 02:52 PM, said:

What kind of objects?

Like just about any vehicle (school bus, flatbed truck, sedan). It's not practical to make lots of invisible flat sprites moving along with it, but without something like that the clipping will be hopelessly bad regardless of what clipdist you set.

[Night Wolf]

I have a question...
Is it possible to play classic software mode Duke 3d in widescreen?
the other renders mess up the original colours.
I want to play true 8bit Duke 3d in widescreen, with none of that weird viewing angle that the dos version had...

[Plagman]

Unfortunately, real 8-bit rendering goes hand to hand with the perspective problems associated with the software renderer. Widescreen isn't really supported either.

[Night Wolf]

Damn that's a shame, I always admired the classic render, has a different feel to it.