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
Mh 
thanks for the tips, will play with the merging brush models into the world sometime.

Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array - there's no R_RecursiveWorldNode - then reverses the order per-texture from the chaining. Not sure if cl.worldmodel->nodes has any meaningful order to it.

ijed, that's a good point. 
Yeah... 
the idea was that iterating a list is much better on CPU than walking a tree, and the order wasn't that important. This idea was taken from darkplaces at the time.

I have no idea if it's the correct tradeoff with current hardware. If GPU bound I guess front to back would be best. 
Fitz Walks Through The Surfaces... 
Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array

The big problem is that it only regenerates texture chains when the PVS changes. Merging brush models really requires texture chains to be regenerated each frame.

It's actually quite trivial to write a GL renderer that runs twice as fast as Fitz on ID1 maps (much more on big maps), but much of that is down to batching rather than BSP tree traversal (this isn't including dynamic lighting which is it's own separate problem).

So adding some good batching and accepting the CPU overhead of building the chains each frame is a reasonable tradeoff that you're going to come out on the good side of on any hardware (unless you're totally fillrate or ROP bound, which the original 1996 hardware was, and therefore none of this was a problem back then), and then you get the ability to merge as a bonus. 
Happy New Bump 
Any progress on fixing the vs2008/OpenGL build of the latest snapshot? I'd hate going back to r15 after all the improvements which have been applied since then. 
Source 
any chance you can post the source for that last snapshot Baker? (no rush, just curious to have a look at it) 
 
@ericw -- of course! I'm deep in the middle of possibly finally handling some frustrating math calculations that have been owning me all week at the moment, will upload first opportunity tomorrow.

@nightfright -- Don't want to promise a timeframe at the moment. At same time, I do want to get a revision out. 
 
@eric w -- source 
Thanks! 
 
 
Also: There needs to be an SDK folder above the source code with this. Contains DirectX, Curl, a very heavily modified "FDFramework" (the Mac build was derived from Fruitz of Dojo), some headers and some things moved out of the engine folder.

(More complex than I prefer ...) 
Crash On Quickload F9 
Getting Quake Error
R_Renderview: NULL worldmodel
When pressing F9 to quickload after previously saving with F6.
Fitzquake mark V 0.94 
 
try again without any mods 
Fitz With .mp3 Files Etc 
Any idea how to get this to work?
I just can't it working in FQ, but it seems to work fine in quakespasm. 
Quickload Crash 
Can't work out why this is happening. Workaround: put the following in autoexec.cfg:

bind "F6" "echo Quicksave...; wait; save s0 "
bind "F9" "menu_load "

So the top save slot is the quicksave one. 
Bizarre... 
can you try this:
in the console, type load quick.sav

the 'load' command can load any save by filename and quicksave just saves to a quick.sav file. There should be no difference between loading a normal save and loading a quicksave via quickload. A crash there would indicate something up with quickload code? Or the order in which things are done with quickload vs load?? 
Happens With V0.94 For Me Too 
but it seems to be fixed in v0.99, maybe try that version?
http://www.celephais.net/board/view_thread.php?id=60831&start=507

necros: "load quick" in the console causes the same crash. For some reason loading via the menu works. 
 
Maybe it disconnects first. 
Quickload 
Thanks, 0.99 vs2008 version works. The winquake version wouldn't start. (Win7 Pro x64 i7-4770 integrated graphics) 
Autoexec.cfg 
If I have an autoexec.cfg then the sky is drawn over the world. Anyone else having this issue?

https://www.dropbox.com/s/kxkl7j9mrlj22rh/bug.jpg?dl=0

I thought it was a setting in the file but it seems that any entry will cause the problem. 
Nb 
I tried to get around this by having a file called 1.cfg (the only setting being r_shadows 1), I typed exec 1.cfg and I get the same sky drawing error. 
Ignore Me 
I just went back and re-read the thread and realised there's a bug with shadows in the latest build...

What a weird coincidence that this was the only setting I decided to keep. Losing my marbles. 
 
The Nehahra Fog doesn't work in Mark V. I remember Directq used to have a problem with this. 
Nehahra Fog ... 
Nehahra is an interesting thing, especially the fog. Here is what I did ...

1) DPNehahra is the official engine for Nehahra.
2) Because dpnehahra is the official engine, I view how dpnehahra displays a map as correct and only way it should be displayed.

Load up the map in question in dpnehahra:

A) If dpnehahra shows fog on the map, I have a bug.
B) If dpnehahra does NOT show fog, I am complying to the official presentation.

JoeQuake and derivatives present the maps in a different way than DPNehahra.

But JoeQuake didn't exist when Nehahra was released and I view any differences in map presentation between JoeQuake and DPNehahra to be JoeQuake presenting the maps wrong.

Case in point, there is a DP Nehahra expansion map with a skybox and non-standard fog keys.

1) If I load up the map in DPNehahra, I see the sky but no fog.
2) If I load up the map in JoeQuake, I see fog but no sky.

I had to pick which way to do it, I picked the DPNehahra way. 
Who Needs A Fog Anyway? 
the fog is a lesser issue 
 
But DPnehehra has the fog in Neh2m5, but Mark V does not 
 
Since you are playing Nehahra, if you happen to know where any of the smoke emitters are, let me know. I spent a lot of time trying to get the sprite 32 support perfect and such, but the maps are so large and I couldn't find a smoke emitter. 
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.