News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
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/fitzquake_mark_v.zip

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).
First | Previous | Next | Last
@gunter - Re:scoreboard 
FitzQuake is pretty much geared to display the multiplayer scoreboard in the center of the screen, as you've noticed. Just like how the menu is very center of the screen in FitzQuake.

A ton of centerprint like a centerprint-based menu on, say, a RuneQuake server, clashes with the FitzQuake multiplayer scoreboard worse than original Quake.

Pretty much makes the scoreboard unreadable.

I tried the Qrack draw a background behind the scoreboard (didn't look Quakey) and a few other thoughts to avoid the problem before realizing no good answer was possible -- so not drawing the text was the only option.

But notice it still does print the chat messages with the scoreboard up! ;-)

I know those are important so I salvaged what I could. 
 
"Centerprint consistency has always sucked as tool available to the QuakeC modder"

Yep, that's pretty much it.

I can move centerprints DOWN out of the way by padding it with nnnn, but I have to be careful with that, because I could move it right off the bottom of the screen depending on resolution and text size settings of the client....

But there's no way to move it UP out of the way... which is why I greatly prefer them to be placed high on the screen by default, like Proquake does. There's no danger that they will be TOO HIGH, no matter what the client settings.

Since I can move things down but not up, I think it would be great if all centerprints were positioned like 4 text lines down from the top of the screen, no matter what (even for one-line centerprints). There's really no reason for them to be centered vertically anyway.... As I have said, it can block part of what you are trying to look at, leaving all that all that unused free space (resolution and text size permitting) near the top of the screen which could be used instead.

Of course, not all clients do it that way, but Proquake was "the standard" for many years, and that's how it works (I would suspect for the reason I mentioned, as Proquake is supposed to have enhancements for deathmatch play, and not having your view blocked by text is good when in deathmatches).

But yeah, not all clients do it like that....

All these variations in different clients is also a reason why I name Mark V as the "officially recommended" client for FvF -- if I get the majority of players using the same client to play FvF, then I know they are seeing the same thing that I see.


Anyway, my main point would be: There is really no reason centerprints need to be vertically centered. It has potential negative impact, whereas putting it higher on the screen (like at a set position of "4 text lines from the top") has no negative impact. 
 
There actually is a reason, it's in the Quake manual:

Certain messages appear inconveniently in the middle of your view. These are always important, and you do not want to ignore them! 
 
And ironically, the manual also states that messages that appear on the top of the screen are non-critical, ignore them if you please. That includes chat. 
 
Whaaaaat?

*goes and finds Quake manual to check*

Well, I'll be damned... it does say those things.

Funny that id intentionally made centerprints "inconveniently" located to make sure the noobs read them, heh. But I think at this point they are no longer "always important," sooo.... they don't really need to be inconveniently in the middle of your view anymore :D 
 
I'm not certain that I agree with this way of thinking about it.

What you're basically doing is taking a default feature of Quake, using it for a purpose for which it's not intended, then asking for it's default behaviour to be changed in a way that would suit that unintended purpose but at the expense of it's actual intended purpose.

That's the kind of thinking that led to the horrific collections of hacks that polluted Quake engines and mods years ago, and which culminated in Nehahra. It would be a lot more productive to open a dialog about creating a new message type that would suit your requirement. It's 2016, we understand things better now, and we don't have to rely on ugly hacks to get stuff done any more. 
I'm Inclined To Agree With MH, 
not particularly for the reasons he mentioned, though they're perfectly valid, but because there are still Quake n00bs who might still need centerprints to pop up in their faces. Just a couple days ago there was this guy at QuakeOne asking how to open the megahealth door in the water section of E1M1... 
 
Even for non-noobs, don't underestimate the extent to which one's muscle memory can be trained.

I speak from bitter experience here: For every 1 person who thinks it's good there will be 10 who want it back the way it was. 
 
there will be 10 who want it back the way it was.
Good point. I know very well the flak Darkplaces or HD textures can get around here... because "it's not Quake, hurr". 
 
