News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00
http://quakeone.com/markv/

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
@mh 
It's all good. I thought I'd ask.

(@fifth: eta = very murky. I will promise that it will happen at some point. Maybe spring. It's important to me.)

/Yeah, I know joystick in Quake isn't DirectInput but multimedia. 
 
The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one.

Done.

I just need to sanity-check my bottom-left-is-origin to top-left-is-origin conversion, but otherwise - done.

An interesting FitzQuake bug arose while doing this, that's specific to a GL vs D3D difference.

In GL the current viewport doesn't affect glClear calls.

In D3D the current viewport does affect IDirect3DDevice9::Clear calls.

So in other words, in D3D the clear is bounded to the viewport dimensions.

This came up because FQ sets a smaller viewport to draw the warp images, but doesn't unset it before clearing; that small viewport is therefore the only cleared region. A "GL_SetCanvas (CANVAS_DEFAULT)" was needed in R_Clear to work around this. You could probably also put it in R_UpdateWarpTextures.

This wouldn't affect D3D10+ where the clear is done directly on a render target view, and I have no idea if it affects D3D8-. 
 
Odd what MH is saying, you had a video with multiple clients and splitscreen?

I don't have much choice but to wait... us non-coder guys are at the mercy of whatever you guys decide tbh. :P 
Mark V Build 1011 - Temp Build 
pulsar - this doesn't have func_illusionary mirrors. I'm putting that in separate 1012 build in case I messed up something ...

Build 1011 - Windows only GL|DX8|WinQuake

Everything except func_illusionary mirrors, in case func_illusionary mirrors explode something.

@fifth - I multitask extremely poorly. Can't get into deep discussion with MH about that without jeopardizing what I'm doing now. If I mess up 1 line of code ... you get the point. 
 
I also multitask poorly but am less disciplined about it, so I'm heavily dependent on people just backing off. :) 
@mh 
Yeah, ...

This func_illusionary mirrors thing is cool, but has several points of modification. Don't want to unleash an exploding build.

/Ok .. concentration time ... 
Vsync 
Implemented WGL_EXT_swap_control - vsync no longer needs a mode change and works perfectly. 
 
Hah... it's cool guys, I'm probably one of the few people in the community that is even bothered about that stuff.

If I had it my way every classic 90's shooter with multiplayer would have splitscreen in it ;) 
 
Do you have any plans to allow for a custom crosshair graphic when crosshair = 2? 
 
So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist. 
@pulsar 
@pulsar - carry on knowing the feature will exist in a few hours ;-)

I'm slowboating a little because I noticed some scenarios I didn't consider and uncovered what might explain why all my attempts at adding alpha masked textures in the software renderer failed while looking through the mirror code, which doesn't matter right now but has me slightly annoyed at myself.

So I'm walking through the several pieces to make sure I didn't make any mistakes. 
@c0burn 
Already supported for crosshair 1, but I sense you may know that since you said crosshair 2.

Crosshair 1 is gfx/crosshairs/default.tga, which I am thinking is the same as DarkPlaces, but I can't really remember and I know DarkPlaces supports many crosshairs.

I never anticipated a reason that someone would want to substitute for the dot crosshair, but I am guessing you have a scenario in mind like an alternate gun crosshair or something?

/If you have a good scenario, I'll put it the eventual to-do list because I suspect even 2 crosshairs would not suffice. As soon I get pulsar func_illusionary mirrors ironed out, Mark V version 1.1 is wrapped and I plan on taking a break for a few weeks (I'm kinda burnt out). 
@gunter 
So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist.


Could you identify which ones? I thought I got them all, but maybe not? 
@c0burn - Extra Thought 
Is it just a 2nd crosshair for a gun?

If you tell me what DarkPlaces expects the replacement texture name to be, I'll see if I can add an alternate crosshair 2 to version 1.1

And I'll change the dot crosshair to be crosshair -1 (or something). 
 
Like version 1.1 is the one I'm wrapping up now. 
 
#274 above -- what should be blue particle splashes sometimes come out as orange sparks (watch the splash.dem in the zip I linked to).

Even when they are not sparks, the blue QMB particles just appear then vanish without moving outward, as they do with QMB disabled.


The other issue wasn't really about particles, but about how an effect trail thinks it started where the last one ended if you are near that position; screenshots in #414 above. I found this quirk also happens with the rocket launcher trail, but it's faster moving and harder to reproduce. Try shooting a wall (like the one in the position of the screenshots), then move next to the wall and fire your next rocket, with the point of impact of the previous rocket still in your view. The rocket trail will originate from the previous impact point. Same with the trails from lava balls and knight spikes. 
 
