Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ALL_BLACK and ALL_WHITE appear to be implemented wrongly for raster copy functions #34

Open
mfro0 opened this issue May 9, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@mfro0
Copy link
Member

mfro0 commented May 9, 2022

vro_cpyfm() calls utilizing the ALL_WHITE (0) or ALL_BLACK (15) logic op constants appear to be interchanged: ALL_WHITE gives black while ALL_BLACK gives white at least with the 16 and 32 bit drivers (Aranym) and the FireBee driver that seems to have inherited the same behaviour (others I can't test currently).

@mfro0 mfro0 added the bug Something isn't working label May 9, 2022
@chrisridd
Copy link

Assuming fvdi just passes the logic op straight through to aranym native code, then aranym seems to be calling this on each pixel (?):

uint32 VdiDriver::applyBlitLogOperation(int logicalOperation,
	uint32 destinationData, uint32 sourceData)
{
	switch(logicalOperation) {
		case ALL_WHITE:
			destinationData = 0;
			break;
		case S_AND_D:
			destinationData = sourceData & destinationData;  
			break;
		case S_AND_NOTD:
			destinationData = sourceData & ~destinationData;
			break;
		case S_ONLY:
			destinationData = sourceData;
			break;
		case NOTS_AND_D:
			destinationData = ~sourceData & destinationData;
			break;
/*
		case D_ONLY:
			destinationData = destinationData;
			break;
*/
		case S_XOR_D:
			destinationData = sourceData ^ destinationData;
			break;
		case S_OR_D:
			destinationData = sourceData | destinationData;
			break;
		case NOT_SORD:
			destinationData = ~(sourceData | destinationData);
			break;
		case NOT_SXORD:
			destinationData = ~(sourceData ^ destinationData);
			break;
		case D_INVERT:
			destinationData = ~destinationData;
			break;
		case S_OR_NOTD:
			destinationData = sourceData | ~destinationData;
			break;
		case NOT_S:
			destinationData = ~sourceData;
			break;
		case NOTS_OR_D:
			destinationData = ~sourceData | destinationData;
			break;
		case NOT_SANDD:
			destinationData = ~(sourceData & destinationData);
			break;
		case ALL_BLACK:
			destinationData = 0xffffffffUL;
			break;
	}

	return destinationData;
}

Looking at how colour seems to work elsewhere in the aranym code, ALL_WHITE (0) will be black and ALL_BLACK (0xffffffffUL) will be white.

But if firebee's misbehaving too perhaps I'm mistaken about aranym's native code.

@mfro0
Copy link
Member Author

mfro0 commented May 15, 2022

this is what tos.hyp says:

ALL_WHITE 0 D := 0
...
ALL_BLACK 15 D := 1

which is correct for plane-organised screens where you set the color index in the bit plane (and not the direct color). Color index 0 is supposed to be white there and color index 1 black.
With high and full color screens, you don't set the color index, but the color itself instead and the value needs to be 0xffffffff and 0, respectively (at least that's what I strongly assume, as documentation doesn't explicitly say so).

I have fixed that for the 16bit driver. It appears that for Aranym, it should to be fixed in the Aranym code itself?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants