|Posted by Baker on 2016/11/19 04:53:11|
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017
That's a hell of an awesome catch!
I'd like to think I spot stuff like that.
Baker fail +1.
Now ... what I did was this ... I added ericw controller support. But I didn't want all kinds of joystick buttons showing for people without a joystick, so I made the display dependent on whether or not a joystick was connected.
But I was "too clever by half" ... and a tad not careful enough ...
Mark V - Version 1.99 - Revision 3 (I Blame Esrael!)
Download: Windows - DirectX | WinQuake
1) mwheeldown wasn't showing due to a <= vs < typo (esrael)
2) Link to DirectX 9 drivers on homepage (mfx)
Experimental/requested extra builds: Alternate Builds
Question of the day:
Is DirectX Mark V faster than VxQuake (Vulkan)?
I have reason to suspect DirectX Mark V is faster than VxQuake.
(start.bsp beginning has a mirror there that Mark V uses so that is not a good test spot).
Triple Speed Screenshot
Screenshot: DirectX Mark V sometimes 3x speed of FitzQuake 0.85
And from what I have seen, VxQuake using Vulkan is only about 15% faster than its source base.
But the mh DirectX wrapper is offering a frames per second jump that is vastly greater than 15%.
There's no point benchmarking an engine in small tight corners with very few polygons visible. This is the same syndrome as "50,000 fps in dm3 - woooo!!!!" - it's a meaningless statistic.
Benchmark it under heavy load, then do a comparison. You'll likely find that D3D9 MarkV is substantially slower than either QS or VkQuake (but substantially faster than Fitz) because it still hand-feeds all vertices to the GPU every frame, whereas QS or Vk store them in on-GPU buffers. But that all depends on where the bottleneck in your system actually is.
For the record, I make absolutely no claim whatsoever that my cobbled-together wrapper is faster than properly written native code, and I would always recommend properly written native code over a wrapper.
Addition To The Above
It's OK for Engine A to run at 200 fps in dm3 whereas Engine B might run at 5000 fps.
What matters is how they run in a map like sepulcher. If the same Engine A runs at 150 fps in sepulcher whereas the same Engine B runs at 30 fps, then Engine A is clearly the better performer.
Waiiiit, Fitzquake had a noshadow list? Hmm, must have been inaccessible to the user, and only existed in the engine code? Ok, in that case, if you grabbed your list from Fitzquake, then it was Fitzquake that had an error in its list. Way back on the old page, I first reported that bolt.mdl was missing from the list, then I clarified that "bolt1.mdl needs to be renamed to bolt.mdl" See, that was just a typo in the original list: it did not contain the actual bolt.mdl but it did contain the non-existent bolt1.mdl (simply, the "1" should never have been there). So that's the reason Fitzquake had it there: a typo, not some intentional inclusion. Of course, even if it was an intentional inclusion to account for some specific mod, I would be against that too (it's not the engine's job to account for every custom model that a mod might use -- the correct option would be for the mod to include an altered noshadow list).... But it sure looks like it was just a typo. You did add the bolt.mdl that I pointed out was missing, but you didn't remove (or more correctly, rename) the bolt1.mdl which was there in its place, so now both bolt.mdl and bolt1.mdl are there... which is just building upon the original mistake instead of fully correcting it.
It looks like Quakespasm copied your early noshadow list (as stated here: http://quakespasm.sourceforge.net/Quakespasm.html#ss6.5
) and never fixed the error (they don't have their own Gunter to point these things out to them!), as you can see in its code (i.e., bolt1.mdl instead of bolt.mdl): https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/gl_rmain.c
Hardware Gamma: Ok, then it is still using Shader Gama when it says Shader Gamma. The problem is that switching to any non 1024x600 fullscreen resolution resets my desktop hardware gamma setting just as if I were using the Hardware Gamma setting in Quake. i.e., normally my desktop gamma setting is adjusted up a bit, and that applies to Quake as well, so I don't have to adjust Gamma in Quake up by a lot. Using Shader Gamma in Quake in a window or fullscreen at 1024x600 doesn't alter my desktop gamma at all. Using the the Hardware Gamma setting in Quake, either in a window or in fullscreen, resets my desktop gamma, meaning I have to ramp up the gamma in Quake to make it brighter, then I have to reset my desktop gamma when I quit Quake.... The same gamma reset happens when using Shader Gamma, but only for full-screen resolutions other than 1024x600 (native).
And just a note: you don't have to connect to an online server to test the CTRL/ALT buttons in console; just do New Multiplayer Game locally.
Hey, would it at all be possible to allow mouse selection of text in the console for CTRL+C (copy text)?
Oh, and there's little chance of me spilling coffee on my netbook... I don't drink coffee ;)
Who would want to deal with a caffeinated Gunter??
And on the Second Day, Gunter posted his long list of feedback over here: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3811
FitzQuake's no-shadow list was indeed hard-coded into the engine.
Compare it with the tempent parsing code and it seems evident that progs/bolt1.mdl was a typo/bug; the tempent code (correctly) has progs/bolt.mdl but does not have progs/bolt1.mdl; meantime the no-shadow list doesn't have progs/bolt.mdl; I don't think we need to debate this one.
Fork Of MarkV
first of all I'd like to say a big thank you for this excellent source port. I love playing the WinQuake version.
A few months ago I made the following changes to the old 1036:
* Fixed a bug in single player where a saved game wasn't properly reloaded after death (you fixed this too in 1050)
* Changed all the defaults to make WinQuake look and feel exactly like the original
* Hid all the customization menus but without removing the variables, so if a mod needs them, it will work
* Limited the maximum resolution to 1280x1024
Ever since I made this, I've been following your changes and keeping my little fork updated, but I haven't uploaded it anywhere yet.
Since Mark V isn't on github or a similar site, I didn't want to just upload it and make it look like I'm the author so I wanted to ask if you're planning on uploading Mark V on github or a similar site, so I can fork the project and give you the credit that you deserve.
Heyyy, I like the idea of having a fork that "Changed all the defaults to make [Quake] look and feel exactly like the original"... to a certain extent; I mean, I see no need to remove menus that allow for easy customization, and if a user wants a higher resolution, there's no need to prevent them from selecting it.
I have no problem with making all kinds of changes (I enjoy tweaking and playing with settings... which is why I break so many things in bugtesting!), but the default Quake look and feel should always be the starting point (which was the vast content of the post I just made on my forum -- all the actual reasons why I would like many settings to be reverted to the Quake Default, as they produce unwanted behaviors for me).
In any case, no disrespect to Baker, who is the true mastermind behind Mark V, but I (and others) would absolutely prefer use a fork which addressed all the issue I have with altering Quake defaults. AND maybe dosse91 would remove the intentional blocking of OGG support! :D
Don't worry, I'd still bugtest here ;)
Though I might run into issues with dosse91's fork trying to make everything like WinQuake whereas I prefer hardware-rendered Quake....
MAKE YOUR OWN github repo call it sporkV or something then not its a test fork of markV with a link to Baker's website. or make your github private and only show it off to baker? or no just compare notes.
Ah, I don't care about credit -- I don't even have "Baker" on the Mark V page nor in a text file with the executables (or on most other things like the QuakeDroid page) because I don't care.
Everyone's work is a fork of Carmack's anyway, isn't it? /end joke
My only interest is conveniently being able to play any Quake mod in the context that was meant in a resolution independent and preferences independent way and be able to use as close to anywhere as possible (all major desktop platforms, all major mobile platforms) -- with the start demos working nice and properly which no other engine has ever taken the effort to do it because it is tedious and unrewarding (stuff like bizarre behavior of the start demos if the menu is opened when the start demo switches, etc. etc. It's like 25 things. Hence almost all engines hide the start demos because the problems are so hard to address.)
Settings is no win. Some people think Quake is GLQuake or ProQuake (like gunter) and some people think Quake is WinQuake/DOS and others prefer say the FitzQuake feel or (insert another engine).
There is no winning with settings, only trying to make the major ones available -- even with things like mouselook, always run, animation smoothing, stair smoothing.
I tried to make it easy to compile so someone wanting to compile themselves would be able to do that.
<--- That Pitfall Guy Is Me Successfully Escaping ...
Warm weather now. I'll check the thread sporadically in read-only mode, unless someone finds an Earth-shattering mistake or such.
Main difference from last year, is I think I get to vanish with no annoying bugs like last year tool_inspector being broke.
I Think I Heard A Whoosh
And There He Goes
See you again for v2.0, mate! You deserve a break after this update marathon, I guess. We can all play AD in the meantime. With Mark V, ofc. :P
Well, dosse91, Baker's outta here for now, so it looks like you need to make your fork available for download and create your own thread here on Func so we bugtesters can take a crack at (breaking) your version and provide feedback :D
Two points on Baker's last thoughts as he ran out the door:
"My only interest is conveniently being able to play any Quake mod ... and be able to use as close to anywhere as possible."
Would it not be so much more convenient and compatible to allow OGG support then, for people who have OGG Quake soundtracks (it seems to be a common format for Quake users), and for people who have computers that don't handle MP3 well though Mark V for some reason (like me!)....? Just saying! OGG support would serve both the stated goals there: more convenient, and more compatible.
"Settings is no win. Some people think Quake is ..."
Indeed, which is a good argument for leaving all settings at the Default. Then you are sure to please at least one (rather large) group of people: people who expect Quake to act/look/feel the way it always has (whether that's Win or HW version).... Other people who want to change that can do so, to their own tastes. But having the engine set SOME settings to different defaults (some old, some new, some Fitzquake) has no chance of getting it just right for anyone... except people who don't care.
... hey... how do you people make your quoted text appear grey?? Is it a secret function for registered users?? bbcode obviously doesn't work here....
Huh, ya know, come to think of it, there are already those options at the bottom of the Preferences page:
Set to Mark V
Set to Fitzquake
Why is there no "Set to Quake Default??" That should revert everything I complain about to the standard Quake Default settings ;)
And that should be the Default settings, heh, and then people could easily apply your Mark V recommended settings if they wanted.
Quoting from #1763 for your benefit.
I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.
Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).
Adding this support is not as easy and clean as you think it is.
Replacing the existing MP3 support with a different format - easy and clean.
Adding support for two or more co-existing formats - messy, troublesome, hard decisions to be made.
You say "just saying". Well you've said it; over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and Sweet Baby Jesus Make It Stop.
You want people to listen to you? Return the favour and do some listening back yourself; I don't think that's too much to ask for.
Been Super Busy
I haven't been keeping up with Quake recently, good to see so much work still going into MarkV. Can't wait to play some split screen when it happens ;)
Linux Binary PLEASE
Any chance for a Linux version of the 1.99 release? And actually have working external music support? Quakespasm Linux has working music I don't see why the Linux binary of MarkV can't have it.
Also what the hell does "Cache_RLU: NULL link" or whatever even mean? I've never had that happen in Quakespasm.
Now, mh, YOU KNOW that the paragraph you quoted from yourself in the past is utter nonsense (why are you trying to make it sound overly-complicated by talking about sorting lists and comparing bitrates and acting as though it's a crazy impossible situation if there are multiple formats in the same folder?).
Do you know how I know that you know it's nonsense? Because I just fired up DirectQ, YOUR QUAKE ENGINE, and guess what? It can play both MP3 and OGG files, and if I have BOTH an MP3 and an OGG file of track04 in the same folder, it simply plays the MP3 instead of getting confused by this "crazy-assed situation" and causing the earth to explode. FTE, on the other hand, supports both formats and gives preference to the OGG in the same situation.
So, YOU'VE done this. It was simple, because apparently you did it without even knowing you did it. It just works automatically, easily, and effortlessly for the user. But now you act like it's some impossible insurmountable obstacle to programming....
Are you retarded or something?
See, I don't listen to tards, because they say retarded things that just aren't true.
Just saying! ;)
Now the continuing report of the weird centerview behavior....
Me and another player on the FvF server experience it working and not working at the same times. I checked the clock and it seemed to be right about 15:30 when it stopped working. On the next map (it starts working again after map change), I watched again to see if it would repeat, and it seemed to stop working again right about 15:30. Then it started working again around 18:00, stopped again sometimes after 20, then stopped again after 21... and stayed that way. At each point I told the other guy and he agreed that it would start/stop working during the same periods it did for me.
I was using Quakedroid with keyboard only, and he's in Linux Mark V using mouse + keyboard.
I tried playing around some more to see if those times would aproduce the bug in single player or local multiplayer, and by restarting a map on the online server and messing with the host_framerate, but I can't really get it to repeat.....
But it's rather odd that centerview (not force_centerview) should be affected by anything the server is doing... at certain times... for multiple connected players... isn't it? We were just standing around in the game not doing anything weird. Pretty sure I don't do anything in FvF that should alter a player's view like that. And as I reported before, after tapping the centerview key, the view will center itself after like 10-30 seconds when the issue occurs.
Weird one. *shrug*
@gunter ... get me a demo and the time within the demo the problem crops up. Use cl_autodemo 1 or have your friend use cl_autodemo 1.
There are dozens of items used in the Quake view drift calculations, some come from the server or the mod (QuakeC).
It could be so many different things like the server/QuakeC specifying "wishangles" or movetype fly/noclip or an onground flag that without live catching it, there is not a reasonable chance of isolating what is occurring.
Since a demo is the capture of all communication from a server, the information within a demo should be enough for examination to see what variable is the source of what you have experienced.
Other: I'll build the Linux in the next 24-72 hours. The "link active" thing should go away. Although I spent some time examining ffmpeg, too many irons were in the fire and I never got around to adding soundtrack support for Linux nor QuakeDroid because there was too much going on. So that'll happen next time (maybe Christmas).
@fifth - Yeah, split screen is going to happen! Haha! Almost happened this time. Next time is a lock.
It's ironic that this may happen when I am playing the least amount of Quake for about 10 years.
Asking Baker for help
since he has experience with both the software renderer and with things like his tool_texturepointer.
Did I say adding ogg support was impossible? Don't seem to recall saying that. Yes, I've written it myself in the past, did I deny that? You'd think the fact that I've written it would put me in a position where I could be assumed to know what I'm talking about, but apparently not.
Yes, I know what code that supports multiple formats looks like. I know the kind of things it needs to do. I've written such code, so please don't assume that I'm BSing when I say that the MP3 code in MarkV is nothing like it. This isn't a simple modification, this is an extensive gut-and-rewrite.
Asking for the same thing over and over again when it's already been both patiently and impatiently explained that you're asking for a lot more than you realise is wearing pretty damn thin.
MP3 Vs OGG
I don't quite understand what's the big fuss about having to use MP3 versions of the Quake soundtrack. They are not that hard to obtain. "Other ports support OGG" is not a valid reason to insist on this IMHO.
Sure, it's maybe nice if you can use the soundtrack files in different ports if they are in OGG format, but honestly I am only using Mark V by now. As far as I am concerned, I got used to using MP3 files.
@gunter - Your Rare Heisenbug Demo
I reviewed your demo and peeked at some internals. Things affecting lookspring ...
1) internal game clocks (seems fine)
2) onground is non-issue
3) Although the problem went away on level change, it could be just a coincidence.
4) The server wasn't stuffcmding anything that interfered.
Can you link me up a copy of your config.cfg and autoexec.cfg so that I can review some other potential things since cvar settings combinations could be involved or divide strangely with floating point.
I almost replied your post @ inside3d yesterday about your engine and polygon points.
But I suspect you might not like my opinion of an answer, but here goes ...
Mark V has *ALL* of mh's matrix calculation and manipulation functions. This stuff primarily is not needed for WinQuake since it doesn't use OpenGL, yet even Mark V WinQuake uses these.
I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.
What stopped me from posting is that since you do the software renderer, you likely don't use OpenGL matrix transformations -- and I felt my answer would be unhelpful (*).
You'd also probably have to add some GLQuake extra fields to some structs to make life easier. So I figured you would hate my answer and didn't post it.
(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)
There is Carmack matrix manipulation stuff in WinQuake, but where it differs from the look and feel of OpenGL matrix manipulation it looks Greek to me, mostly because if I didn't need to understand it for a feature, why investigate. I think one of the few times I used Carmack's matrix stuff was for "fov doesn't affect gun" option.
More Concise version: If I were in your shoes, I would add all the glpoly_t to the WinQuake renderer and modify the surface structure and use those to access coordinates. Then use mh matrix functions against those points and things like Mark V project/unproject (which is basically similar to gluProject) But I don't think you'll like that idea.
Plus my thoughts are shaped by my lesser knowledge of the internal workings of the software renderer than yourself, so I don't even know if "what I would do" is optimal.
(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)
Yes, that's more or less the point. I don't want to get deep into this kind of 3D math before finishing the stuff I'm working on right now. Plus, what puzzles me the most is not the math, but the fact that it seems that the on-screen vertex data is unreliable.
I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.
For now I'm going to do it the brute force way and extract the coordinates from the chained spans data, iterating through the whole chain to get the max and min x & y values. I suspect there'll be a lot to rewrite in the engine to get this kind of data in a straightforward way. But I'll take a look at what you suggested, thanks.
By the way, Makaqu has support for .scale on SPR sprites, so you can copy it from there. IIRC it's pretty simple. It also has .scalev, which can be used to scale each axis individually. The only model format I didn't try figuring out how to scale is BSP.
extract the coordinates from the chained spans data
The glpoly_t has those and generates them on map load.
BuildSurfaceDisplayList <--- in Mark V and I think the same name in FitzQuake 0.85, which might be the same code as GLQuake (never looked, but seems very likely).
Also see: DrawGLPoly where it shows code drawing iterating through a polygon.
Generates all that glpoly_t stuff. Just on map load.
For any glpoly_t named "p" ... the verts are p->verts (X), verts (Y), verts (Z)
Anyway, the reason I recommend this is that the code for getting the verts is already written in GLQuake.
(Then create a projection matrix and a model view matrix based on current player origin/angles and fov and combined with the viewport width/height you can get convert between real world points and screen points including z near depth 0 and z far depth 1 as much as you like <--- part of answer you will hate obviously, but the nice part is that it works.).
Here's a thought for you ... QuakeDroid has tap-fire and the very first QuakeDroid was (WinQuake) before a switched GL to be the main QuakeDroid.
1) Load up Mark V WinQuake.
2) Type vid_touchscreen 1 in the console.
3) Double click on a torch and watch what happens. It is QuakeDroid "tap fire".
Now double click on a wall.
Now think about the fact that in order for that to work, the "tap fire" has to know the targeting distance to get the angle of fire correct!
("Tap fire" has about all the calculations you want, and it does them in WinQuake! No GLQuake at all. It shows you how to do most of the things you need.)
@Baker Help/support For My 100b Jam Map.
Hey, I've got a map incoming for the 100bjam. It is currently using many new mdls, some with alpha textures recently supported with the newest Quakespasm release. Notable, these trees here as seen in Quakespam 0.93, Quakespasm currently displays all my models correctly:
When in MarkV dx9 the transparency doesnot work on 1 skin, also the model itself appears to be transparent with the background bleeding through
In Mark V the skin is fixed but bleeding from behind the model is visible, as well as a transparent layer that seems to cover the entire model:
Also, geometry is bleeding through all my models in Mark V even when they don't have transparent skins:
Currently only QS will run this map correctly. Anything that can be done Baker?
OMG! It's beautiful! I knew you were a talented guy but I've never seen anything like that in Quake. I'm not sure I would have ever thought it possible.
1. Do you have r_shadows off?
If r_shadows is off ...
There is an Open GL Mark V 1.99 in the following zip http://quakeone.com/markv/builds/1099_mark_v_windows_extras_revision_3.zip (It's the SDL GL .exe)
I would recommend you check and see if looks ok in OpenGL.
Let me know ...
Running on the newest openGL MarkV fixed all the issues with the models and the display perfectly now.
But there's a new problem. My map uses a func_illusionary for the bottom skybox face, with a minlight func_group beneath it. This is in order to properly light the models. Other methods failed because there is a problem with the current version of ericWs tools. This sky works fine in QS, but the bottom is not showing in this MarkV release now.
I guess I didn't notice that the bottom skyface wasn't showing on older MarkV version as well. I mean I could try casting sky on a func_wall (although this makes sky 'shootable') instead as this also worked in QS, but will either of these methods methods display properly in MarkV?
So there is a func_illusionary skybrush at the bottom of the map?
Do you have a sample .bsp that illustrates the issue? Need something to look at.
Sample map with func_illusionary as bottom sky face, beneath that func group with minlight, beneath that a regular brush. 3 layer Sandwich. Run this in Quakespam and MarkV and you will see MarkV has no support for func_illusionary sky.
Source is included
Cool! Sky brush entities are rare (so rare I can't name with a map that uses one, and I have lists of maps with uncommon features) I probably forgot to implement it for lack of a test subject.
Yeah, otherwise it seems to run fine in the newest version which is good news. I guess this means v1.999 is on the way?:)
Trouble With Rubicon Rumble Pack
Rubicon Rumble Pack, version 1.03. In map telefragged, when you approach the area with the 4 labs (the one with the platforms going up and down in a pool of slime), Mark V closes to desktop with no error.
This is on Windows 10 1803 x64, with all versions of Mark V.
For the area you are talking about, could you type viewpos and give me the numbers.
It looks like this:
Camera: (544 288 50) 0 90 0
Viewpos: (544 288 28) 0 90 0
Rubicon Rumble is a really big map.
Sky entities addition done. Just need to build.
(I would like to look the issue that gvakarian says occurs with Rubicon Rumble before doing another build, I've looked around some of the maps but I don't know/can't find the area he is referring to ... the maps are gigantic).
Great stuff Baker. I'm hoping that players who are MarkV users will be able to enjoy my map. Not sure how your gonna find that Rubicon glitch, needle in a haystack. Goodluck
The approach to the 4 labs is in telefragged.bsp at "1134 -319 -8" facing angle "0 0 0". the labs are through the doors at the end of the hall.
Haha! Thank you!
If someone says they have an issue and I can't investigate it, it is annoying as hell!
@redfield - Any chance to get something to test the outstanding issue of screenshot you first posted that had black where transparency would be in the DirectX Mark V. I've done some fence model texture skin tests in DirectX Mark V and it renders just fine.
I'm glad to see alpha masked models get some live use in actual Quake.
It's a tricky one. Baker mentioning floating point divisions put me on the right track of what to look for.
Ok, in FvF, the Cleric and Monk can create health and armor. In Quest (coop) mode, they get XP (frags) for giving that health and armor to their teammates.
A regular health box given to a teammate earns you 0.25 frags... so after you've given 4 health boxes you've earned 1 frag/point/XP.
Quake doesn't have a problem with this for math and display purposes, as it only shows the rounded number in scoreboards and such, and when the map changes, the fraction is dropped completely from the frags value.
BUT! This seems to be the cause of the bug. When ANY player's frag value contains a fractional value, it prevents EVERYONE on the server from using centerview! Well, I mean, it usually works on a delay of like 20 seconds.... But what's up with that? Why should someone else with a fractional frag value prevent everyone's centerview from working correctly? Why would frags even be involved in centerview?
Upon tossing that 4th health box to a wounded teammate (so my frag value no longer contains a decimal value), my view will then auto-center right away (having previously pressed the centerview key).
Reproduced in Mark V, QuakeDroid, ProQuake, and Qrack... so... if you fix this bug, you'll be breaking new ground ;)
@gunter - Great!
Awesome gunter! Glad to see you solved the mystery.
I turned over every rock and was striking out.
For me the big deal is that Mark V has a really hard time loading MP3 files on my WinXP netbook. I've heard another person say something similar.
When loading a decent-quality MP3 track inside Mark V, the entire game literally freezes up for over 20 seconds while a glitched menu sound (if I just activated external music in the menu) replays over and over until it unfreezes, and then the music starts playing.... I manged to find some re-encoding settings that reduced the quality of the MP3 a lot and got that freeze delay down to 5 seconds....
However, when I use OGG files (by renaming things or hacking Mark V with a hex editor to replace "MP3" with "OGG") then the song loads almost instantly, with only a 1 second delay or less.
So yeah, it's a real issue for me, and not just some weird irrational preference for certain formats! ;)
Add: I'm not sure, but since you can reliably identified and recreated the circumstances in multiple engines, it gives me something to think about.
Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor) while because mp3 uses hardly any cpu at all because it has hardware decoding built into every phone/PC/device on the planet.
Plus the Mac version of Mark V plays mp3 via Apple API via hardware decoding using nearly 0% cpu. ogg being an obscure format that no companies ever use, there is no Apple API for that.
I care that your Quake works right, but you already found a solution that works for your computer issue
with mp3 by cheating around with something that happens to work on Windows.
So your personal issue is solved.
My issue is I want things to work the same on all 5 platforms that Mark V supports.
Why the hell would I want to support an obscure music format that can never work on the 2 mobile platforms that I like with Mark V.
Why would I also want to recode the Mac version to support a shittier music format that uses more CPU? Oh -- and since I couldn't use Apple API I would have to rewrite the music code.
And the Quake .mp3 sound tracks are available everywhere, like on the Steam page. Case in point, this guy is links to it. Also Travail's soundtrack is mp3.
Also why the hell support more than 1 music format?
Shall we figure out new graphics formats like .bmp or hey let's do .gif!
The only engine that can't play mp3 is DarkPlaces, and to be blunt --- DarkPlaces is an extremely shitty engine for playing Quake because it made itself so damn incompatible with a lot of Quake mods.
I'm just communicating my point of view.
I don't care if people discuss it or what not, discussion is always a great thing -- environments where you don't find discussion or arguing are sterile and mindless. You might consider listening to my point of view, though --- I have one too! Haha
mh, yeah, I was being overly-dramatic because you were doing the same. But you've remained clam and respectful in your recent post, so I will do the same (funny how that works).
Sure, I would normally take your word for it, in areas of engine programming, but not when you are making statements that are clearly exaggerated and misleading.
Of course, in your original post on the matter ( #1757 ) you pointed out that Mark V already supports OGG through DirectShow, which you knew because you were the original author of that code, but Mark V is hard-coded to only look for MP3, and supporting OGG should just be a matter of adding support for other extensions, but, you said, "I can't say what kind of work would be involved in this change."
After that tip, irlyap and I found we could hack Mark V to allow OGG files, and PRITCHARD made the amusing comment: "It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think 'I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!' "
irlyap made the comment that it would be like "adding 3 characters" which is when you pointed out it would not be THAT simple, which I'm sure is true, but the paragraph of reasons you gave (which you recently re-quoted) is the problem.
I'll just take one part of it as the crux (though I believe the entire quote is trying to make it sound more complicated than it actually is):
"making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?)"
So, since you have coded multiple-file-format support before in DirectQ, did you actually DO that comparing of bitrates?
I already know the answer: No, of course you didn't. Comparing bitrates of various file formats would be a completely ridiculous thing to do. There are several Quake engines that support multiple formats, and I bet not a single one of them would dream of doing something like that. The only decision you have to make as to what takes priority is, "do I want MP3 or OGG to have priority?" and the answer to that is already quite obvious for Baker! Heck, I'm thinking that decision would happen automatically if the coder didn't want to specify a specific order -- the engine would just play the first format it came across according to it's internal list of formats to look for....
In #1764 irlyap pointed out that OGG was already " listed in Mark V's file extension look up table" and he guessed that there must be some code that explicitly ignores of forbids it. Then just a couple posts after that, both he and I pointed out that you don't need to do any of that overly-complicated stuff -- just add support for OGG with preference for MP3, and that's it. Sure, that's likely more than adding 3 characters, but I know it's nowhere near as complicated as the quote you brought back up, after we had previously "patiently explained" that none of that was necessary....
Now, maybe your original intent wasn't to make it sound overly-complicated and you were just considering options.... You did also say in that same old post, "I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. ... it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out."
The expected behavior is just as I said (and maybe irlyap explained a bit more thoroughly in #1768 though he spoke of 3 example formats when all you need are 2). Allow support for MP3 and OGG in that order of preference. Or, stated more simply: just allow the engine to look for OGG files if it doesn't find MP3 files! How hard could that be?
Baker's objection to OGG has never been that it would be difficult -- he just wants Mark V to be The Engine of the Future, and OGG doesn't exist in his Perfect Future! (or something like that!).
Now, before there are any slippery-slope arguments like "Where do you stop? If you add one format, you have to add hundreds more..." -- Nope, all anyone is seriously asking for is a second format, OGG. So you have a mere two formats, and that's all you need. Nobody uses any other formats for Quake music (not that I've heard of -- someone said something about Opus and QS? Is that really a thing? What the hell's an Opus?? Isn't that the penguin from a comic strip??).
I explained my point of view. I want the engine to work the same on all 5 platforms.
Tomorrow, you might get a new computer and you will no longer care about any of this.
Ok, I'll address your points.
I accept that Android won't play OGG. No problems with that. But I don't see that as a good reason to say, "Since mobile platforms don't support OGG then I also want to prevent the desktop versions from using OGG when they otherwise could."
You say you want things to work the same on all 5 platforms, but that's never going to be quite true. For example, my WinXP netbook does not have a touch screen, and my Android device doesn't have a mouse.... Yet there are touchscreen and mouse things coded into the engine.... So what happens if I enable touchscreen or mouse on a device which doesn't support touchscreen or mouse? Nothing. Nothing happens. And that's fine. That's how it should be.
So if you allow Mark V to simply look for OGG files if it doesn't find MP3 files (simplest way of stating it), what would happen on an Android device, even if I had OGG files installed? Nothing? Would just nothing happen because Android won't play OGG files? So it would be no different whatsoever from now? That's what should happen: Nothing.
So there would be no harm done if a WinXP computer, which can easily play OGG through DirectShow, were allowed to do so, but a Mac or Android would simply do Nothing because it can't play OGG. For the user's benefit it would just be as simple as stating, "Mark V supports MP3 as the primary format, with OGG as an alternate format if you have a Windows computer with DirectShow which is capable of playing OGG" (and face it, Windows users are likely the majority, so it's not a trivial number of users we're talking about).
"Why support two formats?" For convenience of the users. I'm not the only person who has asked for OGG support in the past -- I only started asking when I found OGG magically fixed my freezing problem with MP3s (and I suspect Dutch had the same problem). Yeah, I can hack a workaround, but then I have to offer my hacks to other users who may prefer OGG for various reasons, and I find that "solution" to be ... ugly.
Nobody is asking for more graphic formats, and nobody is asking for a multitude of music formats. But yeah, apparently OGG was a fairly common format for the Quake soundtrack... otherwise there wouldn't have been multiple people asking for it.
And what would be the harm if just *Nothing* happened on platforms that don't support OGG? While at the same time allowing OGG to be used on supported platforms by simply allowing Mark V to check for an OGG file IF it doesn't find an MP3?
The benefit is that it helps users who either have MP3 problems in Mark V (like me), or users who already have the soundtrack in OGG format installed....
Pros: Benefits/is more convenient for some users.
Is that accurate?
I mean, this isn't a case where you have to specifically tell android to NOT play OGG because it will be slow and crappy, is it?
Isn't it the case where Android (or Mac, or whatever) will simply do Nothing if an OGG is present? Because that's exactly what Mark V does now when an OGG is present!
"Tomorrow, you might get a new computer and you will no longer care about any of this."
You keeeeep wishing that, don't you? XD
(And I still don't know how to make quoted text appear grey.... How do people do that?)
And then I found THE FAQ thread.... Which told me the codes, which are very similar to BBCode but not exactly the same....
Baker, download this model and drop it into a map using Quoth custom_mapobject or AD misc_model and set the skins to 0 and 1.
I tested with an isolated clean install of Quake and MarkV Dx9 and your newest build. Only the new build displays these models correctly.
Thing was a bitch to make, so its nice that newest builds of all the engines (DP untested as yet) can display it properly.
@redfield - Masked Models Will Be Ok In DX9
I think everything is going to work ok for DX9 with the masked models.
screenshot: red tree masked model now renders leafy style in DX9
I'm not actually modify the DX9 rendering, but in this case was able to determine what the DX9 hated and do it a bit differently to get it pretty close to what it should look like.
Just curious, what was different between the two mdl's that caused one to work and the other not?
This is great Baker, thnx.
Yeah would be interesting to know. Its the same model only skin difference.
The Red Tree Skin
The red skin has fullbright pixels in it.
If you do "imagedump" and look at the fullbright skin generated ...
You can see dark red that would technically show up in pitch black with no lightning.
(Really the texture probably shouldn't -- like it might have glow in the dark pixels to the extent that dark red is , but it happens in map textures all the time too, haha.).
So it was using a combination of OpenGL capabilities at the same time that doesn't normally happen in Quake with alias models (.mdl), so the Direct3D wrapper wasn't prepared for that situation or at least never tested in that situation.
/Short version: Was a DirectX wrapper thing
I gotta fix this POS tree asap. I'm gonna kill this fu*king thing!
I had the palette set to no brights, goddmanit!
This should be a meme or something
I'm drafting court papers against mtPaint right now. No brights was loaded in the palette. FRAUD.
Everyone Take A Deep Breath...
Ok, the tree has been DEALT with. The evil brights are gone and the tree now displays in Dx9 Mark V as intended:
Directx9 Alice Quake Map
There is also a womans shoe model in an bubble with alpha applied and it seems to display as well. There is still a visible transparent layer across the models that does appear in the 1.99 release however.
Thank you @Baker and everyone.
I'm going to celebrate now with the mixing of chocolate and milk...
^Does NOT appear in 1.99 I should say^
Just say "there is small rendering glitch in Mark V DX9 in one area and I'm told that it will be looked into and fixed in the engine if it can be".
If I can fix it, it'll get addressed. I wouldn't stop the show because of that.
Mark V - Version 1.99 - Revision 4 (Final)
Download: Windows - DirectX | WinQuake
Download: Linux GL | Linux WinQuake
* Sky entity support (redfield)
* Alpha masked models w/fullbrights fixed in DX9 (redfield)
* Ctrl/Shift bind firing/console if on server (gunter)
* Linux "Cache LRU link_active" fix (Dr. Dumb*uck)
Also available are a couple of alternative/requested builds: extra builds
Just related a note, (as I've reported before) my func_illusionary guy with his fullbright pixels still isn't transparent unless I set gl_fullbrights 0. The same goes for weapon models except the axe when I have a ring (unless custom weapon textures are used, which contain no fullbright pixels).
Now, a fun story!
Oh my gosh.... I just went on a very frustrating adventure to try and make one point... and ended up with several points to make.
So to do this, I decided to try out Mark V's "install" command for map pack from Quaddicted. I've never messed with this feature before.
I tried "install qump" then I went to Single Player, New Game (because Mark V's "map guessing" feature is supposed to make that work)... but... it didn't start Qump.
So I looked at how it was installed, and I see that everything was put directly into the id1 folder....
So I checked the Qump readme, which explained that everything should be installed to a Qump folder.... But I scanned down and saw that the first map was titled "Beginning" (by PRITCHARD!), so I tried "changelevel beginning" -- map not found.
So I looked in the id1/maps folder and saw all the maps were actually named qump_[something], but there was no qump_beginning.... but I saw a "start.bsp" which had been installed.... Ok, that must be it, BUT because of unpacked files not taking preference, doing "changelevel start" will not go to that map!
Ok, so let's start over. I do "uninstall qump" ... NOPE! Mark V tells me the qump folder does not exist.... But.. you just INSTALLED it that way! argh!!!
Ok, I MANUALLY delete all the files that Mark V installed, using the list it told me in console. Handy.
And I notice that it overwrote my id1 start.lit file with qump's start.lit file.... *grumble* So I'll have to replace that with the correct lit file later.
Now, I remember people saying something about specifying a gamedir to install things to with the "install" command, but the HELP info for "install" doesn't tell me how to do that....
Soo.... I just guessed it would be something like "install qump qump".... buuuut that doesn't work, and produces an error message that I find unhelpful:
Need the game to install or the entire URL with
the http:// in it
Example: install travail or install [http://URL]
The version of libcurl used does not support
https:// at this time
So I give up on that and come to the conclusion that I dislike the install feature and will just install everything manually from now on!
I noticed when removing files that the qump.zip file has been downloaded to a id1\_library folder, so I just unzip that and it already contains the Qump folder, making it very simple to install correctly.
Next I switch to the qump game dir and start a New Single Player game, and I'm in the qump start map (because it's correctly named start.bsp, making map guessing completely unnecessary).
So am I happy now? Nope! I finally got to the (only) issue which I started out wanting to illustrate: Mark V does not play the background music for this single-player release from Quaddicted because it's in OGG format!! XD
So I started up DirectQ (mh's engine!) since I knew it supports both MP3 and OGG (with preference for MP3) and did "game qump," and to my surprise it automatically tried to exec an autoexec.cfg file in the qump gamedir!! Which is now the third issue I have previously argued for in Mark V, which mh has strongly argued against, which I have later found to already be incorporated into his own quake engine!
So let me just go through this checklist:
[continued in next post, because I write more than 5000 characters!]
So let me just go through this checklist:
1. Failed at correctly installing with the "install" command (and overwrote one of my lit files), and I couldn't find in-game help info to tell me how to do it correctly. So I had to install manually by just extracting the zip file, as usual.
2. The "map guessing" feature failed to help whatsoever, because in the first situation the start.bsp was installed to the id1 folder, and Mark V gives preference to the pak files (yeah, that's the Quake default, but it shouldn't be, because if someone has copied new files, like this new start.bsp, that should obviously take priority -- I guess that's issue 2.5). Then, once I installed qump correctly, the "map guessing" feature was pointless because the map pack correctly has its own start.bsp... and even if it didnt, I could have used the Levels menu to select a map.
3. Mark V does not play the background track because it's in OGG format, even though (on my system) Mark V can easily play OGG -- it's just hard-coded to only see MP3 files.
4. If I had set up my own cfg files in the Qump directory with any special configurations I want for Qump, Mark V would not run those for me when I switch to the Qump game folder....
Compare this to DirectQ, which is old and no longer being developed:
1. No difference in the first step -- I have to install the qump folder mahually. But since I know I have to do this, I wouldn't have to go through that annoying experience I had trying to use Mark V's install command!
2.5 Even if I had installed incorrectly into the id1 folder, DirectQ would have handled it correctly because it gives preference to unpacked files!
3. DirectQ automatically plays the background music because it hasn't been hard-coded to ignore OGG files.
4. DirectQ automatically runs the autoexec.cfg file in the qump folder when I switch to that gamedir (just the autoexec, not quake.rc), so any settings I want to use for qump will be automatically applied, as they should be.
Now, I'm not actually considering switching to DirectQ, but damn, it did EVERYTHING better in this example!! And each of these issues are things I have strongly argued for in Mark V. And ironically, every one of these things are things that mh has argued with me about, taking the opposite position! Well, not specifically on the "map guessing" feature -- I don't think he's said anything about that, but DirectQ also has a map selecting menu like Mark V does (which is the most correct option for starting custom maps).
mh may suggest that he made mistakes by including those features in DirectQ (he's done that before: #1640 ), but I'm serious here: mh, don't sell yourself short -- these features I've just encountered were great additions to DirectQ, because they "just work" and make things easier for the user without getting in the way or causing problems.
Now, back to the only point I was trying to make when I began this ordeal: some single-player map packs at Quadiccted contain the soundtracks in OGG format (as that was a pretty commonly-used soundtrack format for Quake engines), and Mark V, even though it could easily play them (though not on every platform, I understand), will not do so because you basically won't allow it to look for OGG files.... So... Mark V is (intentionally, in this case) not compatible with maps packs like the following, which contain OGG soundtracks, ranging from 1, 4, up to 11 songs:
These are just the ones I found when specifically looking.... Are there more? I would expect so.
You've said compatibility with single-player releases from Quaddicted if one of the main goals of Mark V, so why deny compatibility to the platforms (like Windows) which are easily capable of playing OGG if you would simply allow it to do so?
And oh yeah, all those other issues which I have argued for in the past, which just happened to come up when I was testing this example:
- No "map guessing" -- it causes me problems in addition to not working or not being needed.
- Unpacked file preference -- if a user installs unpacked files, those are obviously what he wants to use rather than the defaults stored in a pak.
- Exec autoexec.cfg when changing game dir -- if a user has an autoexec in a game dir, he obviously wants it to auto... exec it for that game.
Well, that was fun! XD
Are you sure you are using the most recent version of Mark V?
There's no way current Mark V would install/unpack qump to anything except its own folder.
Johnny Law and I used qump as one of the test subjects for getting the install unpack perfected.
Ah, you're right about that; I have a separate test folder and didn't copy the today's newest Mark V there before testing. I was using 1.98.
I'm testing again with 1.99 annnd... it installed correctly to a qump folder.
Johnny, since you are familliar with a lot of the map packs, do you know of any others besides the 4 I mentioned that come with OGG soundtracks?
Quick comment -- I wanted to look at qump's skyboxes on the original start map. Of course, qump includes its own start.bsp, meaning it overrides the usual start.bsp (as it should).
Then I went to the Levels menu and scrolled down past Qump's "Start - Between Worlds" map, all the way to the bottom section for "Original Quake Levels," hoping Mark V would know to use the start.bsp located in the pack file if I selected it from the "Original Levels" list... but... it doesn't, and qump's start.bsp still runs.
How about forcing it to use the original levels from the pak file if they are specifically selected from that section of the Levels menu? Is that possible?
Thinks: I wonder if this same topic "over and over and over and over spam" reaches the point where moderator assistance becomes necessary? I sure hope not.
I wonder if moderators will start taking action on all the passive-aggressive posts on this site? I sure hope not, even though a lot of people around here are [edited by moderator]
What you want is possible as long as the unpacked maps are in a different gamedir (qump/maps) while the original Quake packs remains in id1.
Start the pack with -game qump, and type map ../../id1/maps/start in the console.
When running mods, it would be wise for the maps menu to add this relative path to the original maps' names.
[edited By Moderator] No Offence
i don't get that fancy shit, like automatically extraction to that given folder, the peeps are too lazy nowadays
just download the hotdamned archive, and extract it according the readme file
About the "OGG drains too much battery" issue, that can be perfectly worked around by making the engine transcode the OGG files to MP3 and saving the resulting MP3 files to the storage flash/disk drive during engine bootup. This way, when the game wants to play music the MP3 files will be there.
Optionally, the OGG files could be automatically deleted after the MP3 files are saved, to conserve storage space. I'd leave such an option turned off by default, though.
It's true. Few people will use the install command.
It's a stepping stone to full blown built-in "Quake Injector".
At this point is only needs a nice user interface inside the engine.
I want it to be very sophisticated like the Quake Injector, but I also want it to look nice and Quakey in the engine.
Maybe next "development season" I'll talk with Johnny Law and get his thoughts.
I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)
/Next time things
<--- There He Goes!
Ended up doing a final revision for redfield especially because the map uses alpha masked models (I like alpha masked models and want them to be used in Quake).
I'll be back sometime before Christmas and do split screen for sure and I'll probably check the thread every few weeks in read-only mode.
/Back around Christmas, I imagine.
I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)
Wow, sounds nice!
There He Goes
Or so he said last time. We'll see....
@mankrip, nice, that would be a really clever way to "support" OGGs on systems such as Android that can't play OGG natively. Though I'm not sure how much of a delay might occur the first time the transcoding occurred. And it wouldn't help in my situation, as I would be right back where I started, with MP3. But still, that would be a clever workaround to allow maximum compatibility for soundtracks on all platforms.
I've got a pretty thick skin so I can handle being called a "dumbf*ck." But I have never run Quake on Linux and have not tested Mark V on anything but Win7.
As far as the install command. I plan on covering that in the upcoming Mark V video. I love that feature and anything that will make it easier for people to play my maps is welcome. It's not laziness IMO. There are too many alternatives for people's attention.
Mistaken identity. There's actually an FvF player called Dr.DUMBFUCK who I told to come here and report his Linux issue, heh. #2137
But I guess you could be Dr. Dumptruck!
it wouldn't help in my situation, as I would be right back where I started, with MP3.
Then I don't see what's the problem. I don't pay attention to most posts.
Shortest version: on my WinXP netbook, loading an MP3 causes Mark V to completely freeze up for up to 20 seconds, but an OGG file of the same track loads in 1 second or less.
Then the MP3 playback needs fixing.
I've been following the thread and didn't notice that name. LOL
Mark V And Xinput
Baker, here's a note for your next session. :-)
Sometimes I play Quake through Steam in-home streaming. My controller in that case is a Steam controller that presents as an Xinput joystick + buttons. This works with Quakespasm, but not with the latest Mark V (even with the -joystick option specified).
The console says:
joystick not found — invalid joystick capabilities (6)
Reading back through some previous posts I can’t quite tell if I should have expected this to work or not. So, FYI.
Thanks for putting out that new release Baker. You are da boss. My map should be out with the release of the upcoming mapjam.
Yeah, I still have issues too. I still have to physically unplug my other controller (whether set to dinput or xinput) just to get Mark V to recognise my XBone controller. I, too, was unclear if these issues were addressed or deferred... I'm not the brightest bulb on the Christmas tree so it's nice to see I'm not the only one a little confused here. :)
[edited By Moderator] Not Sure If This A Bug, But
Let's say i'm running a background streaming video in my browser
i run MV, and in that case, the fps are locking at 60
i terminate the streaming video, the fps are upping to their max
i'm still cannot figure this shite
|1 post not shown on this page because it was spam|
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.