1) The QMB trails. Yeah, those sometimes they get confused. Inherited from the JoeQuake implementation. At some future date I'll fix that. It is hard to reproduce, annoys me too. It is more frequent with non-Microsoft compiler (Mac version has it happen more often).

So could be the compiler doing it. On longer term list.

2) Blue particles become orange ... yeah, I hear you. Likely similar issue to #1. Also I noticed Shambler charge up has slight checkerboarding and doesn't in JoeQuake -- tried to unearth the reason, couldn't figure it out.

Those little nuisances will dealt with at a future, but I think I inherited from JoeQuake implementation or compiler related or compiler optimization.

My mana bar is too low for me to take that on right now. 
 
The shambler thing doesn't actually look bad....


Wow, super ugly effect in DX with:

vid_hardwaregamma 0
chase_mode 2
chase_active 1

and swing the camera outside the wall. Doesn't occur in GL.

gl_clear 1 fixes it.

Is there any reason why someone would want gl_clear 0 [default]? 
@c0burn - 4 Crosshair Support In Mark V 1.1 
Decided to add support for multiple replacement crosshair textures.

Dot crosshair (currently crosshair 2), will become crosshair -1.

@gunter - gl_clear 0 is faster and you don't have to redraw the status bar every frame (if the status bar is solid like original Quake and not transparent or see through). 
 
Replacement crosshair texture names will be named

gfx/crosshairs/crosshair_1.tga
gfx/crosshairs/crosshair_2.tga
gfx/crosshairs/crosshair_3.tga
gfx/crosshairs/crosshair_4.tga

Expected 32 x 32 texture with alpha channel.

A JoeQuake/ezQuake/Qrack crosshair is likely to work if it is a .tga

I named the texture names slightly different than DarkPlaces which doesn't have the underscore, because I don't know what rules/sizes DarkPlaces expects for a crosshair texture and it may suppport things like huge sizes, which I would not be willing to do. 
 
Is "gl_clear 0 is faster" just academic at this point, on modern hardware? Even on my ancient netbook, I can't tell any difference in performance. 
 
Yeah, gl_clear 0 is rather academic usually.

@gunter - I may have fixed the QMB trails being jumpy. Maybe. Looks good so far.

Crosshairs in next version

Changed my mind. Per weapon crosshairs so if someone makes a single player release with a weapon they want special crosshair available, automatically takes effect.

Like if someone were to make a crossbow (Drake), could use custom crosshair for that weapon.

Crosshair details

// Yes, sadly it appears 24 weapons are possible. Quoth plasma gun is 24, as far as I can tell.

gfx/crosshairs/weapon_1.tga to
gfx/crosshairs/weapon_24.tga

gfx/crosshairs/default.tga // user's crosshair

scr_weapon_crosshair - defaults on. Use a single player release's crosshairs. Set to 0 to not use them.

crosshair 0,1,2 from previous builds continue to work as-is.

I've seen some mods that do stuffcmd ("crosshair 4") and it's just bad design. What the mod typically wants is per weapon crosshair anyway.

This will let single player releases provide crosshairs for crossbows (Drake) or even a empty texture for axe (no crosshair) or maybe a funky one for a high tech weapon. 
Mark V - Build 1013 (Temp Build) 
Build 1013 - Windows Open GL | DX8 | WinQuake

1) QMB trails being jumpy possibly fixed (gunter)
2) Per weapon crosshairs replacement texture support (c0burn)

scr_weapon_crosshair, defaults on -- allows single player releases to provide per weapon crosshairs. So if a mod has a crossbow like Drake (A Roman Wilderness of Pain, Something Wicked and a few others right?) or a high tech weapon and wants a special crosshair, it can do that.

User can set scr_weapon_crosshair 0 to not use the single player release's crosshair and just use normal crosshair. Player can still use gfx/crosshairs/default.tga to have a texture replaced crosshair.

Still tuning func_illusionary mirrors -- func_illusionary mirrors is not in the above build. 
@gunter - Re:splash.dem 
Another fine catch.

When I rewrote QMB particles, I missed something. Should be able to make the behavior proper. 
 
If you are using using TE_GUNSHOT as a particle effect in splash1.dem, QMB modifies that into an effect. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.