fhdoom

Discuss anything not covered by any of the other categories.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

fhdoom

Post by revelator »

there has long been a demand for a modernized version of the old idtech 4 engine, well now its a reality it seems :) https://github.com/eXistence/fhDOOM

fully batched glsl renderer, defaults to opengl core profile.
uses framebuffers.
shadowmaps.
bloom and hdr.
soft particles.
blur.
support for dxt compression instead of the old s3tc.
cross platform (cmake build system).
editors using QT instead of mfc.

still has a few hiccups which interrested parties might be able to help with.

some AMD cards do not properly support core profile despite having the full extensions nessesary they run in compatibility profile like my R9 390.
roe expansion missing shaders.
sometimes hangs in cinematics.
a few shaders might need more work, atleast on my card they sometimes act up.
Productivity is a state of mind.
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: fhdoom

Post by ceriux »

Now we just need the extensions
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

Image

By extensions you mean ?

Engine uses GLSL besides that and maybe the need for some reworked material shaders (which johl has actually supplied) its pretty standard, it can use mods also, but if you intend on a full mod with gamex86.dll support then you would need to use his as a base cause the names difffer, but besides that its bussiness as usual :)
and i fixed the bug that cropped up on some AMD cards where core profile is supported but needs to be initialized and runs in combatibiliy context.
Productivity is a state of mind.
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: fhdoom

Post by ceriux »

revelator wrote:
By extensions you mean ?
Im sorry just count me as mentally challenged. I thought this was a quake engine.. Lol havent been sleeping much.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

Hehe i know the feeling m8 :) no worries.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

One thing that might be particularily interresting is that his shadow maps use prebaked cubemaps, this should take care of some of the more irritating stuff that has been a problem with shadowmaps in general (acne).
Also the engine uses SSAO by default and the tools are actually capable of putting out oclusion queries as files to be preloaded (*.ocl format).
It can also use phong instead of blinh - phong.
It supports parralax occlusion mapping but this is disabled by default because it can look weird in some places. This is due to the fact that at the time Doom3 did not use correct heightmap data in there normalmaps which causes some textures to render wrong if pom was enabled. Atm there is no easy fix, so unless someone takes up the job of recreating the heightmaps for the broken parts it should probably be left off.

I have fixed a plethora of the bugs reported by iodoom and some from dhewm besides my fix for some AMD cards misbehaving, i also added MH's VBO code to it :).
Ill upload my fixes to johl so he can have a look at the stuff and decide if he wants to keep my additions. I suspect he wont mind the fixed bugs atleast hehe.
Productivity is a state of mind.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: fhdoom

Post by toneddu2000 »

I didn't understand a thing: did you do this fork, revelator? Or is it by someone else? Because you said:
revelator wrote:I have fixed a plethora of the bugs reported by iodoom and some from dhewm besides my fix for some AMD cards misbehaving, i also added MH's VBO code to it :).
Is that related to this fork? In that case, awesome work dude! :)

You know what I REALLY liked? That someone added FTE qcc interpreter to it! That would be cool
revelator wrote:Also the engine uses SSAO by default and the tools are actually capable of putting out oclusion queries as files to be preloaded (*.ocl format).
wow, that would be REAAALLY useful in FTE, because, no matter how I struggled to do it, I never achieved a good AO in FTE
Meadow Fun!! - my first commercial game, made with FTEQW game engine
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

No just lending a hand with a few problems i noticed, since its worth getting this project stable :)

not sure what to do with a qcc interpreter in Doom3 ? unless someone wanted to port over quake :), it uses a system more like quake2's though (game dll's). Not to say that it could'nt be done.

Might be worth looking into the code then :) but aside that it's C++ so might need a bit of porting.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: fhdoom

Post by frag.machine »

I love QuakeC but let's be honest here: nope. It was revolutionary for the time Quake was launched but totally clumsy and inadequate nowadays. Either just keep using native C++ for game logic or implement something more modern, like Lua, Python or even (gasp) Javascript (this actually may end up having a great appeal with current indie developers).
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

Lua should be great as a game scripting language, homeworld 2 was one of the first engines i know of that used it, and it ran pretty well besides enemy scaling which was totally fubared because it insisted on making the enemy 10x as badass as you xD, but that was just the way it was written, and not lua's fault.

Im a bit biased in regards to python cause i find it to be rather slow, same with java, but java script like in nodejs or something like json could probably be nice.
Productivity is a state of mind.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: fhdoom

Post by toneddu2000 »

revelator wrote:not sure what to do with a qcc interpreter in Doom3 ? unless someone wanted to port over quake :)
Well, I beg to differ. I guess I'd use with profit fteqcc interpreter in a modern engine. Infact, if fte had global illumination, mesh collision control and other minor tweaks, it'd be my engine of choice right now! And I tried Unity 5, Ue4, Ue 3 and ClickTeam fusion!
frag.machine wrote:I love QuakeC but let's be honest here: nope. It was revolutionary for the time Quake was launched but totally clumsy and inadequate nowadays. Either just keep using native C++ for game logic or implement something more modern, like Lua, Python or even (gasp) Javascript (this actually may end up having a great appeal with current indie developers).
Again, respectfully disagree :biggrin: ! If I should have used C++ for craFTEr or projectUnknown I'd never started in the first place.

Python syntax is just awful, lua is something incredible..as it's clumsy and chaotic! Javascript Es6 would be the less stupid of the 3 I guess (infact Unity uses it, but this is the percentage of people using it). But, if I should think of "the best" scripting language I should think of C#. In Unity it's matter of minutes to create a c# class to improve it later. But, apart from c#, quakec it seems to me easy and yet powerful to create a game with. In just a couple of days you can build "the skeleton" of your games. Just take a look at what Shpuld did in just 2 days of work (or 1 day, I don't remember). Plus, I never used quakec to make something related to Quake. Never. :biggrin:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: fhdoom

Post by frag.machine »

c# would be an acceptable compromise, although I am not aware of the effort involved to implement/embed an interpreter. I don't know of any available runtime (not even considering legal aspects here).

About JavaScript: if you are refering to UnityScript on that link, IMHO 18% is not bad at all.

I confess I have close to zero experience in both Lua and Python, but personally have no problems with any of the syntax sugary involved (well, that's not entirely true: when I saw Python using indentation as code block mark up while in 99% of the rest of the languages { and } are the norm, all I could think was "OMG, it's COBOL all over again!").

QuakeC just lacks too many to be fit to a mid-size or big project.

a) sorry: float, pseudo-string (see below), vector and entity are not enough anymore;
b) no actual arrays, let alone collections;
c) no actual objects: having the same hundreds of disparate fields in every entity won't never scale (and it's a nightmare to keep sane);
d) no actual inheritance: you cannot have a WalkingMeleeMonster super class so you can quickly write a new monster in 15 or 20 lines;
e) no actual string support, strzone/unzone/whatever hacks are not good replacements;

The list goes on and on, I think you got the idea.

QuakeC is a very fun language for hobby code projects. The original progs.dat itself wasn't big, you can study it all in a weekend. And I agree, it's easy to write a game skeleton in QuakeC (and any other language we mentioned here). The real pain starts when you try to put flesh on those bones. When you try to write decent AI. When you try to implement non-standard behaviour (monsters that try to activate an alarm when sees a player or a interactive NPC are good examples - I know because I already did both in QuakeC). Trust me: if you want something besides vanilla deathmatch or single player monsters stuck in wall corners, you need more than QuakeC.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: fhdoom

Post by toneddu2000 »

frag.machine wrote: a) sorry: float, pseudo-string (see below), vector and entity are not enough anymore;
b) no actual arrays, let alone collections;

Code: Select all

//*********** not JUST "4 types".. *************
typedef struct weapon
{
	string name;
	entity proprietary;
	int ammoType;
	int inventorySlot[5];//this is an array
	float dmgAmount;
} t_myweap;

t_myweap rifle;

void Rifle_Init()
{
	rifle.name = "destroyyyyerrr";
}
//now cprint rifle.name and you'll have "destroyyyyerrr"
frag.machine wrote: c) no actual objects: having the same hundreds of disparate fields in every entity won't never scale (and it's a nightmare to keep sane);
I'll leave this alone because I didn't quite fully understood what you're saying. I'm not that advanced in programming to understand it.
I prefer Spike speaks for it. But, IMVHO, I never had problems with fields, as long naming conventions is good

frag.machine wrote:d) no actual inheritance: you cannot have a WalkingMeleeMonster super class so you can quickly write a new monster in 15 or 20 lines;

Code: Select all

//*********** CLASSES *************
class monster
{
	void() 	monster;
	virtual void()	monster_run;
	virtual void() 	monster_remove;
	
	float 			mhealth;
	float 			mvel;
	
};

void() monster::monster_run =
{
	this.velocity = v_forward * mvel;
};

void() monster::monster_remove =
{
	if(this.mhealth <= 0){
		remove((entity)this);
	}
};

//constructor
void() monster::monster =
{
	if (!this.mhealth){
		this.mhealth = 100;
	}
	if (!this.mvel){
		this.mvel = 20;
	}
};

//inheritance
class swampmonster:monster
{
	virtual void()	monster_runinswamp;
	virtual void()	monster_run;
};

//constructor
void() swampmonster::swampmonster =
{
	if (!this.mhealth){
		this.mhealth = 200;
	}
	if (!this.mvel){
		this.mvel = 50;
	}
};

void swampmonster::monster_runinswamp()
{
	//you get the point..
}

void swampmonster::monster_run()
{
	super::monster_run();
}
Just take a look at what Spike did with menusys. It' all OOP!
frag.machine wrote:e) no actual string support, strzone/unzone/whatever hacks are not good replacements;
From defs.qc generated in FTEQCC via the command pr_dumpplatform
string(string s, ...) strzone = #118; /* Part of FRIK_FILE, FTE_STRINGS, ZQ_QC_STRINGS
Create a semi-permanent copy of a string that only becomes invalid once strunzone is called on the string (instead of when the engine assumes your string has left scope). This builtin has become redundant in FTEQW due to the FTE_QC_PERSISTENTTEMPSTRINGS extension and is now functionally identical to strcat for compatibility with old engines+mods. */

Infact, I never talked to implement qcc in fhdoom, I always talked about fteqcc. IMHO they are 2 different worlds.. :biggrin:

#EDIT#: I forgot to mention that you can use pointers, malloc, memfree, memcpy too if you want! infact, I was trying, for exercise, to convert an algorithm made with Flowgorithm in Code::Blocks and it didn't worked. In 2 minutes I made it work on FTE! :lol:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: fhdoom

Post by frag.machine »

toneddu2000 wrote:
frag.machine wrote: a) sorry: float, pseudo-string (see below), vector and entity are not enough anymore;
b) no actual arrays, let alone collections;

Code: Select all

//*********** not JUST "4 types".. *************
	int ammoType;
	int inventorySlot[5];//this is an array
Fine, FIVE data types (with the caveat that ints are supported only using the FTEQW/fteqcc combo). My point stands.

Also: your inventorySlot is not an actual array. It's a compiler hack (try using anything different from fteqcc). What you really have is something more like:

Code: Select all

int inventorySlot_0;
int inventorySlot_1;
int inventorySlot_2;
int inventorySlot_3;
int inventorySlot_4;
And this is ugly, because not only this "array" needs to be previously dimensioned, but it cannot grow/shrink dynamically. Also, it's replicated in EVERY OTHER ENTITY because we don't have actual classes. Remember your rifle you declared in the first example ? It will also have the .inventorySlot "array". Player gibs ? Same thing. Monsters ? Yup. Grenades ? yeah, they also have inventories. And .score. And .noise, .noise2, .noise3, .noise4. And EVERY OTHER FIELD declared in your code for a completely unrelated reason.
toneddu2000 wrote:
frag.machine wrote: c) no actual objects: having the same hundreds of disparate fields in every entity won't never scale (and it's a nightmare to keep sane);
I'll leave this alone because I didn't quite fully understood what you're saying. I'm not that advanced in programming to understand it.
I prefer Spike speaks for it. But, IMVHO, I never had problems with fields, as long naming conventions is good
See my comments above. When you have a few entity types it is manageable, but try to implement something really complex and you'll start reusing fields among different entity types for different things (.button1 is a classic example) and have to remember EVERY time you used .delay or .wait for something non-obvious and bam, suddenly chaos takes your project over.

TL;DR: what I am talking about is being able to declare a Weapon class that don't have a .th_pain member because the Monster class declares it. You cannot do that in QuakeC (even using fteqcc and FTEQW).
toneddu2000 wrote:
frag.machine wrote:d) no actual inheritance: you cannot have a WalkingMeleeMonster super class so you can quickly write a new monster in 15 or 20 lines;

Code: Select all

//*********** CLASSES *************
class monster (...)
// BIG SNIP
Just take a look at what Spike did with menusys. It' all OOP!
Nope, see above. It's a hack. Spike does a great job emulating those features mostly via compiler tricks, but they still are hacks, lipstick in the pig. He cannot truly implement OOP, actual strings and more datatypes without breaking compatibility with vanilla QuakeC. But frankly, what he manages to do it's awesome for a 20+ y/o game engine, so I am not complaining, just pointing the facts.

toneddu2000 wrote:
frag.machine wrote:e) no actual string support, strzone/unzone/whatever hacks are not good replacements;
From defs.qc generated in FTEQCC via the command pr_dumpplatform
string(string s, ...) strzone = #118; /* Part of FRIK_FILE, FTE_STRINGS, ZQ_QC_STRINGS
Create a semi-permanent copy of a string that only becomes invalid once strunzone is called on the string (instead of when the engine assumes your string has left scope). This builtin has become redundant in FTEQW due to the FTE_QC_PERSISTENTTEMPSTRINGS extension and is now functionally identical to strcat for compatibility with old engines+mods. */
strzone, strunzone and other builtins are again hacks (you use them to manually write code to manage the allocation and deallocation of your strings in a separated memory space), because the standard QuakeC VM only supports immutable (read-only) strings or a single temporary string (through a single char buffer). FrikaC came with the strzone/strunzone idea, LordHavoc improved the standard temp string by using a fixed size string array (he also created some stringbuffer builtins to compensate the lack of operator overload for string concatenation - in other words, "Hello, " + self.netname ), and finally Spike improved the temp array string to the point you can (mostly) forget about this issue but you are still forced to resort to strzone/strunzone sometimes. Again, it's not their fault, they did what they could without breaking the ability to execute old progs.dat; knowing how those things work under the hood makes you respect their efforts.

My point haven't changed: QuakeC (including the fteqcc/FTEQW dialect) is just fine - for idtech2 engines. Newer engines with more features needs more powerful and versatile scripting languages, with real strings, more data types, at least some support to basic collections, an some real OO model for entities, not emulation using field arrays.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: fhdoom

Post by revelator »

Heh heated debate on this issue i can see :P
c# would be an acceptable compromise, although I am not aware of the effort involved to implement/embed an interpreter. I don't know of any available runtime (not even considering legal aspects here).
mono ? might be worth looking into the interpreter from it at least.

QC might not cut it for an engine as advanced as idtech 4 atleast if you want to take advantage of all it's capabilities, sure it could probably be done but you might end up regretting it afterwards because it would be an unholy mess even if support could be hacked in. That said it could probably be cool for something like the mini games inside Doom3 :) or something similar to wolfenstein the new order where you could play levels from the old wolfenstein. A remake of quake in this engine would rock and then we could throw in the old version as a minigame :idea: . Maybe something for bethesda to ponder on hmm ????
Productivity is a state of mind.
Post Reply