Engine X 4.62 Beta

[Baker]

Care to share your current source so I can scavenge on it ?

I have the applicable code encased in "#ifdef SUPPORTS_ALPHACHAINS". Now, there is slightly more than that but it can easily be backtraced.

I'll upload my current source here in a bit and put it in this post.

[mh]

Quake used sorted spans to allow zero overdraw in the bsp renderer. The assumption is that between the left end of a span and the right end of a span, nothing behind the current polygon needs to be drawn. Not true if the polygon has holes in it.

Surely though software Quake already has cases (MDLs and sprites for example) where drawn objects are split off from the BSP and done separately? I'm not seeing how these surfaces would be much different, especially given that they can't be part of the world to begin with (as qbsp won't handle adjoining surfaces correctly).

Even so, the problem of translucent water and other alpha surfaces was solved as early as Quake II and it's not a particularly huge leap from those to these.

[andrewj]

Surely though software Quake already has cases (MDLs and sprites for example) where drawn objects are split off from the BSP and done separately? I'm not seeing how these surfaces would be much different, especially given that they can't be part of the world to begin with (as qbsp won't handle adjoining surfaces correctly).

They could be part of the world using the same mechanism as liquid surfaces (and the same logic for drawing the stuff behind them as when making liquids transparent).

The most compatible way would be to use them on brush models, probably the only way to do it if you are using the original qbsp.

P.S. Quake 2 simply stores all alpha or masked surfaces into a list and renders them in back-to-front order after rendering everything else.

[frag.machine]

I would be OK if vanilla Quake didn't had support alpha masked textures for worldmodel (but allowing it for the rest). That would be a reasonable trade-off, at least to me.

[Baker]

Source:

http://quakeone.com/proquake/enginex_465_src.rar

[frag.machine]

Danke!

[Baker]

have you added frik file baker?

Might add it today. Might not. Part of me thinks I will put off adding extensions until I exclusively focus on that.

One thing that will probably in that mix is thinking about how to integrate Error's vwep + q1.mdl stuff ...

viewtopic.php?t=2384

http://www.youtube.com/watch?v=0TuohcmfDpA

[mh]

I would be OK if vanilla Quake didn't had support alpha masked textures for worldmodel (but allowing it for the rest). That would be a reasonable trade-off, at least to me.

That's really the only sensible way to do it, otherwise you're talking about qbsp changes (which I wouldn't be surprised if HL has). On the other hand it does bump up the number of models, but making them static entities (and doing the most trivial fix in the world to increase max static entities to infinite) would work around that. When you think about it, having them block neither light nor vis does make sense too.

[metlslime]

Quake used sorted spans to allow zero overdraw in the bsp renderer. The assumption is that between the left end of a span and the right end of a span, nothing behind the current polygon needs to be drawn. Not true if the polygon has holes in it.

Surely though software Quake already has cases (MDLs and sprites for example) where drawn objects are split off from the BSP and done separately? I'm not seeing how these surfaces would be much different, especially given that they can't be part of the world to begin with (as qbsp won't handle adjoining surfaces correctly).

Even so, the problem of translucent water and other alpha surfaces was solved as early as Quake II and it's not a particularly huge leap from those to these.

Well i'm sure it can be done now, after all quake 2, half-life, and others have more feature-rich software renderers. I'm still not sure it was possible in 1995/96 with the system specs they were targeting.

Sprites and models are rendered very differently; they aren't lightmapped, models have really crappy perspective correction (check out how swimmy it gets when a triangle is close to the screen) and i believe they used a really rough z-buffer which broke down at a medium distance from teh camera (but you can't tell that much with models at typical quake screen resolutions -- the exception is seeing the muzzle flares inside the torsos of far-away enemies).

[stevenaaus]

from QuakeOne

This going to bog things somewhat, but I've expanded the goals a bit:

ProQuake
FuhQuake
ZQuake
Enhanced GLQuake
JoeQuake

---> EngineX
....
The idea comes from TyrQuake which builds both NetQuake and Quakeworld from a very similar codebase with a high degree of shared files.
....
I'm not sure if it will ever hit a point where I can fully merge the anticipated NetQuake and Quakeworld builds in a single exe, but that will be something surely attempted down the long, eventual road.

Hmmmm... Is all this still on the drawing board ?
It'll be hard to achieve without lots of effort and bug hunts, but merging some of the features of ZQuake / ProQuake is interesting.

Personally , i think you're a little crazy to be even contemplating this rewrite.

[Baker]

Hmmmm... Is all this still on the drawing board ?
It'll be hard to achieve without lots of effort and bug hunts, but merging some of the features of ZQuake / ProQuake is interesting.

Personally , i think you're a little crazy to be even contemplating this rewrite.

More than likely. I've just been getting owned on "free time" side of things lately, so I haven't got much traction on anything lately.

[r00k]

I've finally gotten around to compile zquake-c (v.17) cleanly, but im at the "what's the point" point. As soon as i wanna try to adopt QW-style protocol, i keep thinking, just use DP.
Then about that time i see DP getting more and more less of a Quake engine :O

Adding ProQuake stuff to zQuake would be reasonable though with zQuake the first thing i noticed is that stuffcmd from the PQ servers dont work.

[Baker]

I've finally gotten around to compile zquake-c (v.17) cleanly, but im at the "what's the point" point. As soon as i wanna try to adopt QW-style protocol, i keep thinking, just use DP.
Then about that time i see DP getting more and more less of a Quake engine :O

Adding ProQuake stuff to zQuake would be reasonable though with zQuake the first thing i noticed is that stuffcmd from the PQ servers dont work.

Part of the interest for me is learning. Goal #1, really. I want to personally explorer some of the differences between NetQuake and Quakeworld in the protocol, the physics and the progs interpreter.

That being said, I care about prediction for coop.

I think single player is "where it is at" and single player without coop is a "fail". And ZQuake runs coop for many NetQuake mods just fine and isn't so far from the island as to be a headache.

DarkPlaces can't run a ton of Quake mods. Now, whether or not any of that has a thing to do with the protocol --- I can't conclusively say --- but from my interests in learning, I'd prefer to merge 2 working models rather than a working one and a busted one.

I have done past ZQuake playing around and find the engine easy to work with. Plus I have not completely Quakey interests like Kurok compatibility --- seeing Kurok and Remake Quake to a large degree as the two tail ends of enhanced Q1 "level 2" standard.

[stevenaaus]

Then about that time i see DP getting more and more less of a Quake engine :O

Haha.

Part of the interest for me is learning

Yeah.. Quake is so interesting... The client/server model, weird Quake C language, OpenGL, the optional 3rd person view, and the console and binding complexities. And the way it's been bastardised by everything from Hexen 2 to RTCW. I wish i had more energy to code for it. It's also a shame the amazing SP mods like Travail and all the Quoth mods don't get more credit.

[Baker]

I've been working on some of the stuff here for about 3 months non-stop and taking the previous version (4.64) from about 4 months ago and incrementally building it up for getting it out by Quake Expo.

I'm gonna list these as I add them in ...

Engine X 4.65

1. Make a debug build that compiles. (DONE)
2. Make it have an icon (DONE).
3. Rename enginex to Engine X for project. Engine_X for files. (DONE)
4. Optional MH crash detection (not present in debug builds for obvious reasons). One real-world reason is that a GL engine crashing using hardware gamma does not get a chance to restore it (super annoying). See MH code in viewtopic.php?t=2416 where he shares how to catch "Unhandled Exceptions"
5. I like Code::Blocks, but I'm not going to make a Code::Blocks project file until the end because MinGW doesn't work as good as MSVC

I've been using -window in the debug builds along with -nohwgamma (disable hardware gamma).