Engine X 4.61 Beta

[Baker]

OK
gcc returns errors about missing windows.h file
Is the source even complete?

EngineX is a Visual Studio 6.0 project. To get it to compile with gcc you will have to invest a lot of time and effort.

That being said, the next ProQuake with feature a gcc compile version with CodeBlocks for *Windows*.

This will probably bleed eventually into Engine X but I am doing a ton of work entirely reworking the foundation of ProQuake (and therefore Engine X) to be more multi-platform friendly.

I really like Code Blocks and I have taken a liking to gcc because Microsoft Visual Studio is so fat and bloated. With gcc, I can stuff my source on a USB drive and work on it anywhere.

[MH]

Pity gdb is crap though.

[rev]

love the engine. i know you're aware of many of the bugs already, and maybe this one has been mentioned already, but when i exit the game, my monitors color settings are FUBAR'd to hell... completely washed out and wayyy too bright....until i execute setgamma... just thought you might want to know

[R00k]

When you start the engine, scroll up to the top of the console and look for
"Hardware gamma not available (GetDeviceGammaRamp failed)"
if that's the case then there may be a driver issue with your gfx card disallowing the software from setting the gamma directly.

[bluntz]

EngineX is a Visual Studio 6.0 project. To get it to compile with gcc you will have to invest a lot of time and effort.

That being said, the next ProQuake with feature a gcc compile version with CodeBlocks for *Windows*.

When you say VS 6 project Are you saying its not C but C++ ???

[rev]

ROOK-

"hardware gamma enabled"

it only happens when it crashes. and whats with the half the video settings menu not working?

like i said, love the engine, can't wait to see a more polished version... i think my favorite thing about it, is it still have PQ features like +quickshaft, and all the eyecandy doesn't affect my fps. GJ Baker.

[rev]

oh, one other thing, no RJ'ing issues for me, in fact, RJ'ing is smoother and more accurate... it must be certain settings they are putting the options to that's messing them up.

[MH]

When you say VS 6 project Are you saying its not C but C++ ???

It's C; you can use C perfectly fine in VS (even the latest versions).

[Baker]

oh, one other thing, no RJ'ing issues for me, in fact, RJ'ing is smoother and more accurate... it must be certain settings they are putting the options to that's messing them up.

I've got about ... no kidding ... 30 somewhat significant changes (probably 25 of them are not obvious to a non-engine coder using only Windows) in the next version of Engine X and ProQuake.

I'm working to assimilate all of them, but the rocket jump weirdness thing is as good as dead. It was a stupid mistake on my part. Not everyone experiences the problem if Engine X uses your existing ProQuake config.

For at least ProQuake, Linux and SDL builds will be available. This is largely because I got mad and decided to make Ubuntu co-habitate on my notebook plus my recent found love for Code::Blocks and gcc (I like being able to put my engine code on a USB drive and work on it anywhere, which I cannot do with Visual Studio). This means the Linux version will receive an update after 2.5 years.

I'm still not a Linux fan, but I always wanted to evolve the Linux version more and that was stopped by my Linux machine being foobar'd ... which is no longer an issue.

[Seven]

Hello Baker,

first of all I must admit: I didnt read this complete thread.
So maybe my question has already been answered. If so, I am sorry.

Now, that you are kneedeep in coding (or even deeper), one serious question came to my mind.
Yesterday, Mr. Burns brought it on the table in another thread:
For me, as a modder, it is very hard to satisfy all people.
Reason:
Lets say, there are 100 people in the world, playing Quake.
Today there are lets say 5 great engines available, so 20 people play each engine.

Today I can NOT bring all 100 people a benefit with my mods/enhancements.
Because there is NOT a standard/agreement between the engine devs !
Example:
One engine needs its files in the folder "xx", the other engine needs these files in the folder "yy".
One engine must name its files "111" another engine needs the "222" format for it.

This makes it impossible for us to create something for ALL 100 people.
So we must decide, which 20 people we make happy and wich 80 are left alone.

I guess youe engine will support external files (textures, models, shaders, skins and stuff).
- Which standard will you use in Engine X ?
- Are there secret meetings with engine devs where you talk about something like this ?
- Why is there no standard today ?

I would also be happy if other devs (like LH, MH, Spike, Rook, ...) would write a few lines about it.

I really dont want to complain. I can imagine that everybody has its own ideas.
I am just curious and a little sad, about the situation.

Thank you for your reply.

Kind Regards,
Seven

[MH]

That's an interesting can of worms. I was around when all of these "standards" were being developed in the first place, and - to my mind- one reason why things are the way that they are today is that content ended up being released for partially evolved standards. Another, probably more important, reason is that there wasn't enough interaction between the mapping/modding community and the engine development community at the time (in fact it was common for there to be bouts of open hostility). You only need to look back at some old interviews to see that.

So we had mappers and modders looking with scorn on engine work, and we had engine coders going off doing their own thing in isolation and without any guidance as to what was actually required (thus further fuelling the antagonism). Bound to end in tears, and today we have a stupid situation where skyboxes (to pull an example out of thin air) need to be supported in /env, /gfx/env or /gfx.

If that sounds a bit biased towards engine-coders I suppose it's only natural to be (I am an engine coder after all!), and no doubt a mapper or modder would give you a variation from their perspective, but the guts of the point are - I think - mostly correct.

