News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

Why so few uses of Id Tech 4?

Started by Shawnturner, November 10, 2017, 06:49:29 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ADV_MD5

Personally, for myself, I find it hard to justify using Id Tech 4. Quake 1/2 were fairly similar in terms of design and Quake 3 carried many similarities in the source itself. This helped pioneer development on these early idtech engines. Also when they were released we didnt have as many FOSS game projects so they carved a niche.

Doom3 (and id tech 4), has a few key shortcomings.
1) Multiplayer (or lack thereof)
2) When designing D3, the multiplayer code that was present was incorporated directly into the single player code, unlike Q3 with cgame/game. Although there is some simplicity gained from this approach, it sacrifices some security. Additionally, in my personal preference I prefer having two isolated code bases because it helps me separate the client and server logic clearly.
3) Engine. Many modders lack the tools/care to deal with high quality sprites/textures. I personally prefer a simple texture to having to deal with bump/normal maps.
4) I love Carmack to death, but the Physics in D3 did not age well. They are completely software based unlike PhysX or Bullet. You can find some QuakeCon talks on this subject.
5) The niche. D3 engine is very optimized for a very small subset of gameplay.
6) When released, it did not hold the spotlight for long. Gameplay/mod enthusiasts had gotten the UDK in 2009, and then right around D3s release, we also got Wolfenstein Enemy Territory, and the Jedi Academy/Outcast.

revelator

Agreed idtech4 is a niche product as it is, dependant on the work we put into expanding its capabilities.

Things that may make sense would be to expand the work done on fhDoom's tools to port and expand the toolset.
QT is excellent for that purpose :) as was shown with fhDoom.
Next would be to expand the engines uses by introducing virtual texturing (not nessesarily megatextures, there are other options we can use),
this would push it in a more all purpose direction, though we would still have to expand a few other areas to truely take advantage of the engine.
Physics could be changed to take advantage of bullet or the open dynamics engine ODE, not sure how much work it would take though.

Bump and normal maps can be produced by code but the generated images would lack certain details that artists making them by hand can, but its entirely possible to do.

As for the multiplayer part, idtech 1 and 2 also used this approach so it is not uncommon in id's engines,
however security concerns are definatly valid so maybe change the NET code to SSL based ?.

I admit most grievances i heard about idtechs NET code was about bad performance :P because it does not compress the stream (LAG galore).

ADV_MD5

#32
Quote from: revelator on September 14, 2019, 06:01:18 AM
Agreed idtech4 is a niche product as it is, dependant on the work we put into expanding its capabilities.

Things that may make sense would be to expand the work done on fhDoom's tools to port and expand the toolset.
QT is excellent for that purpose :) as was shown with fhDoom.
Next would be to expand the engines uses by introducing virtual texturing (not nessesarily megatextures, there are other options we can use),
this would push it in a more all purpose direction, though we would still have to expand a few other areas to truely take advantage of the engine.
Physics could be changed to take advantage of bullet or the open dynamics engine ODE, not sure how much work it would take though.

Bump and normal maps can be produced by code but the generated images would lack certain details that artists making them by hand can, but its entirely possible to do.

As for the multiplayer part, idtech 1 and 2 also used this approach so it is not uncommon in id's engines,
however security concerns are definatly valid so maybe change the NET code to SSL based ?.

I admit most grievances i heard about idtechs NET code was about bad performance :P because it does not compress the stream (LAG galore).
Yes. From an engine perspective, I have seen good progress from some devs. Ultimately, I plan on observing the scene before deciding because you have the benefits of dhewm3 being 64bit, fhdoom for the engine, TDM for some improvements and then RBDoomBFG. I plan on observing for awhile longer before making a list and porting the features wanted to the engine of choice. Megatextures are a dead end imho. They were kinda present in d3, but until we would have a way to compress the files and use them effectively, they are a dev trap.

My first project d3 related is actually to work my way through trying to replace the physics with a 3rd party library. Rather than ODE/Newton I had been looking into either Bullet or PhysX due to the fact that they can run some calculations on the GPU (afaik) rather than being purely software. Based on a preliminary glance last night, the physics is rather tightly integrated with the actual game (physics code is built into the game dll on d3). As a result, there is no way to add physics to the engine and have it work with existing mods as a drop in solution.

Yeah. I have seen some tools that will do that, I had previously used Unity3D, and I was using one. It was just an extra level of complexity.

Well, pretty sure that the D3 server model is authoritative. I more meant along the lines of ease of end user use/separation of logic.

That and also, I noticed something when I was looking through the physics. The way that they are synced through the network appears to be quite heavy. Especially if you are using a UDP/snapshot based network and have to worry about fragmentation.

revelator

Unfortunatly physx will only run on the GPU with nvidia cards since it relies on the cuda core,
so bullet would be a better choice i reckon ?. It would probably break existing game code as you noticed,
but might come in handy for new games developed using it.

We also have a plethora of different idtech4 projects that each have there strengths like you noticed.
It would be a nice move to consolidate the work on those into a shared project i think.

