fhdoom

[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.

[ceriux]

Now we just need the extensions

[revelator]

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.

[ceriux]

[revelator]

Hehe i know the feeling m8 no worries.

[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.

[toneddu2000]

[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.

[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).

[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.

[toneddu2000]

[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.

[toneddu2000]

[frag.machine]

[revelator]