qbismSuper8 builds

[ceriux]

working on a sin-city like palette. this is a wip.

http://imgur.com/a/bnJOU/all

looks cool reminds me of classic gameboy + red xD but yeah the black spots do make it look like it might be hard to see at times.

[qbism]

Build 162 is released. This version completes the cvar help strings. It also fixes (I think) an infrequent crash in the threading dll during waterwarp. Because the crash occured inside the mingw pthread dll, the debugger couldn't give an exact line for the crash. I had some static variables defined in the waterwarp thread loop function which may have been the problem.

Installer or zip: http://sourceforge.net/projects/qbism/f ... rce=navbar

[dreadlorde]

Looks good, dread. Maybe try getting a few brighter highlights in there - lighten the top range a little more. I'd also suggest adding some noise to the palette to get some 'grit' into solid color areas, especially solid black.

yeah, i did that in a new version. i'll try to get some shots up soon.

[revelator]

oh god i hate thread library debugging

[mankrip]

Build 162 is released.

I'm getting the same "crazy spinning" error that I just got in Engoo. Hmm... this is also happening in Makaqu.
I guess it's related either to Windows 7, or to the Synergy+ service I'm running.

The video aspect of the 2D renderer is wrong when using 4:3 resolutions. Seems like you hardcoded it for widescreen only.

And there's too much of the viewmodel appearing on the screen. Seems like either the viewmodel is too high, or the camera is too low.

[qbism]

Build 162 is released.

I'm getting the same "crazy spinning" error that I just got in Engoo. Hmm... this is also happening in Makaqu.
I guess it's related either to Windows 7, or to the Synergy+ service I'm running.

The video aspect of the 2D renderer is wrong when using 4:3 resolutions. Seems like you hardcoded it for widescreen only.

And there's too much of the viewmodel appearing on the screen. Seems like either the viewmodel is too high, or the camera is too low.

Haven't seen the crazy spinning.

Aspect is not hardcoded, but is determined by the highest resolution available on the screen. Hrrm, however, it might not take into account 4:3 on a 16:9 monitor. Probably need to look into R_ViewChanged and do rescale there.

Viewmodel - 4:3 aspect on 16:9 screen, or all the time? Seems OK in 16:9 screenshots. Cvars to adjust position: scr_ofsx and scr_ofsyz.

[leileilol]

Or you could just nab the bits of Quakespasm code I stole to get hor+ working so there's proper aspect no matter what if there's 4:3, 16:9, 16:10, 18:4, 24:1...

Aspect is a very overlooked thing in Quake engines - have you seen how many 4:3 stretched 16:9 shots are in the Steam Quake gallery?


(q3 has vert- btw, wish it had hor+)

[mankrip]

Aspect is not hardcoded, but is determined by the highest resolution available on the screen. Hrrm, however, it might not take into account 4:3 on a 16:9 monitor.

My monitor is a 4:3 one.

Probably need to look into R_ViewChanged and do rescale there.

I'd really recommend to port over the video aspect code from Makaqu 1.6. I don't know how other Quake engines deal with this, but I have pretty much never seen any other solution better than what I've developed for Makaqu. Not even in any commercial game.

Makaqu's solution may seem overcomplicated, but it isn't. What happens is that other engines always overlook something and don't deal with all the possible setups.
And Makaqu's solution is actually pretty simple for the end user to configure in the menu.

[edit] By the way, there's a single very specific rare case that the aspect code in Makaqu 1.6 can't deal with, but I've not implemented a solution for it yet because it depends on completing an unmentioned rendering feature that Id Software left unfinished. It's not hard to do, but isn't a very high priority right now.

Viewmodel - 4:3 aspect on 16:9 screen, or all the time? Seems OK in 16:9 screenshots. Cvars to adjust position: scr_ofsx and scr_ofsyz.

The viewmodel aspect isn't wrong, what's wrong with it is the position. Hmm, wait a second. I've just tested it again, and the viewmodel is fine when starting the game. What makes it go wrong is the zoom. If you zoom in and then zoom out, the viewmodel doesn't return to its normal position.

The repositioning of the viewmodel on zoom looks great, by the way. It's one of the Super8's features I want to port.

[leileilol]

I wouldn't dare to reposition the viewmodel on zoom. There's a couple mods with sniper rifles that have a scope designed for the center of a viewsize 100'd screen with the intention to be F11'd through, with the "fudged" weapon position code most Quake engines don't seem to retain, either.

[qbism]

