code Widescreen Support

[Tempust85]

So after having a dive into the source code dump of JKA and noticed widescreen code for Xbox, I figured hey! let's do widescreen support!

 

Now before anyone yells: zomg you ported illegal codez! No, I didn't. I've taken the idea of what was done for Xbox and applied it using a cvar. It's basically a long list of "if (cg_widescreen.integer)" all throughout cg_draw.

 

This is at 1280x720 resolution. As you can see, the HUD is stretched. Now I turn on cg_widescreen...

 

 

(yes I know I need to lose the force number, ignore that)

[LucyTheAlien]

So after having a dive into the source code dump of JKA and noticed widescreen code for Xbox, I figured hey! let's do widescreen support!

 

Now before anyone yells: zomg you ported illegal codez! No, I didn't. I've taken the idea of what was done for Xbox and applied it using a cvar. It's basically a long list of "if (cg_widescreen.integer)" all throughout cg_draw.

 

This is at 1280x720 resolution. As you can see, the HUD is stretched. Now I turn on cg_widescreen...

 

 

(yes I know I need to lose the force number, ignore that)

 

Bloody excellent. 

[minilogoguy18]

That's awesome that it auto fix's the hud but what about the menu and load screens? Surely that will take some reworking of the image files they use for their backgrounds.

 

I wonder if there is a way to run some sort of auto detect of the user's video resolution to auto resolve to use the aspect ratio that is correct so that the game doesn't boot in an incorrect aspect ratio.

[Teancum]

So after having a dive into the source code dump of JKA and noticed widescreen code for Xbox, I figured hey! let's do widescreen support!

 

Now before anyone yells: zomg you ported illegal codez! No, I didn't. I've taken the idea of what was done for Xbox and applied it using a cvar. It's basically a long list of "if (cg_widescreen.integer)" all throughout cg_draw.

Would people get bent out of shape about something so small anyway? Seems trivial to worry about.

 

Regardless that's awesome. It's a much needed feature these days.

[minilogoguy18]

Yeah, if you're still using a 4:3 monitor you're also still probably rubbing sticks together to make fire.

[Tempust85]

Been trying to work out the disruptor zoom fix. It half worked, until it came time to alter the width of the rotating image and ticks. Now we have to redo the zoom overlay design into something with no ticks or rotating images. The base JKA images are pretty small anyway.

 

Now, moving onto menus. Stay tuned.

[ent]

@DT85, https://github.com/entdark/jaMME/blob/master/codemp/cgame/cg_draw.c#L216

Check all ratio var related things.

 

[Tempust85]

Doesn't help me much, I'm working with SP not MP. But ty, I'll see if I can get some ideas from it.

[ent]

It's not a part that differs from SP much. You can adapt, I am sure.

The main trick is in trap_R_RotatePic2RatioFix.

[Tempust85]

I have the font and cursor ratio fix working, but the HUD is now not being drawn at all and the rotatepic fix hasn't done anything.

[ent]

Did you just add that function or implemented the new trap call? The trap does not exist and requires implementation. (Just Ctrl+f all the references.)

[Tempust85]

I may have missed one or two things, I'll have to double check again.

[Tempust85]

@@ent

 

Ok, it's working. Now it's just the disruptor being a pain:

 

 

When it should look like this, but widescreen of course:

 

 

Notice how the green ticks aren't placed properly, or the rotating blue circle. Seems like the rotate fix trap isn't doing what it should, even though I've put it in all the way into the renderer.

[ent]

Can I look at how you implemented the trap?

[Tempust85]

I'll tidy a few things up and commit the code, then post back here with a link.

[Tempust85]

Here's the link: https://github.com/DT85/OpenDF2/tree/rend2-sp

[minilogoguy18]

What's odd is that rather than what you'd think isn't really happening, I'd expect it to be stretched horizontally but it's actually squished vertically judging by the green ticks.

[ent]

You missed this: https://github.com/entdark/jaMME/blob/master/codemp/rd-vanilla/tr_backend.cpp#L1684

[Tempust85]

@@ent the rotatepic2 code is different to yours. Could you please find a fix for this version?

static const void *RB_RotatePic2 ( const void *data ) 
{
	const rotatePicCommand_t	*cmd;
	shader_t *shader;

	cmd = (const rotatePicCommand_t *)data;

	// FIXME: HUGE hack
	if (!tr.renderFbo || backEnd.framePostProcessed)
	{
		FBO_Bind(NULL);
	}
	else
	{
		FBO_Bind(tr.renderFbo);
	}

	RB_SetGL2D();

	shader = cmd->shader;
	if ( shader != tess.shader ) {
		if ( tess.numIndexes ) {
			RB_EndSurface();
		}
		backEnd.currentEntity = &backEnd.entity2D;
		RB_BeginSurface( shader, 0, 0 );
	}

	RB_CHECKOVERFLOW( 4, 6 );
	int numVerts = tess.numVertexes;
	int numIndexes = tess.numIndexes;

	float angle = DEG2RAD( cmd->a );
	float s = sinf( angle );
	float c = cosf( angle );

	matrix3_t m = {
		{ c, s, 0.0f },
		{ -s, c, 0.0f },
		{ cmd->x, cmd->y, 1.0f }
	};

	tess.numVertexes += 4;
	tess.numIndexes += 6;

	tess.indexes[ numIndexes ] = numVerts + 3;
	tess.indexes[ numIndexes + 1 ] = numVerts + 0;
	tess.indexes[ numIndexes + 2 ] = numVerts + 2;
	tess.indexes[ numIndexes + 3 ] = numVerts + 2;
	tess.indexes[ numIndexes + 4 ] = numVerts + 0;
	tess.indexes[ numIndexes + 5 ] = numVerts + 1;

	VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts ]);
	VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 1]);
	VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 2]);
	VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 3 ]);

	tess.xyz[ numVerts ][0] = m[0][0] * (-cmd->w * 0.5f) + m[1][0] * (-cmd->h * 0.5f) + m[2][0];
	tess.xyz[ numVerts ][1] = m[0][1] * (-cmd->w * 0.5f) + m[1][1] * (-cmd->h * 0.5f) + m[2][1];
	tess.xyz[ numVerts ][2] = 0;

	tess.texCoords[ numVerts ][0][0] = cmd->s1;
	tess.texCoords[ numVerts ][0][1] = cmd->t1;

	tess.xyz[ numVerts + 1 ][0] = m[0][0] * (cmd->w * 0.5f) + m[1][0] * (-cmd->h * 0.5f) + m[2][0];
	tess.xyz[ numVerts + 1 ][1] = m[0][1] * (cmd->w * 0.5f) + m[1][1] * (-cmd->h * 0.5f) + m[2][1];
	tess.xyz[ numVerts + 1 ][2] = 0;

	tess.texCoords[ numVerts + 1 ][0][0] = cmd->s2;
	tess.texCoords[ numVerts + 1 ][0][1] = cmd->t1;

	tess.xyz[ numVerts + 2 ][0] = m[0][0] * (cmd->w * 0.5f) + m[1][0] * (cmd->h * 0.5f) + m[2][0];
	tess.xyz[ numVerts + 2 ][1] = m[0][1] * (cmd->w * 0.5f) + m[1][1] * (cmd->h * 0.5f) + m[2][1];
	tess.xyz[ numVerts + 2 ][2] = 0;

	tess.texCoords[ numVerts + 2 ][0][0] = cmd->s2;
	tess.texCoords[ numVerts + 2 ][0][1] = cmd->t2;

	tess.xyz[ numVerts + 3 ][0] = m[0][0] * (-cmd->w * 0.5f) + m[1][0] * (cmd->h * 0.5f) + m[2][0];
	tess.xyz[ numVerts + 3 ][1] = m[0][1] * (-cmd->w * 0.5f) + m[1][1] * (cmd->h * 0.5f) + m[2][1];
	tess.xyz[ numVerts + 3 ][2] = 0;

	tess.texCoords[ numVerts + 3 ][0][0] = cmd->s1;
	tess.texCoords[ numVerts + 3 ][0][1] = cmd->t2;

	return (const void *)(cmd + 1);
}

I've tried adding *ratio to the every cmd->w (this looks to be the width?), but it still doesn't look right.

[Xycaleth]

On this line:

{ c, s, 0.0f },

Multiply c by ratio. That should scale everything along the x axis by the ratio variable.

[Tempust85]

Added that, thanks.

 

Rotating circle start size is a circle, but morphs into this by the end of zooming:

 

 

And the green ticks still do not look right, at the bottom where they end. They clip over the blue art as you can see, but don't at a 4:3 resolution.

[minilogoguy18]

After this what about the binoculars? Do they work properly? I know it might be too soon to ask since you kinda gotta finish 1 thing at a time.

[Tempust85]

The fix is already coded, I just haven't checked them to see yet. So far only the fonts, HUD (not all of it yet) & crosshair have the ratio fix. I can't do anything about the menu backgrounds, I'll have to redo them as 16:9 and 4:3 res players will just have to deal with it.

 

I've also made a setting for it in the setup menu (Set Ratio: 16:9 or 4:3) which i've made require a vid_restart to apply the change. Fonts look seriously borked without a vid_restart.

 

I've ALSO added the 720p & 1080p widescreen resolutions to r_mode.

[minilogoguy18]

I think in 2017 4:3 players are far and few between, it's much better to just focus on everything working in widescreen since that's like 98% of all users.

[ent]

@DT85, I think you did not apply the ratio fix to the ticks' width somewhere.

Or maybe @Xycaleth's solution is not completed.