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? 

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. 

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. 

Will test later..... 

I'm laid up for a week with sciatica and won't be near a PC :[ 

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

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. 

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. 

I'm building with Tyrann's latest tools, though I doubt they're the cause in this instance. 

 

I'm provoking the white HUD with bad qc. 

quake one is the best game in all time 

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. 

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. 

I have the 4000 version in my surface and I am constantly having to dick around with different drivers.

I haven't had a lot of problems since I updated from windows 8 to 8.1 though. 

Been away from the internet for 3 months and just now trying the newest Mark 5 from post 314. I got the same hud bug posted by Yhe1 (post327). Next day I used Metl's original 0.85 to check an Unforgiven map for something. Then later, went back to Mark 5 for some other testing. Hud is now fine... hehe.

Is it something to do with the config.cfg? Everytime I'm switching engines I sometimes need to delete the config.cfg from the Id1 and Quoth folder to clear up some issues with various info_command and trigger_command entities.

Engine is really fast now with lots of my alpha_masked trees, leaves, bushes, ferns etc (as .bsp mapobjects). It's like Pyramid of the Magician.

Dynamic lights usually pass through func_wall and door entities but world brushes do block them. I checked at some examples while in Mark 5 and it was working correctly. 

Only one more thing - is there a way to prevent weapon moving up/down while looking up/down, like it's implemented in QuakeSpasm? Double-Barreled Shotgun completely disappears when you look straight down. 

Hi all. I've tried this little nice engine for a minute. Looks like this type of bug:

https://dl.dropboxusercontent.com/u/21356102/mark%205%20bug.jpg

happens when your gamma cvar is set to ANYTHING but 1 IF your scr_sbaralpha cvar is set to 1 (scr_sbaralpha 0.9 or 0 will fix the problem). 

And I have found a bunch of stuff that I cannot get to work,

texture pointer, ghostdemo, r_mirroralpha... it's weird because things like gl_greyscale and r_stains work.

Also, no m_filter??? 

do I get external textures working for models and such? It says the engine supports it but what are the files that it supports? What are the naming conventions? What directory do they need to be in? 

if it follows the standard method, then external model textures go into /progs/
the filename should be [modelFileName].mdl_[skinNum] 

Save the files as .tga files using your naming convention you just mentioned.

The files I had were as .png files.