[Mike Norvak]

 DeeperThought, on 02 October 2011 - 05:05 PM, said:

Some maps have glitchy doors. If you've ever tried making swinging doors, you know how easy it is to mess it up with this kind of result. Unless you can show that the problem is being caused by a recent change in EDuke32, the most reasonable assumption is that it is a problem with the map.

It should be caused by a recent change in EDuke, since that door has always been working. Maybe something about what is rendered first thing?

Attached thumbnail(s)

• 

[Plagman]

Could be related to the changes Helix made to the Polymost drawing algorithm for TROR.

[Mike Norvak]

 Plagman, on 02 October 2011 - 07:50 PM, said:

Could be related to the changes Helix made to the Polymost drawing algorithm for TROR.

Well it looks correct with r1871 o.O Gonna check the last revision that works fine

EDIT: Glitch was introduced with r1887 Yep TROR was also introduced with that revision...

[Helixhorned]

It was a bug with dragpoint() since the first TROR revision! Good thing it's out of the way now.
---

I'll be away till the 16th, but maybe I'll find a way to keep in touch.

[Tetsuo]

Since my builds tend to have fullscreen broken I like to get builds from you Helixhorned so are you going to do another one soon? Oh wait, he's gone until the 16th...

Don't mind me in this post anyone else.

[Mark]

 Plagman, on 02 October 2011 - 02:26 PM, said:

I haven't changed anything in Polymost; can you send me one of the models that's problematic in the new version?

Email with 2 models and skins has been sent. Thanks.

[Danukem]

I think someone else asked this recently, but I don't remember where, or if they got an answer.

Is there an easy way to prevent the "CACHE SPACE ALL LOCKED UP!" crash? Apparently it happens when too many hi-res sprites are being drawn. I could reduce the number of sprites, but I'm wondering if there is a way to increase the cache size.

EDIT: Nevermind, I found the cachesize command.

But is it really necessary for the game to crash? Couldn't it dynamically increase the cachesize or do something smart like that?

[Stabs]

plagman iam not sure if you aware of this as i dont think many people use it but splitting sectors so a se49 cannot see a sector and therefore not cast light into that sector does not seem to work within TROR stacks

[TerminX]

DeeperThought, on 03 October 2011 - 09:19 PM, said:

But is it really necessary for the game to crash? Couldn't it dynamically increase the cachesize or do something smart like that?

It could, but it would introduce a slew of new actual crashes to hammer out before it ever worked right. Changing the cache size after the engine is initialized like that would involve changing the location in memory for every 8-bit tile, non-ogg sound effect, etc, I guess the game could be saved and the engine could be transparently reinitialized with higher cache values but there would certainly be a long pause during this process, probably to the extent of having to throw up a loading screen during it.

It's a lot better of an idea to just specify a larger cache in your def files.

[Hendricks266]

TX, on 12 October 2011 - 07:12 AM, said:

Changing the cache size after the engine is initialized like that would involve changing the location in memory for every 8-bit tile, non-ogg sound effect, etc

/me shuffles to the to-do list of things too ambitious to do

(as in not requiring massive repositioning)

[Ronin]

The way you guys are working, Duke 3D will probably keep getting better until eventually it becomes god.

[Micky C]

When I first read that, I thought you said they'd keep working on it until it becomes 'good'.

Anyway I second DanM on the slicer tool for mapster, it would be a huge time saver. It doesn't even have to be a slicer tool per say, it could be if you draw a red line over one or more red lines, and connect it to a wall at the other end of the room, a point is inserted at each intercection, with the red line going through all points. Maybe it could ask if we want points to be inserted like with the copy and paste.

[Ronin]

Micky C, on 13 October 2011 - 04:58 PM, said:

When I first read that, I thought you said they'd keep working on it until it becomes 'good'.

Anyway I second DanM on the slicer tool for mapster, it would be a huge time saver. It doesn't even have to be a slicer tool per say, it could be if you draw a red line over one or more red lines, and connect it to a wall at the other end of the room, a point is inserted at each intercection, with the red line going through all points. Maybe it could ask if we want points to be inserted like with the copy and paste.

HAHA no I love it and only recently have I got a pc powerful enough to run stuff like polymer properly, I show it off to some of my mates who are old Duke fans and it makes them want a better PC, I have enjoyed watching the evolution of Duke 3D and cant wait for the next leap which I hope will be be enemy animations though I understand there are limitations at the moment with what can be done with them. But it keep growing like nothing else out there, which is cool because I often wondered why one of the best games ever made doesnt get more attention and sequals, and it hurts less when I see the progress being made on this, it will eventually reach perfection...how could it not?

[Master Fibbles]

The problem with what you propose is that what if you don't want your red lines to intersect? While doing TROR and not having the layers fully greyed out or something similar, that could cause all sorts of map bugs.

[Micky C]

That's why mapster would ask if you want points to be inserted. When you paste sectors inside other sectors, it asks you whether or not you want to create an inner loop, and that's what'll happen with the slicer. The TROR does make it more complicated though, as you would have to have areas greyed out sometimes. Or it might be able to check which group of sectors the start and end point are directly connected to, and only insert points in those sectors.

[Stabs]

