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

[MusicallyInspired]

It's too bad. I'd love to see the polymer renderer with models, normals, etc and everything all on 320x200 with 256 colours. That'd be neat. Purely hypothetical curiosity: isn't there some kind of conversion that can be made post-render to scale down the colours to their nearest 256 equivalents? I guess at the end of the day that wouldn't really have the same effect as actual 8-bit mode, though.

[Night Wolf]

Here's a few shots of the differences between 8bit software mode and 32bit mode
there are differences which sadly affect the atmosphere of the game.

Left: software mode / Right: 32 bit mode







Edit: note: There's something odd with The Abyss level in 32 bit mode, some walls come out black and textureless as you can see in the bottom right screenshot.

[Danukem]

ozz, on Oct 15 2010, 09:55 PM, said:

Edit: note: There's something odd with The Abyss level in 32 bit mode, some walls come out black and textureless as you can see in the bottom right screenshot.

That's because the default shading scale is off in 32 bit mode. It affects a lot of maps, not just The Abyss. You can fix this by opening the console and entering:

r_shadescale .99

Higher values can work too. DanM uses 1.05 for example.

[Helixhorned]

Plagman, on Oct 15 2010, 06:17 PM, said:

Widescreen isn't really supported either.

Not directly at least. It seems that the classic/Polymost code always assumes a fixed screen aspect ratio of 4:3, irrespective of the actual resolution. In our times this assumption is wrong because there are monitors with other ratios and because the user could be playing in practically any windowed resolution.

[LkMax]

ozz, on Oct 16 2010, 01:55 AM, said:

(...)
Edit: note: There's something odd with The Abyss level in 32 bit mode, some walls come out black and textureless as you can see in the bottom right screenshot.

DeeperThought, on Oct 16 2010, 03:50 AM, said:

That's because the default shading scale is off in 32 bit mode. It affects a lot of maps, not just The Abyss. You can fix this by opening the console and entering:

r_shadescale .99

Higher values can work too. DanM uses 1.05 for example.

Yep, but I think the closest scale value to 8-bit is 1.15
Not so dark and not so bright.
You can try it see if it gets better.

[Helixhorned]

Only classic/Polymost is new code, note the exaggerated aspect ratio of 8:3 and the different handling of HUD rendering (which I didn't change).

[Tea Monster]

Is there any way of re-producing that artificial darkness that haunts far-away corners of the map? I would only recommend 'fixing' this if you could for Polymost. I don't think it will work with Polymer (screwing up lights and so forth).

[Hendricks266]

I request that an option be added to the 32-bit renderers to revert shading to the 8-bit classic style (PALETTE.DAT/TABLES.DAT) for all non-hightile resources, with an associated CON-accessible userdef structure member. I'm not the only one who wants this.

[Plagman]

You realize this is a _lot_ of work, right?

[MusicallyInspired]

Yeah, I don't really expect this to be done. It's only for a neat effect anyway. Not worth it.

[Danukem]

imo the most important things to do for Polymer are fixing bugs and improving performance. Anything else would be a bonus.

[LeoD]

Are serious performance improvements possible or will the engine put a limit on that? If DNifever should run fine on my current PC I wouldn't go out to buy me a new one just to have good framerates on DPCBP to be honest.

[Micky C]

I've noticed for spotlights that there's an area when facing down where sprites won't case shadows. I'm guessing that it has to do with which way the SE is facing, and when sprites including the player are under it or behind them they simply don't case shadows. I hope it's not too hard to fix.

[TerminX]

LeoD, on Oct 17 2010, 04:40 PM, said:

Are serious performance improvements possible or will the engine put a limit on that? If DNifever should run fine on my current PC I wouldn't go out to buy me a new one just to have good framerates on DPCBP to be honest.

Yeah, major performance improvements can and will happen in the future.

[DavoX]

Latest snapshot of Mapster32 crashes after I open a map for the second time... really annoying to start over mapster again and again. Had to revert to a previous version.

Using HRP.

[Jblade]

I know I've asked this a few times before, but will we see a raise in the max number of sounds we can define? I've almost reached 2000 in the AMC TC, and I know I'll hit the limit soon rather than later (Things like cutscenes, character specific lines, even more lines for enemies and stuff)

[LeoD]

TX, on Oct 23 2010, 03:26 AM, said:

Yeah, major performance improvements can and will happen in the future.

[Hendricks266]

I updated my building script to include the extra DLLs and the debug executables to reflect the changes Plagman has made to synthesis.

In the SVN, tiles.cfg should be moved out of the samples/ dir back into the directory above it. Everything else in samples/ is fine where it is.

I also wanted to pop in here and say that I'm taking a C++ programming class. It's been quite easy so far because of my experience with CON scripting. We're still doing really basic stuff, but I hope at some point to become an active developer of EDuke32.

[kenia]

i hope you will, but learning C / C++ is just the very first small step for doing so. Im programming since 6 years now (c++, java etc.) but I never had the time
or motivation to read through the source, too much code, too less motivation hope you are different to me