Page 2 of 3

Re: fhdoom

Posted: Wed Oct 18, 2017 1:51 pm
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 ????

Re: fhdoom

Posted: Wed Oct 18, 2017 1:51 pm
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 ????

Re: fhdoom

Posted: Wed Oct 18, 2017 3:18 pm
by toneddu2000
revelator wrote:Heh heated debate on this issue i can see :P
No, not heated at all! frag.machine, accidentally, proved my (very personal) point! I wouldn't be mad at all if porting fteqcc (and not qcc) compiler to a modern engine would break compatibility with old Quake stuff, I'd be happy if it'd do! :biggrin: It would be a new era as programming language on its own! A language that fired up my passion for programming, so, I'm pretty devoted to it! :)

My point (as frag.machine's one, of course) stands: probably Spike attempts to add advanced features to fteqcc are hacks (I don't have the low-level skills to say anything about it), probably they're just lipstick on a pig (that would depends: if the pig is beautiful even a little of eyeliner wouldn't hurt! :mrgreen: ), but personally I don't have any complaints to do to FTE and fteqcc. I love working with them and, imho, qc language it's not its weaking point. It lacks serious good mesh collision control, a personal physics engine (ODE support is too crashy to be considered usable) and a new rendering engine.
No one will do these things to FTE? Of course, but I'm happy to have created craFTEr with it! :biggrin:

Re: fhdoom

Posted: Wed Oct 18, 2017 10:33 pm
by frag.machine
revelator wrote: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.
Please don't think I am bashing anyone for trying to improve QuakeC - actually I am grateful to Spike, LordHavoc, FrikaC and many others that contributed to improve during years what was a very crude but efficient scripting language to my favorite game. Also I actually have fun programming in QuakeC as a hobby, but that won't prevent me to see how limited it is for serious projects, and how it would be a bad decision to try to use it outside the idtech2 scope.

Regarding c# interpreters: a quick googling brought this, besides some StackOverflow old threads where people was looking for similar solutions without much luck. I think it may be worth a look, maybe it's possible to saddle it on top fhdoom with the right hooks to the existing game logic API.

Re: fhdoom

Posted: Thu Oct 19, 2017 7:05 am
by revelator
http://www.mono-project.com/docs/advanced/embedding/

It does support embedding :razz: well that could be fun.

Re: fhdoom

Posted: Fri Oct 20, 2017 5:37 pm
by JasonX
Has Doom 3 networking been improved on those new source ports? It used to suck. A lot.

Re: fhdoom

Posted: Sun Oct 22, 2017 12:40 pm
by toneddu2000
In a half-related way, Godot engine supports (in alpha still) C# scripting language. Yum, if they finish to implement graphics features they advertised, hmm.. it could become a great choice in the open source engines universe

Re: fhdoom

Posted: Wed Oct 25, 2017 7:30 am
by revelator
Seems the bug i encountered where my card would not initialize the core wgl extensions have been fixed in the latest version :)
Still some small buggers (mostly shadowmap related) but it's getting there.

As for scripting Euphoria could also be a good candidate :) it is a very powerful language and easy to learn.

http://openeuphoria.org/index.wc

Re: fhdoom

Posted: Thu Oct 26, 2017 6:50 am
by revelator
Something to keep in mind with this port unless you want to get confused like hell is that it does not support fixed pipeline at all, so any older stuff like getting the number of tmu's or texture coordinates is a no go unless you do it via shaders. You can actually see this if you open the console and look at GL_MAX_TEXTURE_COORDINATES, it reports 0. The only reason its still there is that the early megatexture code has not yet been ported :).

And if you card does not support OpenGL 3.3 minimum then your totally out of luck, no voodoo cards allowed here hehe.

It might have been doable by using the compatibility profile but the dev opted to not support old stuff, and in a way i see his point cause it would be hell to maintain.

Re: fhdoom

Posted: Sat Nov 11, 2017 3:09 pm
by Nahuel
toneddu2000 wrote:In a half-related way, Godot engine supports (in alpha still) C# scripting language. Yum, if they finish to implement graphics features they advertised, hmm.. it could become a great choice in the open source engines universe
godot has online testing also
I think this enginecan be great in the future, but it's still in alpha for 3d games.
https://www.godot.online/wasm/

Re: fhdoom

Posted: Mon Nov 13, 2017 1:59 pm
by Barnes
revelator wrote:And if you card does not support OpenGL 3.3 minimum then your totally out of luck, no voodoo cards allowed here hehe.
Cut off 3.x!!! Only 4+ only hardcore

Re: fhdoom

Posted: Tue Nov 14, 2017 2:01 am
by revelator
Cut off 3.x!!! Only 4+ only hardcore
Or hardware more likely hehe.

Most cards today support atleast 4.4 anyway :), could be interresting to see how it runs on the less stellar cards though.

Re: fhdoom

Posted: Tue Nov 21, 2017 8:12 am
by Barnes
my card support 4.6 :lol:

Re: fhdoom

Posted: Mon Jan 22, 2018 4:04 am
by revelator
Has Doom 3 networking been improved on those new source ports? It used to suck. A lot.
Not sure much work has been done on the network side, but some bugs were squashed by iodoom, so that might have fixed it up atleast a little.

development seems to have halted a bit on fhdoom, i hope someone takes up maintaining it if the dev decides to leave it as is.
Would be a shame to let his work go to waste when people have screamed there heads off about adding modern glslang to doom3 :P.
Still room for more improvements like Vulkan support, which would be a nice plus ;).

Someone might even recreate quake, just imagine the horror show that would be possible with this engine hehe.

Re: fhdoom

Posted: Mon Jan 22, 2018 8:03 am
by toneddu2000
revelator wrote:Someone might even recreate quake, just imagine the horror show that would be possible with this engine hehe.
they (kinda) did