[Plagman]

That's a good point. I don't think slope makes any sense in the context of a connected floor/ceiling since it's not going to physically, right? So we could just use that member when the corresponding cstat is set, yeah. From the editor side, I was thinking there would be a function to stack a sector above or below the selected sector (that would essentially create the same exact sector, set the height for it to be higher and connect it), and then a function to switch between the different levels of the map in order to be able to work on one at a time without the screen being a huge mess of lines. I guess other levels could be faded gray in the background or something like that to make it more fancy. From the renderer side it would be as simple as walking these connections the same way as red walls, and from the engine side it should be pretty easy to change the collision code to follow these links when clipping with floor and ceiling.

[DavoX]

Watching Programmers of my favourite Port of Duke makes me feel warm inside. Specially considering the ultimate Stadium remake is coming and this would be a great feature .

I dunno about the levels being actually ON TOP of the previous levels... why not use the oldfashioned way of sector effectors?

[3D Master]

Room over Room? Sounds good, but then, it begs the following observation:

There's already a Build engine version out there with room over room, seethrough water (which is a result of room over room), and controllable (sector created) vehicles; namely the Shadow Warrior engine.

What would it take to run Duke under the Shadow Warrior engine / upgrade Duke's Build build to the Shadow Warrior Build build. (No pun intended.)

In other words: merge the two engine projects together. It would have several advantages:

1. Both Duke and Shadow Warrior would benefit from improvements in engine/renderer; you don't need two separate projects. (Shadow Warrior doesn't yet have a Polymer/dynamic lighting renderer does it?)

2. Duke gains all the improvements the Shadow Warrior engine had, which would improve future mods/projects. Most notably controllable vehicles, and if that control scheme could be applied to models as well as sector-based vehicles, you could put a model jeep in there and control it.

[Plagman]

Except these are all game-based effects. The only features that SWBUILD had over DN3DBUILD back when the games were released were voxel rendering and some tweaks in the mirror code. These weren't SW-specific at all and came from Ken's own Build tree. When Ken released the Build source in 2001, it had all these features and more; that's what 3DRealms put alongside the Duke3D source code, so anything that was in SW is also in the codebase used by JfDuke and by extension EDuke32.

The room over room from Shadow Warrior was just a multi-pass approach based on the game code calling drawrooms() more than once. That's exactly what's done with the SE-based RoR, and it works today. If you don't want to use the SEs, you can use CON code and the showview command (interface to drawrooms) to re-implement it yourself.

See-through water is the same thing, there's even an example map that demonstrates the SEs that has it; it ships today with EDuke32.

Vehicles are just a matter of moving the sectors, like doors or whatever. Anyone could implement sector-based vehicles today using CON code. It's not an engine thing.

In other words, JfDuke and JfSW are based on the same engine code, and so is EDuke32. There's nothing to benefit here.

[Helixhorned]

Plagman, on Nov 7 2010, 10:20 PM, said:

Vehicles are just a matter of moving the sectors, like doors or whatever. Anyone could implement sector-based vehicles today using CON code.

In fact, I have begun doing just that. That's what the new CON commands were for. I won't have time to work on it in the near future though, so if anyone is interested to develop it further, drop me a note. Sidenote: the really hard thing is clipping on rotation.

[Helixhorned]

Just an idea that sprung to my mind: do we need to connect the ROR ceilings/floors by their indices at all? The simplest implementation would be to have a new ceiling/floorstat bit mean "don't draw this ceiling or floor". This way, people could begin to build stuff right away while the editor would accumulate some convenience features to deal with ROR over time.

[Plagman]

Yeah, both the renderer and the engine would need that link to the next sector.

[Hendricks266]

Helixhorned, on Nov 7 2010, 04:03 PM, said:

In fact, I have begun doing just that. That's what the new CON commands were for. I won't have time to work on it in the near future though, so if anyone is interested to develop it further, drop me a note. Sidenote: the really hard thing is clipping on rotation.

IMO, the ideal thing would be a model with your new sector collision. Ability to traverse multiple sectors, vehicles that look like vehicles, etc.

[Helixhorned]

There could be a slight misunderstanding here of what my code handles and what it doesn't. It does handle collision of things against model sprites. It does not handle collision of the model sprite against other sprites or the map geometry in a new way. Why the asymmetry? The reasons are that the API doesn't work that way (you only pass coordinates to clipmove, for example) and if it did, there would be many new issues to deal with, including the aforementioned clipping on rotation.

Plagman: you're right, of course. What I was trying to express was that there shouldn't necessarily be a 1 to 1 relation, nor should the walls of one sector necessarily match the other. Think of an elevator shaft with the exits slightly off on every level. With the restriction, a mapper would need to put points in every sector where any lower or upper sector had points, wasting the most precious map resource. In a way, this resembles the problems mappers face when they want to model the floor and ceiling separately.

