Beta Uae4All Additions


Just switched on my original Amiga 1084S (with RGB) and compared it to the blurry look of the LCD: It looks a bit different, yes. But the hardware scaled LCD picture definately came closer to the original Amiga 1084S monitor picture than the ultrasharp one.

Amiga Monitors were RGB, yes - but as they were PAL resolution with 50Hz (or NTSC resolution with 60Hz) and monitors weren't that sharp back these days, you can not make out single pixels (unless the game had bad graphics ;)). With a sharp LCD, you can make out single pixels - which looks good for PC stuff (as they were done for that) but looks crappy when you play games meant for older CRT monitors.
 
Oooh yeah, I love my old 1084S. Would be cool if there was a filter that looked like that! The scanline screenshot looks quite close. Probably not overly expensive to do in software for the pixel-doubled (quadrupled?) mode by shifting the colour values for every second line.
 
SteveM said:
Probably not overly expensive to do in software for the pixel-doubled (quadrupled?) mode by shifting the colour values for every second line.
Click to expand...
Yes, shouldn't make it notably slower. Here's the simple2x-function used for the doubled pixels mode:

Code: 
void Simple2x(unsigned char *srcPtr, unsigned int srcPitch, unsigned char *deltaPtr, unsigned char *dstPtr, unsigned int dstPitch, int width, int height)
{
    unsigned char *nextLine, *finish;
  
	nextLine = dstPtr + dstPitch;
  
	do 
	{
		unsigned int *bP = (unsigned int *) srcPtr;
		unsigned int *dP = (unsigned int *) dstPtr;
		unsigned int *nL = (unsigned int *) nextLine;
		unsigned int currentPixel;
    
		finish = (unsigned char *) bP + ((width+2) << 1);
		currentPixel = *bP++;
    
		do 
		{
#ifdef BIG_ENDIAN
			unsigned int color = currentPixel >> 16;
#else
		        unsigned int color = currentPixel & 0xffff;
#endif

			color = color | (color << 16);

			*(dP) = color;
			*(nL) = color;

#ifdef BIG_ENDIAN
			color = currentPixel & 0xffff;
#else
			color = currentPixel >> 16;
#endif
			color = color| (color << 16);      
			*(dP + 1) = color;
			*(nL + 1) = color;
      
			currentPixel = *bP++;
      
			dP += 2;
			nL += 2;
		}
		while ((unsigned char *) bP < finish);
    
		srcPtr += srcPitch;
		dstPtr += dstPitch << 1;
		nextLine += dstPitch << 1;
	}
	while (--height);
}
Now how do you make the pixels of every odd line 25% darker (to simulate 25% scanlines)?

Would color *= 0.75; (for the pixels in odd lines) accomplish this?
 
Last edited by a moderator:
Assuming 16-bit colours, the format of the "color" variable is probably something like RRRRRGGGGGGBBBBB. What you need to do is extract each of the red, green and blue components and adjust them in the same way. For example, if you want red to be half the brightness, you'd typically mask the top five bits (&0xf800) and shift them right one. Floating point isn't likely to be your friend in such a loop; you'll probably want to keep it to simple bitwise logic. Maybe try with half brightness first, but don't forget that 1/2 + 1/4 == 0.75 ;-)
 
SteveM said:
you'd typically mask the top five bits (&0xf800) and shift them right one.
[...]
don't forget that 1/2 + 1/4 == 0.75 ;-)
Click to expand...
So in order to get the 3/4-value should I then do the bit-shifting again with the 1/2 value and then just add the 1/2- and 1/4-values (or is there a quicker way)?
And 6 bits are used for green?
 
Last edited by a moderator:
Does this look correct?

Code: 
//make color half bright
unsigned int red = (color & 0xf800) >> 1;
unsigned int green = (color & 0x07e0) >> 1;
unsigned int blue = (color & 0x001f) >> 1;
color = red + green + blue;

//get values for 1/4 brightness
red = (color & 0xf800) >> 1;
green = (color & 0x07e0) >> 1;
blue = (color & 0x001f) >> 1;

//add them to get 3/4 bright color
color += red + green + blue;
(Currently don't have my Pandora available so can't test this.)
 
Sort of like that, but you need to add the RGB components to each other separately, then OR the results together. Watch that you don't start shifting one colour's bits into its neighbour's. Once it's working you can probably do some nice optimisations like combining the shifts (e.g. half_bright = (color >> 1) & 0x7bef). Every little helps, as you're going to be doing this for a lot of pixels every second...
 
I often find it useful to write a little C program or Perl script to test this kind of stuff as it can be frustrating if (when?) it doesn't work. Putting printf()s in your code works fine too, of course, but expect a lot of output ;-) Unless you have the program kill itself after drawing a frame or so.
 
I'll just load a savestate of some colorful game to test this (when I get my Pandora back which currently is on a journey).
 
