News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.

FitzQuake Mark V Download:

http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.

It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.

Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme).
First | Previous | Next | Last
@cheating 
"sv_cheats 0" will stop god, noclip, freezeall, fly in Mark V.

A Mark V server will also tell Mark V clients what gamedir is running and automatically switch them.

For instance, if the Mark V server is running "-game warp -quoth" it will instruct Mark V clients to do the same upon connecting.

[Which is a Spikeism ... thanks Spike!] 
Any Chance 
Of supporting bsp2? 
@ijed, Why Do People Like This Engine? 
Mark V has almost no features that anyone ever asked for. Ever.

And yet people like the hell out of it?

I guess what I saying here, why should anyone use this over Quakespasm, Fitz 0.85 or DarkPlaces?

Yet, serious single player or coop people love this engine.

Despite the fact it doesn't implement ANY features that anyone ever actually wanted or asked for?

I implemented stuff that I thought the average player would really like to make things fun, user-friendly and easy.

I guess I'm saying, bsp2 is just going to ruin single player entirely. You probably can't even properly coop any of those maps.

Is the master plan here to create impossibly large levels that can never be cooped and bust all sanity in even things like recording demos?

Of what use are maps that cannot be cooped in the bigger picture?

I personally don't see super-giant for the sake of super-giant as a positive direction --- many Fitz 666 maps are only barely coopable over LAN.

What makes Quake isn't multiplayer --- QuakeLive or other things can do that --- and it isn't literal single player because you can find this in other games.

But coop is where Quake reigns supreme -- how does BSP2 further this great strength of Quake? Or are we just breaking engine limits these days without considering the consequences of where the path is leading?

Let's just break every limit --- creating a cascade that challenges rendering and the network protocols and even advanced predictive protocols is just "wrong" to me.

If you think about it, almost everything in Mark V has been done to support coop and demo sharing. BSP2 teaches map authors to not really consider map design constraints for maximum "utility" and just be lazy. There are many incredibly big protocol 15 maps --- Fitz 666 raises that to beyond absurdity --- and now lazy map design isn't satisfied by that?

Sheesh --- some of the Travail levels --- like the one with the lift that teleported --- worked around that. Just as a base example.

The short version: bsp2 end result maps aren't usually coopable --- coop is a design strength of Quake --- perhaps maps that don't fit in the design strengths of Quake should only be playable by outside the mainstream engines.

/Good judgment almost kept my from clicking submit --- then again, I don't have much of that. Submit it is! 
Baker 
What about sex before marriage? 
 
Baker, If you're actually serious about coop, you'd go implement support for RFC 5245 somehow. :P

Also, its probably worth rewriting the network protocol anyway, *especially* for coop. Coop can easily get more spammy than deathmatch. 
Bug Again 
https://dl.dropboxusercontent.com/u/21356102/mark%205%20bug.jpg

It's on an ATI 3670 with 11.12 drivers. 
Coop Is The Only Reason To Play Quake? 
And big maps are lazily made?

Each to their own then.

I get the point of wanting a simple engine though. 
Quake Does Not Equal Coop 
I've played coop quake maybe once or twice in my entire life.

I thought the whole point of these huge super giant bsp2 maps was to make an epic singleplayer romp? And these super maps are very few and far between.

I really don't see the reason for this rant, most people like Fitz for its stability, simplicity and faithfulness as a quake engine.
I personally prefer DirectQ because it is slightly more feature-rich, but it's mostly unsupported these days. 
Baker 
I take exception to the comment about lazy maps too.

The features I like about FitzV:

Runs fast
Supports loads of demos
Cool demo features
Perspective correction on weapon models in widescreen


Though I would like it if I could play my big map on your engine. As we move forwards in time, some people are going to want to make huge maps. TBH it's been a fantasy of mine since I started mapping, the only reason for not doing it was the engine limits.

9 out of 10 people have hardware that can run huge maps. r_speeds is not really an issue any more (though I still full-vis my maps).

I mean it would be nice if there was an active Fitz branch engine that supported BSP2. Tyrann's new compiler is quite possibly the best qbsp compiler we have ever had, AguirReMHLight is IMO the best light tool. Everything is in place, we even have engines, but it would be nice if an active (and very cool) engine supported everything. Then I would ONLY use FitzV for EVERYTHING. And more than likely, the majority of other folks would too...

Pleeeeeeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaasssssssssssseeeeeeeeeeeeeeeeee? 
Warp 
Supported Coop but my new one won't at all. In theory I could try and include it, but there's a tonne of dependencies in the AI and core game mechanics that mean it wouldn't make sense to try it coop unless I completely changed the game mode...

Which could be valid I suppose, will give it some thought.

It's also a very big map. 
 
"freezeall" command is what you seek.
Wow thank you, the command is perfect! :D

Mark V has almost no features that anyone ever asked for. Ever. And yet people like the hell out of it?
I like this engine because it is simple and not over the top. There are no fancy extra graphical features or SP fixes, it just works, really well.

+1 for wanting bsp2 support, it would be nice to play future large maps with my favourite engine. 
Lets Make Things More Interesting... 
one quick hack later: voila, markv with bsp2 support: http://triptohell.info/moodles/junk/markv_bsp2.zip
Completely unsupported, use at own risk, etc.

Baker, be sure to read the readme in there. I mean it. Really. 
Yay! 
Will test later..... 
Bah 
I'm laid up for a week with sciatica and won't be near a PC :[ 
@Spike 
Thanks

[I owe Spike so many thanks at this point, I think he flipped the universe's digit counter with that one.]

@Others

I'm not reading your replies right now.

Here is why --- and perhaps I can make Barnak really happy here ---

All of the spare time I don't have --- 100% of it --- I am building Fruitz of Dojo native OS X Mark V with 100% feature set (well maybe 99% --- Mark V AVI capture on OS X isn't something I can add conveniently).

[Will still have a very Quakespasmy codebase.] 
Woot 
Thanks Spike!

Got the level plugged in and running now. There's a couple of graphics glitches - the standard id sky doesn't render properly and the HUD sometimes gets stuck on white, but a lot of the other stuff that I was missing like coloured light and fullbrights is now working properly. 
@ijed 
sky+hud bugs don't relate to the code changes I made. Could be down to compiler differences or due to simply being based off an old version (baker still hasn't released the source to match his latest exe).
Coloured lights and fullbrights are not my work either. 
Fair Enough 
I'm building with Tyrann's latest tools, though I doubt they're the cause in this instance. 
I Meant C Compiler. 
 
Looks Like 
I'm provoking the white HUD with bad qc. 
Good 
quake one is the best game in all time 
Gray Borders 
There are thin (1-2 pixels wide) gray borders along the right and bottom edge of the screen in Fitz MkV, at any resolution. Any way to remove them? Graphics are Intel HD Graphics 2000. Also, is it normal that dynamic lights break through walls?� 
 
Dynamic lights break through walls because because computing occlusion dynamically was too big an issue in 1996 (english: shadows are expensive). Nowadays we use shadowmaps or shadow volumes for that stuff. So you can use something like Darkplaces or FTE if you want those kind of features. 
Lines? 
And about the gray lines? A graphics driver issue perhaps? 
 
I have no idea, that one sounds more like some engine or driver edge case. You'll have to ask someone qualified. I've read that Intel's openGL drivers can be a bit buggy tho. 
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.