@gunter ... yeah z-fighting fixes suffer from the "fine tuning" problem ...

"Hey, this looks right on this map, where I am currently standing, with my specific video card, at this angle, if I don't go around and look at any more entities in the current map, ..." 

(pesky stuff) in next one:
1) Zoom: One-size fits all solution that handles specific sensitivity, fov, r_viewmodel_fov values according. dwere brought this up.

2) scr_showspeed - On-screen speed indicator, so someone wanting to speedrun a map or see how fast they can strafe jump doesn't miss JoeQuake.

2) renamed warppos to setpos for consistency with Quakespasm

3) scr_showpos -- for consistency with Quakepsasm r_pos will suggest this command. This is an on-screen indicator, not a console print one.

4) skyfog, wateralpha, slimealpha (etc) worldspawn keys ericw proposed as a standard

5) Curb stomps a couple of things in default.cfg overriding certain horrible Quake default keys, using a WASD setup for the keyboard. Only does this for default.cfg in id1/pak0.pak, does not interfere with mods that override that. 

I wonder if anyone has made a list of all instances of z-fighting in standard Quake?

There aren't all that many "major" places where it happens. It's actually pretty easy fix in QuakeC, heh, just by giving the appropriate entity a different value for either start position or end position when the map is first loaded. It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps).... 

All of this happened years ago, none of this is anything new.

http://quakeone.com/forums/quake-help/quake-clients/8030-ways-eliminate-z-fighting.html

http://quakeone.com/forums/quake-help/servers-coding/8033-breaking-up-z-fight.html

http://quakeone.com/forums/quake-mod-releases/works-progress/8064-z-fixed-quake-beta.html 

It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps)....

Depends on your tools. External .ent files doesn't need QuakeC, it's like doing -onlyents map recompile.

In Mark V do this:
1) "copy ents" ... copies the entire map entity string to the clipboard.
2) Save that as c:/quake/id1/maps/e3m3.ent
3) With the map in Mark V, type tool_inspector 1
4) Press 3 for the graphical display to show the edict #.
5) In the console type "edict 55" if the edict # is 55.

You can just find the map entity in the .ent and change numbers.

I'm only pointing out what you can do with tool_inspector in Mark V. 

Ah, that is pretty cool. Yeah, tool_inspector is a great feature -- I've found that very useful.

I didn't know about "copy ents," or really ent files in general. That seems like it would be a nice solution for engines that support it... but in practice it doesn't seem to work.

Looks like the ent information doesn't really contain ALL the information for the ent, and I can't seem to change an origin of a door using the ent file, even if I add a line for it. I know setting an origin can be tricky....


Hm, it looks like "copy ent" loads the information directly from the bsp (ignoring any changes I've made from the progs), and the ent file stuff is only applied if there's a difference between it and what's in the original bsp. And that happens after any progs changes have been applied (overriding any changes I make with QuakeC).

Also, having a blank ent file (as I first crated when testing) will prevent you from loading a level, heh, because "Host_Error: SV_ModelIndex: model progs/player.mdl not precached" 

An .ent file is just to replace the entity text in a .bsp (without recompiling the .bsp without doing -onlyents, which would replace that text).

Open a .bsp in a text editor, go to very near the bottom, that's the entity information.

It won't exactly match the output of the "edicts" or "edict x" command because some of the edict entity information is filled in at run-time.

An example is modelindex. The .bsp (the map) has no idea what that will be, because a map have idea what progs.dat will be running, etc., etc.

But some fields will be exactly the same much of the time, like "spawnflags". A monster's origin if stationary, door information, etc. 

Next will have:
1) Texture gamma option, change it on-the-fly. Uses no cpu/gpu. Should work on gunter's old video card. The no cpu usage/cpu usage thing was the appeal.

2) Gun positioning cvar r_viewmodel_scale. Similar to ezQuake/FuhQuake Can move the gun forward and more prominent.

3) Automatic 2D console/status bar scaling -- Small | Medium | Large or off and use the different FitzQuake cvars.

Change resolution and it will use the best non-jaggies combination of settings based on your preference. 

And "ProQuake" centerprint option --- which is just the same place that original Quake did centerprint. scr_winquake 1 to turn it on. Also sets the scoreboard at the top of the screen.

Mostly doing this because next update could be the last one for a very long time. 

Might add:

if (scr_center_lines <= 4)
..... y = vid.height * 0.35;
.. else
..... y = 48;

Is the original Quake code. And quite terrible, really.

So if less than 4 lines of text, sort of center it on the screen (sort of). If more than 4 lines, do it way up near the top.

So if the resolution gets really high, that discrepancy in positioning will get very large between the positioning of a 4-line centerprint vs. a 1-liner.

It is what it is.

I basically prefer the FitzQuake way provided the text is ensured to be above the crosshair.

/But then you have compatibility ... and I get that too. Hence, upcoming option I don't entirely like to begin with. 

