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

Awesome gunter! Glad to see you solved the mystery.

I turned over every rock and was striking out. 

@NightFright

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.
Cons: None?

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.

http://www.quaketastic.com/files/models/redfield_model.zip

Thing was a bitch to make, so its nice that newest builds of all the engines (DP untested as yet) can display it properly. 

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 skin has fullbright pixels in it.

If you do "imagedump" and look at the fullbright skin generated ...

http://quakeone.com/markv/media/autumntree_fullbright_pixels.png

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. 

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
https://i.imgur.com/mnSnXW1.jpg

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