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. 

Hah, neat. Reposting that on the fvf forum....



Thinking more about gamepad input, due to the limited number of buttons on a gamepad as compared to a keyboard, you may need to implement a "shift" key functionality.

Example:
Pressing Button 1 alone causes you to attack.
Pressing Button 2 does nothing by itself, -- it's a "shift" key.
Pressing Button 1 while holding Button 2 causes some alternate action, like changing your gun.

That's how they did the Playstation port of Diablo.


This could be added into Mark V as a standard feature -- not just for gamepads.


Perhaps something like:

bind ctrl +attack
bind alt @shift
bind @ctrl +jump

Now the ctrl key can be used to attack, or to jump if you are holding down alt at the same time.

Yeah, it doesn't seem as useful when you could just use alt to jump, since there are plenty of other keys on the keyboard, but you could bind lots of other keys or mouse buttons to shift their behavior too, like:

bind mouse2 +moveup
bind @mouse2 +movedown
bind mouse3 (next weapon impulse)
bind @mouse3 (previous weapon impulse)


etc....

It would give more options, which would be more useful for a gamepad.

I suppose you could even add more than one "shift" key, so ctrl could be @shift and alt could be #shift or something.

Then you have even more overly-complcated things to bind!

bind ctrl @shift
bind alt #shift
bind mouse1 +attack
bind @mouse1 +jump
bind #mouse1 "say I can do 3 confusing things all with one mouse button!" 

Is pretty damn near perfect btw. 

I have all the major console controllers to test with 

Hello, first of all great job on the engine, it's definitely my favourite.
I'm playing Scourge of Armagon and Dissolution of Eternity for the first time and using the winquake executable of Mark V for the original look. I've noticed that in both expansion packs the hud icons for new weapons are not displayed properly. In Dissolution the weapon in use should have a "lava glow" and in Armagon there should be unique weapon icons. These effects are completely missing. I'm using the GOG version of the games.

Should these icons be working properly in Mark V? 

@ zbikey -- Theory ... make sure you started the command line right

cmdline: -game hipnotic -hipnotic
cmdline: -game rogue -rogue
(The -hipnotic activates the hipnotic HUD)

If you prefer to switch to the gamedir in the console instead, it is basically the same:

In console: game hipnotic -hipnotic
In console: game rogue -rogue

Let me know if that was the issue!

@fifth, when the time comes I'll definitely need your help with the gamepad support.

My first priority is getting out the new release, getting feedback on it to see if there are any outstanding issues to make sure Mark V can finally become non-beta for the first time in a few years.

Then I can confidently proceed to make split-screen a standardized feature and add controller support. 

Everything is working perfectly. Sorry, I should've looked for the solution myself, didn't think there would be a command line for this. Thanks so much! 

It's a common problem. 

It's a common problem.
The command line or the people who ask without looking first? 

Multiplayer save games working.

/Never looked at either DarkPlaces or FTE. I think DarkPlaces might have feature; FTE is known to have feature. 

 

Hm, this is a bit beyond the type of thing I usually ask for... but is it even possible to allow some kind mod-side support for drawing things transparently? Like, client-side (similar to the way you draw the viewmodel transparent when the player is invisible), even if the server isn't using a protocol that sends alpha information....

I guess the problem would be that the server doesn't send much information to each client other than like the model, location, and frame of another entity, right?

So, for example, you couldn't just draw something transparent based on a .field of an entity....

It would have to be something like a

r_transparentlist progs/wizard.mdl,progs/bolt.mdl,progs/laser.mdl

Or perhaps somehow allowing only certain frames to be transparent, like progs/wizard.mdl:5-7,


I guess that doesn't give much control with a mod, other than just stuffing the list to the clients when they connect....

What I was hoping to achieve would be transparent observers.... I suppose if I could make one certain frame of the player.mdl designated as transparent, I could just avoid using that frame during any other animation, and have observers only use that frame when they are flying around (that frame being 71, heh)....


Just brainstorming here..... 

It both can and cannot be done.

FitzQuake protocol 666 supports .alpha on entities.

Do this:
1) Start E1M1
2) Console type: copy ents
3) Open text editor, paste it. Save as c:quakeid1mapse1m1.ent
4) Add this at bottom of e1m1.ent text file, then save again.
{
"classname" "func_illusionary"
"model" "progs/player.mdl"
"origin" "430 574 24"
"alpha" "0.5"
}
5) Load E1M1. You will see what I am talking about.

So it can be done automatically with FitzQuake protocol 666.

FitzQuake 0.85 obv, Quakespasm, Mark V, Qrack, Super8, FTE all support FitzQuake 666 protocol.

DarkPlaces doesn't. ProQuake doesn't. Those clients would not be able to connect, but both of those are by far the 2 most likely clients someone connecting to your server would be using.

If you were to run FitzQuake 666 protocol, this would mean you would need to run something different as your server executable (couldn't be ProQuake, no .alpha support).

In addition, if you were to use something non-ProQuake as the server, if you use qccx hacks to mask ip addresses that stuff would have to be stripped out your QuakeC source because it depends on fixed memory structures/memory addresses that only an adamantly retro-compatible engine like ProQuake can possibly support.