What seems obvious is that the intention of that code is to fit a 320x200 display. Original releases of GLQuake scaled the menus, console, sbar, etc to 320x200 via glOrtho.

What seems deeply fucking odd is that the very same code survived through software Quake, GLQuake, QuakeWorld, Quake 2 and presumably Hexen 2 although I don't have a copy of it's source handy for cross-checking.

I stand by saying that the stated intention of centerprints is for important messages that the player needs to be pay attention to and that obstructing your view is the correct and desired behaviour.

Something like y = (vid.height * 0.35) - (scr_center_lines * 4) seems a better compromise to me. 

@mh - Mark V uses a formula not too different than that. 

It's really not as terrible as one might first think. It actually provides a great deal of control over the positioning of the centerprint (as I previously mentioned).

Also, it does seem worse when you use standard winquake or glquake (or proquake) in very large resolutions where the text gets teeny tiny, so the positioning is affected quite a bit, BUT this is not a problem with the centerprint positioning -- it's a problem with the text size, and Mark V lets us scale the text size up regardless of screen resolution, so the weirdness of positioning of teeny tiny text is really not an issue -- at least not for anyone who scales the text size up to something more reasonable/standard-looking.

Speaking of teeny-tiny text, I tried out the tool_texturepointer thing, and it does not scale the text up along with my other text, so it remains teeny tiny and hard to read in large resolutions.


Anyway, thanks so much for providing the option to use Quake's standard centerprint positioning. This ensures compatibility so that the text will appear as the modders intended (as they saw it in Quake), with pretty much every Quake mod (and standard Quake itself) -- assuming the user's text size is also scaled to a more "normal-looking" setting for Quake


Ya know, I don't think id designed Quake to only run in 320 x 200 -- that's just the minimum supported resolution. And text size is pretty unwieldy at that resolution (not to mention the console is too large); you can hardly tell the difference in the position of 4 or 5 line centerprints when in 320x200. I highly doubt they never tested it in the higher resolutions; they didn't just accidentally position the centerprints the way they did because they neglected to test in anything but 320x200.... 

I'm pretty certain that it wasn't exclusively designed around 320x200... Although conback.lmp is 320x200 so you sure can't make assumptions.....

Nonetheless, I'm also pretty sure that there are huge chunks of the engine that were designed around hardware constraints of the time. The whole zone/cache/hunk thing in the memory manager, for example, is so obviously designed around "must run in 8mb memory". 

Just found this on my hard drive. Dated 2 minutes ago. It is an interesting screen shot.

4-player split screen

.... 

Need tbh. Gonna play some DM with my buddies!

Will it have multi pad support somehow? 

I don't at the moment have a plan for input, that's the hitch.

Maybe within the next week or two after thinking things over, I can come up with a plan for input. 

Boring stuff: next version will clear any aliases send via stuffcmd to the client upon disconnect.

Posting a 2nd screen shot of 4-player:

4-Player Shot #2 

cool stuff! did it require a lot of code changes? 

You could do like Blaster Disaster and support two people on the keyboard, one person on a multi-button mouse, and one person on a joystick/gamepad.

Downsides: keyboard players would be stuck with oldschool no mouselook. All players would probably only be able to change weapons via cycling up or down except for maybe one of the keyboard players. Mouse player might need to steel a couple keys for strafing (laptop users would definitely be crowded). 

Boring stuff: sv_gameplayfix_setmodelrealbox for Quake Rally or other old mods that need original Quake bugged setmodel.
------------

I've got a video of the four-player uploading now. Sadly, the video is 1 GB and it says 1 hour, 17 minutes remaining on the YouTube upload.

@ericw -- I went full retard. Never go full retard. I literally posted the screenshot 2 minutes after I got the prototype working.

------------
With any luck, the new version will out today or tomorrow. 

Just opened up ol Blaster Disaster and it let you have up to 8 players:3 keyboard, 1 mouse, 4 joysticks. 

@qmaster - I'll solve the input solution with some thought. Spike, R00k and myself have had numerous conversation about FTE split-screen in the past. 

Wow, that's pretty cool.

I think you will definitely need joystick/gamepad support for that to be usable.

Perhaps the simplest thing to get it working at first, may just be to have one joystick configuration (button 1 = jump, button 2 = fire, etc., however the user sets it up), and just copy that behavior for gamepad 1, 2, 3, and 4, with each gamepad sending its input to player 1, 2, 3, 4.

Otherwise each gamepad will need to be configured separately. Which would probably be ideal in the long run, but just having one configuration for joystick input may be easier just to get it working.

Keyboard input should probably always be for player 1 (the one in control of the computer, which would often be the "server," in effect). Hm, but I hope it be able to connect all the extra players to an online server too....


But I'm already imagining hooking my netbook to the large TV screen and playing couch-coop splitscreen Quake! I have plenty of PS3 gamepads (which are basically just USB gamepads in Windows). 

There's a video I posted in the General Abuse thread. Read the names of the players in the scoreboard.