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

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. 

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 

 

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

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 

Any idea how to get this to work?
I just can't it working in FQ, but it seems to work fine in quakespasm. 

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. 

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?? 

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. 

Thanks, 0.99 vs2008 version works. The winquake version wouldn't start. (Win7 Pro x64 i7-4770 integrated graphics) 

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. 

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. 

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

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. 

Does Mark V support external fullbright maps for brushes, like Darkplaces do? What do I have to do? I already have some xxx.tga and xxx_glow.tga in my ID1/textures directory. Mark V reads the texture, but the _glow thing doesn't seem to work. How do I fullbright a brush surface?

Also, is there support for alpha translucency? How do I do it?