Duke4.net Forums: Build 2 Released by Ken Silverman - Duke4.net Forums

Jump to content

  • 6 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Build 2 Released by Ken Silverman

User is offline   MusicallyInspired 

  • The Sarien Encounter

#31

I definitely want more features. Like models, normals, MOD music, and a heck of a lot more explanation for this KC language. It's definitely not as easy to work with as sector effectors and stuff, but it obviously allows you to do a lot more with a lot more versatility since you can just program it in real time. That's a really cool feature, actually.
0

User is offline   Micky C 

  • Honored Donor

#32

Don’t forget it’s all done with CPU rendering; there’s only so much it can do before becoming unplayable.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#33

But it says it supports OpenGL....or am I misunderstanding?
0

User is offline   Player Lin 

#34

https://www.virustot...93f0d/detection

Someone maybe should tell Ken about this, 13/67 isn't good...
(even it still likely false positive but it still not good... :))

This post has been edited by Player Lin: 09 March 2018 - 06:29 AM

1

User is offline   Micky C 

  • Honored Donor

#35

View PostMusicallyInspired, on 09 March 2018 - 06:24 AM, said:

But it says it supports OpenGL....or am I misunderstanding?


Does it say that in the download? On the website it says "Native Windows, 32-bit color, 6 degrees of freedom, pure CPU rendering".
0

User is offline   Hendricks266 

  • Weaponized Autism

  #36

View PostMicky C, on 09 March 2018 - 03:42 PM, said:

pure CPU rendering

This could be a deal breaker for any serious use of this engine. We would need to see what kind of performance it gets with complex constructions and 1080p+ resolutions.
1

User is offline   MusicallyInspired 

  • The Sarien Encounter

#37

I must be mistaken. I can't find it anywhere now. I could have sworn I read it somewhere. My bad. Why did he choose to do that when almost everything supports OpenGL??

Speaking of which, is that why I'm getting this really annoying graphic wall-flashing above and below certain objects like sprites and the help window?

This post has been edited by MusicallyInspired: 09 March 2018 - 04:24 PM

0

User is offline   Micky C 

  • Honored Donor

#38

View PostMusicallyInspired, on 09 March 2018 - 04:24 PM, said:

Why did he choose to do that when almost everything supports OpenGL??


Possibly intellectual curiosity. Still, he surely can't expect people to use it for commercial projects?

Btw, IIRC Dark Forces had some simple polygonal models, so it's not outside the realm of possibility that they could be incorporated, if he so desired. Some of the voxels he's using are certainly fairly high res.
0

User is online   Danukem 

  • Duke Plus Developer

#39

Right now I see this as a great platform for making a quirky high-concept build game with dynamic lighting and voxels, possibly experimenting with procedural map generation. I already have an idea for a game where you start deep underground and your goal is to explore and dig your way to the surface. But, in the absence of staples like hardware acceleration and transparency, I have to agree with Hendricks266 that it may not be viable for most serious projects.
3

User is offline   Tekedon 

#40

So fun to play with, my avast keeps deleting it though.
1

User is offline   MrFlibble 

#41

View PostDavoX, on 08 March 2018 - 01:10 PM, said:

Video uploaded showing the stuff possible.

https://www.youtube....1&v=3qtmkkdND6M

Hmm, a caption at around 1:56 says "In 1994, Apogee pushed Ken to write a successor to the Build engine to compete with id Software's Quake", but wasn't the Quake engine developer later? Wikipedia says its development was from 1995.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#42

A list of EVALDRAW functions would be welcome.

EDIT: I found them. I really really need to read more before asking questions.

This post has been edited by MusicallyInspired: 10 March 2018 - 09:40 AM

1

User is offline   Forge 

  • Speaker of the Outhouse

#43

View PostTrooper Dan, on 09 March 2018 - 05:43 PM, said:

I already have an idea for a game where you start deep underground and your goal is to explore and dig your way to the surface.