The goal for my little side project is in fact similar since im consolidating work from various ports into an all purpose engine.
So far i have added the SMP changes from darkmod as well as newer CPU intrinsics like AVX and AVX2.
Still in progress is porting the OpenAL Soft implementation from dhewm as well as 64 bit support.
Engine uses a hybrid GLSL ARB assembly backend which allows use of old shader mods like sikkmod,
but that might change if someone can port sikkpins shaders to GLSL.

But its a huge undertaking so it will take a while.

motorsep

@revelator:

It's been said many times that one of the reasons latest games from EA suck is due to Frostbite engine being used. Had they used Unity or UE4, they'd had less issues on launch. The only reason some companies still roll with their own engine is that they sank a lot of money into development and they don't want to write it off, re-train staff (or fire them and hire UE4/Unity devs) and also pay royalties to Epic/Unity. Not because in-house engines are somehow better.

As for PhysX, well, you'd be surprised to know it runs on AMD as well as on Nvidia, since like long time ago :)

revelator

Eh yes ?!?.

What i meant with physx is that it will only run with "GPU acceleration" on nvidia cards.
It runs fine on AMD but with lower performance as a side effect.
Bullet runs with hardware accelleration on both AMD and Nvidia.

Frostbite is actually a pretty good engine but as was the case with idtech4 it was a niche product since it could not handle an RPG out of the box (it was mostly used for shooters and car games).
Bioware had to implement a facial animation system as well as several other elements like inventory and whatnot.
Sadly this coupled with a troubled development cycle, with problems with procedurally generated environments and starting over on a totally different engine,
ment a 5 year project suddenly had to be finished in 18 months.

Anthem makes use of the new frostbite developed for mass effect andromeda, though it has had a bit more polish now:).

revelator

Well my experiments with using darkmods SMP system has yielded some interresting results.
vsync on 58.5 fps on sikkmod Oo. sadly SSAO and softshadows continue to be major FPS sinks due to the fact that sikkmod uses a hacked depthrenderer to simulate real depthrender access.
But everything else was on and previous runs without the darkmod optimizations only yielded about 25 to 30 fps with
those options.

So it gives a rather neat speed boost :).

One gripe though was with the hybrid GLSL ARB2 renderer, it causes bad UV's in maps with loads of decal blood, so it might be prudent to turn of GLSL interactions when using sikkmod.
Weird thing is that it only affects sikkmod other mods work fine so wtf...

revelator

Ok yesterday i got updated to win10 1903 and now gamma is no longer working wtf... ?!?
Does not work on any opengl engines that uses wingdi actually  ???, this seems to be a bug in 1903 but microsnot
seems to believe they fixed it (well they did not...) sigh.

motorsep

Quote from: revelator on October 28, 2019, 01:48:24 PM
Ok yesterday i got updated to win10 1903 and now gamma is no longer working wtf... ?!?
Does not work on any opengl engines that uses wingdi actually  ???, this seems to be a bug in 1903 but microsnot
seems to believe they fixed it (well they did not...) sigh.

Update your video drivers?

revelator


revelator

Ok heres how to fix it and it has nothing at all to do with "your" drivers in case you are wondering.
Open the -> (old control panel) go down to system -> device installation.
Find your monitor and hit update drivers, do not let windows auto install instead chose look on my pc for drivers and let me select from availiable devices.
Now choose pnp screen (standard) reboot and lo and behold gamma works again.
This bug also broke color calibration, nightlight, and various other apps.

Hope it helps anyone else with this problem.

revelator

My engine now builds cleanly with msvc 2017 and 2019  ^-^
still uv bugs on some sikkmod enabled mods like grimm quest (seems to be the only one with that bug so far, so i suspect the mod might have gotten corrupted in a drive crash now ugh).
as long as you stay away from enabling SSAO and softshadows sikkmod looks like a million dollars and runs pretty purty on this engine.
The only sad thing about it is that i removed all editors from the code early in development due to not being cross platform and generally badly implemented code,
so unfortunatly you can not use it for creating your own mods, you can however use it as an sdk for game dll changes (which is pretty much a must if you want to play your mod on this since it is no longer compatible with stock doom3).

revelator

My project is dead and will not return, github destroyed all my changes when committing and overwrote my local copy with a mix of old and new code. I deleted the repositories because there is no way to get the changes reverted i tried.

So this is the end.

revelator

scrounging up what i could from this disaster, i started adding in the SMP and timing changes to dhewm as well as the multicore renderer.
Its a big job though so might take a while.

revelator

Well i got the UV problem fixed and readded the AVX intrinsics.
Still lacking the SMP changes from TDM, code was quite a mess and some functions had to be changed rather heavy handedly i remember.

The problem with the bad UV's was a silly one in the GLSL code, i forgot to detach the shaders when the program object had been created (most of the earlier GLSL examples actually forgot to do that) which also caused numerous bugs with them  :)). Well i guess we can be excused, neither of us had much experience at the time with GLSL so that it actually worked to some degree was in itself pretty amazing heh.