I've been with DooM, DUKE3D and BLOOD for several years now :).
I'm just investigating some concepts behind this two engines. I'm sorry but I've reposted this message to this forum as I found out that is more propable that Ken Silverman will read it here.
This is what I found out:
BOTH are 2.5D sector based engines, support slopes and got OpenGL, HiRes texture and MD2 support.
(Z)DOOM
- uses BSP tree to store sector/level information, thus levels are static
- moving map parts are possible only by using zdoom/hexen polyobj hack and polyobjs aren't real sectors
- doesn't have "native" editor, mapper is unable to preview level realtime
- doesn't support sector over sector mapping
- zdoom has acquired powerfull ACS sripting language and sector capabilities
BUILD
- uses some diffren't algorithm for visibility calculation (which one) ?
- map is completely dynamic, any sector can be moved
- has "native" editor with online preview
- supports sector over sector scheme when certain conditions are met
- has quite obscure sripting system
My question is mainly, what algorithm current OpenGL BUILD incarnation uses?
My second question is, are there any other differences?
Thank you
KillerQ13 at
Re: BUILD & DOOM technology comparison
Have you even played the original Doom or original Build? ZDoom is an independant project without id Software and there are many others such as Boom and jDoom. The original Doom didn't support slopes, OpenGL, hi-res textures, or have MD2 support (MD2 is from Quake 2). The original Build did support slopes but did not have a scripting system, unless we're comparing Doom and Duke 3D.
You may also want to note that Build has a more advanced sprite drawing system. Allowing level creators to use sprites that are not always facing the camera such as decals on walls and platforms. Also there a two levels of transparencies for all sprites. All rendered surfaces (including sprites) can use different lighting levels and palettes (unlike Doom's sector based lighting and full screen palette changing). Build also supported VESA for resolutions higher than 320x200.
etko at
BUILD & DOOM technology comparison
KillerQ13 wrote said
Have you even played the original Doom or original Build?
Yes, I know the both engines quite well from the "advanced user's" point of view. What am I interested in are internal engine differencies. Actually today you can achieve almost the same results with both engines. Both have OpenGL , slopes, MD2, decal sprites and sliding/rotating doors support.
Discussing this same thing on ZDOOM forums, revield however that even for ZDOOM, BSP tree is a must, so it is generated on the fly for maps where it's not present. For now to me BUILD seems to be naturaly superior technology in terms of level editing, plus its interactive nature can be used by mappers/coders to it's fullest potential.
Anonymous at
etko said
KillerQ13 wrote said
Have you even played the original Doom or original Build?
Yes, I know the both engines quite well from the "advanced user's" point of view. What am I interested in are internal engine differencies. Actually today you can achieve almost the same results with both engines. Both have OpenGL , slopes, MD2, decal sprites and sliding/rotating doors support.
Discussing this same thing on ZDOOM forums, revield however that even for ZDOOM, BSP tree is a must, so it is generated on the fly for maps where it's not present. For now to me BUILD seems to be naturaly superior technology in terms of level editing, plus its interactive nature can be used by mappers/coders to it's fullest potential.
Yeah, I asked just this in another thread ("Visibility algorithm used in Build engine"). The original BUILD Engine (used in Duke3D & Blood) used a modified version of the "Portal" algorithm. There are a lot of sites that describe how to render worlds using "portals" (search on google). But Ken uses something quite different, yet the effect is the same.
etko at
Yes Guest, I found out too, that about your post. Your question asked was much precise than mine ;), so thank you. At zdoom forums I was suggesting it (BUILD) uses portals, so I assumed right. I'm happy about it. Now to the hard part. I will try to compile the thing :)). Don't laugh ;).
So today I persuaded myself to download devc++. I understand C roughly,but personaly I like more BASIC-like languages (xblite,vb) and I don't have too much experience in so it will be really fun to make things go. Can I count on your advices during that process? :)
Anonymous at
etko said
Yes Guest, I found out too, that about your post. Your question asked was much precise than mine ;), so thank you. At zdoom forums I was suggesting it (BUILD) uses portals, so I assumed right. I'm happy about it. Now to the hard part. I will try to compile the thing :)). Don't laugh ;).
So today I persuaded myself to download devc++. I understand C roughly,but personaly I like more BASIC-like languages (xblite,vb) and I don't have too much experience in so it will be really fun to make things go. Can I count on your advices during that process? :)
Yeah, sure, you can count on me! I visit these forums often.
Here is some advice to start you off with:
- DevCpp won't compile BUILD (perhaps the newer JDuke, but NOT Ken's original BUILD).
To compile that i think you'll need to Get Watcom C/C++, i think you can get it off www.openwatcom.org for FREE!
It wont compile it because BUILD has inline assembly code, which is definately not compatible with DevCpp or other compilers. Escpecially cause DevCPP uses AT&T style inline assembly, not the more popular Intel format.
Trance at
Re: BUILD & DOOM technology comparison
etko said
- doesn't have "native" editor, mapper is unable to preview level realtime
Well, the first part is true. The second is no longer true, in the sense that I understand it. Are you referring to "preview" as a 3D WYSIWYG editing mode like BUILD has? Because CodeImp has made an editor with a lot of similarities to Ken's BUILD engine UI. Consequently, its name is Doom Builder. :D
There's one advantage that I believe Doom Builder has over Ken's wonderful bundle of editness; the movement in 3D mode is a mouselook-controlled no-clipping type that allows you to get pretty much anywhere a lot faster than with BUILD's three movement modes. Of course, this may have changed; I used to map a lot of DN3D and SW maps back in the day but don't anymore.
Apart from that, BUILD is a knockout in every aspect. When I learned how to make sprite-based bridges, I just about died. :P Come on! BUILD has sprites that shrink, stretch, orient to the wall, to the floor, turn transparent, they can slice, dice, you name it! Can DOOM do that? Last I checked, they were only able to face in 8 directions with no orientation or deformation capability, and only recently have they been able to be placed above the ground or become transparent (with the advent of ZDOOM). Point for BUILD. Natively sloping floors, moving sectors, underwater sectors, colored lighting, all things that BUILD one-ups the DOOM engine in. And with all the modifications and stuff made for the different BUILD-based games out there, it's THE most awesome 2.5d editor out there. And man, is it easy to use! I was making maps since the age of 8, for the record. :P
Okay, I'm ranting now. Sorry. BUILD rocks.
Phoenix at
BUILD & DOOM technology comparison
but of course - Build was released years after Doom so of course it's better :P (it's still a beautiful accomplishment in a 2.5d environment, especially with the later games (Blood, SW) with the "real" room-over-room and the voxels)
I like editing for ZDoom because it's what I'm used to. and even though it can't do moving sectors and yadda yadda it's still possible to make some damn nice looking stuff. plus, it's fun to come up with crazy hacks to fake some effects. i imagine it wouldn't be fun at all working with modern engines because you can already DO everything and nobody is impressed :P
Anonymous at
Very Long Post about BUILD's future
Sorry Guest that I've mistaken you, when I was referencing BUILD I was actually thinking about JFBuild :). Original Build is according to me very outdated.
I thought that jonof's OpenGL build is great base to start from, so I've downloaded devcpp to give it the try, but I'm unable to get it to compile. First of all because devcpp complains about many syntax errors which I'm unable to fix as mi skills as C programmer are very limited (it seems to me that it's caused by differences between vc, watcom and mingw or what) and second because my math really sucks ;).
I wated anyway, to try it. I'm not giving up, but now I see that I should take some real courses in math and c.
Anyway I think that jfBuild can still be base for many good games which can be competitive even today.
I realized this when I was playing Silent Hill 3. This game looks quite good and many firends of mine think that it is very complicated, but I think it's much more simple than say Quake 1. Actually monsters AI is quite dumb and environment is in reality composed from 2d "sector" based rooms connected with doors. What makes this game look so great are HiRes textures, HiPoly models and great design which makes you forget about all the limitations of that game's engine.
So I concluded to myself that with very good planning almost anything is possible.
I'm assuming that on current machines whole OpenGL BUILD level processing is superfast and takes very little CPU time (I got 130 fps on GeForce 2 MX). Using some extra OpenGL features like vertex arrays (if they aren't used already) can make it even faster. So there is solid base and big room to add some reallly fancy graphic stuff.
For exapmle I was thinking about including HiPoly models with skeletal animation or heavy pixel shader stuff. World can be made even more realistic using sector geometry for walls and HiPoly prop models for furniture etc. Adding colored lightmaps into jfBuild can really revamp the thing. Project I've found at http://tempusmud.com/~jwatson/sdl-dg/screenshots.html proves it can be done even with sector based engine. Using some great looking algorithm for light calculation like Radiosity or GI can make jfBuild look really good and appealing.
So that are things I'm interested in but unable to realize :).
etko at
Opps
I got loged out or something, so to make it clear, the previous post was mine :)
Semicharm at
BUILD & DOOM technology comparison
NICE! The last shots look kind of like Hexen2, but only better. ;)
Trance at
Has anyone noticed that the second-to-last pic's slime texture has skulls in it? :P
hawkeyefile at
has ne1 played marathon? came out in 94 (bout 5 months after doom), it vertical looking, better physics, dual wielding.
btw you should see how aleph one is doing.
all of those games rocked id's ass.
martin_howe at
As for "native" editor, well DoomBuilder is pretty much the de-facto "default Doom level editor" these days. Most new ZDoom projects seem to be built with it and most n00bs seem to use it, which is not surprising as it is a full Windows GUI editor and makes editing quite easy. I don't think it'll ever support editing DN maps though.
Anonymous at
Re: BUILD & DOOM technology comparison
etko said
BOTH are 2.5D sector based engines, support slopes and got OpenGL, HiRes texture and MD2 support.
Aren't MD2/MD3/ect Copyrighted By ID?
TX at
Anonymous said
etko said
BOTH are 2.5D sector based engines, support slopes and got OpenGL, HiRes texture and MD2 support.
Aren't MD2/MD3/ect Copyrighted By ID?
No. You really shouldn't use big words like "copyright" without having a clue as to what they really mean -- a file format is not literary or artistic work.
Anonymous at
BUILD & DOOM technology comparison
I know what "copyright" means lol, I was confused because someone on another forum was saying that they were copyrighted.