[Plagman]

Ah, I see what you mean. I think the linked sector outlines should be identical, cause we probably don't want holes in the map. My idea was that the editor would take care of duplicating the walls when you use the "stack" function to create your above/below sector, and that any dragpoint after that would be sure to drag all the corresponding points in the stack. This'll waste some walls, yeah. I don't see another way, though. If the mapper has to draw the outlines of the stacked sectors and make sure they're moved together this feature is probably going to be a major annoyance in the long run. That doesn't mean the two rooms of the stack have to be the exact same shape since you can always put red walls around them.

[DavoX]

Is there any way to make Eduke32 load like 2 or 3 maps in the first loading as to connect them with a seamless corridor or something (like the HUB) but you don't actually exit the level? This way people could separate the map in different parts and not worry about the wall or sector limits.

[DavoX]

Sorry for double post, but will this get fixed sometime? Sprites pasted to the wall show z fighting :



This didn't happen before.

[High Treason]

I could be wrong on this, but try pressing O on the sprite (for the time being - it still needs fixing).

[DavoX]

That makes it worse

[Awesomebob]

DavoX, on Nov 8 2010, 08:08 PM, said:

That makes it worse

Hover the sprite 1-2 units from the wall?

[DavoX]

That's not the only issue regarding sprites. Spritework used to be much more effective before. Now if you make a bridge with stretched sprites and look from around a corner, half of the damn bridge dissapears, rendering the spritework useless.

[Plagman]

Before what? Are you talking of a difference between classic and Polymost or Polymost and Polymer?

[DavoX]

Bear in mind I've been absent from the Mod scene for one year at least. That's what I call "before" and I didn't use Polymer at that time, just polymost. I believe it wasn't even released.

I'm talking about the difference between polymost and polymer.

Now that I'm testing, I'm having the same result with polymost and polymer, probably it's something that both are sharing now.

[Plagman]

Can you post a sample map that exhibits the behavior you're talking about? I don't remember any changes that would affect sprite visibility in Polymost, only models.

[Stabs]

is your map in an oversized grid and on the grid its fair distance from the centre?

i remember having severe sprite z-clipping in the first DNE realease because the map was moved so far from the centre

[DavoX]

I was thinking about this the other day... Plagman, if ceiling and Floor ROR worked... it would be like a portal, right? Well... can it be used on walls as well? To make interiors and exteriors two separate places... the result would be interesting.

[DavoX]

I'm getting this thing when I have several sectors and different Polymer lights:



As you can see, the two lights don't blend properly. If I raise the floor a little bit the lighting looks better, but when I save it all looks wrong again.

[Plagman]

Does increasing r_pr_maxlightpasses fix the problem?

[Danukem]

If he is using the latest DukePlus, that might explain it because it includes an autoexec file that reduces light passes to increase performance. In that case, he should edit the autoexec file to increase them.

[DavoX]

ACtually I'm still using dukeplus 2.0 ... I'm going to check out that maxlightpasses thing.

[Sobek]

I've been away from mapping with Duke for a while now, but I've just started up again and I've noticed some improvements here and there, such as Polymer lights now affecting HUD models properly. I've been out of it for many months now, can anyone summarise some of the major changes that have happened recently? Obviously there's the HUD model lighting, which is really fantastic... But has there been anything else?

*edit* Also, what's the go with clipshapes? I'm reading back through the thread but I'm still a little unsure of how it works. How detailed is it? Does it just create a basic square square blocking shape around the model in question, or does it conform to the smaller details on it? The details about it in the Samples folder don't seem very clear to me... Is this just a test for something that will be integrated automatically into the renderer, or are we always going to have to use some second .map file to work out clipping on models.

Has me a bit confused is all.

[Helixhorned]

Basically, you provide special maps called _clipshape0.map through _clipshape9.map in which you model the clipping behaviour of a given tile with one or more bunch of sectors. When playing, every sprite with that tile number has this clipping information transformed to its position and rotated, and behaves as if the sectors were in its place. For a start, I'd recommend reading the doc and taking a look at the example _clipshape0.map provided in the samples directory.

[The Commander]

Yeah Sobek this feature should benefit your mod quite nicely.

[TerminX]

Choosing to give Helixhorned svn commit access is probably one of the best decisions I've made regarding EDuke32 during the entire life of the project.

[Helixhorned]

Hey, I'm just a guy who got way too emotionally attached to Duke3D in my childhood years, so hacking the port is my way to repay the countless hours of fun.