Posted Image
4

User is offline   The Nate 

#44

I'm pretty sure no one here think's it's a good idea for eDuke32 to make the jump to Build2.

My idea is that a special version of eDuke32 using Build2 is developed alongside the normal one. It might be a good alternative to Polymer.

I may move this discussion to another thread in eDuke32 general.
0

User is offline   Mark 

#45

The devs have stated before they have no desire or time to maintain more than one main engine.

This post has been edited by Mark.: 10 March 2018 - 02:48 PM

0

User is offline   Zaxx 

  • Banned

#46

View PostSgt Nate V, on 10 March 2018 - 02:10 PM, said:

I'm pretty sure no one here think's it's a good idea for eDuke32 to make the jump to Build2.

My idea is that a special version of eDuke32 using Build2 is developed alongside the normal one. It might be a good alternative to Polymer.

In my opinion Polymer doesn't need an alternative because it's kind of a flawed approach in improving the engine. Does Build need dynamic shadows? Absolutely not, that stuff doesn't fit the graphical style the engine has and it's really only worth a damn if you convert Duke 3D to a fully 3D game. Of course the HRP does that but as time goes on the HRP ages the game more than anything else: you basically have a choice between the timeless "pixel art" of the original graphics and the HRP's dated 3D models and high resolution textures. The only thing the HRP proves is that you can't remake a Build game faithfully in 3D because the end result will be this weirdly cartoonish mess of a thing.

What is good in Polymer is the option for better lighting effects because that could compliment the original graphics style in a number of ways. That's what Gearbox's new renderer for World Tour did and that's the good approach (man, it feels so strange to say something good about Gearbox :)).

This post has been edited by Zaxx: 10 March 2018 - 03:54 PM

4

User is online   Danukem 

  • Duke Plus Developer

#47

View PostZaxx, on 10 March 2018 - 03:49 PM, said:

Does Build need dynamic shadows? Absolutely not, that stuff doesn't fit the graphical style the engine has and it's really only worth a damn if you convert Duke 3D to a fully 3D game.


I agree with most of your post, so I upvoted it, but I disagree with the statement I quoted. There's nothing about Build which precludes developing a game on it in which dynamic shadows would fit in perfectly. Remember, this is Build 2, not Duke 3D 2. I think a game with voxels that have dynamic shadows would be pretty cool.
3

User is offline   Mark 

#48

View PostZaxx, on 10 March 2018 - 03:49 PM, said:

you basically have a choice between the timeless "pixel art" of the original graphics and the HRP's dated 3D models and high resolution textures.


My feelings are hurt that you don't consider a 3rd alternative of high res custom content and TCs as a viable project for Build and Polymer. :)
0

User is offline   Micky C 

  • Honored Donor

#49

View PostZaxx, on 10 March 2018 - 03:49 PM, said:

The only thing the HRP proves is that you can't remake a Build game faithfully in 3D because the end result will be this weirdly cartoonish mess of a thing.


I don't think the HRP proves anything like that. It was made by a large number of different people over a very long period of time, with no kind of overall direction. Just because it didn't work perfectly here doesn't mean it can't work.

Does Build 2 really have that much of an advantage over eduke32 though?


Quote

Native Windows,
32-bit color,
6 degrees of freedom,
pure CPU rendering
Native support for sector over sector (SOS).
Advanced lighting system with true dynamic shadows, colors, spotlights.
Multi-user editing with client-side prediction.
Powerful scripting compiler in EVALDRAW.
Full RGB color mapping.
Voxel sprite support.
Skybox support.
No sector/wall/sprite count limits.


In terms of the game itself, the only real advantage (assuming polymer is finished) is the lack of sector/wall/sprite limits. The 6 degrees of freedom is nice I suppose, and polymer does support it, but I gather the underlying build engine does not. It's impressive that it can do everything in software, but as others have said, hardware acceleration is the desirable choice between the two.

The SOS, which appears to be a wall-over-wall (WOW) implementation does look pretty good though.

This post has been edited by Micky C: 10 March 2018 - 05:10 PM

0

User is offline   Mark 

#50

The SOS feature is what I like the most. It means an end to creating a building with walls raised up from the floor and puttiig a flat spite roof on it. Easier to make a building with multiple levels of windows and player space.
2

User is offline   MusicallyInspired 

  • The Sarien Encounter

#51

Build2's SOS is way better and much less cumbersome than EDuke32's TROR. IMO. Also, I think the EVALDRAW custom programming stuff could be far more versatile potentially than CON. But I'm no CON programmer so I have no idea. I really like Build2's mapping interface as well. Everything just seems more easily accessible and sensible. Designed with modern approach. It always feels like pulling teeth trying to make things work in Mapster32. That's not a slight against the amazing work the EDuke32 team (and Ken initially) did with Build. It's just so outdate with a bunch of modern amenities patched on top of an old system.

This post has been edited by MusicallyInspired: 10 March 2018 - 06:07 PM

1

User is offline   Mark 

#52

I hardly used the editor in the few minutes I spent with it. When switching to 3D I couldn't figure how to stop the wild, seemingly aimless rotating and flipping of the map. I'm sure if I actually read an instruction or two it will make more sense.
0

User is offline   Micky C 

  • Honored Donor

#53

View PostMusicallyInspired, on 10 March 2018 - 06:03 PM, said:

Build2's SOS is way better and much less cumbersome than EDuke32's TROR. IMO.


It's a good system, but I'd view it more as a compliment to TROR rather than a replacement. As far as I can from playing around in the level editor, if you want to make a hole in the ground for example, TROR would be much easier.


View PostMusicallyInspired, on 10 March 2018 - 06:03 PM, said:

I really like Build2's mapping interface as well. Everything just seems more easily accessible and sensible. Designed with modern approach. It always feels like pulling teeth trying to make things work in Mapster32. That's not a slight against the amazing work the EDuke32 team (and Ken initially) did with Build. It's just so outdate with a bunch of modern amenities patched on top of an old system.



The editor seems to be missing a LOT of basic functionality and conveniences that really speed up mapping with mapster32. As it stands, the editor is extremely bare bones and I wouldn't want to use it to make large, complex maps.

Having had a look at build2.txt, it appears that Ken hasn't really worked on the engine since 2012, and seems unlikely to work on it in the future. Perhaps it'd be possible to convince him to release the source?
1

User is offline   Zaxx 

  • Banned

#54

View PostTrooper Dan, on 10 March 2018 - 04:46 PM, said:

There's nothing about Build which precludes developing a game on it in which dynamic shadows would fit in perfectly. Remember, this is Build 2, not Duke 3D 2. I think a game with voxels that have dynamic shadows would be pretty cool.

I agree, it would be cool but on Build 2 and not on Build. The way I see it Build 2 emphasizes 3D graphics, dynamic shadows and lighting and voxel models so sure, a game that focuses on those things would be the perfect choice.

