Makes sense, in the past I've wondered how much that calculation matters for objects other than the view weapon or extremely close items. In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation. 

In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation.

Floating point is likely going to be faster than alternatives on modern CPUs. By which I mean anything in the past 10 or so years. 

http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_WindowResizing.jpg

Knew you'd be pleased :) 

That is very nice. 

As it turned out the wrapper supported it anyway (aside from changing a window style to allow for resizable borders in the reset code), it was just engine code changes that were needed.

The version of the wrapper used by Mark V also lacks one function (other versions of it had that function) that can reset the mode without having to recreate the window, but that can easily be provided if Baker wishes to retain D3D8 for any reason. 

#define R_LIGHTPOINT_ON_BMODELS
Include brush models in lightpoint calcs so that if you stand on a plat, train, etc you pick up light from that bmodel rather than from the underlying world geometry.

http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_r_lightpoint_bmodels.png 

I've been fiddling around with some batch files that could use Mark V and its install command as an "easy button" for getting some popular Quake SP content installed. I've come across a bug/quirk in the command behavior:

Sometimes a zipfile does not have any top-level folder, and also does not have any pak or progs, but does have things other than maps (so it likely does need/want to be in its own mod folder). arcanum.zip and mapjam6.zip are examples of this; they contain lots of content aside from the bsp files, but the installer just puts the bsp files into id1\maps and throws the rest of the zip content away.

There's a few different ways to fix that if you want to. FWIW my own preference would be for the install command just to always put installed content into its own mod folder (or have that option available). 

Also something interesting I just noticed with installing warpspasm.zip. I see that there an "FMOD.DLL" file in the original zip that gets extracted as a file named "dll" into the warpspasm gamedir.

Haven't really investigated this yet, but this may be because most of the extracted files are in the "warp" subfolder of the zip, but FMOD.DLL is not. So when doing path-munging to get the base file name, Mark V may incorrectly skip over too many letters of the path. 

I wonder if there is a tutorial somewhere to add a better modelformat to FQ?
Im thinking to add a (simple) MD3 loader based on JoeQuake or even IQM..

Would it hard to add IQM to FitzQuake? 

I added IQM to the RMQ engine, which was based on a much older build of QuakeSpasm that was nearer to FQ.

The big constraint of IQM in the context of Baker's stated goal to not go beyond GL 1.2 is skeletal animation: it's just far too slow to run this on the CPU. Even as few as 3 to 5 moderately complex models in view will pull your framerate down to a significantly low percentage of what it was. Stock FitzQuake is already CPU-bound and the last thing it needs is even more loading.

MD3 should be easy enough I think (I've never coded it up myself so can't comment more) and MD2 should be very doable (it can even share data structures with MDL). 

@mh -

true lightpoint

I would be interested in using your implementation of getting the light from brush models as a cvar or a worldspawn key to activate it. There are existing maps that this change alters the lighting in an undesirable way so it was removed from Mark V, but also I never quite 100% trusted my 2012 implementation. But I can remember pulsar wanting such a feature and activating it via a worldspawn key (name? "true_lightpoint" "1"?) would be ok for sure for a map wanting it.

dx8 build after dx9

Yeah if you have an enhancement for dx8 ... I expect the dx8 build to existing in the project as unused separate build since it's just 1 file

I've been slowly trying to wrap up implementation of the other platforms I want to have builds available for one example.

@johhny

Thanks for the heads up on how certain specific files that don't contain primary playable Quake content or that weren't planned for in the installer.

About batch files, this reminds me that I should make sure Mark V can play demos via file association ...

c:/quake/mark_v.exe +playdemo "c:/path_to_file/mydemo.dem"

... which in theory I wrote, but in practice I have never tested. And since untested things rarely work ... I would expect it to not work ;-)

Same for ...

mark_v.exe +capturedemo "c:/path_to_file/mydemo.dem"

... which allows bulk capture of demo to AVI. But I haven't tested it recently and as untested do not necessarily work right, it may or may not do so.

@steve - Mark V won't be doing IQM, etc. and isn't suitable for total conversions, etc. Why not use an engine like FTE which does fancy model formats and can even run in a web browser and is built to support total conversions? 

@Baker:
Why im currently using FitzQuake is because my current project is based on an abandoned psp project which uses a customized engine from crowbar and porting it to pc would be basicially just copy/paste/modify my own modifications (so it basicially becomes a stand alone game using fq).

Using FTE would be a nice alternative ofc, but i dont know anything about csqc.. 

If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

No obligation, of course. ;-)

/I figure since your knowledge of the .bsp is a few tiers of above mine, I'd mention this. My understand of the .bsp is not too bad at all, but is not on the level that I could write map compile tools in a timely manner or spec out a new .bsp format ;-) 

@gunter - I made a stab at making the blood fullbright dark red, but the existing particle texture is not suitable :( Not even reversing the colors, etc. The textures in question are rather hard-wired for "subtractive blending". So that imperfection is likely to live a while, unfortunately.

@steve - I hear you. And empathize. There are csqc tutorials at insideqc, I suspect you already know this. If even mh has trouble fully implementing iqm at a good framerate, any mere mortal (including myself) has a 0.0000000000 chance (plus my interest in iqm for Mark V is also 0.0000000000).

If I were in your position, I'd start learning csqc and switch to fte. 

If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

They're all trivially easy & I took the opportunity to clean up the code a little too.

Interesting thing: this should also work for putting shadows on bmodels (because "lightspot", used for positioning shadows, also comes from R_LightPoint) but currently it doesn't. I'll need to debug that a little.

There's room for substantial optimization in all of this code. With r_shadows 1 R_LightPoint is actually run twice for each entity; cull tests and a few other things are also run twice. There's a whole block of work that should basically be done once only much earlier in the frame.

Again, this stuff is such that it's not going to grossly impact ID1 maps, but start ramping up the entity count and it will make it's presence known. 

o.O
the engine supporting csqc doesn't mean it MUST be used, you can still get quite far without it (eg: smc, tenebrae etc). 

Thanks, MH!

They're all trivially easy

Then here's a quick question. Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *).

I have a hilariously awesome and clever idea for traceline and SV_Physics.

But I need traceline to return the surface because if it does, the check is "free" (no extra cpu).

/If this is possible. Also obviously, no obligation, now or ever. Keeps engine coding more fun ;-) 

Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *)

