[DavoX]

I tried searching everywere but couldn't find shit.

Now... can ROR be achieved using polymer? has any work been done to the RoR code lately? I've been out of the loop and really need this effect.

[Helixhorned]

DanM, on Nov 1 2010, 11:42 AM, said:

just a thought helix, because models have volume now with its clip shape, could this fix the problem with models disappearing?

Not easy.

[Plagman]

This is all in the renderer hands anyway, and it already has access to the model bounding information so using such a hack wouldn't be the right answer.

[DavoX]

Awww plagman... why didn't you answer MY question?

[Plagman]

I don't believe RoR can be achieved using Polymer right now, either through the RoR SEs or through CON coding, because they're multi-pass based and Polymer clears the whole screen at the top of drawrooms(). Fixing it would require a little work, but it's something I have planned (that would also benefit stuff like handling multiple skies and some sky clipping problem behaviors). Something that I also have planned is to make RoR more of a first-class feature instead of having to rely on SEs and multiple passes, since Polymer is perfectly able of rendering multiple levels in one pass. The renderer work is minimal, but the editor would need some work to allow editing stacked levels instead of working on an exploded version of the map.

[Stabs]

so why wont it work, make it so if the clipshape is on screen it should always be drawing the clipshapes sprite, why is it wrong that its a "hack"?

[Jimmy]

Helix, I'm kind of late replying, but I really like the new feature. It even has potential to be useful for sprites in 8bit, so I'm interested to see how I can use it.

[High Treason]

I don't know what you did, but Mapster32 has started working fully again on my system. Thanks, now I will be able to finish my map - don't expect it any time soon though, I've got a lot on at the moment.

[Plagman]

DanM, on Nov 1 2010, 02:47 PM, said:

so why wont it work, make it so if the clipshape is on screen it should always be drawing the clipshapes sprite, why is it wrong that its a "hack"?

Yeah, I understood what you meant and it's indeed doable; however, it would be a hack and I'll explain why: right now, model (and model bounding boxes by extension) are a renderer-only thing, the engine (which is responsible for collision) doesn't know anything about them. Making the collision code in the engine model-aware would require a big overhaul of the interface to propagate the concept of model all the way to the engine core and introduce different gameplay depending on what renderer is being used. It would be a huge amount of work and tricky to get right, and for these reasons Helixhorned went with the clipshape approach where you specify that custom collision information to the engine. However, determining when a sprite is visible or not is totally up to the renderer; in this case, the renderer already has access to the model bounding information. It would make no sense to use that clipshape for model visibility where you can already use the actual model bounding information with less work and more accurate results. Does that make sense?

[Stabs]

yeah it does a bit, so how difficult would it be to make the render do it correctly, would models need some kind of per pixel on screen detection to get around how sprites work?

[Danukem]

Keep in mind that for 90% of Polymer users, improving frame rate and overall performance is still the top priority. I don't really care whether a model disappears sometimes when it shouldn't because I can barely use Polymer at all except in simple maps with not much going on (like E1L1).

[Stabs]

a rather cool screenshot, i was spawning cars in game and because they have blocking they stack, so in honour of helixhorned momentous acheivement, a helix of porches reaching the heavens themselves!

[Fox]

Cool dude! Fun things happen if Recon car spawn multiple sprites at death

[The Commander]

DanM, on Nov 4 2010, 12:18 AM, said:

a rather cool screenshot, i was spawning cars in game and because they have blocking they stack, so in honour of helixhorned momentous acheivement, a helix of porches reaching the heavens themselves!

Not to burst your bubble, but you could always do that with spawned sprites. It's not just because of helixhorned changes.

Anyone want to count whos picture has more cars?

[LeoD]

DanM wins. Can the helix be climbed?

[Stabs]

yeh but if you do it slowly you can actually stack cars properly that are not inside each other, i made mine with a spawn bind. yeh you can run around the helix, kinda got me thinking how i could use this for structures

[Helixhorned]

DanM, on Nov 3 2010, 01:18 PM, said:

a rather cool screenshot, i was spawning cars in game and because they have blocking they stack, so in honour of helixhorned momentous acheivement, a helix of porches reaching the heavens themselves!

eduke32_...12_56_05.png

Haha, a DNA strang made of cars. Thanks, dude!

Plagman, on Nov 1 2010, 11:15 PM, said:

I don't believe RoR can be achieved using Polymer right now, either through the RoR SEs or through CON coding, because they're multi-pass based and Polymer clears the whole screen at the top of drawrooms(). Fixing it would require a little work, but it's something I have planned (that would also benefit stuff like handling multiple skies and some sky clipping problem behaviors). Something that I also have planned is to make RoR more of a first-class feature instead of having to rely on SEs and multiple passes, since Polymer is perfectly able of rendering multiple levels in one pass. The renderer work is minimal, but the editor would need some work to allow editing stacked levels instead of working on an exploded version of the map.

That sounds great! How general do you plan the ROR system to be? I was thinking, if connecting sloped floors and ceilings were disallowed, there would be no need at all for a new format -- we could simply use the [ceiling,floor]heinum members for sector indices whenever the corresponding (cstat & 2) would be 0. The map version number would need to be incremented, though. This way, I could work on the editor side of ROR ahead of time.

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