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

fhDOOM (modernized idTech4)

Started by eXistence, April 10, 2016, 12:35:13 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

aphexjh

Hi. Looks great. 1 issue, maybe someone knows the reason for it. I get a problem where the skybox (cube map) flickers to black. see images.




Arl

#16
Quote from: eXistence on April 11, 2016, 10:24:41 AM@Phobos Anomaly: HD 5770? Phew! Thats even older than my test card (HD 6950)... but the specs look fine.
This starts fhDOOM in a window, enables OpenGL debug message, dumps the console to console.txt and quits the game.
fhDOOM.exe +set r_mode 6 +set _fullscreen 0 +set r_glDebugOutput 2 +condump console.txt +quit
Please send me the console.txt file via pm.


Yeah, my radeon is an ancient remaining of antique technology, but right now graphics cards are very expensive, so an update will have to wait... ... another ten years.


I'll send the .txt to you right now.

argoon

Holly shit!! I still didn't try it but from what the guys say it seams to work fine for the most part, so congrates man!
And a QT based GUI engine?! Does this mean i can use QT designer to do GUI's?

romulus_ut3

Runs like shit on AMD cards as always. The Soft Shadow, specially.

trebor

Quote from: romulus_ut3 on April 12, 2016, 04:59:32 AM
Runs like shit on AMD cards as always. The Soft Shadow, specially.

I'm somewhat glad to hear that :P

argoon

#20
Quote from: romulus_ut3 on April 12, 2016, 04:59:32 AM
Runs like shit on AMD cards as always. The Soft Shadow, specially.

I'm on AMD and it does run more slowly when using shadow maps, that is somewhat expected because stencil shadows are faster by design, but even so, reading the eXistence (fhDOOM) engine docs seams it was tested on Nvidia cards only, i'm sure with some more tests on AMD we can help eXistance improve things. 

Quote from: trebor on April 12, 2016, 05:02:02 AM
I'm somewhat glad to hear that :P

Why?  :(


eXistence I will be glad to beta test for you if you want, my GPU is a R9 270X GPU.


Made some Searching about why AMD is slower on OpenGL compared to Nvidia and this came up, trebor is this accurate?

Quote... to put things simply, deferred contexts and command lists are not mandatory. AMD have specifically chosen not to use it in their driver. The drawback is significantly higher CPU overhead is observed, which heavily chokes the GPU(s) in CPU intensive applications. However, the positives from this is that you get a simple and stable driver which can work with almost any newly released game without compatibility issues and the need for specific driver tweaks. It also gives consistent performance in most games across the board, even if that performance is relatively low. Hence why you can run pretty much any Indie game on an AMD card without a "not supported" error message. In contrast to Nvidia drivers, each game requires driver tweaks for that game to actually remain stable. This is a lot of work for the driver team, but at least you are getting the performance boosts from the multi rendering capabilities of Direct-X 11. I would not be surprised if AMD chose compatibility over performance to either reduce staff workload, or because the driver team don't have the ability to compile a fully stable driver which uses such features discussed.

AMD have shown promise in the past with their CPU overhead issues with "Sid Meier's Civilization Beyond Earth", whereby they worked closely with the developer to ensure the game used good API optimization methods for enhanced CPU performance. AMD also enabled command list support (such a rare moment) for this title which allowed proper usage on all threads.

QuoteThat's to do with DX11 overhead, we aren't talking about that, nor do we have an issue with it. it's the OpenGL overhead which is shocking on AMD cards as they don't support Multithreaded OpenGL, where Nvidia does.

eXistance do you know about this?

https://community.amd.com/thread/194895

romulus_ut3

It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

oneofthe8devilz

Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.
I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

romulus_ut3

Quote from: oneofthe8devilz on April 12, 2016, 11:04:41 AM
Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.

No improvements whatsoever. What executing these cvars does is make the graphics worse.

eXistence


Quote from: aphexjh on April 11, 2016, 02:33:16 PM
Hi. Looks great. 1 issue, maybe someone knows the reason for it. I get a problem where the skybox (cube map) flickers to black. see images.

@aphexjh : what are your system specs? Do you have a savegame or a minimal map that demonstrates the problem?

Quote from: argoon on April 11, 2016, 06:15:44 PM
Holly shit!! I still didn't try it but from what the guys say it seams to work fine for the most part, so congrates man!
And a QT based GUI engine?! Does this mean i can use QT designer to do GUI's?

@argoon : Probably yes... i am not 100% sure about how to use the custom widgets in the designer (i did the light editor manually), but it should be possible. The light editor is meant to be some kind of example: it interacts with the editor and game, it lists some Decls from the game and has a little rendering preview. Based on that, you could do more complex GUI tools.

Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

@romulus_ut3 : I just got my AMD graphics card for debugging and testing and i have to admit, it runs shockingly bad on AMD. Besides some rendering issues that i still need to solve, the performance is very bad in general (compared to the original game). Shadow mapping has nothing to do with this. I am working on this, but since i am doing this in my spare time, don't expect a "quick fix" for it.

I cannot emphasise strongly enough, this is just a very early alpha version and is not (yet) meant to be used in more serious projects. I originally hoped for some feedback from users with a modern Intel GPU (to clarify whether some of the rendering issues are an AMD-only problem, or if it just happen to work on nVidia). My ultimate goal is to modernize the engine (to make implementing new feature like Qt-based tools and soft shadows easier). Porting Doom3 to modern OpenGL is a lot more than just rewriting a couple of shaders with GLSL. Doom3 is essentially a fixed-function engine. Obviously there are some shaders: The interaction shader is quite important and there are a couple of special effect shaders, but that's it. Everything else is fixed-function:


  • depth prepass
  • stencil shadows
  • particle effects
  • blend lights
  • fog lights
  • GUIs
  • debug tools (r_showtris and friends)
  • editors

Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)