its such a quirky little engine you just learn to work around things, hell i worked around that shit SOS sector detection for years ( way better now but still not as accurate as lebuild ) , and if you understand TROR enough you should be able to understand and compensate for the complications of an operation like this.

no one will be forced to use it but the fact its there is nice

[Jblade]

Any chances you guys could raise the max level limit in an episode to 64 or something? Or let us define music tracks up to that much? I know we could use other episodes for extra levels but some stuff I've coded depends on levels being in a set episode so It'd help me alot if we had more room for maps and music tracks

[Fox]

Since you are asking, can it be made so it's possible to start the music defined by title and briefing screen? I would also like to be able to stop the track without the need to define a blank sound file.

[Hendricks266]

I've had for some time in my list of stuff to add some way of splitting music out from the episode/level system and adding controls which are not available now.

Same thing with increasing map amounts.

[Mblackwell]

Still want paused rather than stopped sounds when the game is interrupted.

[Mikko]

Anyone else unable to play in Polymost since the latest ATI patch (the one that was released right after Rage)? EDuke32 simply stops responding immediately after launch and the log reveals nothing.

The software mode has an annoying bug that reverts brightness/gamma settings back to default whenever the screen flashes. Pressing F11 returns the user's settings but this fix only lasts until the screen flashes again (or changes pal etc.).

[Helixhorned]

 Mikko_Sandt, on 24 October 2011 - 12:04 PM, said:

The software mode has an annoying bug that reverts brightness/gamma settings back to default whenever the screen flashes. Pressing F11 returns the user's settings but this fix only lasts until the screen flashes again (or changes pal etc.).

Confirmed for ATI systems in fullscreen. Do you also suffer from abysmal performance for palette effects that change every frame (like the red damage flash)?

[Plagman]

Well that blows. Mikko: when you say the log reveals nothing, do you mean the crashlog of the debugging version or the regular log?

[Mikko]

The regular log. I'm not familiar with the debug version.

 Helixhorned, on 24 October 2011 - 01:10 PM, said:

Do you also suffer from abysmal performance for palette effects that change every frame (like the red damage flash)?

There's a noticeable spike but I wouldn't call it abysmal.

[Jblade]

Is there a reason why a startlevel command taking the player to volume 1 level 9 would bug out and take them to the menu instead? Micky reported a problem where the level transition (using startlevel) took him to the main menu instead of E1L9 like it should of done. I went straight to that level and it took me to the base map, but does Duke do something weird with Episode 1 levels if you play them in a row or something?

EDIT: Nevermind, I misunderstood what Micky C meant!

[Kyanos]

Quote

In computer graphics, accounting for level of detail involves decreasing the complexity of a 3D object representation as it moves away from the viewer or according other metrics such as object importance, eye-space speed or position. Level of detail techniques increases the efficiency of rendering by decreasing the workload on graphics pipeline stages, usually vertex transformations. The reduced visual quality of the model is often unnoticed because of the small effect on object appearance when distant or moving fast.
Wikipedia.

Does polymer use this? Or possibly mipmapping support?? I came across the term LOD and got curious.

[Plagman]

It does use mip-mapping, so there are texture LODs. They're automagically derived from the textures you specify in DEF, though. That means that if you pass in a DDS file that contains its own mip levels, they won't be read and EDuke32 will generate its own set instead.

For models there's no such thing right now. You can't really automatically derive LOD levels for models and expect it to look good, so the proper way to fix that would be to let people define their LODs and use that. However you can pretty much achieve that right now by specifying several separate models and switching through them with CON code depending on distance/whatever other criteria you chose, so making this a full engine feature would be more of a convenience than anything, which makes it pretty low priority.

[Kyanos]

That's good news that it's something that can be done with con code. It doesn't need to be an engine based feature, or applied to most models, but I can see it coming in handy with something large in an open space or just a lot of models being "seen" at once in certain places in a map. And I didn't ever notice the mip-mapping going on so that's great work.
"automagically" LMFAO

[Plagman]

Mipmapping only kicks in if you pick a texture filter mode that takes advantage of it. With Bilinear, transition between mipmaps is rough (like in HL1 where you could clearly lines of blurriness at fixed distances). With Trilinear, it's smooth so it's harder to notice. However you have to remember that Anisotropic filtering is a technique that relies on mipmaps being used to work, so maybe you've been taking advantage of it without realizing it.

[Helixhorned]

OK, here's the deal with the hardware gamma bug on ATI cards:

Setting the gamma works all right, but the next time a new palette is uploaded (IDirectDrawPalette_SetEntries), the gamma is reset to the base value! Revision 2085 works around this issue in two ways.

r2085 commit log said:

From the time of OpenGL initialization, gamma lookup in classic/fullscreen
will be done in software. Before that, always do a setgamma() after setting the
palette, since this is what resets the HW gamma. However, this may lead to
unappealing artifacts with portions of the scene being sent to the screen with
different gammas.

The reason that OpenGL must be initialized in order to disable HW gamma is that I couldn't find a way to query the driver vendor using the DirectX interface. So, this looks like a genuine DX driver bug to me, but I don't have the motivation to check whether such behavior might be to spec after all.