Func_Msgboard: Fitzquake Mark V

News | Forum | People | FAQ | Links | Register | Log in

|  | Fitzquake Mark V

Posted by Baker [69.47.162.203] on 2012/06/29 11:38:17

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

Wow!
#1 posted by RickyT23 [94.13.59.186] on 2012/06/29 19:17:17
#2 posted by necros [99.227.156.158] on 2012/06/29 19:18:46
gonna dig through this now.
#3 posted by necros [99.227.156.158] on 2012/06/29 19:22:59
-sndspeed 44100 doesn't enable 44khz sound?
Had A Look
#4 posted by DaZ [78.147.171.182] on 2012/06/29 20:54:32
Digging the new water effect, set it as default :) the environment map & texture scrolling could be put to some good uses also, is it possible to have the environment map over a standard texture though? Looks kinda weird having only environment mapping with no base texture underneath.
The demo features are EXTREMELY welcome! Oh god you saved my life here :)
Looks Very Interesting...
#5 posted by metlslime [159.153.4.50] on 2012/06/29 23:32:37
I'll have to check it out when i get home.
Baker, does this engine make obsolete your previous "custom builds" of fitzquake? For example there was one a few years ago that had various fixes like the Intel adapter fix.
Also...
#6 posted by metlslime [159.153.4.50] on 2012/06/29 23:41:52
Is there a full list of changes? The news post says "see readme" ... the readme says "see home page" ...
Sweet
#7 posted by nakasuhito [65.130.189.104] on 2012/06/30 09:41:43
going into fullscreen doesn't give me black screen anymore! :D
with the latest fitzquake i had to use a .bat with the windowed option for it to run, otherwise i had to tab out and then back in to see something. that was my only issue with fitzquake.
so far nothing wrong that i can see though [only played like 5mins though].
#8 posted by necros [99.227.156.158] on 2012/06/30 19:13:57
water ripple seems buggy though. lots of tearing and inconsistently sized faces on water brushes cause the ripple effect to be uneven.
BSP2 Support?
#9 posted by Tronyn [24.79.203.208] on 2012/06/30 19:39:23
Or is that still RMQ engine only?
Lots of those fixes and features seem very useful. I like fov does not affect gun, although people that use extreme fovs in multiplayer kinda annoy me (especially in the 3rd person Rune, where you can see without being seen using an extreme fov).
I Don't Think So...
#10 posted by generic [67.235.210.16] on 2012/06/30 20:13:10
I didn't load your beta map ;)
Heh
#11 posted by Tronyn [24.79.203.208] on 2012/06/30 20:57:55
understandable ;)
vis is getting close to done, but every time it gets to 15 hours it goes back up to 25. lol.
Random Note:
#12 posted by metlslime [67.188.81.46] on 2012/07/01 09:24:27
r_waterripple looks better if you set "r_oldwater" to 1, because when r_oldwater is 0 it ignores the "gl_subdivide_size" setting. There are still subtle issues with it due to glquake's buggy subdivision (for example, it creates t-junctions.)
The Real Problem Is
#13 posted by mh [109.79.36.245] on 2012/07/01 13:49:42
Sine waves don't linearly interpolate. You cannot linearly interpolate a sine wave; the best you can do is increase tesselation so much that the problem becomes less visible - that's what r_oldwater 0 (in a sorta-kinda-roundabout way) or low values of gl_subdivide_size do, but at other costs elsewhere (fillrate, limiting texture size, extra vertex processing).
#14 posted by Text_Fish [94.169.119.204] on 2012/07/01 14:31:34
Is there any way to stop monsters and pickups from being fullbright?
Thanks
#15 posted by onetruepurple [91.240.47.30] on 2012/07/01 16:29:11
Now my shitty laptop integrated gfx card can finally run maps with dynamic lighting without stuttering like Walter Jr in Breaking Bad.
But yeah, what Text_Fish said.
@metslime
#16 posted by Baker [69.47.162.203] on 2012/07/02 07:38:49
See quakedef.h
I described the changes as best I could.
make obsolete your previous "custom builds" of fitzquake
Yes. My intention with this engine was so you (or the Quakespasm guys or any interested modder) could implement any fix or improvement you were interested it at will.
I know that over at Inside3D a lot of engine weaknesses have been uncovered [it is actually almost intimidating :( ] and rather than make it hard to absorb the solutions, I wanted to make it an easy process.
I've learned a great deal about the rendering process from FitzQuake's complete rework of it. This is my reciprocal work. :)
So far ...
@others
#17 posted by Baker [69.47.162.203] on 2012/07/02 07:41:10
MH deserves all the credit for the frames per second increase. In the engine, this is marked as SUPPORTS_MH_DYNASPEED. It literally turns 11 fps dynamic light situations into 250 fps lighting situations.
@daz
#18 posted by Baker [69.47.162.203] on 2012/07/02 07:43:19
I do have a great liking for you demos. ;-)
I'm glad this made your day.
Argh ... Quadruple Post ...
#19 posted by Baker [69.47.162.203] on 2012/07/02 07:50:15
@Tronyn ... no I haven't implemented BSP2 ... yet.
It you'd like everything BSP2 does, but in classic BSP, I do have your answer:
http://quake-1.com/docs/utils/txqb...
^^ BSP compiler with rotation and all BSP2 modification except it does classic BSP.
I didn't make that because I'm against BSP2 (I'm not) but because I have a conservative side that wants to understand individual changes one at a time.
@Text_fish
#20 posted by Baker [69.47.162.203] on 2012/07/02 21:49:41
Is there any way to stop monsters and pickups from being fullbright?
Fixed. Thanks for pointing that out.
Please re-download.
#21 posted by necros [99.227.156.158] on 2012/07/02 22:26:32
holy fuck the tool_inspector is awesome.
edict numbers, model index number, frame, target/targetname, absmin/maxs...
I won't be using this as a 'playing' engine (and it seems like that wasn't the intent anyway) but i will certainly use it for debugging stuff.
thank you!
#22 posted by Text_Fish [94.169.119.204] on 2012/07/02 23:40:52
Cheers Baker. :)
@daz, Necros
#23 posted by Baker [69.47.162.203] on 2012/07/03 08:00:54
is it possible to have the environment map over a standard texture though?
I agree, but I didn't want to introduce a hack into this. I'm not sure what a good mapping use of sphere maps are (except making metals look nice). That being said, you could use FitzQuake protocol 666 to place an alpha brush in front of another brush and use the environmental map texture on the alpha brush.
-sndspeed 44100 doesn't enable 44khz sound?
That isn't actually a FitzQuake 0.85 feature.
#24 posted by necros [99.227.156.158] on 2012/07/03 08:31:06
Sorry, I've been using QS for so long now, I totally forgot about that.
Well ...
#25 posted by Baker [69.47.162.203] on 2012/07/03 09:15:31
I've always liked the original Quake sounds as-is and one of the first times I gave a serious look at using DarkPlaces my first question was "The sounds in DarkPlaces are very 'crisp'" and I was told about the -sndspeed parameter which I set to 11025.
Maybe I'm in the minority.
I added -sndspeed command line param.
Agree With Baker On -sndspeed
#26 posted by mh [137.191.242.106] on 2012/07/03 11:12:02
With the sources at 11k and with the way Quake "upsamples" them by default, all it's really doing is pitch-shifting. The crispness may be there, but the bottom-end welly is all gone.
#27 posted by necros [99.227.156.158] on 2012/07/03 17:59:33
don't really care about that myself. i've never noticed anything bad with the way it's done in quakespasm. that said, for whatever reason, the 11khz sounds seem uglier in DP for some reason.
Also, with my habit of using so many ambient sounds and random crap, i really can't do without 44khz.
Waterwarp
#28 posted by Lunaran [99.67.239.83] on 2012/07/04 02:40:12
Is it implementation-time vs. level-of-interest prohibitive to add GLSL support for the sake of restoring software Quake's original per-pixel waterwarp on liquid surfaces and on the screen while underwater? If not it seems like a clear visual win over relying on subdivision and ST distortion, and I'm surprised we haven't seen it in more engines by now (MHQuake comes to mind).
GLSL isn't exactly new, and vertex based warp still exists as an elegant fallback.
#29 posted by metlslime [159.153.4.50] on 2012/07/04 02:50:42
doing waterwarp on the surface with GLSL is fairly doable (though it is something I have never done.) It's probably cheap enough on any shader-capable card.
Doing the fullscreen warp when underwater involves touching a bit more of the renderer because you have to render the scene to a texture, then copy that texture to the screen using a warping shader. In terms of hardware requirements, I think anything that can run doom3 can handle it, but this is, again, based on zero personal experience.
Waterwarp
#30 posted by mh [109.79.190.50] on 2012/07/04 04:08:15
It's very cheap on any shader-capable card. The per-pixel sin is slightly expensive (although the shader compiler will typically optimize it to a single sincos instead of two sins) but that balances against a lower vertex submission cost due to no subdivision (and not to mention the ability to keep everything in a static VBO if you want to go that far).
Doing shader-based versions of both water and sky means that every single surf can go into a single static VBO, in fact, as no per-vertex data needs to be updated on the CPU at all (you'd use a cubemap for skyboxes in this setup - Doom 3 has some code for converting Q1/Q2 skybox layouts to alignments suitable for cubemaps and I've independently written the same conversion myself a few years ago so I'm reasonably certain that it can't be rocket science). Get some draw call batching in and you're suddenly running up to 5 times or more as fast in big, heavy scenes. That does require a higher GL_VERSION than Fitz aims for, as well as some massive surgery to the current codebase. Probably not reasonable to expect in any kind of short/medium timeframe, if ever.
The fullscreen warp has some complexities in how you handle the edges. You can use GL_CLAMP_TO_EDGE but it won't handle the bottom edge which juts against the sbar. There are solutions (I used a "control texture" that fades off the warp effect at the edges, another option is to just destroy and recreate the texture at the appropriate size if it needs to change, which generally doesn't happen at any performance-critical time).
Generally glCopyTexSubImage is going to be slower than using an FBO for this because it needs to shift more data around. Overall you can expect to lose maybe one third of your performance owing to increased fillrate even in the best case.
Another way to do it that doesn't need shaders (and will even work on GL1.1 hardware) is to use a grid of quads (much the same as what Fitz does for r_oldwater 0). That can give acceptable enough quality.
The third way is just to rotate the projection matrix a little based on time, which gives a reasonable enough effect at no performance cost. It's like Fitz's current stretch'n'squeeze effect but with some rotation added in too. You need to extract your frustum from the combined MVP rather than calculating it separately if you do this though. Easy enough (and a little more robust than calculating it separate).
Despite all this seeming complexity and multiple options it's probably cleaner and easier to integrate with any engine as it doesn't need to touch any code outside of it's own subsystem. So - detect if we're underwater (via r_viewleaf->contents) at the start of the scene, and either (a) just set a flag and/or (b) switch the render target. At the end of the scene, either capture the scene to a texture or put the old render target back, then draw using the appropriate method depending on what hardware capabilities are available.
For an engine like Fitz I'd recommend asm shaders rather than full GLSL. The main reason for that is that they're available on a much wider range of hardware, so they seem more in keeping with the Fitz philosophy.
#31 posted by eerie [92.249.122.99] on 2012/07/08 13:25:41
good news!
thanks, Baker.
Alpha Animated Textures
#32 posted by tester [76.185.157.42] on 2012/07/08 20:01:54
Would it be possible to do alpha animated textures?
Something like this:
{+fire1
{+fire2
{+fire3
#33 posted by mh [109.79.188.79] on 2012/07/08 23:08:20
I'll let Baker answer on his own behalf; this opnion is mine and mine alone.
Yes, it should be possible with the necessary code changes. However, by this point in time you're stacking up multiple "first character" hacks (alpha animated water with alternate anims anyone?) and things will begin to look a little delicate.
So some form of alternate system would be needed. Since Q3A shaders are out there, since we have a GPL working reference implementation (the Q3A engine), and since they don't require any format changes (just add a .shader file for anything you want different behaviour for), that would be my own preference.
@Tester
#34 posted by Baker [69.47.162.203] on 2012/07/09 02:02:58
It might already be possible to do them:
Set r_texprefix_fence "+alpha" and load your level.
It should process all the textures that begin "+alpha" and likewise set a flag to mark that surface for alpha mask rendering.
I hadn't expected someone to want to use alpha textures like that, but I bet it works.
(Note: fullbright pixels in alpha textures are supported (except color 255 of course). Replacement textures replacing an alpha texture that has an alpha mask are also supported.)
#35 posted by Trinca [194.65.24.228] on 2012/07/09 11:57:03
Baker this makes fitzquake look more like darkplaces, joequake, qrack e.t.c?
record demo is awesome...
No
#36 posted by Baker [69.47.162.203] on 2012/07/09 17:44:31
@Trinca
#37 posted by Baker [69.47.162.203] on 2012/07/09 20:30:16
If by chance you are looking for something like JoeQuake, you might try Engine X. Engine X supports FitzQuake 666 protocol and looks like JoeQuake with the kind of very recent engine features one would expect (video mode change, etc).
#38 posted by trinca [89.154.57.172] on 2012/07/09 23:22:05
Obrigado Baker
I will see it ASAP!
thanks
@Baker
#39 posted by tester [76.185.157.42] on 2012/07/10 12:04:30
Thanks for the reply!
Also, regarding the alpha textures, I think there is a bug with the way they are rendered, or it may be intended. The transparency textures bleed through the floor and you can see the void of the map.
Here is a picture showing what I mean:
http://imgur.com/ZFOz1
Even if I paint the bottom of the glass brush with a solid texture, it still shows the void through the floor.
#40 posted by roblot [216.106.106.205] on 2012/07/10 12:55:44
Turn your alpha brushes into an entity like illusionary, door, func wall etc. Use a really good q3 fence texture, enable texture scroll and be amazed.
#41 posted by mh [137.191.242.106] on 2012/07/10 17:19:42
Yup.
Because of the way QBSP seals the world and chops off outside faces, putting this texture type on a brush that's not part of an entity will produce this result. It's expected behaviour and a result of normal QBSP operation, not really an engine bug (there's actually nothing that the engine can do to work around it as the data required isn't even there in the BSP to begin with).
Yeah
#42 posted by Baker [69.47.162.203] on 2012/07/10 22:49:54
See above. I almost decided to enable alpha textures only for entities (func_wall, etc.).
But an experienced mapper knows all the rules and how the tools work and allowing it for the world is no different than, for instance, using the skip-remove tool.
Alpha textures should generally be limited to entities (func_wall, platforms, doors, etc).
Random Black
#43 posted by sock [24.84.102.77] on 2012/07/16 21:32:28
I have been testing my map with the mark V engine and for some reason all my models (map objects, items, weapons and monsters) randomly go black and monsters do it while patrolling.
I have checked the area the monsters patrol and my weapon does not go black. It is not a subtle change either, they are normal (full bright) one minute and then solid black the next.
Is there a special reason for this? (I know this is a counter productive thing to say but it does not happen in Fitz85) Is there a command line parameter I need to stop this?
Sock:
#44 posted by metlslime [159.153.4.50] on 2012/07/16 22:25:02
do they stay black with r_fullbright 1?
If yes, may be a texture problem.... if no, may be a lighting problem. (not a problem with your level, i mean a problem with the engine)
Fullbright
#45 posted by sock [24.84.102.77] on 2012/07/16 22:41:38
I loaded the map, typed in r_fullbright 1 and I could see everything, no blackness. It looks like r_fullbright removes the light map from everything. It is very strange the blackness on certain objects, I thought it was specific locations where I have spawned stuff but it happens to wandering monsters.
I checked the original Q1 maps (played episode 1) and could not see any problems. I am using the latest compiler tools, hitting a couple of max limits but the engine still copes with it.
Sock
#46 posted by Baker [69.47.162.203] on 2012/07/16 22:52:54
It could be because I made the light check test against world submodels (plats, lifts).
I have a new revision to this with new features essentially done. I'll put a cvar in disable shadows/lighting from world submodels to see if that is the origin of the issue.
I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).
The new version should be be available in 6-7 hours.
Another Of Very Few Possibilities
#47 posted by Baker [69.47.162.203] on 2012/07/16 22:58:48
The code that obtains shadow surfaces in Quake is actually very imperfect and can fail to "hit" a downtrace for lighting. Prior to the trace, I may have it reset the result color to black (full darkness).
Either way this shouldn't be hard to solve.
Baker
#48 posted by sock [24.84.102.77] on 2012/07/16 23:03:20
Awesome, thanks :D I will download it and test my map once you got a new link ready.
Another bug:
When I start the engine (windowed mode) the +mlook does not work (even if I have the window selected) The old Fitz engine when it started windowed would never give up the mlook but at least I could test my maps without have to go full screen all the time. (I usually have to exit Fitz to use another application because the mouse cursor is not available to any other windows apps).
Is this a windows issue? a problem with active window focus? Or is the application (mark V) not able to control the mouse look when windowed?
#49 posted by metlslime [159.153.4.50] on 2012/07/16 23:37:07
I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).
Note: the reason i extended this distance is because CZG had a really deep pit in one of his maps, and the scrags floating over that pit were black instead of taking the lighting from the floor.
Maybe
#50 posted by sock [24.84.102.77] on 2012/07/16 23:39:06
the light depth check could be tweaked via a command line parameter? Something to set before the engine fully loads?
#51 posted by necros [99.227.156.158] on 2012/07/17 00:44:05
How much the increased depth check costs to make. Is it really worth reducing back to stock quake for a little extra performance?
#52 posted by mh [109.79.194.116] on 2012/07/17 03:03:41
The lighting depth check should be cvar-ized. Having to restart the engine to change something like this is stupid.
2048 is probably a little too low, especially with the "run the test for static entities once only at startup" trick (which was where the main performance impact came from in tests - and mind you this was quite an extreme case too). It also fails to light models properly in Zerstorer when this low.
It's probably worth finding the max top-to-bottom extent of the world and using that value as well - that'll be guaranteed to catch anything.
Yeah, That Works.
#53 posted by mh [109.79.194.116] on 2012/07/17 03:14:42
end[2] = start[2] - (cl.worldmodel->maxs[2] - cl.worldmodel->mins[2]);
Why make the player do it when you can do you yourself?
Continued ...
#54 posted by Baker [69.47.162.203] on 2012/07/17 03:20:06
@Necros: The lighting check is one of those super slow recursive world checks. I'll do as MH suggests and default it to the Fitz 0.85 --- I wasn't looking to make an changes in how Fitz 0.85 operates (I lacked the imagination of a situation where 8192 could actually be needed, like the CZG map metslime said that induced him to raise the distance check).
[I'll add in MH's idea of a world bounding box check .. and if set to 0 will check lighting from unlimited depth. These things are going to push the update version to tomorrow it seems. But getting things absolutely right is something worth taking the time to do.]
@Sock: Any chance you could zip your map plus save the game exactly at the point the view model (weapon) lighting is wrong? It would help me avoid investigating things that aren't actually the source of the problem.
Mh:
#55 posted by metlslime [159.153.4.50] on 2012/07/17 03:20:31
if you use the max level extents of the world, does that still save any performance? I assumed the cost of a traceline is related to the number of nodes it has to cross, and once the line is >= level extents, it's already the worst case, right?
#56 posted by mh [109.79.194.116] on 2012/07/17 03:20:53
Or just end[2] = cl.worldmodel->mins[2] - better yet.
@Sock Part 2
#57 posted by Baker [69.47.162.203] on 2012/07/17 03:21:21
Another bug: When I start the engine (windowed mode) the +mlook does not work (even if I have the window selected)
I didn't change any mouse operation, but I'll investigate and see that this gets resolved.
#58 posted by mh [109.79.194.116] on 2012/07/17 03:35:14
The big advantage of basing it on the world extents is not so much in terms of performance but in terms of correctness. Using cl.worldmodel->mins[2] (I'd actually subtract another 10 or so just so that the end point is ouside the map, then check that start[2] actually is bigger than end[2] to cover for noclipping) means that you're always going to hit something during the downtrace - it's guaranteed because nothing in the world can be outside of that point.
The other method - pick a number and hope it's big enough - fails because eventually a map is going to appear for which it isn't big enough. True, 8192 matches protocol 15's default +/- 4096, bounds but it breaks on extended protocols that may increase those bounds.
Ultimately it comes down to a choice between a simple method that is guaranteed to always work versus just picking a number.
@Baker
#59 posted by sock [24.84.102.77] on 2012/07/17 03:55:10
Any chance you could zip your map
You certainly make it hard to be contacted, I tried the MarkV readme file, your account here and got no joy. Any chance you can drop me an email address? (my account here has my details)
Done
#60 posted by Baker [69.47.162.203] on 2012/07/17 07:05:01
check your mail ;).
New Version:
#61 posted by Baker [69.47.162.203] on 2012/07/18 01:17:29
Download: http://quake-1.com/docs/utils/fitz...
Readme: http://quake-1.com/docs/utils/fitz...
Some features:
Game command supports -hipnotic, etc. Like type: game warpspasm -quoth
ALT-ENTER switches between fullscreen and windowed mode, "folder" command now opens the folder and highlights most recent file made (like a screenshot or demo).
Many bug-fixes, speed increases and Sock's lighting bug should be gone.
[Issue wasn't related to shadow downtrace for lighting, but I made that "infinite" now. r_lightpoint_depth 0 = infinite. You could set to 8192 or 2048 ... but I think I'll remove the cvar eventually. "infinite" is a Z endpoint of cl.worldmodel->mins[2] ... few objects.]
There are also major capture demo improvements to make things easy. See readme. If interested in demo capture, I recommend trying Google WebM (known as vp80) available at http://www.optimasc.com/products/v...
WebM is the video codec Google wants to use as the HTML5 video standard, so it compresses video fast and the file size is small.
This engine revision will automatically detect that this codec is installed and use it.
[Video capture is simple in this engine.
Type capturedemo demo1 in console. Best to be in windowed mode so you can see demo progress. That's it.
You can also bind "capturevideo toggle" to a key]
#62 posted by mh [109.79.188.44] on 2012/07/18 02:32:03
Another old Fitz bug, by the way:
Set host_maxfps to something stupidly high (10,000 or so) (I suggest adopting host_maxfps 0 = unbounded - Q3A did that and I had one player who was expecting the same behaviour from Quake).
Set scr_showfps to 1.
Look at the fps counter. Funny, isn't it? The tileclear isn't being refreshed every frame (which is a bad enough idea to begin with...) so the area where the counter lives just gets new figures drawn over it each time.
#63 posted by Baker [69.47.162.203] on 2012/07/18 02:43:04
I'll need to absorb your timing fixes first (plus add the server-side lerp movement for "monsters") and afterwards I'll make host_maxfps 0 function like as above.
#64 posted by Spirit [80.171.82.162] on 2012/07/18 16:24:26
Please do not release updates using the same filename. Use the date as suffix or a version number.
...
#65 posted by Baker [69.47.162.203] on 2012/07/18 17:59:06
First release (R0): http://quake-1.com/docs/utils/fitz...
Revision 1 (R1): http://quake-1.com/docs/utils/fitz...
Revision 2 (R2): http://quake-1.com/docs/utils/fitz...
Revision 5 (R5): http://quake-1.com/docs/utils/fitz...
This meets my need of making someone doesn't download an old one for no reason, and should satisfy your desire to make sure no source codes/binaries get lost.
Thanks!
#66 posted by Spirit [80.171.82.162] on 2012/07/18 18:19:07
"Title Demo" Support
#67 posted by Baker [69.47.162.203] on 2012/07/19 10:10:54
I forgot to mention the latest version has support for "title demos".
A "Title Demo" is a demo that plays with no HUD, no crosshair, fov 90, viewsize 120 (No status bar).
Usage: cl_titledemos_list "demo1.dem,demo2.dem,demo3.de...
This allows usage of "startdemos demo1 demo2 demo3" to essentially play as a movie or an intro. This could be gameplay action or you could record of demo of you touring the map with no clip and no target (hopefully with a QuakeC progs that uses a null view model).
I more or less got this idea from how Warsow starts up showing game play action or how the original Unreal did a cool moving view of the castle.
Add ...
#68 posted by Baker [69.47.162.203] on 2012/07/19 10:15:12
Kurok used a "title demo" as the start screen. It was a demo of a small map that was 70-90 seconds long (repeating) that showed a mountain and a block labelled "Kurok". For the longest time, I didn't realize the intro screen was a demo.
Demos, of course, are recordings of a map so they can have a soundtrack just like how a map can have a soundtrack key.
#69 posted by Yhe1 [108.0.230.2] on 2012/07/20 06:53:54
Any chance to add widescreen Fov? Currently I have to put FOV 106 in the command line.
Well ...
#70 posted by Baker [69.47.162.203] on 2012/07/20 13:15:13
That is a "no win" situation. Here is why ...
The field of view is the degrees of view showing. If I set to that to 90 degrees, I would hope that would be 90 degrees.
If I correct the FOV for widescreen to adjust to, say, a 4:3 aspect ratio (wide-screen correction) then it isn't really 90 degrees but some other number.
If I make it auto-correct, many people will not like it because it looks wrong because they are used to it looking a certain way in FitzQuake. So I would have to add a cvar to control it.
Which is one more setting for someone to mess with.
With how things are now, there is a setting to mess with (FOV) and everyone knows what it does. Versus add a new setting, which people would have to learn about. And other engines wouldn't save this new setting so it would get erased periodically. Not that FOV saves to config anyway.
Then there is the argument that 4:3 isn't the Quake aspect ratio to use for widescreen. That 8:5 is because original Quake loaded up to 320x200, not 640x480.
So ... I would add widescreen correction if a magic bullet answer exists. But I can't think of one.
The nicest thing about FitzQuake is that unlike some other engines that you can rely on it to be familiar versus some engines that do things that confuse you and you don't know how to change it or maybe it can't be changed.
#71 posted by metlslime [198.228.216.158] on 2012/07/20 17:39:03
Agree with baker re:fov, but I would add that even in 320x200 mode, quake is intended to fill a 4:3 display, which means non-square pixels, but that is how monitors displayed that mode AFAIK.
(I sometimes look at the menu art and wonder if the letters are intentionally stretched to look correct in this mode.)
Mlook
#72 posted by sock [24.84.102.77] on 2012/07/20 18:17:03
Hey, when do you plan to release the version with mlook + windowed fixes?
@sock
#73 posted by Baker [69.47.162.203] on 2012/07/20 20:57:58
Boring engine technicality: MH explained a superior way of handling mouse input in the last day or two that is streamlined and efficient and very reliable and easy to manage.
So at the moment, I'm on a side quest since I don't want to put out two separate revisions that change the input code heavily back to back. Giving me something extra to do before I get this newest revision out and slowing me down a bit at the moment.
FOV
#74 posted by mh [78.152.221.241] on 2012/07/20 21:58:35
I have to respectfully disagree with the rationale just given for not fixing up FOV. The reality is that hardware has moved on since 1996, and widescreen is now the norm. My own experience is that fixed-up FOV is a basic player expectation and not a fancy engine feature that's only of technical interest - I have a fairly large amount of positive feedback from people who specifically mention fixed-up FOV as a feature that they welcome.
Fixed-up FOV can be implemented without changing the defaults or other behaviour of the FOV cvar. FOV 90 will still give you the correct horizontal and vertical FOV for your chosen resolution and aspect, so everything can still work as expected.
320x200 resolution was not an aesthetic choice, it was a technical one. 320x200 was the old standard VGA mode 13h, meaning that it was the one display mode that was just guaranteed to work on everything. If that mode had been any other resolution, then that hypothetical other resolution would have been Quake's default.
#75 posted by metlslime [159.153.4.50] on 2012/07/20 22:52:43
If widescreen really is the norm, just set FOV to default to 105 instead of 90. This gives correct behavior on a clean install, and doesn't override existing users configs that already have ~105 in their config.cfg or autoexec.cfg
#76 posted by metlslime [159.153.4.50] on 2012/07/20 22:54:04
note that this probably means putting in a hack to ignore the default.cfg value for FOV, if there is one. But messiness under the hood may be worth it if the user experience is your highest goal.
#77 posted by sikkpin [107.4.231.237] on 2012/07/20 23:14:43
Why not just add a cvar to toggle between using absolute and aspect corrected fov, having absolute set as the default.
#78 posted by metlslime [159.153.4.50] on 2012/07/21 00:16:14
the question is whether new users will have to change their configs, or whether existing users will have to change their configs. Any cvar like that would require one set of people to change their configs.
The Problem Is...
#79 posted by mh [78.152.221.241] on 2012/07/21 00:40:37
A large percentage of players aren't even aware that the FOV setting exists, or - even if they are - that it can be used to correct for widescreen (the same applies to +mlook). Those that are aware of it can always re-adjust. I suggest doing some research around the usual suspects such as the Steam forums, etc, for info on the specific problems that people have with Quake; these make great targets for fixing in any engine that aims at being accessible to players. Find what prevents people from getting into the game, fix it, and problems go away. This is the same philosophy behind removing the necessity for (but not the existence of) command-line options. Identify the barriers to entry, remove them, otherwise you're just developing for a captive audience who already know everything inside-out and are therefore not bothered by this stuff (and nor are they appropriate people to pass comment on how these things should be handled).
Regarding configs, the obvious solution is engine-specific configs. The old QuakeDev forums raised this as a point that was widely addressed in Q2 ports but all but ignored in Q1. It enables more peaceful engine cohabitation by ensuring that settings specific to one engine don't wreck another.
Again, it depends on who you're developing for. The same old group of people who will always use your engine no matter what, or are you trying to reach out to new players?
#80 posted by necros [99.227.156.158] on 2012/07/21 02:41:59
engine-specific configs
oh my god, yes! or use /documents/mygames/engineName/modN...
#81 posted by necros [99.227.156.158] on 2012/07/21 02:42:22
documents / mygames / engineName / modName / config.cfg
I Have To Admit, I Think MH Is Right
#82 posted by RickyT23 [94.13.59.186] on 2012/07/21 20:19:15
I've seen his implementation of it, and it looks superior to anything else when it comes to the weapon being in the right place. Methinks. :E
My Thoughts Were Incomplete
#83 posted by Baker [69.47.162.203] on 2012/07/22 00:11:48
MH is right as not having widescreen correction eats away at vertical FOV, narrowing the range of what is on-screen vertically. FOV was never intended to penalize vertical visibly, it was just that everyone used 4:3 resolution in the CRT era (640x480, 800x600, 1024x768, etc.)
This is a flaw.
New Version: Revision 6
#84 posted by Baker [69.47.162.203] on 2012/07/22 14:12:28
Download: http://quake-1.com/docs/utils/fitz...
Readme: http://quake-1.com/docs/utils/fitz...
Widescreen FOV correction, dynamic lights properly affect moved/rotated brush models, dynamic light bleed-through fix.
All entities are colormapped (colored dead bodies, etc. - like if in coop and you die or play against bots, etc.)
Demo rewind (PGDN) and fast forward (PGUP) of any demo the user plays via "playdemo"(and pause pressing pause key).
(The startup demo sequence is not user-initiated and that sequence is not meant to be paused or messed with as it is a game preview.
You must use the playdemo command like "playdemo demo1" to have demo pause/rewind/fast forward available.)
Revision 7
#85 posted by Baker [69.47.162.203] on 2012/07/31 14:25:20
mp3 tracks support. And boring stuff you won't care about, although documented in the readme.
Download: http://quake-1.com/docs/utils/fitz...
Readme: http://quake-1.com/docs/utils/fitz...
Baker
#86 posted by spy [178.88.1.73] on 2012/07/31 14:44:55
what about that infamous whiteroom bugfix
i assume thats still not fixed
#87 posted by Baker [69.47.162.203] on 2012/07/31 15:01:35
It's on the to-do list. I haven't worked through the potential solutions. I understand the underlying issue involved as szo and MH explained what causes the problem.
#88 posted by Spirit [80.171.143.124] on 2012/07/31 15:27:37
fitzquake_mark_v_r7.zip please
#89 posted by Baker [69.47.162.203] on 2012/07/31 16:09:02
I followed the same naming pattern, I kinda of thought you'd know the URL but still ...
http://quake-1.com/docs/utils/fitz...
Keeps Crashing/freezing My Computer
#90 posted by Berntsen [158.38.86.48] on 2012/10/30 15:55:07
Hi, loving the fov/gun/various other fixes in this, especially the clock fix so that the game runs at the proper speed, however as with your "Fitzquake Plus" I keep having an annoying issue - after playing for a while, the game freezes up completely, with the last sounds played looping over and over, then after a few seconds the screen turns a solid color and the sound a single tone. I can't ctrl+alt+del or do anything other than forcing a shutdown by holding down the power button. Previously this has only occured after playing for an hour or so, but today it happened after just a few minutes. I assume it has something to do with my computer having multiple cores, but I can't really pinpoint the problem. It's an ASUS G73JH laptop which I've had for two years, and I think it has only frozen up/crashed two-three times if I'm not taking these Fitzquake issues into account.
Here are my system specs:
Windows 7 Home Premium 64-bit
Intel Core i7 Q 720 @ 1.60GHz, 1600 Mhz, quad-core
6GB Installed RAM
ATI Radeon HD5870, 1GB VRAM
And my Fitzquake command-line parameters:
-width 1920 -height 1080 -bpp 32 -zonesize 2048 -heapsize 12800
I haven't played using Fitzquake 0.85 for long enough to see if it'll happen there as well, as I have the clock bug with it running too fast - that's why I've used Fitzquake Plus in the past, and now Mark V. Any input/advice on this is much appreciated.
#91 posted by stevenaaus [49.176.98.43] on 2012/11/02 20:28:44
It's probably worth while to test using another engine (eg Quakespasm or FitzQuake0.85) to check that the problem is not one of bad hardware/overheating.
If That Is REALLY Your Command Line
#92 posted by Baker [69.47.162.203] on 2012/11/03 22:10:30
Then you should be using:
-heapsize 12800
That means 12800 KB. Which is about 12 MB.
Although not a sure thing, this is likely why you are crashing.
Gah!
#93 posted by Baker [69.47.162.203] on 2012/11/03 22:11:27
"Then you should be using: " = "Then you should NOT be using:" obviously ...
/Pays the price of not previewing post for 567th time.
Whoops
#94 posted by Berntsen [158.38.86.70] on 2012/11/04 00:22:13
Seems like I managed to leave out a 0, it should indeed say 128000.
Seems like I paid the price even after proofreading!
Also My Vocabulary Sucks
#95 posted by Berntsen [158.38.86.70] on 2012/11/04 00:23:38
131072
#96 posted by onetruepurple [91.240.47.30] on 2012/11/04 01:03:38
Will give you a nice round 128 MB heap.
I'd Give Quakespasm A Try Then
#97 posted by Baker [69.47.162.203] on 2012/11/04 02:07:58
The laptop I used when I was working on Fitz Mark V has virtually the same specs as your machine (graphics, Intel, Win 7 64, etc.)
I don't have any ideas on why you would have this issue, I will say that Fitz 0.85 should run on your machine if you do the "set affinity trick".
Go to Task Manager running Fitz 0.85 and select fitzquake085.exe and do Select Affinity and select "cpu 0" only. Then Fitz 0.85 will run ok without the clock issue.
http://i.techrepublic.com.com/gall...
The "clock fix" is just the standard deal that is used by engines like JoeQuake, ezQuake, etc. There isn't anything supernatural about it, it just uses a different Windows API call to get the time. I might have even used the code from DirectQ.
In fact, you might try DirectQ. Considering the quirky nature of the problem you have, it could be an OpenGL drivers kind of thing and DirectQ uses Direct3D:
http://mhquake.blogspot.com/ (Downloads on the right side of page)
#98 posted by Berntsen [158.38.86.70] on 2012/11/04 19:01:00
Was about to post that after changing my heapsize to 131072 I had played through several maps without crashing... and then everything froze as I quit the program. Joy.
I guess I could just use Quakespasm of course, but after having been away from singleplayer Quake for far too long, instead having played coop using EzQuake, I have become accustomed to how that engine looks and feels. I think Mark V captures this feel well with the widescreen fov and viewmodel corrections.
For comparison, here's how my screen looks using fov 130 with FitzQuake 0.85 and Mark V, and also r_viewmodelfov 130 for the latter.
Incredibly minor detail, and maybe I'm just imagining it, but movement feels much smoother with the corrections.
*0.85
#99 posted by Berntsen [158.38.86.70] on 2012/11/04 19:10:04
Make that Quakespasm. Still, exactly the same as it would be with Fitz0.85.
Is Quakespasm your engine as well, Baker?
So It Crashed When You Tried To Exit?
#100 posted by Baker [69.47.162.203] on 2012/11/05 04:23:21
Like when you tried to quit of Quake? Is this correct? I'm just trying to understand and get whatever info I can.
Quakespasm is a multiplatform FitzQuake: http://quakespasm.sourceforge.net/ by szo, stevenaus and Sleepwalkr.
BTW:
#101 posted by Baker [69.47.162.203] on 2012/11/05 08:51:16
Those 2 features you like (view model correction + widescreen correction). Those are both in DirectQ.
#102 posted by Berntsen [158.38.86.70] on 2012/11/05 16:17:21
Yes, froze up my entire system just as I quit the game. I've updated my graphics card drivers, hopefully that helps.
#103 posted by mh [109.79.231.234] on 2012/11/05 18:54:32
There's a fundamental bug in FitzQuake and derivitaves (even the latest QS in the SVN has it) where the list of GL extensions and capabilities is retrieved once only, at startup, and then reused throughout mode changes. That can cause crashes as this list actually belongs to the current GL context; it's not global.
A potential crash case would be if you have a switchable graphics laptop and you're switched to the Intel GPU before the context goes down, but subsequent drawing uses an extension that the Intel doesn't have. Not certain how relevant that one is here, but it should be fixed.
A further bug is that it doesn't check extension names with a space at the end. This violates GL spec as the extensions string is specified to be space-delimited; it could falsely detect support for GL_ARB_do_something when the extension actually supported is GL_ARB_do_something_else (sidenote: Doom 3 has this bug too). I don't know of any extensions that this would trip up on though, but it is a potential crasher and correctness dictates that it should be fixed.
One other crasher that I'm aware of and that may be relevant here is that Quake Con_Printfs a "player left the map" message during shutdown if you exit while a map is running; if the context is down when this happens it can cause a crash.
The final one is during Host_ClearMemory; if you free this memory you can crash as the progs.dat code is still accessed until a disconnect fully completes. So if that's what's happening, just zero it instead (which is safe) and let the OS automatically reclaim it when the process terminates.
@MH: Interesting ...
#104 posted by Baker [69.47.162.203] on 2012/11/06 03:32:50
See I never implemented string safety stuffs in Mark V because it would have torn a tornado-like path across the source code.
And my plan was to implement a ton of easy-to-understand upgrades like the QIP engine source code did to explain to whoever was interested how to do stuff.
[And changing all the sprintfs and strcpys would maul the source beyond recognition. Yeah techy enginey stuffs to the casuals ...]
One or more of the later part of your list could be culprits in this.
@MH:
#105 posted by szo [160.75.18.212] on 2012/11/06 10:02:01
Thanks for the bug pointers.
Regarding extensions being not per-context: see new commit:
http://quakespasm.svn.sourceforge....
Regarding Host_ClearMemory(): I think qs should be safe about it (same for "player left the map" like messages during shutdown), but I applied the following nonetheless:
http://quakespasm.svn.sourceforge....
@Baker
#106 posted by mh [78.152.207.43] on 2012/11/06 20:48:43
The extensions thing is not actually a matter of string-safety; it's a case of if you're using 'if (strstr (gl_extensions, "GL_ARB_do_domething"))' then you will also get a positive on "GL_ARB_do_domething_else&quo... If your GL implementation supports the latter but not the former, then you've got a false positive.
There are already some extensions that follow this pattern, with GL_ARB_occlusion_query and GL_ARB_occlusion_query2 being one example that springs to mind. In practice and of this example any implementation that supports the second will always support the first anyway, but the pattern is there and it's not guaranteed that future extensions will get lucky like that.
However, since the GL_EXTENSIONS string is documented as being space-delimited (see http://msdn.microsoft.com/en-us/li... - the opengl.org page just describes GL4 where you can no longer glGetString (GL_EXTENSIONS)) the solution is simple.
Just use 'if (strstr (gl_extensions, "GL_ARB_do_domething "))' instead.
That's the bug that both Fitz and Doom 3 have.
Mh:
#107 posted by metlslime [159.153.4.50] on 2012/11/06 20:55:43
first, thanks for pointing out various bugs that i didn't know about :)
second,
if (strstr (gl_extensions, "GL_ARB_do_domething "))
Won't this fail if the desired extension is the last one in the list? Or is there always a space as the last character of gl_extensions?
#108 posted by mh [78.152.207.43] on 2012/11/06 22:24:15
Won't this fail if the desired extension is the last one in the list? Or is there always a space as the last character of gl_extensions?
I've honestly got no idea.
Reading between the lines I'd guess that this might be a reason why the new glGetStringi method was introduced (see http://www.opengl.org/wiki/Get_Con... but I really don't know.
One to check with various drivers I suppose.
Re: Extensions Parsing
#109 posted by szo [160.75.18.212] on 2012/11/07 08:56:28
Easy solution, shamelessly stolen from quakeforge:
http://quakespasm.svn.sourceforge....
#110 posted by mh [137.191.242.106] on 2012/11/07 11:14:05
Yeah, that would work.
I'd be more inclined to emulate the glGetStringi method by first parsing into a char** then just iterating through that, but that's academic - so long as it works it's fine.
Incidentally, just remembered to check for space-termination on the entire string, and yes - the string isn't space-terminated, so either of checking with or without a space at the end of the extension name is bugged.
#111 posted by onetruepurple [91.240.47.30] on 2012/12/01 11:39:03
I think this engine is playing ambient sounds incorrectly.
Example: Run Contract Revoked and load the start map, and then stand in the pentagram in the middle. You can hear the sound cue from the Nightmare selection hall clearly and loudly, which is not the intended behavior at all.
To Clarify
#112 posted by onetruepurple [91.240.47.30] on 2012/12/01 11:39:57
The hall is right beneath the pentagram, but shouldn't be heard. It's as if Fitz Mark 5 does something to the attenuation...
Woukdn't Be The First Port To Do That
#113 posted by negke [31.18.186.11] on 2012/12/01 12:03:50
DirectQ changes this as well, I think, and DP even more. Sometimes you can even hear the spike shooters from logic gates if they are too close...
#114 posted by necros [99.227.223.212] on 2012/12/01 16:49:46
I hate that DP did that, but at least it provides a console command to fix it.
Jesus
#115 posted by onetruepurple [91.240.47.30] on 2012/12/01 16:52:26
What is the reasoning in the first place??
#116 posted by necros [99.227.223.212] on 2012/12/01 18:05:08
in DP's case, I believe it was something along the lines of 'I like it better this way'. :\
Re: Sound
#117 posted by Baker [69.47.162.203] on 2012/12/01 19:16:26
Interesting ...
The sound cut-off distance was brought on par with a couple of other engines. Unaware of the above.
Back in the day, ProQuake raised the sound cut-off distance "to match DOS Quake" to keep fairness against a DOS client in multiplayer (i.e. not fair if DOS client can hear sounds a bit further away) -- although some recent discussion @ Inside3D explores this in more detail. This change found its way into DarkPlaces maybe 5 years when it was noticed DarkPlaces could hear sounds other clients could, and of course found its way into DirectQ (these aren't only clients).
Wasn't looking to alter the intended designs of any single player maps ... and I thought this change was innocent enough but seems not.
Furtunately
#118 posted by mh [89.19.84.155] on 2012/12/03 01:25:38
It's easy to just cvar-ize this value (I use "snd_clipdist").
My own use of it dates back to QuakeSrc.org days when it came up originally, and where (as I recall) evidence was presented that this was the original value but had been subsequently changed in a patch. Unfortunately QuakeSrc.org is long dead and it's not possible to provide links, but that's where things stand so far as my recollection is concerned.
It opens an interesting question so far as the topic of "fixing up Quake" is concerned, and I believe that it's similar to the question posed by supporting fullbrights and overbrights - to what extent do you draw the line between "this is the way things are supposed to be" on one hand versus "this is the way mappers/other content creators prefer it" on the other? We're all aware that content exists where using fullbrights and overbrights causes problems with the original design (e.g. using palette entries from the fullbright range for textures which never caused problems in GLQuake), but should this be treated the same or is it something that it's better to keep away from?
Resurrecting FOV
#119 posted by mh [89.19.84.155] on 2012/12/03 01:32:09
I've been hacking some on the Doom 3 BFG code, and was interested to note that it uses the same method as mine for widescreen FOV: first calculate fov_y based on an ideal aspect (16:9 for D3, 4:3 for mine, although I adjust height for sb_lines too), then calculate fov_x based on the true aspect.
#120 posted by necros [99.227.223.212] on 2012/12/03 01:38:08
It opens an interesting question so far as the topic of "fixing up Quake" is concerned
For myself, as far as sound attenuation is concerned, as long as there is a cvar to revert it to default values, then engines can default to whatever they want. Like I said, DP has that option and now I know your engines do so it's a simple matter of including them in config files that run before a mod is loaded.
It's more problematic if you aren't making a mod, but at least the option is there to fix it.
In fact, providing a cvar offers interesting new possibilities for messing with sounds such as fading them out gradually for dramatic effect.
Next Time An Update Happens ...
#121 posted by Baker [69.47.162.203] on 2012/12/03 02:26:30
I'll just use the original sound distance if the single player scoreboard is showing (single player + coop) and if the deathmatch scoreboard is showing I'll use the other value.
Not looking at the source, I'm not 100% sure if the value is client (likely) or server (doesn't seem likely, but I'm not looking @ the source).
I don't like cvars and settings (except for features that help developers tune stuff).
#122 posted by ZealousQuakeFan [82.16.80.21] on 2012/12/09 04:06:21
There's a bug in my map that has a unique component only in Fitzquake. The first room has a pretty large bsp model for some pesky vertex saving. It seems that only RMQ actually allows collision with the model (DP/DirectQ/Fitz don't collide with it at all so I guess this bit is definitely my fault).
However in fitzquake if you move to the far side of the room away from the model it disappears, which no other engine does:
Model rendering properly
Taking a step backward
#123 posted by ZealousQuakeFan [82.16.80.21] on 2012/12/09 04:07:53
fyi the model entity is positioned just to the left of the healthpacks near the middle of the screen, so is definitely inside the room.
#124 posted by necros [99.227.223.212] on 2012/12/09 04:16:58
1. ALL engines should handle external bsp collision. Unless you rotated it.
2. You can't fix this unless you can find a way to change the size of the entity's bbox to be smaller. :(
#125 posted by necros [99.227.223.212] on 2012/12/09 04:18:41
bleh. '2' is referring to the disappearing bmodel.
This is due to the bmodel's bbox being linked to too many visiblility 'areas'. the problem is that the engine has a limited number of links to visible areas and when that list fills up, it just starts removing other links and replacing them.
#126 posted by ZealousQuakeFan [82.16.80.21] on 2012/12/09 04:21:37
Ah, hopefully won't be a problem with a full vis then? :/
ZQF
#127 posted by Fern [174.29.134.247] on 2012/12/09 05:16:26
I noticed that dropout in the beta but didn't think anything of it specifically because lots of the bmodels in my map did that and yes it got better after fullvis.
#128 posted by necros [99.227.223.212] on 2012/12/09 15:37:31
In my experience, it tends to get worse with a full vis, but you won't know for sure until it's done.
BSP Models Suck
#129 posted by mh [213.233.148.190] on 2012/12/10 03:19:28
As well as the problem with it's size (which would affect any brush model type) try this:
gl_flashblend 0
Fire a rocket at it.
Ugly, isn't it?
Luma ?
#130 posted by mechtech [65.190.42.20] on 2013/01/05 00:42:03
Does Mark V support luma on skin textures?
Yes
#131 posted by Baker [69.47.162.203] on 2013/01/05 02:08:08
Model replacement textures use the DarkPlaces external texture naming convention (so replacement textures for models go in the progs folder).
You can call them _glow or _luma (_glow is what Quake 3 uses.)
Luma And V
#132 posted by mechtech [65.190.42.20] on 2013/01/05 20:27:41
After trial and error I got _luma to work. The thing is the _luma texture need to be sized to the original model skin NOT the replacement texture. So dropping in a replacement skin pack doesn't work out.
+1 To Future To-do List
#133 posted by Baker [69.47.162.203] on 2013/01/05 23:41:39
I can't remember all the details, but it was really hard to add external texture support for .mdl for FitzQuake while sticking by the strengths of FitzQuake.
I can't remember what texture set I used to test the feature, but I wanted to keep with FitzQuake way of doing things which in this particular case involved some contortions.
FitzQuake, unlike other engines, doesn't stretch skins to accommodate OpenGL baseline compatibility and instead pads it. This made adding external texture support for .mdl difficult while still retaining the feature (which is good and avoid stretching). As far as I know, the replacement texture and the luma/glow texture being the same size should always work, but you seem to be saying it doesn't.
I'm not sure when I'll be back to doing a revision #8 of the engine, but clearly this will be checked out , rectified and documented in the readme.
I'd Recommend
#134 posted by mh [137.191.242.106] on 2013/01/07 11:39:31
Checking for and using GL_ARB_texture_non_power_of_two as an optional path instead of using skin padding.
Also - and this is available in GL1.1 as well so it may appeal to you more - instead of recalculating the skin texcoords based on the padded size, just scale the texture matrix instead. You can keep the original skin texcoords and have different sized skins this way.
The Non_power_of_two
#135 posted by Baker [69.47.162.203] on 2013/01/08 05:20:42
Extension would be extremely useful in FitzQuake, ultimately. Because the padding stuff --- and that code was ingenious --- but it really increases the overhead.
Something fun about non_power_of_two --> the texture you download is the one you uploaded ;-) so in theory, one might even be able to super-optimize the Fitz texture manager to not even need to store raw pixels source location (* I am aware of the exceptions here and there).
re: Texture matrix scaling, may I trouble you for a really simple example (which I would normally do at I3D except it is rather broken)?
I've never done anything with the texture matrix, but a simple example and I'm sure I could take it from there with ease ...
Texture Matrix Scaling
#136 posted by mh [137.191.242.106] on 2013/01/08 11:15:23
Something like this should work:
void GL_PadAliasSkin (aliashdr_t *hdr, gltexture_t *tex)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glScalef ((float) hdr->skinwidth / (float) tex->width, (float) hdr->skinheight / (float) tex->height, 1.0f);
glMatrixMode (GL_MODELVIEW);
}
void GL_UnpadAliasSkin (void)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glMatrixMode (GL_MODELVIEW);
}
Thanks ...
#137 posted by Baker [69.47.162.203] on 2013/01/09 07:05:03
MH adds Baker XP +1 for the Nth time, where N is getting to be a sizable number ...
#138 posted by mh [78.152.253.188] on 2013/01/09 12:52:04
You can also translate and rotate, or even do wacky crap like load perspective onto it. Very handy stuff, and a far more elegant solution to many problems than trying to brute-force it in C code.
Entity Lighting
#139 posted by mechtech [65.190.42.20] on 2013/01/13 18:08:47
Would it be possible to have a map key to set light level on static entities?
Static Ents
#140 posted by MadFox [84.26.175.209] on 2013/01/13 20:07:26
I remember asking when working on statics in my last map
and I thought it was not possible.
So the only way out was resetting the gammalevel of their skinfiles.
#141 posted by mh [137.191.242.106] on 2013/01/14 12:32:38
It should be possible but would need a protocol change as statics are sent from the server to the client during connection time. You'd also need to define how it works with coloured light and whether or not they should be affected by dynamic lights too.
Basedir Option For Paths With Spaces
#142 posted by Johnny Law [76.126.53.122] on 2013/01/16 00:26:58
I'm trying to use the -basedir command-line option and something is off. (This is on Windows 7.)
If the path doesn't have any spaces in it, all is fine. Let's say the folder containing id1 is named "foobar" at the root of the C drive:
fitzquake_mark_5.exe -basedir C:\foobar
That works. But if the folder name is "foo bar" I'm out of luck. This doesn't work:
fitzquake_mark_5.exe -basedir "C:\foo bar"
Using the "shortname" (barf) of the path-with-spaces does work:
fitzquake_mark_5.exe -basedir C:\FOOBAR~1
This isn't an emergency at all and I'm likely just making some stupid mistake, but FYI. (I ran across this while trying to write up some info on how to use different Quake engines.)
FWIW, QuakeSpasm does handle the path with spaces OK.
Engine Update
#143 posted by sock [181.1.88.179] on 2013/02/18 20:40:22
@Baker, Is there any plans for another update soon?
Sock
#144 posted by Baker [69.47.162.203] on 2013/02/19 02:56:08
I got your private message. I'll respond in thread @ I3D.
Is This Some Sort Of ARG?
#145 posted by ijed [200.73.66.2] on 2013/02/19 15:08:21
Magical Mystery Tour
#146 posted by sock [181.1.88.179] on 2013/02/19 15:21:49
I am not sure what you mean by ARG, but this is me trying to contact Baker. I am planning to tie up loose ends on the development of my MOD and I want to modify the MarkV engine so I can distribute it in my final zip file. I tried emails, private messages and finally this place, hence the weird reply.
Baker is a very tricky person to contact! :)
Just Meant It Seemed
#147 posted by ijed [200.73.66.2] on 2013/02/19 17:38:48
A roundabout way.
Or, possibly, if we chased up the link to I3d we'd find some hidden ITS release... :)
Maybe ...
#148 posted by sock [181.1.88.179] on 2013/02/19 17:59:17
#149 posted by onetruepurple [91.240.47.30] on 2013/02/19 19:12:37
This MOD by SOC is not an ARG, FYI
#150 posted by Spirit [194.95.79.12] on 2013/02/19 19:30:56
Moody arc figs modify cargos. Crag modify so cigars my food.
#151 posted by Mandel [80.217.68.43] on 2013/02/23 15:04:48
I have a tiny issue with mark v. My soundtrack mp3 files won't play. I'm sure I have installed the files in the right place, since this is logged:
Current music track: music/track04.mp3
But I'm not hearing it. Either there's another volume adjuster I'm not finding (I tried the CD music volume slider), or perhaps this has something to do with it:
CDAudio_Init: MCI_OPEN failed (266)
I don't have a physical CD player present on this machine, perhaps some virtual ones though. Or is this codec related?
Ignore That
#152 posted by Mandel [80.217.68.43] on 2013/02/23 15:10:47
DirectQ used to work but now it's giving the same error message. Has to be something with my system. Never mind.
Stuff ...
#153 posted by Baker [69.47.162.203] on 2013/03/03 00:49:06
@Mandel: A sincere thanks. Makes me think the world is a better place when seeing high investigations like that.
Anyways, I told Sock I'd do an update for Mark V and once is coming shortly (24 hours or less is the estimate. Maybe with something of interest to Mandel.)
Revision 8
#154 posted by Baker [69.47.162.203] on 2013/03/08 04:11:20
1. tool_menu command. A conceptual experiment.
2. follow/chase/race your ghost player (type "ghostdemo demo1" in console to follow John Romero around e1m3). A ghost will not pass out-of-sight and will wait for you.
3. community.lmp support (sock wanted this and is a quality solution).
4. Sound limit reverted to GLQuake/WinQuake/FitzQuake 0.85 level instead of the "DOS Quake level" per comments above.
Zip: http://quake-1.com/docs/utils/fitz...
Readme: Zip: http://quake-1.com/docs/utils/fitz...
For reference: community.lmp http://www.simonoc.com/files/misc/... (This is an alternative to pop.lmp registered Quake check for a total conversion to indicate that Quake should act as if the registered version is being run).
#155 posted by sock [186.108.77.104] on 2013/03/08 11:50:17
@Baker, thanks for the community file, it works a treat. :) There is one more thing I would love to add, the current -heapsize is crazy small, is there a way to make the default 64000 instead?
Would this cause problems with anyone else wanting a lower heapsize?
#156 posted by sock [186.108.77.104] on 2013/03/08 12:01:54
Ok what about this idea instead :-
(taken from the source files - common.c)
FIXME:
The file "parms.txt" will be read out of the game directory and appended to the current command line arguments to allow different games to initialize startup parms differently. This could be used to add a "-sspeed 22050" for the high quality sound edition. Because they are added at the end, they will not override an explicit setting on the original command line.
I searched the source files and could not find this implemented but if it was, it would be perfect. I could then create a command line for my MOD. I am trying to make this as easy as possible for new people wanting to play the game and avoid modifying shortcuts.
Also I checked for the map model bug where some were black and everything looks exactly like the original Fitz.
?
#157 posted by Baker [69.47.162.203] on 2013/03/08 12:03:08
The default heapsize in Mark V always was 64MB or the equivalent of -heapsize 65536
Do you mean 640MB like 10 times the allocation?
If so, I can understand that because you use a ton of media.
[ #1 - YES really 640 MB -heapsize 640,000]
[ #2 - NO I meant 64 MB. -heapsize 64,000]
If #2, that's in there now. If #1, sure I can do that but I thought you meant 64MB.
Re: Lighting
#158 posted by Baker [69.47.162.203] on 2013/03/08 12:10:21
"Also I checked for the map model bug where some were black and everything looks exactly like the original Fitz. "
Glad to hear that.
I spent several hours carefully planning the lighting optimizations back at the time and checked each step many times over, precisely to avoid that kind of issue. Although the lighting code is complex, I've always been disappointed that issue slipped through.
#159 posted by sock [186.108.77.104] on 2013/03/08 12:24:28
@Baker, ignore my previous post, the memory is indeed set to 128Mb, I thought it was a memory problem because when I changed resolution I was getting the following error:
SetPixelFormat failed:
I assume this is the fault of my video driver because eventually I can get past this error and the engine works fine. I was trying to set video settings of 1680x1050x32
Thank you for all the help with this release. I know you have been crazy busy lately, thanks for finding the time. :)
Re: 22050
#160 posted by Baker [69.47.162.203] on 2013/03/08 13:04:56
SetPixelFormat: Engine requests to operating system (Windows) "I want 24 bpp and stencil buffer". It wouldn't be the amount of memory allocated to Quake. Your guess about the video card is as good as my guess, seems likely.
I made community.lmp cause sound to default to 22050. ;-)
Redownload: http://quake-1.com/docs/utils/fitz...
Mp3
#161 posted by mechtech [65.190.158.200] on 2013/03/15 00:16:03
Can mp3 be used to replace .wav files in maps yet? Would love some nice HQ ambiance.
Screensaver Issue
#162 posted by Mandel [80.217.79.210] on 2013/03/16 12:17:21
Another tiny issue, not sure if it is unique to Fitzquake Mark V - I was watching a longer demo when suddenly the screensaver activated (or at least the monitors turned black). I moved the mouse to wake up the monitors (the pause demo playback feature is great btw) but when the picture came back, the gamma and contrast had reset.
@Mechtech
#163 posted by Baker [69.47.162.203] on 2013/03/18 16:41:03
mp3 is just a compressed .wav file [more or less].
mp3 is lossy compression of a sound file like JPEG (.jpg) is lossy compression of a graphics file.
mp3 is to .wav as ...
jpg is to .tga or .bmp or raw.
Use http://media.io/ [or another tool] to convert your mp3 to wav.
@Mandel Re: Screensaver
#164 posted by Baker [69.47.162.203] on 2013/03/18 16:49:29
I'm not sure when the next update will be (late summer?) but I'll address that.
I hope you found PGUP/PGDN keys too when you play a demo [fast forward/rewind].
#165 posted by Spirit [80.171.152.86] on 2013/03/18 17:20:22
I think mechtech meant using mp3 files for single sounds in a map.
@Spirit Mp3 Instead Of .wav
#166 posted by Baker [69.47.162.203] on 2013/03/18 17:44:16
What I was trying to illustrate: why?
FitzQuake doesn't support jpeg [lossy image compression]. You use tga.
Why do you need to use mp3 [lossy sound compression]? Convert the mp3 to wav.
mp3 engine code is super-ugly and you don't really want the engine to do it, you want the operating system to do it. This is more of an Inside3D discussion, but you know how H264 is often supported by hardware? You want hardware doing the mp3 decoding ideally just like you want hardware doing video decoding H264.
Short version: mp3 is messy to support and that's ok for a soundtrack, but the idea of using mp3 instead of .wav is a really bad one for some sort of the same reasons as why png is slow, pk3 is slow and video encoding is slow even with hardware support.
I'd Like To Have...
#167 posted by mechtech [65.190.158.200] on 2013/03/19 03:42:32
A compressed sound format. .wav is a huge waste of space. MP3 or ogg even flac. If I was to use say a 15 minute background loop wav is too fat.
if sound file decompression is too much overhead I get it.
An Attempt To Descibe As Best I Can ...
#168 posted by Baker [69.47.162.203] on 2013/03/19 05:24:11
It chews up a ton of CPU (lessen some by hardware support). Quake supports at least 8 simultaneous sounds, 9 if you count sound track.
One mp3 playing via operating system API (Mark V) = no big deal.
You don't realize the unreasonableness of your idea in regards to performance.
Which is ok, I get that. A few years ago, I would have grilled engine authors with the same thing.
Your idea on the surface seems totally reasonable. mp3 = common = why not lots of them. I know the engine side and I first ran into this with PSPQuake which had both a software version (mad.cpp) and a hardware emulation option.
mp3 playback is resource intensive.
Unfortunately, I don't have an MH/Spike/LordHavoc or Divverent here to better translate this to "layman's terms" of the world of suck that goes on with mp3 decompression.
It's ok for a single "stream".
If I have done a "communication fail" here, I'm to blame. But watch Quakespasm's CPU utilization when playing MP3 or imagine why Quake 3 or DarkPlaces don't support what you propose and realize that my poor attempt to phrase the problem in an easily digestible way is a bad reflection on me but the actual problem is real.
#169 posted by necros [99.227.223.212] on 2013/03/19 11:51:43
Are we talking about mp3 music or mp3 sound fxs?
Ogg support would be nice for ambient sound though.
..
#170 posted by Baker [69.47.162.203] on 2013/03/19 22:41:01
The above is a discussion about using .mp3 instead .wav files.
(ogg has all the same issues as mp3, as ogg is the lossy compression of a sound file that requires the cpu to continually decompress it adding "stress" and a potential new "lag factor" into the mix [i.e. several mp3 sounds at same time].)
Baker
#171 posted by mechtech [65.190.158.200] on 2013/03/19 23:31:00
I understand now your explanation was fine. 9 decompressions happening at once=BAD Idea
And
#172 posted by mechtech [65.190.158.200] on 2013/03/19 23:33:24
Baker thank you for your dedication to Quake
#173 posted by necros [99.227.223.212] on 2013/03/19 23:47:51
so how do modern games do it then? D3 had it, for example, and it's not even that new anymore.
I'm not actually asking for this, but I'm not really understanding what the big deal is. I understand that it takes time to decompress the audio files, but surely it's not so bad as to impact engine performance?
Necros
#174 posted by Baker [69.47.162.203] on 2013/03/20 03:56:33
I think that goes outside the scope of this thread.
But would be good material for another thread to discuss this in further detail (Does Saurbraten do this? Did they think about doing it and rule it in or out and what reasons did they have? What does szo + co. think about this idea? As I understand it, DarkPlaces does not do this ... did LordHavoc rule this out? Did Remake Quake try to talk MH into this? Did MH reject this idea? Etc. etc.)
But these thoughts exceed the scope of FitzQuake Mark V and my knowledge almost entirely ...
[And it is so out-of-scope I'd like to not have it in the Mark V thread, since I can't even be a knowledgeable participant in the discussion ... if you see what I mean ...]
#175 posted by Spike [86.166.67.135] on 2013/03/20 07:52:36
The time you spend decoding an mp3 is time you don't spend waiting for the disk to read a much larger wav.
If you're worried about decoding time, you can always offload it to another core before initiating playback.
You really won't notice it unless its done in bulk, but that's the same as everything else done during load time.
The real problem with mp3 is that its patented and thus the only way a gpl program can legitimately decode one is to make use of an operating system feature that does the magic for you, resulting in portability issues. ogg vorbis is thus a better choice on account of third-party libraries being legal in the usa and stuff.
In fte, its 200 lines to load+decode mp3 (using the win32-os-based decoder), and 400 lines to load+decode ogg (using libvorbisfile).
Sure, the sound code needs a slight tweak too, of course, but while you're doing that you get bonus points for running the audio mixer on another thread (if your mixer is on a different thread, your on-demand decoding will be too, and yes, I got a not insignificant fps increase from that).
16-bit Models
#176 posted by Kinn [81.156.206.151] on 2013/03/20 17:16:22
So, following that quake character re-modelling thread (see General Abuse) - I learned that the QuakeForge engine supports an .mdl format that simply uses 16-bit vertex accuracy, rather than the standard 8-bit vertex accuracy.
What's more, the guy doing the new monster models is using blender, using an .mdl exporter that has the option of writing to this 16-bit .mdl format.
My question is this:
Does support for the 16-bit .mdl format sound like something that's easy enough and worthwhile enough to be worth considering?
Please Don't ;-)
#177 posted by SleepwalkR [130.149.243.224] on 2013/03/20 17:28:34
Because then there's another incompatibility between engines.
Well
#178 posted by Kinn [81.156.206.151] on 2013/03/20 17:35:19
if it was implemented in a way so it's only used to replace existing 8-bit models, in the same way that external texture support only works by replacing existing quake textures...
No worse than external texture support then, right?
#179 posted by necros [142.245.59.16] on 2013/03/20 18:43:35
if you want to mess with the format, i would highly advocate MD2 format because the grid's granularity is calculated per frame instead of per model. that right there would give a huge boost to fidelity.
IQM
#180 posted by ijed [200.73.66.2] on 2013/03/20 18:48:25
Or the inter-quake model format is already supported by a handful of Quake engines.
http://lee.fov120.com/iqm/
And yeah, works in exactly the same way as external texture support.
Okay
#181 posted by SleepwalkR [92.231.110.64] on 2013/03/20 20:11:25
That sounds like a good compromise. And +1 for IQM.
Well
#182 posted by Kinn [81.156.206.151] on 2013/03/20 20:41:08
I'm only suggesting this because it looks like that capnbubs guy is making some absolutely nop-notch and faithful remakes of the character models, which even an old fuddy-duddy such as myself thinks are cool.
So it got me thinking that it's a shame to have to be stuck with 8-bit vertex accuracy on those models if it's easy for capnbubs to export versions of those models in a better format...
Just tentatively dipping my toes into the water here really...
Appendage
#183 posted by Preach [77.98.165.95] on 2013/03/20 21:50:17
There used to be an "extended-BSP" format which allowed you to bundle high-res textures etc with a bsp file - the extra data was zipped in a lump attached to the end of the file. Because existing quake engines were happy to ignore any junk appended to the end of a file, they would load in any engine.
You could do something similar with an extended .mdl format. It would be a bit fiddly to add the extended coordinates there. The way to do it with no duplicated data would be to split the 16 bit coordinates into a high and low byte, store the high byte in the regular mdl coordinate data and the low bit (offering the extra precision) in the extended data lump.
Care might have to be taken that this method didn't parse models which already have a lump of extra data on the end. Which models have that? Any saved by QME 3.0 - the extra data is things like skinnames and model groupw which the editor wants to preserve (3.1 has its own file format instead)
Necros/Mechtech Re:ogg
#184 posted by Baker [69.47.162.203] on 2013/03/21 01:19:58
Spike basically said "already doing this in FTEQW, if you run sound in separate thread is not problem".
I have the next 2 versions of Mark V planned out, but don't expect to be working on those until late summer.
There is a chance that the "ogg instead of wav" could be in the 2nd future revision.
Meanwhile, in two separate projects goldenboy and Dr. Shadowborg are targeting FTEQW which does Fitz 666 protocol and bsp2. DarkPlaces does bsp2 and IQM.
There is ample opportunity to play around with those features even now in other engines.
#185 posted by necros [99.227.223.212] on 2013/03/21 01:29:16
I just wanted to know why decompressing oggs or mp3s is such a problem for quake.
..
#186 posted by Baker [69.47.162.203] on 2013/03/21 04:34:59
24 hours ago I had only considered "what might go wrong" or how someone might abuse the feature (turn every .wav into an 11 MB .ogg or .mp3 and then blame the engine and demand "you must fix").
Then it occurred to me that you can make a laggy map with bad r_speeds in a map editor. I had already changed my mind prior to Spike's post, but I had the idea of pre-emptively decompressing to .wav on gamedir change.
Spike's method is far better than that.
Not the first time someone thought "this feature would be bad" and later changing mind.
I actually look forward to playing around with this.
Mouse Acceleration?
#187 posted by Nick [78.37.176.18] on 2013/03/22 14:30:22
How to get rid of mouse acceleration completely? It's switched off in the system and I use -dinput and m_filter 0
, couldn't find anything else in readme.
But still get inaccurate mouse input like with a bit of acceleration - depending on the speed I move my mouse with, not just distance.
It is specific fitzQuake problem, I don't have this in DP or FTE or other quake games.
Try
#188 posted by Baker [69.47.162.203] on 2013/03/22 14:54:51
-noforcemparms
-noforcemaccel
-noforcemspd
or all 3.
http://www.quakewiki.net/archives/...
Both WinQuake and GLQuake have this issue, FitzQuake isn't unique. And the code causing the issue you refer to is "not well liked" by hardly anyone. But it is in WinQuake/GLQuake so like +mlook, the behavior is destined to remain in this engine so that keeps with the original Quake behavior [whatever they could have been thinking ... ??? ].
#189 posted by metlslime [159.153.4.50] on 2013/03/22 20:23:34
it seems more and more that fitzquake gets called out for behaving in some ways the same as glquake.
At the time i thought it made sense because the target user is someone who is switching from glquake to fitzquake, so their configs should continue to work (i.e. i didn't change the defaults of any pre-existing cvars.)
Many years later i guess people install fitzquake before any other engine, or they are switching from more radically different engines like darkplaces, which have very different default behaviors.
So i should probably change all the default settings in the next version to "good settings."
@metlslime
#190 posted by sock [186.124.37.216] on 2013/03/22 20:28:08
There are plenty of settings that should be default without having to change the config; mlook on, mouse wheel up/down changes weapon, console speed higher (terrible with large screens) and console/sbar text changes size to match screen resolution.
@sock ... Quake.rc + Default.cfg
#191 posted by Baker [69.47.162.203] on 2013/03/22 22:26:07
There is sadly annoying stuff in default.cfg hiding in pak0.pak too:
* F11 key zoom alias that changes sensitivity and default.cfg
* Keys could be improved to default to WASD with Q and E for swim up/down
* "Reset to defaults" in the engine has unpredictable behavior because Quake didn't reset cvars, so re-running default.cfg does not fully default.
* The +/- sizeup and sizedown keys confuse if accidentally pressed and these are in default.cfg living in pak0.pak
Also the original QuakeC source didn't support both impulse 10/impulse 12 weapon switching, some single player mods like Castle of Koohoo or Duke of Ontranto (and far more) impulse 12 does not do anything.
[Avoiding mentioning too much how in original Quake (or Travail or Marcher or ...) in coop if one player grabs silver key and dies, key is gone and map is effectively broke as no further progress is possible ... relevant to exact topic ... I suppose not].
#192 posted by negke [31.18.175.98] on 2013/03/22 22:39:17
In coop, the keys always stay just like the weapons (but unlike them, they fire their targets correctly).
#193 posted by stevenaaus [49.176.97.231] on 2013/03/22 23:01:24
I hope you found PGUP/PGDN keys too when you play a demo [fast forward/rewind].
No way... Nice feature :)
+1 Awesome Feature
#194 posted by sock [186.124.37.216] on 2013/03/22 23:13:39
@Baker, there is certainly plenty of stuff that is wrong with the defaults and it is nightmare for anyone coming back to Quake wanting to play the game. I hope you still keep tinkering with this engine, I certainly appreciate all your effort.
+1 also for PGUP/PGDN, freakin awesome feature. I can't believe it is not a standard feature for Quake engines.
Ogg Stuff
#195 posted by mechtech [65.190.158.200] on 2013/03/24 16:48:11
I converted pak0 and pak1 sounds to ogg 128bit. I ran DP 20130304. Works well IMO.
Nice converter at
http://www.rarewares.org/ogg-oggdr...
Revision 9: Automatic Gamedir Switch In Coop
#196 posted by Baker [69.47.162.203] on 2013/04/02 17:24:13
Revision 9: If you setup a coop game running, say, Marcher or Warpspasm, when a Mark V client connects it will automatically switch to the right game dir.
Mark V Server tells client: I'm running "game marcher" or "game warpspasm -quoth" or "game hipnotic -hipnotic".
Mark V Client will switch.
Non Mark V clients won't even notice the message, it is fully backwards compatible and transparent to other clients.
Also:
1. When recording a demo, it will print what gamedir is running so someone receiving your demo can figure out what mod they need installed to view it.
2. Fixed a multiplayer coop demo bug.
Special thanks to Spike for how to achieve the gamedir switching in a way that didn't require yet another protocol --- like we need more of those.
Although I didn't plan on do another Mark V update for a while, there may be one more coming in a few days. If so, this one will solely be due to some fun information from Spike.
#197 posted by Spirit [80.171.97.119] on 2013/04/02 18:59:33
As I said before, please version code your zip files.
..
#198 posted by Baker [69.47.162.203] on 2013/04/02 19:23:22
From now on, I'll post versioned zip link to make your life easy like:
Revision 9: http://quake-1.com/docs/utils/fitz...
Cheers
#199 posted by Spirit [80.171.97.119] on 2013/04/02 20:25:44
Don't Play Marcher In Coop
#200 posted by Kinn [86.161.248.120] on 2013/04/02 23:54:15
the progs is horribly broken in coop :}
Don't Do Bastion Either
#201 posted by onetruepurple [91.240.47.30] on 2013/04/03 00:30:53
Spirit, Negke and I learnt this the hard way.
Truth Is ...
#202 posted by Baker [69.47.162.203] on 2013/04/03 00:45:57
I've discovered a ton of maps fail the coop test.
Whether the progress stopping barrier that never raises (the fix is to make a button that can open it not accessible in the inside, obviously) ...
Or lack of ammo ...
Or insufficient # health boxes ...
[I added sv_cheats 0 to Mark V to prevent cheating in coop like god, notarget, noclip but it doesn't block "give h 999" or "give 7" or "give s 500" ... ]
Yeah Bastion's Buggered Too
#203 posted by Kinn [86.161.248.120] on 2013/04/03 01:32:35
I tried to get clever with the QC and of course didn't get round to testing properly in coop mode.
So, Er, Hpw Do I Get The External Textures For Models Working?
#204 posted by RickyT23 [2.124.172.55] on 2013/04/09 00:13:06
Can't get it working, and I can't find any instructions.....
Please help Baker. I need you.
Tga Skins
#205 posted by mechtech [65.190.158.200] on 2013/04/09 02:06:07
My little 82 meg experiment. Has skins working in Fitz V
Similar to Dark Places format
soldier.mdl_0.tga that kind of thing
http://www.mediafire.com/download....
Thanks
#206 posted by RickyT23 [2.124.172.55] on 2013/04/09 02:33:32
Big help :)
Nice Assist Mechtech
#207 posted by Baker [69.47.162.203] on 2013/04/09 04:39:20
Yeah, Mark V uses the DarkPlaces naming convention for replacement model textures like soldier.mdl_0.tga where the texture should be in the progs folder.
So Are They Enabled By Default?
#208 posted by RickyT23 [31.53.116.69] on 2013/04/09 10:33:02
Does anyone have a working set for the standard Quake bad guys? Proving harder than I thought....
Yes Because I Don't Believe In Options/settings
#209 posted by Baker [69.47.162.203] on 2013/04/09 18:46:42
Download a DarkPlaces texture pack and look at the texture names if needed like quakeone.com/reforged.
Naming convention is simple:
Model name: player.mdl
Replacement name: [model name.mdl] _ [skin #].tga
Result:[model = player.mdl]_[skin = 0].tga
Result: [player.mdl]_[0].tga
Result: player.mdl_0.tga
#210 posted by Spirit [80.171.9.171] on 2013/04/09 18:51:16
Save your sanity, read text instead: http://icculus.org/twilight/darkpl...
I'm Not Interested In Bumping The Thread For This
#211 posted by Baker [69.47.162.203] on 2013/04/15 03:14:56
[But don't want to risk making Spirit upset.]
Revision 10
Incremental refinements but the source changes are large and includes a Visual Studio 2012 project file now.
Main real changes:
give ks - give yourself silver key
give kg - give yourself gold key
give q1 - give yourself rune #1 [r and s aren't avail]
give q4 - give yourself rune #4
"give" command with no parameters gives you minimal info on give command.
Reworked video mode shutdown in a way that might fix the crash one user was experiencing that I don't get [or may not].
Good To See
#212 posted by Kingold [59.151.95.220] on 2013/04/15 09:43:17
this being worked on. Go on with the good job. Cheers.
To Anyone Interested ...
#213 posted by Baker [69.47.162.203] on 2013/05/10 16:31:29
Within the next week, there will be another upgrade to Mark V. It won't include the mp3 request due to running out of time.
On the plus side, I think it completes the idea of getting the codebase entirely straight.
Keep in mind that the emphasis of this was to give back code clean-ups to the FitzQuake codebase to tune-up the 100 oddball bugs discovered at Inside3D without burdening, say, metlslime without having to read all that.
Exciting? Well ... that is subject to intepretation.
I do want to fix any bugs discovered, but other than that, it will be the final Mark V.
Bsp2 Support
#214 posted by RickyT23 [86.145.251.165] on 2013/05/10 18:13:55
It's the future!!!
By the way my faveourite thing about this engine is the demo handling. Supports multiple (most) protocols :)
Looking Forward To It
#215 posted by FifthElephant [82.12.230.210] on 2013/05/11 21:55:12
!!
Well ...
#216 posted by Baker [69.47.162.203] on 2013/05/14 15:55:24
It will be a very boring release. At least from the angle of exciting and interesting features goes.
From the other possible angles like the "boring and uninteresting" releases angle, it might barely fit itself in to mildly underwhelm.
And these are the kind of expectations I hope I can almost meet.
But from the more serious side ... it will be available in many preference flavors such as .exe, .zip, .rar, .7z and the classic and irritating .dzip/.dz format.
It will be a very worthy final chapter to this engine and I have to among other things type up a credits.txt to accidentally not include in the final .dz archive.
Kidding aside, it has quite a number of things that I owe significant credits to others. For 5 days I've been tempted to release this intermittently in pieces, but no ... I want to do it all at once.
BSP2!!!!
#217 posted by RickyT23 [86.179.8.172] on 2013/05/14 16:47:41
Final Chapter?!
#218 posted by FifthElephant [82.12.230.210] on 2013/05/14 18:44:49
... I hope you WERE kidding ;)
I Wasn't Kidding
#219 posted by Baker [69.47.162.203] on 2013/05/20 05:33:22
This will be the final chapter of Mark V. I'm doing some final testing and want to give a day or 2.
I'm not fond of "pre-release talk" (it's hated here, which I like because I hate it too) but I wanted to see if anyone had something to say I wasn't aware of that I needed to take into consideration.
If ever the words "radical" and "conservative" fit a description, it my hope this last one achieves this. It is my desire to draw this to a close with a very wide range of conservative fixes, some of which don't seem reasonable.
Thursday release. Final answer. Unless Thursday final turning requires an expansion of the definition of "Thursday" to include Hawaii or one of Jupiter's moons to meet a slight procrastination.
[But yeah, I really love FitzQuake ... what a marvelous engine.]
Hello Baker,
#220 posted by dooomer [60.190.100.244] on 2013/05/20 05:45:25
I don't know if it is too late to submit a feature request, but if not, could you add external ent support and multiple gamedir support to Mark V? I have been using these two features extensively with darkplaces, and found them to be extremely convenient and useful. Thanks.
Doomer, Sound Like You Want "happy Ending"
#221 posted by Baker [69.47.162.203] on 2013/05/20 06:52:17
Don't worry, maybe you don't get what you think you want, but maybe you get more than you bargained for ... and then some ...
Thank You Baker!
#222 posted by dooomer [60.190.100.244] on 2013/05/20 07:34:55
Wait with excitement.
Bsp2?
#223 posted by RickyT23 [86.179.8.172] on 2013/05/20 11:17:54
O_O
Fog
#224 posted by sock [200.82.40.116] on 2013/05/23 13:56:01
Is it possible to set fog parameters before the map is loaded? Then the fog parameters could be specified in the quake.rc file.
Can you add a fog distance command? Like at say 1024 units the fog does not affect surfaces? Then really tall ceilings could be black instead of the colour of the fog. Also make this a new fog command like 'fogdist' or something, don't add this feature to the existing fog command, it will cause problems with mods that use the fog command already.
Masked Textures
#225 posted by FifthElephant [82.12.230.210] on 2013/05/23 22:23:03
Can we get masked textures (like grates, chainlink fences) to have a value key in a similar way to how the "alpha" key works? This would be much better than having the texture start with a curly brace "{"
(which pissed off SleepwalkR to no end)
Yikes, Talk About Last Minute Requests ...
#226 posted by Baker [69.47.162.203] on 2013/05/24 01:49:47
@sock ... I think it would need fade or something otherwise surface at 1023 looks strikingly different than surface at 1024 distance.
FitzQuake expects the fog to be in the worldspawn and resets it on level load and I think new cvars are almost always bad. Better would be backwards compatible way to allow one more fog parameter in the worldspawn keys.
I also think it would require more tuning and testing to make sure it looks rights than I can do in the next few hours, but I'll think about while I'm trying to get the engine out. The Kurok mod (also an engine modification of FitzQuake)used an alternate fog formula, but I haven't been thinking about fog much lately so ...
I'll see if I can integrate the Kurok fogging for you to look with the engine release.
@elephant ... you mean like a worldspawn key to put into bsp to indicate alpha texture prefix? The idea isn't bad, but would be better if the mapping elite got to together and planned out things like that ...
I think me just putting something in that hasn't been discussed and argued about is how "really ugly hacks" happen.
Final Version: Beta 1
#227 posted by Baker [69.47.162.203] on 2013/05/24 09:32:58
Download | Read Me
@sock: type fogex 300 12000 50 60 76 to enable distance fog <z-near> <z-far> <red 0-100> <green> <blue> ... worldspawn key is "beta_fogex"
@Ricky ... see readme.
><((((º>
#228 posted by Mr Fribbles [118.209.226.99] on 2013/05/24 14:06:03
Where the new FitzQuake at... metl, give me a fix!
#229 posted by sock [200.82.40.116] on 2013/05/24 15:27:19
@Baker, I downloaded the new beta and I like noclip, notriggers :) good for testing. I LOVE the command auto-complete, my god about time! It even does map names within gamedir folders :)
What is r_stains? I saw it mentioned in the readme file but could not see any difference and the readme does not say what to do with it.
I had a play with the new fog and it feels back to front to me. I want original fog up close and then fade to specific colour at distance. Maybe I am not getting the parameters right but I tried for a while and could only get black at distance and no fog up close or white fog up close and glowing at distance.
Say for example I have fog 0.05 0.1 0.1 0.1 defined which is a nice wispy fog. On surfaces at distance (1024+) this gets brighter instead of darker regardless of light, I want to have a fog up close and then fade to nothing. I assume the distance fog would have a different colour to the foreground fog. Ultimately I want fog in a room but when looking up at a high ceiling 1024+ units it is black because there is no light, does that make sense?
One possible idea for alpha textures is to link the process to the texture. If the mapper specifies external textures and they have an alpha mask defined (tga/png format) then load and use it. This does not require fancy name changes or lots of effort by mappers just an external texture directory with alpha textures.
Not Worldspawn
#230 posted by fifthelephant [31.72.210.145] on 2013/05/24 17:47:09
Just have it as a brush entity key.
#231 posted by necros [99.227.215.224] on 2013/05/25 00:48:31
External .vis support. No more vispatching maps.
what? so it just loads .vis files generated by vis.exe now?
Alpha Mask Textures...
#232 posted by FifthElephant [82.12.230.210] on 2013/05/25 01:03:45
Ok, let me clarify a little more.
- It would be a brush entity key.
- It would use palette number 255 (the pink one)
- It would be a normal texture. (no tga/png needed!)
Why a brush entity key? Well we have this support with alpha, why not just set the key to something like "alphamask"? You could even have it as "alphamask 1" or "alphamask (insert palette number here)" and specify which colour of the palette can be the alpha texture, this way you could still make a texture look nice in both ordinary quake engines that do not support alpha masks and ones that do!
I like shipping .bsp files only, I really hate cluttering up my quake directory for the sake of one or two maps in a .pak file or any of that kind of nonsense. My quake dir is in enough of a mess!
What do you think?
Baker
#233 posted by mfx [92.227.147.168] on 2013/05/25 01:32:09
exe. doesnt start at all for me. just getting the usual "starting quake" window, then it just flushes out, no warning nothing.
:(
running xp sp3 on intel Chip ati video
@mfx
#234 posted by Baker [69.19.14.35] on 2013/05/25 01:51:40
@mfx Hmmm. Does a previous version work ok? And flushes out = it exits or crash? I added multisample support that abuses that window, but seems your graphics card no like. I'll see what I can do to resolve that.
@necros --- no external .vis means that instead of vispatching your stock Quake maps for transparent water, you just use .vis you toss in the maps folder. I'm on a low bandwidth connection at the moment, in a few days when I'm back I'll upload something and show you what I mean.
@fifth -- You lost me. I can make a BSP with a texture named "{alphatexture" and it works. Why do you need external files? Am I missing something here? Or is something not working right about the engine and external textures?
@sock
#235 posted by Baker [69.19.14.35] on 2013/05/25 01:53:14
Shoot the wall several times in the same place.
Or use lightning gun.
Hah
#236 posted by Baker [69.19.14.35] on 2013/05/25 01:54:25
I didn't initially get that but Fribbles made a fish.
Baker
#237 posted by FifthElephant [82.12.230.210] on 2013/05/25 02:04:21
Yeah the curly brace standard is actually one of the dumbest decisions I can think of. I'm saying the standard should be changed to a key tied to an entity brush instead.
(FYI, the curly brace conflicts with the .map standard formatting...)
Like I said, it really pissed off SleepwalkR and I can fully understand why (open up a .map file in notepad and realise why this was a terrible decision)
Baker
#238 posted by mfx [92.227.147.168] on 2013/05/25 02:06:48
previous ver. works fine.
this one it just doesnt Do anything than
just showing the starting window, no crash msg or sth. just disappearing from ram.
#239 posted by necros [99.227.215.224] on 2013/05/25 03:23:42
no external .vis means that instead of vispatching your stock Quake maps for transparent water, you just use .vis you toss in the maps folder.
oh ok, i see what you mean about that. :)
changelog has some interesting things in it, thanks for doing this, baker.
@fifth ...
#240 posted by Baker [69.47.162.203] on 2013/05/27 07:57:44
Why a brush entity key? Well we have this support with alpha, why not just set the key to something like "alphamask"?
I can relate to what your dislike of the curly braces.
I'm a decent Quake engine coder, but I know my place and I'm the wrong person to code anything that could be interpreted as a standard.
I named the experimental fog for Sock to look with an unlikeable name "beta_fogex" so it couldn't accidentally be interpreted as a standard, and likewise some of the experimental things I did with texture prefixes are console variables.
I'm not the right guy to make those kind of decisions. If I have any credibility with the 10-year engine devs (self-deprecating humor), it is that they know I'd wouldn't think of that doing anything like that.
Shorter version: Maybe ask people like metlslime, tyrann, preach and necros and such?
I'm just not the right guy. Seriously.
@necros ... .vis Files
#241 posted by Baker [69.47.162.203] on 2013/05/27 08:08:53
Extract to quake/id1/maps folder
http://quake-1.com/docs/utils/visf...
Then the original Quake maps are vispatched (unless you set "external_vis 0") to work with r_wateralpha.
It isn't that I think r_wateralpha is that great of a feature, but more that the vispatch process is extraordinarily painful since the original utilities will not work on Win64 even with DOSBox so someone looking to try that out can do it.
@sock ... Triple Post Time ...
#242 posted by Baker [69.47.162.203] on 2013/05/27 08:29:27
If the mapper specifies external textures and they have an alpha mask defined (tga/png format) then load and use it. This does not require fancy name changes or lots of effort by mappers just an external texture directory with alpha textures.
QW and Q1DM players would be very upset because someone (a cheater) would use replacement textures with alpha to make walls "see through" that shouldn't be.
Lol
#243 posted by nitin [180.149.192.139] on 2013/05/27 09:29:07
people do that for a 17 year old game?
#244 posted by Spike [81.159.142.110] on 2013/05/27 10:27:48
@nitin
Yes.
@fifth
{ prefix is compatibility with halflife, but also distingushes between alpha-blended alphas, and alpha-tested alphas. Which is especially useful if you have both active on an entity at once.
In the case of internal textures, palette 255 is a valid palette. While unlikely, its possible that this particular palette index could be used on other textures not intended to be transparent upon the same brush entity. Additionally the image loader will likely need to replace this palette index with an average of its still-visible neighbours in order to avoid colour leakage (yay! HALOS!), which is not something that can easily be done without walking through the ent file and checking each model in a really slow and hacky way on a per-surface basis (with multiple copies of the texture - things get even more fun if the qbsp reused the surface in two separate inline models). Which is why a flag on the entity is a stupid way to do it.
That's why we use a { prefix for alpha tested surfaces.
Yeah...
#245 posted by FifthElephant [82.12.230.210] on 2013/05/28 20:24:09
but it's incompatible with the .map format because curly braces are clearly already used for a different purpose (which appears to be containing sets of information together). This makes certain map editors (namely Trench) take a huge shit when the open curly braces aren't closed properly. :P
I'll leave it up to you coder types to sort out this mess, but I wouldn't mind having alpha mask textures for some of my upcoming maps (I have some nice ideas for them that I haven't seen yet).
It's Not Such A Huge Problem
#246 posted by SleepwalkR [92.231.104.132] on 2013/05/28 22:38:05
but it's annoying, and I wonder why you guys haven't chosen another character that doesn't have a semantics in the context of map files.
You Can Solve The Immediate Problem ...
#247 posted by Baker [69.47.162.203] on 2013/05/29 01:06:50
In console
] r_texprefix_fence
"r_texprefix_fence" is "{"
] r_texprefix_fence "!"
Name mask textures !myfence
] r_texprefix_fence "fence_"
Name mask textures fence_1
You will be able to map with TrenchBroom and view the maps you make in Mark V with alpha masked (fence-ish) textures.
And maybe somehow this problem will come to a conclusion by time you have polished map.
Hrm?
#248 posted by Spike [86.177.29.74] on 2013/05/29 01:20:53
then fix Trench to parse by tokens like qbsp does, or to write texture names in quotes so that it doesn't trip over its own output.
If I read the code right, it looks like a texture name with a comma in it will break it too, with an infinite loop, but its written in c++ and the code flows all over the place, so I've no certainty over that.
@sock Re: Super-auto-complete Of Everything
#249 posted by Baker [69.47.162.203] on 2013/05/29 01:45:32
@Baker, I downloaded the new beta and I like noclip, notriggers :) good for testing. I LOVE the command auto-complete, my god about time! It even does map names within gamedir folders :)
I had to rewrite a large chain-reaction of things to implement proper auto-completion of everything.
It wasn't fun at all, but I was getting really tired of not having autocomplete and asked myself "Ok ... you engine code right? Are you going to kill this once and for all or just keep being aggravated".
I thought since this was the last Mark V, the choice was "regrets" or "no regrets" and I didn't want to look back on it with regret.
I had a play with the new fog and it feels back to front to me. I want original fog up close and then fade to specific colour at distance.
I tested the "alternate fog" on Masque of Red Death to see how surfaces look at a very far distances and they don't fade out to full gray with the settings I suggested.
The OpenGL 1.x fog options are pretty thin. There is linear fog, and whatever GL_EXP and GL_EXP2 do (which clearly involve exponents probably using distance).
I don't know if much better fog could be done in OpenGL 1.x using glFog (I somehow doubt it) and I think it would require someone with a particle effects shader mindset --- which is something I don't have.
[I haven't forgotten about mfx. Not sure when I'll have the chance to put out beta 2).
Re: Bsp2
#250 posted by RickyT23 [2.124.172.55] on 2013/05/31 01:55:14
Heh - I'm definitely no engine coder, I'm totally glad you're even considering supporting it! I really like this engine a lot BTW. Massive props :)
Couple Of Things...
#251 posted by distrans [175.38.100.203] on 2013/06/01 16:17:36
The silver key door in e1m2 was non-solid for some reason. I had the SK but didn't need it to open the door as I just passed through. The released fiend was also able to pass through the closed door.
When using the engine to play DMSP2 I've notived that some enemy become somewhat impervious to fire. One grunt took almost 120 nails to drop.
What Map Had Issue With Dmsp2
#252 posted by Baker [69.47.162.203] on 2013/06/02 00:32:31
Will help me track down bug, I have a few suspects in mind.
Several Maps
#253 posted by distrans [175.35.49.88] on 2013/06/02 05:50:58
Here's demo of me making no impression...
http://www.quaketastic.com/upload/...
That one's on atlantis.bsp, but it's also happened on naughty2.bsp and the Travail DM maps as well. Sometimes there's no effect; sometimes one in ten or so shots hit.
#254 posted by Baker [69.47.162.203] on 2013/06/02 18:38:43
I think I need to double check changes I made when adding external .vis support. I'm able to reproduce the issue reliable. Thanks for the bug report.
#255 posted by Johnny Law [76.126.53.122] on 2013/06/02 22:47:01
This is probably a dumb question but: what does "Automatic wide-screen FOV correction" in the readme file mean?
I thought this might be something like QuakeSpasm or Fodquake's FOV adjustment. Despite the discussion in the thread above. :-) But nope it doesn't seem to be doing that (in revision 9).
So is that readme line just talking about protecting the weapon viewmodel from FOV changes, then? Or is it something else?
Widescreen FOV Means
#256 posted by Baker [69.47.162.203] on 2013/06/03 04:21:29
1) Adjusting the field of view calculations to be equivalent of a 4:3 aspect ratio.
The Mark V vs. Quakespasm FOV correction is the same calculation [although I don't know that the Quakespasm guys know this ;) ]
2) The viewmodel FOV "fix" is entirely separate from the above, but what it does is backs out the FOV calculation when rendering the weapon (viewmodel) so that the weapon does not get distorted if using, say, fov 110.
Note: I expect beta2 to be out later this week correcting the distrans discovery (grrr) and hopefully the issue preventing it running with mfx's video card.
OMG...
#257 posted by distrans [149.144.9.74] on 2013/06/03 05:57:51
...I have a bug named after me *blushes*
#258 posted by Johnny Law [76.126.53.122] on 2013/06/03 08:26:51
Well how 'bout them apples, yeah it really is doing the adjustment ... missed it last time I checked.
Some Requests
#259 posted by Spiney [81.242.127.89] on 2013/06/04 19:38:41
Hey Baker, not sure if you gonna work on it more, but...
Would it be possible to have support for foreign keyboard layouts?
Could you make the console fade-in faster? (maybe make it relative to vertical res)
Have the End key jump to the bottom of console log? (rather than having to hold page down for 30 secs)
Console Fade
#260 posted by FifthElephant [82.12.230.210] on 2013/06/04 22:19:53
is a command, "conspeed" I think it is.
@Spiney
#261 posted by Baker [69.47.162.203] on 2013/06/04 23:08:37
I've run out of time to do anything except light touch-ups to correct bugs and I had to cut international keyboard support from my to-do list (along with many other things, sadly).
I wanted to get one final update out and actually moved that forward rather than late summer.
My time is up, and they'll send zombies and nazis --- and maybe even nazi zombies --- after me if I don't focus on my real world objectives. Go figure.
#262 posted by Spiney [81.242.127.89] on 2013/06/05 13:24:33
Regardless, thanks for the great update :)
Windows Key Disabled? What Gives
#263 posted by negke [31.18.179.222] on 2013/06/05 20:03:28
Is there another way of minimizing it then?
@negke
#264 posted by Baker [69.47.162.203] on 2013/06/07 04:19:13
Yes the windows key is disabled when Mark V runs.
Fullscreen, you definitely want it disabled. Windowed mode, harder to say.
For windowed mode, I made the decision like this:
1) Mappers are really smart, know how to install engines, know how to use more than one.
2) Casual players are afraid of that stuff. And are way less likely to be pressing the Windows key for functionality when running the game because they probably are just "playing the game".
So I decided to err on the side of a casual player who just wants the game to work.
An uber intelligent mapper such as yourself could use Quakespasm or DirectQ or such if you are developing a map or mod and need that.
[Although, I'm betting Quakespasm likely disables that as well ... but I know Fitz 0.85 doesn't ...]
Can't You Just Alt-tab?
#265 posted by Spiney [81.242.117.150] on 2013/06/07 12:12:17
Or Press ALT-ENTER Toggle Fullscreen
#266 posted by Baker [69.47.162.203] on 2013/06/07 20:20:29
Quakespasm also supports this.
Mark V's video code rewrite makes ALT-ENTER a very fast operation.

Post A Reply:

Name: |
Title: |
Body: |

Website copyright © 2002-2013 John Fitzgibbons. All posts are copyright their respective authors.