Duke4.net Forums: How about porting Duke 3D to my new engine? - Duke4.net Forums

Jump to content

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

How about porting Duke 3D to my new engine?  "Make Duke levels playable in a game powered by my Brahma engine"

#1

Hello guys. As some of you might know, I'm working on a retro-3D game engine inspired by old Doom, Build and Unreal engines. The engine is sector-based like Build, but envisioned to have a slew of exciting features like multiple reflections, stacked walls, dynamic ligthing, all done in software to keep the authentic look and potentially free the GPU for other important tasks.

Some recent screenshots for introduction:
Attached Image: CAPT0035.PNG Attached Image: CAPT0006.PNG

At this point, the engine can flawlessly import Build engine artwork and maps. But the results are totally static and unplayable, you can just fly around the levels the way similar to Mapster32 and enjoy the new effects, and nothing interactive beside basic editing functions made for testing. The idea is to recreate (reverse-engineer) Duke3D original gameplay inside my tech. It won't be a strict replication of original physics and object behavior, but one should be able to play all original levels normally. So far I'm having certain questions to Duke3D community. First of all, can (and how can) this be done and published as a commercial product? The rights on the engine itself should remain on my side. Also can I find any investors so I could do the necessary work? I'm noob at things like crowdfunding etc.
17

User is offline   Phredreeke 

#2

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

First of all, can (and how can) this be done and published as a commercial product? The rights on the engine itself should remain on my side. Also can I find any investors so I could do the necessary work? I'm noob at things like crowdfunding etc.


Nope.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#3

Build 3?
0

#4

View PostMusicallyInspired, on 19 August 2018 - 06:49 PM, said:

Build 3?

The engine itself is called Brahma and framework underneath is NipSys64 (which can run 2D games and applications too). And no, they are not based on Build.

This post has been edited by Jan Satcitananda: 19 August 2018 - 09:57 PM

0

User is offline   Phredreeke 

#5

Seems like a lot of effort to recreate a game that already has a quality source port.

That said, unless you have the blessing of the rightsholders (in this case Gearbox) you can't make a commercial project.

You're probably safe as a free project as long as your require users to supply their own DUKE3D.GRP to extract the game's resources. And you can still use your engine for commercial purposes not involving the Duke IP. IANAL though.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#6

The engine intrigues me for sure. Would love to play around with it. Build 2 was fun, but lacking any sort of saving ability mucks up your motivation somewhat.
0

User is offline   Micky C 

  • Honored Donor

#7

View PostPhredreeke, on 20 August 2018 - 02:28 AM, said:

Seems like a lot of effort to recreate a game that already has a quality source port


From his discussion elsewhere, he’s been wanting to work on his own game using this new engine. The potential for a new Duke port out of it is a side bonus, even if it isn’t 100% authentic or compatible with more advanced mods.

Those effects do look impressive. Is it just me or is the grass 3D?

This post has been edited by Micky C: 20 August 2018 - 05:58 AM

0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#8

Parallax?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #9

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

Hello guys. As some of you might know, I'm working on a retro-3D game engine inspired by old Doom, Build and Unreal engines. The engine is sector-based like Build, but envisioned to have a slew of exciting features like multiple reflections, stacked walls, dynamic ligthing,

Cool.

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

all done in software to keep the authentic look and potentially free the GPU for other important tasks.

It's not the Graphics Processing Unit's job to handle graphics?????

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

The idea is to recreate (reverse-engineer) Duke3D original gameplay inside my tech. It won't be a strict replication of original physics and object behavior, but one should be able to play all original levels normally.

Using Duke 3D's name to attract attention to something that is not Duke 3D is poseury.

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

First of all, can (and how can) this be done and published as a commercial product?

Absolutely not. You cannot sell someone else's game. At most you could sell your engine and require the user to bring their own copy of the game. If you use any of Duke 3D's code then you would need to comply with the GPL, which would neuter your revenue stream.
2

User is offline   Phredreeke 

#10

Yeah, the way I see it he has two options
-Use Duke3D code, which means he has to make his engine GPL
-Rewrite the entire Duke3D game logic from scratch (hence my comment that it'd be a lot of work for something that already has a quality source port)

IMO, if you're gonna spend the effort recreating a game, pick a game that doesn't already have a port (for example LucasArt's Outlaws or 3DO's Killing Time)

This post has been edited by Phredreeke: 20 August 2018 - 09:54 AM

1

#11

Thank you guys for the comments. I was just wondering if Duke 3D copyright holders show any interest in reinterpreting the game on my engine with new fancy effects and refined gameplay.

The grass is a voxel heightmap btw. The engine will make extensive use of them.
1

User is offline   Phredreeke 

#12

They did their own re-release of the game just two years ago.

Given that you're doing a lot of features in software, what framerates do you get? (also what's your CPU?)
0

User is offline   MrFlibble 

#13

I suggest create your own game. Take inspiration from Duke3D and other titles from the same era, but do your own twist.

You can use free assets (textures, sprites, sounds etc.) that are available online, if only as placeholders. Freedoom could be a nice place to start, also OpenGameArt.
0