I think you should learn to properly parse people's arguments against the things you like, instead of simply disregarding them as "something stupid, hurr". 
 
I heard their arguments. I don't agree with them and I don't dismiss their tastes either, unlike the other way around. Anyway, that's not the point. The point is the Fitz family of engines is more geared towards conservative Quakers. Therefore, changing things too much might not be a good idea. 
 
I think you should learn to properly parse people's arguments against the things you like, instead of simply disregarding them as "something stupid, hurr".

Nope, way to miss the point.

Whether one likes it or not is irrelevant. I've been here before. You do a nice particle system and the first thing people will ask you is "how do I get the old one back?" You do a nice HUD and the first thing people will ask you is "how do I get the old one back?"

This is something that really does happen. 
 
Uh-huh, except in this particular case we were talking about a very specific conversation where people actually managed to make sound arguments when they weren't too busy throwing insults around. 
 
My discussion with Gunter wasn't a philosophical one. It's an aesthetic one. When I was looking to solve the centerprint issue, I experimented with several different ways and loaded up about every engine including DarkPlaces to assess options.

Centerprint in the ProQuake position makes it so ...

1) it looks really silly when you go to the menu and have white text sitting above the menu.
2) looks silly when you press TAB to see the multiplayer scoreboard and have white center print above the scoreboard.

So to avoid that I'd have to move ...
1) The menu
2) The scoreboard
3) Other stuff

And it would no longer look like FitzQuake. 
 
I am sympathetic to the issue of centerprinting positioning, by the way.

I've worked on mods that have used centerprinting (RQuake, xCTF, Team DM) and centerprinting positioning has always been a thorny thing.

And there are some classic single player mods that use a lot of centerprinting (see Quake Terminus mod list or Frika's Q-Pacman).

I went out of my way to get Mark V to handle centerprinting consistently and tested a lot of different stuff to make sure it looked great, even with mods that have centerprint menus.

But the ProQuake position for a FitzQuake engine is a case where the cure is worse than the disease.

/Maybe at some point some sort idea for a viable solution will emerge. 
 
Couldn't you solve the overlap issues by hiding centerprints when one of the conflicting menus is visible? They do show up in the console as well if I'm not mistaken so if a player missed one it wouldn't be the end of the world. 
 
Stock GLQuake doesn't draw centerprints if the menus are visible; look in SCR_CheckDrawCenterString for a check for (key_dest != key_game); engines that change this are also changing the behaviour from stock GLQuake.

So overlap issues are actually not something that occurs unless someone has explicitly modified the engine code to make them occur. 
 
Ah, so it's the other engines (rather than original GLquake) that do it differently in regard to hiding centerprints when menus are open. I'm mostly fine with that functionality; my only concern was that a centerprint may go unnoticed if someone is staring at the scoreboard. But still, I don't hate that behavior.

My main concern is the positioning of centerprint on the screen. So to address things people said in regard to that (assuming that's what they're talking about):

"What you're basically doing is taking a default feature of Quake, using it for a purpose for which it's not intended, "

What? The purpose of centerprint is to deliver information to the player. That's it. And that's what all Quake mods use it for.... Maybe the information is above and beyond what id originally thought of (like an underwater air meter, for example), but it's still just delivering information to the player. Indeed, centerprint is heavily used in every Quake mod I can think of to deliver information to the players (it's pretty much THE tool we have to do so -- console prints are very quickly swallowed up if a lot of things are happening). But it can have negative issues, as I've mentioned.

Yes, the original resolution of Quake was tiny, so there really was practically no choice but to have centerprints right in the middle of the screen, but now we can run Quake in all kinds of resolutions, and we have MUCH more screen space available, so there is no reason it still needs to be in an area that blocks potentially important areas of the view.

It's not as if text popping up closer the top of the screen is going to go unnoticed by noobs -- UNLESS they are in the middle of a battle, in which case, again, it it detrimental to have text blocking their view when they are trying to aim!