For the most part this situation still exists today, although there are a few big players in engine-land that everything has settled down around, and things are a little better than they used to be (just be grateful that you don't have the hacked-up BSP30 to contend with as well!)

For picking a standard I think there are a few to choose between. DarkPlaces is the obvious one that's popular with content-replacement fans like yourself. FitzQuake is popular with the active mapping community. Follow what either of these do and you won't go too far wrong.

A third option is probably JoeQuake which remains enormously popular with the speedrunning and demo crew. This I guess would also cover Qrack and EngineX which are ultimately derived from it (or which have taken significant enough chunks of the JoeQuake base).

Note that I don't count ProQuake or my own DirectQ here as (1) ProQuake is a very different beast and with a very different focus, and (2) DirectQ was late to the party and tends to follow rather than lead.

DirectQ does, by the way, recognise this problem and is capable of loading most content from almost anywhere. You could put a skybox (going back to the previous example) into C:\Quake\ID1\elephant and DirectQ will find it and load it. But that's avoiding the problem rather than solving it.

I think you're going to have to accept that there is no way you're going to get all 100 of those people you mention. It's not possible. Quake players are a very diverse lot, with very diverse tastes, and for every one person who loves replacement HUD and menu graphics there will be another who is an ultra-purist and who will despise your work. You can't please all the people all the time.

So what you need is to pick your target audience and aim your work specifically for them. Say up front that "if you don't like this kind of thing, then this is probably not for you". Where possible compromise, but where it's not possible you need to put your foot down and say "this is the standard I'm following". Do the best you can and your work will stand on it's own merits.

If your work is good enough then others might even pick up on it and port it to other standards. But relax the expectation that it should work with everything from the outset.

Yeah, I wish things were different too, but making the best of what we've got is the way it needs to be done.

[Seven]

MH,

thanks a lot for your kind and wise words.
I play Quake since its beginning but had looong breaks.
So I wasnt aware of your 1st paragraph.
Its clear now to me, why things developed as they did.
Reading your post was really a pleasure and very informative.

Due to the fact, that I never play multiplayer (I even seldom play Single Player)
but love to turn on screws and bring my own ideas into games, I chose DarkPlaces.
Thats why all of my work is based on it.
Its sad, that LordHavoc is not often in public places (like this forum).
Its hard to reach/contact him, cause I have of course plenty questions.

Thanks again for your time writing this and helping everywhere you can in this forum.

Kind Regards,
Seven

PS: A couple of days ago I wrote a PM to you. Could you please check ?

[Baker]

Hello Baker,

.
.
.

Kind Regards,
Seven

Seven, I understand your concerns and ideas and appreciate your reply.

You have about 7 or 8 different engine authors with their own vision of the "World of Tomorrow". These ideas compete and aren't completely compatible nor completely incompatible.

If you were to sum up my point of view:

1. Runs on all machines, all platforms, all devices (I mean non-desktops), all renderers
2. Fully compatible with standard Quake. Compatible with mission packs, Nehahra, a subset of Half-Life features (rotation, intermap travel, origin brushes, "fence textures"), sprite32 and a well-defined established set of traditional enhancements (skybox, fog, etc.),
3. No bugs. At all. (This is a pursuit. Like the pursuit of happyness. I don't think it can achieved, but can always be pursued).

The engines I work on are more to satisfy the current single player body of work, the current multiplayer body of work and as much of the forward thinking single player and multiplayer body of work as possible plus total conversions.

Engine X supports the DarkPlaces replacement texture naming convention (I believe it should the only one supported) but only supports replacement textures and the fullbright texture overlays (_glow textures).

Most of the existing engine coders talk @ Inside3D.com

[Spike]

FTE attempts to open about 70 (extensions+paths+mapspecific paths) different files per texture - per gamedir. Being a quakeworld engine, you generally have about 8 gamedirs (id1,qw,fte,$mod,$home/id1 etc) at any one time.
So each individual texture in a quake map potentially results in about 560 different file open attempts to the operating system.
That's ignoring fullbright and bumpmaps and stuff (so more than 2000 potential file paths, per texture - I just want to say that linux copes so much better with this than windows).
Yes. FTE has special code to stop such maps maps from taking 5 mins to open.
There is no way that an engine can just add compatibility for every single 'standard' in texture naming, no smegging chance.
Once you have support for one naming system, things get really really messy each time you extend it and add alternatives. Engine modders are typically left needing to support awkward formats for already existing mods, and they know that if they add more combinations, their loading times will rise exponentially.
With those two potentialities, the only way to avoid both is to do nothing - to require the modder to name their textures to match each engine's loading mechanism.

If that makes any sense.


There are two naming conventions that I personally care about. The fuhquake/joequake naming convention, and the DP convention.

The great thing about standards is that there are so many to pick from.

[qbism]

Issues related to conventions include defines of effects and other flags. This can cause a lot of heartache, because a modder may never see a clue as to why a certain effect works in 'Engine A' yet has an unpredictable effect in 'Engine B'.

Let's say Engine A defines EF_COOLEFFECT=512. Now, lots of engines support 'cool effect' but there's no standard for the protocol among coders. The coder for Engine B may choose another slot, say EF_COOLEFFECT=1024. These defines are mimicked in defs.qc and must match up exactly.

This is the combined effect of (1.) development in isolation (2.) prioritizing flags within a limited number of slots for a specific features set and (3.) basic disagreement about that world of the future. And frankly, it's a pain to change protocol, waste packet bytes, etc., just to leave some flag slot open that one's particular engine will never use!

Numerous valiant efforts by 3-letter acronyms have made things better over time and eventually the strong ideas circulate: the QSG (Quake Standards Group), the QIP (Quake Info Pool), the QER tutorials (Quake Engine Resources) - I miss that old message board! - DPE (Darkplaces Extensions) and the newest and greatest effort which combines several others, the QSB (Quake Standards Base)