User is offline   Mike Norvak 

  • Music Producer

#14

View PostMrFlibble, on 21 August 2018 - 03:10 AM, said:

I suggest create your own game. Take inspiration from Duke3D and other titles from the same era, but do your own twist.


X2.

You have much much more possibilities to make a game from start to finish than waiting Gearbox to give you license to release an updated version of a game that has been already released countless times.

I'd suggest starting with something simple very simple, story and gameplay wise: player just can move, croach, jump and shoot, not third person perspective, 2-3 weapons, 2-3 enemies, 2-3 short maps, simplistic art, no items, no hud, few tiles, creative commons sounds, and that's all. Maybe a child is trying to find his teddy bear while hiding from monsters at night, maybe the player is a tank that needs to defeat buildings. I mean what I'd do is take a minimalistic approach.

Don't take the overarching aproach, trying to do a groundbreaking retro indie game, with one hundred weapons and jawdropping enemies, don't make that mistake! You don't even need to crowdfund, you have created your own engine! you can release some minigames taking advantage of what you already know how to do, while improving the engine and adding new features, that way you can test what works and what doesn't, hear people opinions, and come up with new ideas, before you make the crowdfunding step. You can even sell those mini games or ask for donations.

Perhaps I'm saying the obvious but you have an awesome project in your hands, I'm just throwing some opinions.
1

#15

View PostMike Norvak, on 21 August 2018 - 07:49 AM, said:

I'd suggest starting with something simple very simple, story and gameplay wise: player just can move, croach, jump and shoot, not third person perspective, 2-3 weapons, 2-3 enemies, 2-3 short maps, simplistic art, no items, no hud, few tiles, creative commons sounds, and that's all. Maybe a child is trying to find his teddy bear while hiding from monsters at night, maybe the player is a tank that needs to defeat buildings. I mean what I'd do is take a minimalistic approach.


Yup, I'll keep it an indie work. Actually I'm going to create a simple playable tech demo to attract more attention to the project, and then gather a team to complete work with my LNGA startup.
0

User is offline   Zaxx 

  • Banned

#16

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

all done in software to keep the authentic look and potentially free the GPU for other important tasks.

But... why? Software rendering is usually a lot slower these days if the engine is not using every single drop of CPU power through multi threading.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#17

Ken did this with Build 2 as well. I don't get it. He said his reason was because he didn't liked dealing with OpenGL code or something.
0

User is offline   Phredreeke 

#18

Yeah, I don't see what advantage software rendering would bring, and it would hold back potential performance a lot.
0

#19

View PostZaxx, on 22 August 2018 - 03:49 PM, said:

But... why? Software rendering is usually a lot slower these days if the engine is not using every single drop of CPU power through multi threading.

Potential speed gain doesn't really matter. My goal is not to replicate what already exists in other engines. My engine already supports some form of multithreading and can handle pretty heavy effects, some of which can be adequately done only in software (or using indexed color palette). My goal is to have stable 120 fps on 1920x1080 resolution throughout the game with no stuttering. I've noticed that many games suffer from stuttering when the engine attempts to load some assets on the fly, or having excessive loading times, when you have to wait a minute or so just to load your game. My guess it that too many steps are done to load every little asset. My engine runs instantly, loads precompiled resources in a matter of seconds, and you're already in game. Instant load/save, smooth play even if you introduce a 32768x32768 megatexture and lots of mirrors everywhere.

Eventually later versions of the engine might get OpenGL support, but what defines the engine's personality lies inside the software. Now I'm doing a reasonably fast prototype, the next version will be a native 6-DOF renderer with realtime compiled self-modifying code.
0

User is offline   Zaxx 

  • Banned

#20

View PostJan Satcitananda, on 22 August 2018 - 07:58 PM, said:

Potential speed gain doesn't really matter. My goal is not to replicate what already exists in other engines. My engine already supports some form of multithreading and can handle pretty heavy effects, some of which can be adequately done only in software (or using indexed color palette). My goal is to have stable 120 fps on 1920x1080 resolution throughout the game with no stuttering. I've noticed that many games suffer from stuttering when the engine attempts to load some assets on the fly, or having excessive loading times, when you have to wait a minute or so just to load your game. My guess it that too many steps are done to load every little asset. My engine runs instantly, loads precompiled resources in a matter of seconds, and you're already in game. Instant load/save, smooth play even if you introduce a 32768x32768 megatexture and lots of mirrors everywhere.

Eventually later versions of the engine might get OpenGL support, but what defines the engine's personality lies inside the software. Now I'm doing a reasonably fast prototype, the next version will be a native 6-DOF renderer with realtime compiled self-modifying code.

I see, it's just that when I search for reasons on why such an old school engine could be awesome today I always come to the conclusion that it's because you can put a lot on stuff on screen if it's properly optimized. I mean nowadays CPUs are strong enough that a good, multi-threaded engine that focuses on lowering the CPU's load as much as possible when it comes to rendering could run infamous stuff like this smoothly:

(Btw. I'm really curious to see how Serious Sam 4 will handle the 50 000 - 100 000 enemies on screen Croteam is promising :()

And when it comes to the gaming industry it seems like that modern games focus on the GPU handling as many of the complex stuff as possible: you see GPU-physics, GPU particles and whatnot, all the stuff that was handled by the CPU a decade ago. But it's great that you're focusing on multi threading because as far as I know even the more advanced source ports of classic engines like GZDoom or Eduke32 rely on just the one core.

This post has been edited by Zaxx: 23 August 2018 - 01:27 AM

0

User is offline   Phredreeke 

#21

What effects are you doing on the CPU that you can't do on programmable pixel shaders?
1

User is online   Mark 

#22

I read Jan's post about instantly loading pre-compiled resources. Does that mean all maps have to be pre-compiled too. I remember not being too thrilled from a modding standpoint when ICD mentioned that for his NG renderer. After every little change made during a map's creation the map would have to be re-compiled before testing. :(
1

#23

View PostPhredreeke, on 23 August 2018 - 02:34 AM, said:

What effects are you doing on the CPU that you can't do on programmable pixel shaders?

Heightmapping is an example that would be extremely cumbersome if done with shaders. Also I'm not an expert in shader programming, so I just do what I can do with software.

View PostMark., on 23 August 2018 - 07:19 AM, said:

I read Jan's post about instantly loading pre-compiled resources. Does that mean all maps have to be pre-compiled too. I remember not being too thrilled from a modding standpoint when ICD mentioned that for his NG renderer. After every little change made during a map's creation the map would have to be re-compiled before testing. :(

My BHM map format is editable pretty much the same way the Build maps can be edited, because the engine is sector-based, not BSP nor other shit. Just the game resources are aggregated so that every sound/image file can hold any number of items, what is handy and reduces loading times considerably.
0

User is online   Mark 

#24

+1
0

User is offline   Jimmy 

  • Let's go Brandon!

#25

Pretty sick engine, interested to see further development.
1

#26

View PostJan Satcitananda, on 19 August 2018 - 02:29 PM, said:

All done in software to keep the authentic look and potentially free the GPU for other important tasks.


Doing raycasting/triangle fill/raytracing on the CPU(for graphics purposes) is just silly and is a waste of your time, your not looking forward to the future, and are holding on to graphics development practices of the past.

Looking to the future, especially on RTX Turing, graphics work is going to be a lot more complicated then just doing a simple raycaster and saying "oooh I have something". Aside from all the obvious things your missing out on(programmable shaders and such), graphics work is going to involve things like neural networks, which Volta's dedicated hardware units called Tensor Cores, that are going to be in Turning, crunch neural networks a fuck ton faster then the CPU ever will. That's just the tip of the iceberg.

I really do like your enthusiasm, and I think you might be able to be useful as a graphics developer if you open your eyes a bit :rolleyes:, but your useless if you continue development on old ideas.

This post has been edited by icecoldduke: 09 September 2018 - 09:22 PM

-1

User is offline   Phredreeke 

#27

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?
1

#28

View PostPhredreeke, on 09 September 2018 - 08:56 PM, said:

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?

Maybe he's following the MAME philosophy: "Don't bother solving slowdowns on current hardware, because in the future, CPUs will be faster."
0

#29

View PostZaxx, on 23 August 2018 - 01:24 AM, said:

And when it comes to the gaming industry it seems like that modern games focus on the GPU handling as many of the complex stuff as possible: you see GPU-physics, GPU particles and whatnot, all the stuff that was handled by the CPU a decade ago. But it's great that you're focusing on multi threading because as far as I know even the more advanced source ports of classic engines like GZDoom or Eduke32 rely on just the one core.

My PolymerNG work was multithreaded. I had the game running on one core and the engine running on another core. That's how most engine's work, while the game is doing work, the render thread is building up command buffers and submitting all that stuff to the GPU. Multithreading the "software renderer" would be a waste of time. The "Software Renderer" would be benefit from parallelization, but not on the CPU. As it turns out the GPU can run a lot more work in parallel then the CPU ever could(in terms of vector math processing), so you could easily get a huge speed up by moving the "software renderer" over to GPU compute.

This post has been edited by icecoldduke: 10 September 2018 - 06:37 AM

0

#30

View PostPhredreeke, on 09 September 2018 - 08:56 PM, said:

I'm thinking, what happens when you want to move to 4K? what happens when you got a few dozen monsters on screen?

In multithreaded mode, it will handle everything smoothly. Also there's "realtime adaptive detail" feature that will automatically adjust visual quality based on rendering time so the game will never slow down and you'll see perfectly stable framerate. My goal is to develop a technology from scratch that is internally unique down to pixel level, not relying on specific hardware. There's a lot of GPU-powered engines, all of them look pretty much the same using polygon meshes, BSP and bilinear texture filters. This is not what I want. I want a powerful but nonconventional engine that I fully understand. Perhaps, mine will use GPU for physics or AI.

Just added KVX support to my engine. After I complete the voxel drawing procedure (again done from scratch, not based on Build source code), I'm going to introduce my own voxel format supporting large sizes and transparency, as well as dynamic lighting-ready.

Attached Image: CAPT0037.PNG
6

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • 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