Thanks, I'll look at hor+ and MQ 1.6 (again). I think that 4:3 looks OK on 16:9 but will look at one of those ancient 4:3 monitors. There's still a laptop around here with one (and a 3.5" floppy!)

What makes it go wrong is the zoom. If you zoom in and then zoom out, the viewmodel doesn't return to its normal position.

I was unable to duplicate this. I'm seeing it return with both manual fov change and the typical F11 zoom bind. Some weird stuff others reported was fixed by deleting old super8.cfg in /super8 folder and probably should delete even older .cfg in ID1.

[qbism]

I wouldn't dare to reposition the viewmodel on zoom. There's a couple mods with sniper rifles that have a scope designed for the center of a viewsize 100'd screen with the intention to be F11'd through, with the "fudged" weapon position code most Quake engines don't seem to retain, either.

Could be a cvar that controls magnitude of reposition, from 0.0 to 1.0 with 0 being 'none' and 1 being 'ridiculous'.

[mankrip]

I wouldn't dare to reposition the viewmodel on zoom.

Of course, since it's not a feature from vanilla Quake, when implementing it I'll make it optional. But it looks too good with the regular viewmodels for me to pass it up.

the "fudged" weapon position code most Quake engines don't seem to retain

Funny enough, Makaqu and Super8 supports both modes. It works in conjunction with the Bobbing option in the Gameplay options menu.

I wish Darkplaces had an option to use the fudged position mode, by the way.

[mankrip]

What makes it go wrong is the zoom. If you zoom in and then zoom out, the viewmodel doesn't return to its normal position.

I was unable to duplicate this.

Which FOV are you basing the reposition on? If you use the horizontal FOV (r_refdef.fov_x, which is the one that's initially set to 90 from the cvar), it will have different results on different video aspects. A widescreen video has a bigger horizontal FOV than a 4:3 video (which is the one I've tested it on), so if your repositioning algorithm is expecting a widescreen FOV, it will think that the view is still zoomed in when the fov is 90.

To get proper results, the repositioning must be based on the value of the vertical FOV, or on the value of the "fov" cvar itself (if it hasn't been changed by the engine).

[mh]

Quakespasm's "hor+" is broken because it doesn't maintain the correct vertical FOV as it's non-adaptive FOV code. Here's Quakespasm at 800x600 with classic FOV:



And here it is at 800x600 with "hor+" FOV:



Notice that the "hor+" case is completely off for both vertical and horizontal FOV. It also shouldn't scale relative to a baseline of 4:3 but instead one of 640:432 (i.e. the standard 3D viewport when a full sbar is shown) - that's more subtle and can result in slightly squeezed geometry.

The correct code looks more like this:

Code: Select all

float SCR_CalcFovX (float fov_y, float width, float height)
{
	// bound, don't crash
	if (fov_y < 1) fov_y = 1;
	if (fov_y > 179) fov_y = 179;

	return (atan (width / (height / tan ((fov_y * M_PI) / 360.0f))) * 360.0f) / M_PI;
}


float SCR_CalcFovY (float fov_x, float width, float height)
{
	// bound, don't crash
	if (fov_x < 1) fov_x = 1;
	if (fov_x > 179) fov_x = 179;

	return (atan (height / (width / tan ((fov_x * M_PI) / 360.0f))) * 360.0f) / M_PI;
}


void SCR_SetFOV (refdef_t *rd, float fovvar, int width, int height)
{
	float aspect = (float) height / (float) width;

	// set up relative to a baseline aspect of 640x480 with a 48-high sbar
#define BASELINE_W	640.0f
#define BASELINE_H	432.0f

	// horizontalFov = atan (tan (verticalFov) * aspectratio)
	// verticalFov = atan (tan (horizontalFov) / aspectratio)
	if (aspect > (BASELINE_H / BASELINE_W))
	{
		// use the same calculation as GLQuake did (horizontal is constant, vertical varies)
		rd->FovX = fovvar;
		rd->FovY = SCR_CalcFovY (rd->FovX, width, height);
	}
	else
	{
		// alternate calculation (vertical is constant, horizontal varies)
		rd->FovY = SCR_CalcFovY (fovvar, BASELINE_W, BASELINE_H);
		rd->FovX = SCR_CalcFovX (rd->FovY, width, height);
	}
}

Have a read of http://www.emsai.net/projects/widescreen/fovcalc/ and http://www.gamedev.net/topic/431111-per ... -vertical/ for more on this.

[mankrip]

You can confirm this by looking at - say - the right-hand arrow outside the entry to e1 in start.bsp - if you line up correctly to center it on the screen (you'll need to noclip) it should be a perfect square but it's not.

Luckly I've caught that explanation before you removed it from the post.

It also shouldn't scale relative to a baseline of 4:3 but instead one of 640:432 (i.e. the standard 3D viewport when a full sbar is shown)

Let me debunk that theory:



This 432 theory is bogus because Quake was originally designed for two 4:3 resolutions: 320x200 with non-square pixels (in the art assets, which is confirmed by the console background and the pentagram icon) and 320x240 with square pixels (in the software rendering code, which can be confirmed by features like the underwater screen warp).
Most machines at the time of its release would slow down to a crawl if running the game at 640x480, and for years (from 2000 to 2004/2005) my computer was an AMD Cyrix 233 computer that ran it at 12 fps in 512x384.

Another proof that this 432 theory is bogus is that the original software renderer can't scale 2D elements, so the proportional vertical space taken by the status bar always changes when changing resolutions. 640/(480-48) is 1.48, but 320/(240-48) is 1.66.

And the final nail in the coffin is that the viewsize also changes how much proportional vertical space is taken by the status bar. And I'm not talking about viewsize 110 or 120, but about e.g. viewsize 90, which reduces the 3D view.

If Quakespasm is wrong, that's either an specific problem of Quakespasm itself, or of engines derived from GLQuake (of which I never looked much at the code).

The status bar height doesn't matter in the software renderer, because the vertical FOV is calculated before the 3D view is cropped. In Makaqu, this can be proved by switching to a 320x200 resolution with viewsize 100 and sbar_show_bg 1, and changing the "sbar" cvar from zero to 3.
In the vanilla software renderer, the "fudged" view position code must be disabled for testing this.