john4p said:
Does this look correct?

Code: 
//make color half bright
unsigned int red = (color & 0xf800) >> 1;
unsigned int green = (color & 0x07e0) >> 1;
unsigned int blue = (color & 0x001f) >> 1;
color = red + green + blue;

//get values for 1/4 brightness
red = (color & 0xf800) >> 1;
green = (color & 0x07e0) >> 1;
blue = (color & 0x001f) >> 1;

//add them to get 3/4 bright color
color += red + green + blue;
(Currently don't have my Pandora available so can't test this.)
Click to expand...

no, you're moving the lower bits into the other color with your bit shift.
(red bit #0 becomes top green bit)
you need to mask off the lower bits

and reusing the result color again for the 25% causes a read-after-write pipeline hazard, better off shifting the original value by 2.

the correct and faster way for 16 bits RGB 565:
Code: 
color = ((color & 0xF7DE) >> 1); // 50 %
Code: 
color = ((color & 0xF7DE) >> 1) + ((color & 0xE79C) >> 2); // 75%

and for 15 bits xRGB 1555
Code: 
color = ((color & 0x7BDE) >> 1); // 50 %
Code: 
color = ((color & 0x7BDE) >> 1) + ((color & 0x739C) >> 2); // 75%

edit: you only need one of those lines, either the 50% or 75% one, not both
 
Last edited by a moderator:
john4p said:
I'll just load a savestate of some colorful game to test this (when I get my Pandora back which currently is on a journey).
Click to expand...

It's already alive and kicking - but I missed UPS pickup by 5 minutes, so you won't get it back tomorrow, but on Friday :)
 
Last edited:
@StephaneHockenhull: Great, thanks!

Now that Steve and you explained it the solution is easy indeed.
Haven't needed shifting bits around yet. Now I know how to do that.


edit:
EvilDragon said:
john4p said:
I'll just load a savestate of some colorful game to test this (when I get my Pandora back which currently is on a journey).
Click to expand...

It's already alive and kicking - but I missed UPS pickup by 5 minutes, so you won't get it back tomorrow, but on Friday :)
Click to expand...
What?! That's incredible (just sent it to you yesterday afternoon) - thanks a lot. :)
 
Last edited by a moderator:
Glad that scanlines are being considered. Perhaps a user specified percentage would be possible, though 25% sounds about right. Also, I just read in http://www.gp32x.de/board/index.php?/topic/56196-led-suggestions/ that the pandoras LED's are under software control, would it be difficult to map the virtual drives (and maybe the power LED too) to the pandoras LED's? This would be very useful indeed, to see how/if something is accessing a dick and in which drive. I used to use that function with WinUAE and my keyboard LED's, but my wireless keyboard has no LED's and I really miss the function. Also, to save me trawling through this thread can I ask a quick question - is the keyboard working yet, or is it still only a virtual keyboard?

Thanks, really enjoying the frequent updates and progress of this emulator. Though I don't have my pandora yet it's lovely being able to follow the way this is evolving before our very eyes. I'm a big fan of being able to see all the small steps as they are being implememnted, it's really satisfying. It also allows everyone (even people like me) to offer little suggestions and feel like we're part of the process. Thanks for that.
 
Last edited by a moderator:
@TitanUranus: Keyboard always worked fine (the info in the Readme was false).

Don't want to override the Pandora's LEDs because what happens when UAE4All crashes?
You can activate "Status line" in UAE4All more options - then diskdrive-access and power led (and fps) are displayed at the bottom of the screen.

For scanlines I'll just add the options "none", "25%" and "50%". And they'll only be available for doubled pixels mode I think (don't think smooth fractional scale + scanlines makes sense).
 
john4p said:
I remember not being impressed when a friend showed me Prince of Persia, Xenon 2 and Monkey Island on his 286 PC.
Preferred the smoothness of my RGB Amiga monitor (where you didn't see the single pixels) over the blockiness of the PC screen.
Click to expand...
Yeah that is mostly due to the lower dot-pitch of the Amiga monitor. The aperature grille of the Amiga monitor was much larger than PC monitors creating a type of filter almost. This helped round off the edges of the pixels. The grille was much finer on PC monitors and you could see the edges of the square pixels making them look blocky.

Not too much can be done on the LCD to duplicate this exact effect at 2X resolution.
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

john4p
Release UAE4All 2.0
21 22 23
Replies
447
Views
94K
TomB
T
T
Release UAE4All 2.0 with hires
2
Replies
27
Views
4K
john4p
john4p
T
Release [Repo] UAE4ARM
2 3 4
Replies
72
Views
31K
gibs
gibs
john4p
Request @pickle
Replies
2
Views
1K
john4p
john4p
T
Release [Repo] UAE4All 2.5.0.2
Replies
17
Views
4K
Stainy
Stainy
Back
Top