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? 

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. 

...I have a bug named after me *blushes* 

Well how 'bout them apples, yeah it really is doing the adjustment ... missed it last time I checked. 

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) 

is a command, "conspeed" I think it is. 

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. 

Regardless, thanks for the great update :) 

Is there another way of minimizing it then? 

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

 

Quakespasm also supports this.

Mark V's video code rewrite makes ALT-ENTER a very fast operation. 

There is something weird going on with the latest release
Fitz: 0.92 exe: 02:43:35 May 24 2013
(using version command)

After a while the enemies cannot take any more damage from the player. It is like their bounding box has moved/changed. If I quicksave and quickload the problem goes away and then gradually comes back. I have only encountered this problem with my latest map. 

I did some more investigating and it is not the bounding boxes, I can see them with the r_showbbox command. It is a time based event where enemies no longer take/receive damage. After a while I can just walk through them. I can't produce a save file to show what is happening because quick save/load fixes the problem (temporarily) 

Can you capture it in a demo? 

are they still damageable (blood particles vs grey puffs)?

can you get the edict # and check what the fields look like? (maybe make a tiny hack mod where the axe does an eprint of whatever it hits) 

I have no time and sadly will have no time for amount of time that I can't determine right now.

I have about 15 minutes of "real" free-time and this isn't going to be changing soon.

I'm sorry about the bug --- real-life prevents me from having any meaningful amount of time to address this and I will continue to have no time for the future as far as I can see it --- and this is beyond my control.

Someday, I will fix --- I was trying to "go out in style with a delicious technical masterpiece" that could be feature ripped into Quakespasm easily --- I went all out, I thought I was practicing some awesome quality control and this slipped by me --- but I locked-in, I have no time and I'm not going to have any time.

And I'm sorry. I really was shooting for the moon to please to go out with a really fun bang with some incredible engine performance and flexibility.

Now I am beyond the event horizon, all paths available to me lead only towards real-life and I am far beyond the point of return to be able to work on this.

Believe me, I wasn't looking to let anyone down --- but I am no longer able to do anything about this.

Sincerely,


The Sadly Uber-Time-Restricted-Baker
That-Can't-Fix
This-Since-I-Have-No-Time-And-Wont 

seriously?

i mean seriously... 

 

Something to add to a wish list ...

* Be able to freeze a demo and then fly around the world to inspect / look at things. It would be very helpful for debug reasons to see what is happening with a demo. I don't mean change or move stuff around, just fly around and see where things (monsters/items) are. 

From what I know (unless I mix up things) Quake demos only include the entities in the PVS so a feature like that would require a whole different protocol. 

As the demo progresses the engine is updating entities with new locations, states (moving, alive, dead etc) and when the map is frozen I just want to fly around and see where all the entities are and what state they are in. Even the current PVS would be better than nothing. 

Qrack does this today and is the only engine I know of that allows this. I don't have any experience personally using the feature recently, I'm just pointing you to what can satisfy this desire today.

[I still have no time to work on Mark V and don't see this changing in the known future ... but I still care ... ] 

Daz's recent CG video revealed another Mark5 bug: playing back a demo of sock's map, many models were displayed pitch black, sometimes flashing depending on the view angle. I haven't tested it, but I could imagine the clipping and lighting issue also ccurs on other over-limit maps. 

Hey no worries on your time, I just wanted to post here some ideas if you come back to MarkV development in the future.