motorsep

Quote from: eXistence on April 12, 2016, 03:59:35 PM
Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)

So, why didn't you go with BFG engine instead ?

Arl

I don't know why, but today I tried opening fhdoom again and it worked... ...weird.

Anyways, I have to say that I also have bad performance. At the beginning it was all okay, but when I entered the scan room in mars city my fps dropped significantly from that point on. Not even sikkmod with enhanced textures and bla bla bla impacted this bad on my fps.

Beyond that, this is exiting, soft particles looked great and what you are planing to do in the future is also very promising, keep up the good work.

argoon

Quote from: romulus_ut3 on April 12, 2016, 02:28:56 PM
Quote from: oneofthe8devilz on April 12, 2016, 11:04:41 AM
Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.

No improvements whatsoever. What executing these cvars does is make the graphics worse.

I'm sure that was what he wanted, he was trying to see if the shadow mapping was indeed the problem by removing all the other effects.

I also used it and I saw a clear bump in performance but that was expected with low graphics but i still add drop's from 63fps down into low 20fps's, i know is not optimized eXistance so don't think i'm critiquing you. ;)

Btw i add one strange performance problem, when i looked into a specific door with a broken surface GUI(where you get the blue key before passing trough the infirmary) and nothing else in view, my fps's went from 63 down to 18fps, if looked to the right or left where plenty more stuff was in view, fps's went up again to 63, even more strange fact is that, at first i though it could be the game rendering what was behind the door, but that particular door was also next to a window glass, where you could see all what was behind the door, if you looked trough the window, fps's would jump to ~45fps, if you put the door in your view the fps's would go down to ~20, could it be the surface gui causing problems?   

eXistence

Quote from: motorsep on April 12, 2016, 05:09:08 PM
Quote from: eXistence on April 12, 2016, 03:59:35 PM
Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)

So, why didn't you go with BFG engine instead ?

id software put a lot of effort and professional experience into the BFG edition and as far as i know trebor is doing an amazing job implementing new features for it.
Competing and catching up with that is not very likely for me, but that was never my intention.

Just like mentioned in my first post, i started to work on it because i was just curious how certain things were done and wanted to explore the code.
I chose vanilla Doom3 because i was familiar with it (did a lot of mapping and modeling in the early days), it had all the tools at hand and it was very easy and interesting to re-visit the stuff i did ten or twelve years ago.
Releasing it for others to use was not even planned at that point.

Just about a couple of weeks ago i stumbled across these forums. I noticed a few threads asking for a BFG-like shader system for vanilla Doom3, so i thought what i was doing might be interesting for others as well.
If no one is interested in it (for whatever reasons), that's totally fine. Staying with the original engine or with the BFG edition is a very reasonable choice.

motorsep