Not quite the same; the server code doesn't have access to this data, it just uses clipnodes and planes in the hull, not even touching regular nodes. 

I suspected as much :( At least I can mark that off my "investigate if this is possible" list. 

So the reason I was looking at the install command: I was thinking about building a "Quake singleplayer newbie quickstart" package around Mark V and the Simple Quake Launcher. It turns out there is still a LOT that has to be explained, but the menus and install feature of Mark V do help a little. A quickstart package would be a nice thing to have handy for sharing if for example Quake goes on sale in the Steam winter sale tomorrow.

I wanted to provide batch scripts that would help install a sampler of custom Quake content. I laid some ground rules to pick highly-rated and/or influential or classic stuff from Quaddicted, rather than just trying to pick my personal favorites, and ended up with almost 30 selections.

I thought the batch scripts would be pretty simple buuuuut it turns out not so. There are sometimes mod patches to install, sometimes other things to fix about the mod (like if it includes an autoexec.cfg file that overrides your own), etc. And then there's the Mark V install command issues. At this point I'm not sure if the effort was worth it :-) but it's done and it is what it is.

The Mark V issues so far are just in the two buckets that I mentioned in previous posts. Either 1) failing to install all the files (because no progs.dat or pak file in the zip), or 2) mangling some file names because of subfolders.

Of the content I tried to install, these were in the first bucket:
arcanum, apsp3, func_mapjam2, mapjam6
and these were in the second bucket:
nehahra, warpspasm

The second bucket is fixable from the batch files just by doing file commands. Although in one case a file with a short name actually gets completely nuked by the path issues, but that's OK because I didn't want it anyway (the fmod.dll in nehahra.zip).

The first bucket I can also fix in the batch files by extracting the stuff from the zipfile myself instead of letting Mark V do it, but to unzip files I'm using a feature of .Net 4.5 which is only installed by default on Windows 8 and 10. So that's not ideal.

Anyway that's a lot of typing about install issues. To help break up the wall of text I'm going to stop this post and then have two short posts with some questions. 

OK so FYI, here's the installer batch scripts as they currently stand. The "installers" folder should go into your Quake folder next to Mark V: https://dl.dropboxusercontent.com/u/11690738/temp/installers.zip

The .bat files are the ones to run. Ignore the .cmd files as those are just common code shared by the .bat files.

If anyone wants to try them out I'd be curious to hear about problems you encounter. I probably will share these around during the Steam sale, likely bundled with Mark V and the Simple Quake Launcher and a bunch of readme files. I'm sure only a few people will make use of them, but even so it would be cool to get a tiny bit of advance testing.

Even if you are on an earlier version of Windows and don't have .Net 4.5, the installs of the "problem child" mods like arcanum should fail gracefully with a nice message about how to manually fix them.

So if anyone gives these a try, please let me know if they work or if they don't. If it's an interesting issue you could post it here, or otherwise to avoid cluttering the thread you can email me. Use the email address that's in the page footer of http://neogeographica.com/ 

Last thing for now, a question:

When trying to give people a foolproof way to run Quake content, the major gotcha I'm left with is how deal with a mod that needs a base game. Like how warpspasm needs Quoth. I can install Quoth for them but I can't make them specify Quoth as a base game when they launch Quake to play warpspasm.

I know that Quake Injector solves this, but getting people to correctly install and use a Java program has turned out to be a hurdle. It's kind of bad that the mods and engines themselves don't declare and enforce base-game requirements. Has there ever been any discussion of standardizing on a way to solve this? Some metadata that the engine would recognize and honor? 

Forgive me for being an idiot here, but the Quake Injector is open source right? Is there any particular reason why its method of handling unpacking and installation isn't used by MarkV?

Obviously it's not something you can convert (It's java, after all), but surely the logic that it runs can be reproduced. If that were the case I imagine the only compatibility issues would be ones shared by it as well, rather than all these new ones that seem to have cropped up here...


I'm sure there's a perfectly good reason why this wasn't done, but I don't know it and this question has been on my mind a lot recently. 

Mark V can unzip most zip files properly just by itself.

The Quake Injector, as it is currently written, cannot. A brief discussion with Spirit, he was like "Ah, why didn't I think of that?" when I told him the secret sauce.

So the short version goes like this ... let's say someone has a .zip file that isn't in the Quaddicted database. Like this stuff ...

http://www.gamers.org/pub/idgames2/partial_conversions/

The goal of the Mark V is to not be dependent on a database to give independent parties the potential of possibility of creating their own archives.

Also I view the Quake Injector as too permissive in the unzipping, I also think it does it slightly wrong -- a small gripe -- but engine developers worry about "the little things". 

The "installers" folder should go into your Quake folder next to Mark V

I hate to have to say it, but this is where "n00b-friendly" breaks. My experience was that getting stuff into the right folder(s) is the number 1 difficulty people have.