Duke4.net Forums: Modifying Duke/Build beyond what is recommended by sanity - Duke4.net Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Modifying Duke/Build beyond what is recommended by sanity  "I'm having thoughts about using the build engine for a project"

User is offline   Tetsuo 

#31

Brink was id tech 4 though.
0

User is offline   Tea Monster 

  • Polymancer

#32

Yeah, it was, sorry.
0

User is offline   thatguy 

#33

lol I thought Brink was on the unreal engine, with Mirrors Edge and all.
0

User is offline   Marscaleb 

#34

View PostTea Monster, on 08 February 2012 - 01:18 AM, said:

I've often wondered if it would be possible to take the map loading and sector rendering code of EDuke and marry it to the business end of one of the more capable Open Source game engines out there. I have no idea how possible this would be on a practical level. Just seeing some of the examples out there (Source from Quake, Brink from Q3) I keep wondering what it would be like.

The biggest problem with that would be several logical errors with the map design. Particularly, things like overlapping sectors. Modern engines simply are not designed to be able to run things like that. Even the underwater effect would be challenging for many engines. You would think it would be easy to handle, but you actually have to permit actors to fall through the ground/ceiling, or more correctly, have them utilize a collision that is inside the geometry itself. And simply trying to move the sectors so the underwater areas are physically under the water will not work either. I was remaking Raw Meat in Unreal Tournament and I discovered that the underwater areas do not line up. I had to use some artistic license to change the layout into something that could physically exist.
Add to that a number of unique sector effects that defy conventional 3D level design. A lot of the doors (Star Trek doors for example) do not simply move an object but warp the geometry. You'd need to vertex-animate the world geometry, and I don't know of any engine that let's you do that. The earthquakes that make giant slanted cracks in the ground; that's frikkin the level's floor that the player walks on. The subway cars; the Build engine sees no difference between those and the regular rooms.

It would honestly be less effort to completely remake the game with a different engine. And there's people out there who would do it, but it just couldn't be so freely distributed like eDuke and the HRP is.
It would be cool to put together a team and get it legally sanctioned to rebuild the game and have it commercially released, like using the Unreal Engine or something. Hell I'd do it. But it's hard to get the clout to have something like that hold up when you're just taking people who are doing it in their spare time, and it's hard to keep the bigwigs from pulling the plug if you are organized into an official team or a company.
0

User is offline   Tea Monster 

  • Polymancer

#35

I was thinking of going into the code and taking all the drawing routines out and leaving whatever part of EDuke polymer/polymost takes sector geometry and turns it into something that modern renderers can deal with. Then when it sent a call to draw a particular triangle, that bit would be handled by the replaced render engine.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #36

^ That's not how it works... Polymer walks the BUILD engine's geometry and renders it itself; it doesn't convert it or something like that and then render in a "modern" engine style. Polymost would be very far out for your task since it's basically the classic renderer using OpenGL tools and methods.

The problem in the functionality gap is not the renderers in either case; instead it is the underlying engine itself.

This post has been edited by Hendricks266: 09 February 2012 - 02:19 PM

0

User is offline   Tea Monster 

  • Polymancer

#37

I don't think it is worth it to actually convert the current sectors into something like what Quake and Unreal use for level geometry. You would be converting all the problems with sector geometry (blocky environments) into a new format. It has been mentioned that the sector-based caves would always look like sector-based caves, even if you improved the renderer a million-fold. To change that, you would be re-creating the original maps. If you are re-creating the original maps, AND are going to improve the renderer and add particles and so forth, then it's probably going to be easier to do a port and code the old enemy and prop behaviour from Duke into a newer engine.

On that note, how easy is it to work with meshes as level geometry in EDuke? I've never tried mapping with models. Theoretically, it should be possible to build a level in Blender or Max of a spaceship corridor or a cave and bring it into an 'empty' EDuke level and add blocking to it. I'm imagining that its nowhere near that easy in real-life though :D
0

User is offline   Hendricks266 

  • Weaponized Autism

  #38

In theory, meshes could work to some degree in EDuke32. Optimally, you could define a model to a sprite and set up sector-based collision for it. The biggest problem I can think of is the occasional problem where a model disappears when it is close to the edge of a screen because the sprite it is linked to is completely off.
0

User is offline   thatguy 

#39

View PostHendricks266, on 10 February 2012 - 12:25 AM, said:

In theory, meshes could work to some degree in EDuke32. Optimally, you could define a model to a sprite and set up sector-based collision for it. The biggest problem I can think of is the occasional problem where a model disappears when it is close to the edge of a screen because the sprite it is linked to is completely off.


Exactly. Happens with Voxels too. I kind of wish we can get 'Static Meshes' implemented over being a Sprite replacement. Would help the engine understand what to cull or not.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #40

No, the renderers just have to be instructed to depend on the actual visual entity being drawn instead of the sprite bounds.
0

User is offline   Tea Monster 

  • Polymancer

#41

So, that would get around all that nasty BSP stuff (I think). The only problem is going to be if you turn around suddenly, your undersea base will suddenly morph into a huge hollow brick cube :D
0

User is offline   Jimmy 

  • Let's go Brandon!

#42

Somewhat irrelevant, but would it actually be possible to fix the disappearing sprite issue? I know it does that to save memory, but maybe it could disappear when it's further out of the player's sight or something?
0

User is offline   Mark 

#43

In my Graveyard TC I built a tomb that the player can enter. The version of Eduke I used back then things looked fine when you entered inside. But somewhere along the line in newer versions some walls of the model disappear when viewed from inside. Someday when I get around to it, I hope to try different techniques of making the model to get around the problem. Such as making the outside a seperate "layer" from the inside. So that way there will be more than one layer between the player and the outside world. So if the outer layer goes transparent, the inner one hopefully still shows. Who knows, it might work. :D
0

User is offline   Tea Monster 

  • Polymancer

#44

I'd love to have a play with some of this shit. I wish I had time. :D
0

User is offline   Mark 

#45

Pay the rent a few months in advance, send the wife off to her mother, quit your job, and start modding.

Yes, its that simple. :D
1

User is offline   Tea Monster 

  • Polymancer

#46

LOL
0

User is offline   Marscaleb 

#47

View PostMarked, on 11 February 2012 - 12:41 PM, said:

Pay the rent a few months in advance, send the wife off to her mother, quit your job, and start modding.

Yes, its that simple. :D


Not married, no job, car will be paid off in May.

Sweet! I'm almost there!
1

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options