#112932 - Lazy1 - Thu Dec 21, 2006 6:49 pm
I'm not sure if I understand it correctly, but I think it has to do with setting each pixels RGB intensity to act as 3 pixels.
If that is true, would that give me a 1bit display size of 768x192?
That would be a good addition to Mini vMac DS since the entire width of the screen could be seen at once, that is if it would be bearable to look at.
#112934 - Mighty Max - Thu Dec 21, 2006 7:25 pm
Subpixel, does make use of the physical layout of the colors on the display.
From what i have observed by the different subpixelfont using apps, there is a big problem: There are different displays build into the different DSes, meaning a subpixel setup that works on one, doesnt work on the next.
_________________
GBAMP Multiboot
#112935 - Lazy1 - Thu Dec 21, 2006 7:36 pm
Yeah, I heard that too - I think it's the later model fat DS and the DS Lite only.
I guess a config option could be added to set the screen type, unless the display type can be detected.
One problem I see is that I use an 8bit indexed mode to display the screen currently, this is easy since all I need to do is lookup the 8 pixel byte into an array and get 2 u32s which I write to vram.
It would basically need to be roughly the same way since that method already takes 2ms and it's already capped out at 16fps under full load.
Or maybe the cost of a larger display area is worth the cost of some performance.
#112940 - tepples - Thu Dec 21, 2006 8:33 pm
| Mighty Max wrote: |
| From what i have observed by the different subpixelfont using apps, there is a big problem: There are different displays build into the different DSes, meaning a subpixel setup that works on one, doesnt work on the next. |
And they're an R/B palette swap away from being universal, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#112944 - Mighty Max - Thu Dec 21, 2006 8:50 pm
I havent looked into it exactly. But the physical layout of pixels does not have to be a plain line RGB or BGR, do they?
A display might have the subpixels grouped in a quad:
BG
RB
That would render it impossible to get a horizontal resolution of 3*pixel
_________________
GBAMP Multiboot
#112948 - Payk - Thu Dec 21, 2006 11:03 pm
Could it also be ordered like a triangle?
#112950 - simonjhall - Thu Dec 21, 2006 11:08 pm
On cameras it's more like RGGB (I think it's RG on one row, then GB on another) due to the sensitivity of the eye to green. Have a look at bayer patterns on wikipedia. Dunno if the DS screen mimics this pattern.
_________________
Big thanks to everyone who donated for Quake2
#112953 - HyperHacker - Thu Dec 21, 2006 11:31 pm
I've heard that it's possible on the DS just as it was on the GBA, but some older Phats use a different order for the bottom screen than for the top; newer ones and Lites use the same order as the older ones' top for both.
Subpixel rendering can sort of boost your horizontal resolution, but only for black and white images. Indeed it involves colour manipulation to make each pixel's R, B and G components act alone to form 1/3-pixel dots instead of entire pixels, but since they can only be one colour and are so small, they're of no real use for coloured images.
Windows XP's font rendering has Cleartype for LCDs which is subpixel rendering. Try it out and see what a difference it makes. I'd imagine just about every other OS with a GUI does too, assuming it's been updated since LCDs became popular.
Oh, and though it's not an issue on the DS, this has another advantage - on CRTs, there are no subpixels to manipulate, but you still end up with a nice antialiasing effect. Not as pretty as subpixels, but prettier than no antialiasing at all.
_________________
I'm a PSP hacker now, but I still <3 DS.
#112964 - DekuTree64 - Fri Dec 22, 2006 12:32 am
I seriously doubt that nintendo would ever use an LCD with entirely different subpixel arrangements, and a BGR/RGB switch should be fine for an emulator.
Check out the source from my eternity demo for some pretty fast subpixel rendering. Most of it is in SubPx.c, and the 1-bit to 8-bit render loop is in Math.s (search for RenderSubPx, and yes, it has nothing to do with math and I should be shot for putting everything in that one file).
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#112965 - Lazy1 - Fri Dec 22, 2006 1:00 am
I took a look in that file and I'll be honest and say I have no idea what is going on.
I have enough asm knowledge to _maybe_ convert a small C function, but I cannot read it and understand what it's doing.
I keep trying to read that PDF on arm assembly, but I never remember to do it or I get bored half way through :/
#112967 - Lick - Fri Dec 22, 2006 1:07 am
Deku, that's an awesome demo. @_@
_________________
http://licklick.wordpress.com
#112975 - Lazy1 - Fri Dec 22, 2006 2:06 am
My current drawing code is fairly simple, room for optimization but 2ms is fine for what it's doing (at least for now ).
| Code: |
__attribute__( ( section( ".itcm" ), long_call ) ) LOCALPROC HaveChangedScreenBuff(si4b top, si4b left, si4b bottom, si4b right)
{
u8* octpix = ( u8* ) screencomparebuff;
u32* vram = ( u32* ) BG_GFX;
static int st = 0;
static int i = 0;
//st = ( TIMER1_DATA + gTimerBaseMS );
/*
* TODO:
* Rewrite, it's just too hacky.
*/
for ( i = 0; i < vMacScreenNumBytes; i++ ) {
*vram++ = OneToEightTable[ *octpix ][ 0 ];
*vram++ = OneToEightTable[ *octpix++ ][ 1 ];
}
//UnusedParam(top);
//UnusedParam(left);
//UnusedParam(bottom);
//UnusedParam(right);
//iprintf( "HaveChangedScreenBuff( ) took %d ms\n", ( ( TIMER1_DATA + gTimerBaseMS ) - st ) );
}
|
I can't use a 16bit mode since all my vram is tied up with the 512x512 background.
I thought of a few ways, but the pixels never line up properly to work in a LUT.
#113001 - DekuTree64 - Fri Dec 22, 2006 8:08 am
| Lazy1 wrote: |
| I took a look in that file and I'll be honest and say I have no idea what is going on. |
Heh, it took me a few minutes to figure out what was happening, and I wrote it... But here's how it works.
It's actually running in mode0, using 4-bit tiles, not mode4 as I previously thought. Around line 243 of SubPx.c, it generates a table used during the conversion from 1-bit to 4-bit. You index into the table with a 12 bit value (12 sub-pixels) to get a u16 (4 4-bit pixels).
The render loop converts 24 sub-pixels into 8 4-bit pixels per pass (one row of a tile). The conversion is actually done in 2 12-bit chunks, which are then ORed together and stored as a single u32.
The logic is basically: load 3 bytes from the sub-pixel buffer and OR each of them into a register, then convert the lower 24 bits of that register to 4-bit pixels and store them, then shift the register value down by 24 bits (retaining the upper byte for the next iteration).
Now that I think about it though, the shifting down part is kind of a waste of time if you're loading 3 bytes individually each iteration anyway. But if you unroll it 4 times, then I think you could load a u32 at a time which would be a lot faster.
| Lick wrote: |
| Deku, that's an awesome demo. @_@ |
Thanks :) Those were good times. One of these days I'll scrounge up enough free time to do some demo effects on the DS. Lots of fun new hardware and raw horsepower to play with compared to GBA.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#113089 - Lazy1 - Fri Dec 22, 2006 10:48 pm
I see, so I need to generate a 12bit LUT and use a 16 color mode to write the subpixels?
I think I understand, I'm not sure about writing to vram in tiled mode though.
Do I treat vram as a linear framebuffer and setup the map a certain way to display the tiles in order?
#113616 - Nintendo Maniac 64 - Fri Dec 29, 2006 5:45 am
I'm not sure if this was ever answered, let alone if it even matters, but here...
Most DS phats have pixel arrangements of RGB on the top and BGR on bottom.
DS Lites have BGR on both screens.
The DS phats that have BGR on both screens probably have the "upgraded Lite screens", noting that Lites also have the BGR arrangement. From this, we can assume they are the same ones that can use variable brightness settings with a hacked firmware, like how Lites do it naturally. I believe these are DS phats that originally had firmware version 5.
NOTE: refirbished DS's usually have firmware upgrades to the newest version. Such as my refurbished blue DS phat. It had firmware version 5, yet I didn't have the variable brightness setting. I believe my DS's firmware was originally a version 4 because I don't believe there were any version 3 phats that were blue.
#117244 - Lazy1 - Fri Feb 02, 2007 8:29 pm
Well, yesterday I tried to get subpixel drawing into Mini vMac without much luck.
The result I got was a small screen of about half the DS's screen size repeated three times horizontally.
Even still, each one was fairly readable but still broken.
Is there a way to do this sort of thing that I'm missing?
Sorry for the lack of code since I deleted it, but I can always try writing it again.
#117252 - DekuTree64 - Fri Feb 02, 2007 9:22 pm
| Lazy1 wrote: |
| The result I got was a small screen of about half the DS's screen size repeated three times horizontally. |
Probably related to the fact that you're essentially tripling your horizontal resolution. If you're using the 1-bit backbuffer style, make sure the buffer is 3x the actual screen width.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#117253 - Lazy1 - Fri Feb 02, 2007 9:24 pm
Well, the emulated screen size is 512x342 if that means anything.
Another issue someone brought up in IRC was that it may cause things to look stretched, is that true?
#117254 - tepples - Fri Feb 02, 2007 9:24 pm
Or use orange and blue as the primitives in your scaling algorithm.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#117255 - Lazy1 - Fri Feb 02, 2007 9:25 pm
| tepples wrote: |
| Or use orange and blue as the primitives in your scaling algorithm. |
I don't have a scaling algorithm, or the cpu cycles to implement one.