This has nothing to do with muscle memory (I guess you didn't mean that literally...), and it doesn't make any radical changes like a new HUD or particle system -- it's just more optimal positioning of text in the available screen space. Yes, if you make changes that cause things to "not look like Quake" then people will complain. However, I wager NOT A SINGLE PERSON has ever complained about ProQuake's better (IMO) centerprint positioning, and ProQuake was "the standard" for many years....


Perhaps the most ideal solution would be a setting that would control centerprint positioning -- placing it either centered in the screen, or just sticking it about 4 lines from the top of the screen. But I really doubt anyone would prefer to potentially have it blocking their aiming rather than up near the top, out of the way....


Again, I'm not sure everyone is talking about the same issue (hiding centerprints when the scoreboard is up is fine) -- I'm only referring to the vertical positioning of the centerprint text on the screen. This really does not reach the same level of new HUDs or particle systems that alter the look and feel of Quake substantially.

Of course, I do like "rounded" particles rather than the giant square pixels in old software Quake, heh. 
 
Hahaha... ok... REVELATIONS.

I decided to go and look for myself in the original (that's DOS Quake.exe 1.08 and original GlQuake whatever version it was) executables to see for myself....

So you can basically forget all my well-thought-out and valid arguments for why ProQuake's centerprint positioning should be used. My new argument is:

"You've changed Quake's default behavior!! I don't like it!! Change it back right now!! Too many changes are a bad thing!!!!!1"

Yep, that's right, original Quake's centerprint positioning is IDENTICAL to ProQuake's!

...as you can see in this screenshot of original DOS Quake in all its pixely glory at maximum resolution of 800x600:

http://imgur.com/a/Ps11o


It's also identical in that if the centerprint is 3 lines or fewer, it starts more toward the center of the screen, but if it's more lines than that, it appears up near the top of the screen.

Also, you can see that the scoreboard is stuck up near the top of the screen, just like those ProQuake screenshots I provided earlier (and the centerprint text is still visible when scoreboard is up, but not when the Menu is up -- is that what people were talking about?)


Actually, again, I don't hate that centerprints are hidden when the scoreboard is up, but I don't love it either....

And don't actually forget all my previous arguments, heh; they are still completely valid! I still would prefer ALL centerprints, even those of 3 lines or fewer, to be positioned closer to the top of the screen... But I think I can perhaps force that to happen by padding the bottom with empty lines... hm, I'll have to test that.

But yeah, scoreboard and centerprint positions should be just like in ProQuake, which is just like in original Quake, because:

1. It is more optimal for all the reasons I have mentioned about obscuring the important part of the view,

and:

2. OMG, you changed Quake's default behavir and I don't like it and youneed to fix it right nao!!!1!!


:D 
 
Has Gunter won the centerprint wars?
Tune in later to find out!
 
 
A new version is going to be out in the 24-48 hours. 15 changes. Includes DarkPlaces/FTE-like "apropos" ability, which every engine should have.

/Wish had time to fix NightFright's Malice "knockback effect" issue, since he did so much mod compatability testing/bug resolution verification. AAA+++ beta tester.

/So is Gunter/Fifth/Spy/OTP/Pulsar and so many others. Gunter may argue too hard at times, but he sure tests stuff great ;-) 
 
I argue hard, I bug-test hard!


Nice! New update.

...

What is "apropos" stuff?


Here's a quickie "bug" I just encountered. I was trying to type "%complete" and it came out as "100omplete" because apparently %c is a macro for my remaining Cells.... And I guess there are many more such macros. There should be a much more rare macro indicator, like %% instead of just %, perhaps.

I'm preparing a 50-page powerpoint presentation to support my position on this.... I'll post it later! 
Apropos Xxxxx 
is a console command that lists all cvars containing xxxxx.

ex: apropos particles 
I Lied 
Malice is fixed too. 
Apropos Apropos 
As some of you may know, I'm French and "� propos" means "about" in french. Why not have settled on an About command instead? I mean usually, all command names are in english... 
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.