On the other hand Build (1) is all about "2.5D", large pixels and detailed sprite work and its lighting / "shadows" technically may be as primitive as it gets but it's still very specific and it creates a unique atmosphere if used well. Because of this a source port to Build like EDuke32 should always focus on features that stay true to the mindset in which the games for Build were - and are - created. Stuff like dynamic shadows don't fit into this picture so adding them clutters up the engine with features that would be very rarely used and really this is what we're seeing now with Polymer. The large majority of content created for EDuke32 don't use Polymer (hell, Ion Maiden's version of ED32 does not even let you use it) and not only because its performance is bad but also because most of the community prefers the original look of Duke 3D.

And really the way I see it there is a reason why the most popular Doom source ports are the ones that are based on ZDoom: ZDoom was never really about the graphical bullshit but rather about expanding the original engine's functionality in ways that are super useful for the community while also being natural extensions to the original tech. I think that's the optimal way of doing it and that's what a project like EDuke32 should be about too. In that sense I'd rather see improvements that make even more complex maps and even higher enemy counts possible for mods.

Edit: Anyway this is one of my favourite games ever so trust me, I appreciate voxels and software rendering:


This post has been edited by Zaxx: 10 March 2018 - 07:15 PM

1

User is offline   Mark 

#55

I'm very glad that mapster/eduke32 expanded beyond the ability to make vanilla maps. If it wasn't for Polymer and HRP I most likely would not have gotten into any modding at all for the last 7+ years.
0

User is offline   Micky C 

  • Honored Donor

#56

Plus there are a few projects around which combine a more old-school look with colored lighting. There'd probably be a fair few more if performance was reasonable.
0

User is offline   Zaxx 

  • Banned

#57

View PostMicky C, on 10 March 2018 - 05:09 PM, said:

I don't think the HRP proves anything like that. It was made by a large number of different people over a very long period of time, with no kind of overall direction. Just because it didn't work perfectly here doesn't mean it can't work.

I think it does mean that it will never work perfectly. If you look at projects that had much stronger direction, for example the high res texture pack that was created for Doom you can see that upgrading an old game's graphics that way simply doesn't work. All of the textures of Doom were recreated faithfully based on the originals yet the result is still just some cartoony weirdness. Why? Because the original assets were created with a low resolution in mind: everything was stylized, the proportions are unrealistic because everything had to be easy to identify etc. so if you bump those assets up to HD everything will look funny no matter how good of an artist you are. Want to make nice looking HD textures? You can't because even if you redesign the look of every single texture the original level geometry will still limit you and at the end everything will look just as weird as before. The only solution is to fully remake the game from the ground up with modern technology in mind and to do that you need a different, modern engine.

You can do "Duke Nukem Reloaded" with great results but a high resolution texture pack (or a 3D model pack... dear God) will never feel like the originals.

This post has been edited by Zaxx: 10 March 2018 - 08:06 PM

3

User is offline   Micky C 

  • Honored Donor

#58

Sorry, I read 'make', not 'remake'. I agree it's pretty much impossible to do it perfectly. Duke is somewhat easier than Doom though since more textures have a specific purpose.
0

User is offline   necroslut 

#59

View PostZaxx, on 10 March 2018 - 08:03 PM, said:

I think it does mean that it will never work perfectly. If you look at projects that had much stronger direction, for example the high res texture pack that was created for Doom you can see that upgrading an old game's graphics that way simply doesn't work. All of the textures of Doom were recreated faithfully based on the originals yet the result is still just some cartoony weirdness. Why? Because the original assets were created with a low resolution in mind: everything was stylized, the proportions are unrealistic because everything had to be easy to identify etc. so if you bump those assets up to HD everything will look funny no matter how good of an artist you are. Want to make nice looking HD textures? You can't because even if you redesign the look of every single texture the original level geometry will still limit you and at the end everything will look just as weird as before. The only solution is to fully remake the game from the ground up with modern technology in mind and to do that you need a different, modern engine.

You can do "Duke Nukem Reloaded" with great results but a high resolution texture pack (or a 3D model pack... dear God) will never feel like the originals.

Even remaking it from the ground up like Reloaded would be highly problematic as the level designs themselves are done with the same low detail in mind.
Recreate it faithfully and it will look empty, bare and unrealistic. Fill it with details and you will have a cluttered, unreadable mess. Reimagine it in a modern way and it will no longer be the same level design and won't play the same...
1

User is offline   Mark 

#60

The last part of the previous post is what I had to deal with when mapping for HHR. I hoped to find a spot in between. Keep enough of the overall original layout and gameplay while adding lots more stuff to fill the emptiness. Some say I succeeded and others said I failed. So I guess I made the balance after all. :)
0

Share this topic:


  • 6 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • 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