This is what i saw with the vsh menu that i've ported for this resolutions. The exact same code is working flawlessly in component-interlace, and in composite it has refresh problems.J.F. wrote:That doesn't make any sense. Composite should be identical to component interlaced. There's no difference in the signals other than component using Y/Pb/Pr and composite using Y+C. I can't imagine that making any difference in program speed. No one has reported this with the GBA emu I mentioned. The timing is the same, the memory is laid out the same, so why should one be faster than the other?moonlight wrote:And believe me, composite cable is slower than component-interlace. But obviously, fast enough for videos.
Using the TV out in homebrew, whatever cable, full screen
I need help with incorporating tvout. I have been trying to use the dve sample as a basis but for the life of me i can't seem to figure out how to get the image to display full screen properly. I seem to get only the upper portion of the screen displaying the image.
Here is the initialization of the GU.
Here is one of the functions used for blitting.
Now does the blitting require some extra work for TvOut support that I'm not aware of?
Here is a snapshot of what is happening:
Here is the initialization of the GU.
Code: Select all
void initGraphics()
{
int cable=0, u=0, width=0, height=0, displaymode=0;
dispBufferNumber = 0;
sceGuInit();
guStart();
sceGuDrawBuffer(GU_PSM_8888, (void*)FRAMEBUFFER_SIZE, LINESIZE);
sceGuDispBuffer(SCREEN_WIDTH, SCREEN_HEIGHT, (void*)0, LINESIZE);
sceGuClear(GU_COLOR_BUFFER_BIT | GU_DEPTH_BUFFER_BIT);
sceGuDepthBuffer((void*) (FRAMEBUFFER_SIZE*2), LINESIZE);
sceGuOffset(2048 - (SCREEN_WIDTH / 2), 2048 - (SCREEN_HEIGHT / 2));
sceGuViewport(2048, 2048, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuDepthRange(0xc350, 0x2710);
sceGuScissor(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
sceGuAlphaFunc(GU_GREATER, 0, 0xff);
sceGuEnable(GU_ALPHA_TEST);
sceGuDepthFunc(GU_GEQUAL);
sceGuEnable(GU_DEPTH_TEST);
sceGuFrontFace(GU_CW);
sceGuShadeModel(GU_SMOOTH);
sceGuEnable(GU_CULL_FACE);
sceGuEnable(GU_TEXTURE_2D);
sceGuEnable(GU_CLIP_PLANES);
sceGuTexMode(GU_PSM_8888, 0, 0, 0);
sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGBA);
sceGuTexFilter(GU_NEAREST, GU_NEAREST);
sceGuAmbientColor(0xffffffff);
sceGuEnable(GU_BLEND);
sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);
sceGuFinish();
sceGuSync(0, 0);
sceDisplayWaitVblankStart();
sceGuDisplay(GU_TRUE);
if(kuKernelGetModel() == PSP_MODEL_SLIM_AND_LITE)
{
cable = pspDveMgrCheckVideoOut();
switch(cable)
{
case 0:
// No Cable
break;
case 1:
// composite, sdtv
u = 2;
width = 720;
height = 503;
displaymode = 0x1D1;
break;
case 2:
// component, (and probably d-terminal too)
u = 0;
width = 720;
height = 480;
displaymode = 0x1D2;
break;
default:
writeToLogFile("Unknown cable %d.\n", cable);
sceKernelDelayThread(5*1000000);
borExit(0);
break;
}
if(cable == 1 || cable == 2)
{
pspDveMgrSetVideoOut(u, displaymode, width, height, 1, 15, 0);
sceDisplaySetFrameBuf((void*)(FRAMEBUFFER_SIZE*2), 1024, PSP_DISPLAY_PIXEL_FORMAT_8888, PSP_DISPLAY_SETBUF_NEXTFRAME);
}
}
initialized = 1;
}
Here is one of the functions used for blitting.
Code: Select all
void blitImageToScreen(int sx, int sy, int width, int height, Image* source, int dx, int dy)
{
if (!initialized) return;
Color* vram = getVramDrawBuffer();
sceKernelDcacheWritebackInvalidateAll();
guStart();
sceGuCopyImage(GU_PSM_8888, sx, sy, width, height, source->textureWidth, source->data, dx, dy, LINESIZE, vram);
sceGuFinish();
sceGuSync(0,0);
}
Now does the blitting require some extra work for TvOut support that I'm not aware of?
Here is a snapshot of what is happening:
You probably haven't changed any of the defines in graphic.c/.h from 480x272 into 720x480. You might want to get the latest source for pmplayer advance - cooleyes has already added TV support to graphics.c/.h.
http://code.google.com/p/pmplayer-advance
http://code.google.com/p/pmplayer-advance
Hmm... Still not having any luck but it seems, correct me if I'm wrong. In order to support 720x480 some type of scaling needs to be put in place.
While I'm far from being a video expert it seems he is scaling the video to fit the TV's resolution via his texture_subdivision lib.
If that is the case then that seems to be what I'm missing. What I don't understand is why I see multiple images....
** Updated **
Yep, It seems that was the problem as I'm see much better results after manipulating the vertexs.
While I'm far from being a video expert it seems he is scaling the video to fit the TV's resolution via his texture_subdivision lib.
If that is the case then that seems to be what I'm missing. What I don't understand is why I see multiple images....
** Updated **
Yep, It seems that was the problem as I'm see much better results after manipulating the vertexs.
I have EXACTLY the same problem - can you guide me how to do it???SamuraiX wrote:Hmm... Still not having any luck but it seems, correct me if I'm wrong. In order to support 720x480 some type of scaling needs to be put in place.
While I'm far from being a video expert it seems he is scaling the video to fit the TV's resolution via his texture_subdivision lib.
If that is the case then that seems to be what I'm missing. What I don't understand is why I see multiple images....
** Updated **
Yep, It seems that was the problem as I'm see much better results after manipulating the vertexs.
-
MysticWhiteDragon
- Posts: 30
- Joined: Thu Feb 16, 2006 8:46 am
In theory, yes. You could make a plugin to copy (and scale) the video from where the app drew it to the real framebuffer outputting to the TV. But why? It won't hardly be any better than the existing mechanism for displaying games, the scaling would look ugly, would slow things down, and it wouldn't work with everything. It's like slapping a band-aide on a severed arm. It's better to have program authors add proper TV support to the program.MysticWhiteDragon wrote:Couldn't it be possible to grab the screen data like remotejoy does, but instead of sending it via USB, resize it and send it through the video out?
I suppose someone will eventually make a plugin for that. You'll just have to be patient and hope somebody feels it worthwhile enough to spend the time.
The data is not "sent". The tv-out gets it directly from the framebuffer.MysticWhiteDragon wrote:Couldn't it be possible to grab the screen data like remotejoy does, but instead of sending it via USB, resize it and send it through the video out?
The thing can be achieved by setting the DmaLcdcBaseAddr to your memory, destroying the function to avoid it being set again, and painting the screen (copying it to the true framebuffer that you set) in each vertical sync interrupt from the framebuffer that was set by sceDisplaySetFrameBuf but that didn't arrived to sceDmaLcdcSetBaseAddr because you avoided it.
I've done a test in which i simply copied the game framebuffer to my framebuffer (the "real" one), without scaling, just copying it like it is. It was TERRIBLY SLOW, even skipping some frames. Only in psx games the speed was fine (they use 16 bits color mode), but when i tried to do some scaling, the psx game also got slow.
Project canceled :)
gambiting wrote:I have EXACTLY the same problem - can you guide me how to do it???SamuraiX wrote:Hmm... Still not having any luck but it seems, correct me if I'm wrong. In order to support 720x480 some type of scaling needs to be put in place.
While I'm far from being a video expert it seems he is scaling the video to fit the TV's resolution via his texture_subdivision lib.
If that is the case then that seems to be what I'm missing. What I don't understand is why I see multiple images....
** Updated **
Yep, It seems that was the problem as I'm see much better results after manipulating the vertexs.
You can grab the source here: http://openbor.svn.sourceforge.net/viewvc/openbor/
Goto PSP directory then take a look at graphics.c/h
The implementation is based off of Cooleyes' graphic lib. But I found there was alot of overhead that was not needed for what I am doing. I also like having my Blit(s)toScreen perform their own start and flush unlike his version where he manages it within his application (Outside of graphics lib). Lastly, I did like how he managed his pointers for LCD or TV-Out and found it extremely efficient and easy to read!
Good Luck!
-
MysticWhiteDragon
- Posts: 30
- Joined: Thu Feb 16, 2006 8:46 am
I managed to get 32Bit interlaced mode to work in a test program at 10 frames per second using memcpy from the framebuffer to VRAM. Is there any speed advantage by pointing the VRAM to the framebuffer that is drawn and if so then how would I go about doing I do it?
It's based off of a port of the NeHe-GU tutorial on another site so I will just add the graphics.c I used.
graphics.c
It's based off of a port of the NeHe-GU tutorial on another site so I will just add the graphics.c I used.
graphics.c
Code: Select all
#include <string.h>
#include <stdio.h>
#include <malloc.h>
#include <pspkernel.h>
#include <pspdisplay.h>
#include <pspdebug.h>
#include <pspgu.h>
#include <pspgum.h>
#include <pspctrl.h>
#include <psprtc.h>
#include "graphics.h"
#include "CTimer.h"
u32* globalVramBase = (u32*)(0x40000000|0x04000000);
unsigned int __attribute__((aligned(16))) dList[262144];
static void* frameBuffer[2];
static int displayBufferNumber;
static int interlaced;
int BUFFER_WIDTH = 512;
int SCREEN_WIDTH = 480;
int SCREEN_HEIGHT = 272;
int tvmode = 0;
int cable = 0;
int pspDveMgrCheckVideoOut();
int pspDveMgrSetVideoOut(int,int,int,int,int,int,int);
void initGraphics()
{
displayBufferNumber = 0;
frameBuffer[0] = (void*)0x0a000000;
frameBuffer[1] = (void*)(0x0a000000 + 1572864);
sceGuInit();
sceGuStart(GU_DIRECT,dList);
sceGuDrawBuffer(GU_PSM_8888,(void*)0,BUFFER_WIDTH);
sceGuDispBuffer(SCREEN_WIDTH,SCREEN_HEIGHT,(void*)0, BUFFER_WIDTH);
sceGuDepthBuffer((void*)(BUFFER_WIDTH * SCREEN_HEIGHT * 4),BUFFER_WIDTH);
sceGuOffset(2048 - (SCREEN_WIDTH/2),2048 - (SCREEN_HEIGHT/2));
sceGuViewport(2048,2048,SCREEN_WIDTH,SCREEN_HEIGHT);
sceGuDepthRange(65535,0);
sceGuScissor(0,0,SCREEN_WIDTH,SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
sceGuDepthFunc(GU_GEQUAL);
sceGuEnable(GU_DEPTH_TEST);
sceGuFrontFace(GU_CW);
sceGuEnable(GU_CULL_FACE);
sceGuShadeModel(GU_SMOOTH);
sceGuEnable(GU_CLIP_PLANES);
sceGuFinish();
sceGuSync(0,0);
memset(frameBuffer[0],0,1572864);
memset(frameBuffer[1],0,1572864);
sceDisplayWaitVblankStart();
sceGuDisplay(GU_TRUE);
sceDisplaySetFrameBuf(frameBuffer[displayBufferNumber],768, PSP_DISPLAY_PIXEL_FORMAT_8888,PSP_DISPLAY_SETBUF_IMMEDIATE);
}
void checkCable()
{
cable = pspDveMgrCheckVideoOut();
}
void setTVMode(int mode)
{
switch(mode)
{
case 0:
SCREEN_WIDTH = 480; SCREEN_HEIGHT = 272; BUFFER_WIDTH = 512; interlaced = 0;
pspDveMgrSetVideoOut(0,0,480,272,1,15,0);
break;
case 1:
SCREEN_WIDTH = 720; SCREEN_HEIGHT = 480; BUFFER_WIDTH = 768; interlaced = 1;
pspDveMgrSetVideoOut(0,0x1d1,720,503,1,15,0);
break;
case 2:
SCREEN_WIDTH = 720; SCREEN_HEIGHT = 480; BUFFER_WIDTH = 768; interlaced = 0;
pspDveMgrSetVideoOut(0,0x1d2,720,480,1,15,0);
break;
case 3:
SCREEN_WIDTH = 720; SCREEN_HEIGHT = 480; BUFFER_WIDTH = 768; interlaced = 1;
pspDveMgrSetVideoOut(2,0x1d1,720,503,1,15,0);
break;
}
}
void SetupProjection()
{
sceGuStart(GU_DIRECT,dList);
sceGumMatrixMode(GU_PROJECTION);
sceGumLoadIdentity();
sceGumPerspective(75.0f,16.0f/9.0f,0.5f,1000.0f);
sceGumMatrixMode(GU_VIEW);
sceGumLoadIdentity();
sceGuClearColor(GU_COLOR(0.0f,0.0f,0.0f,1.0f));
sceGuClearDepth(0);
sceGuFinish();
}
void flipScreen()
{
// if (!initialized) return;
sceKernelDcacheWritebackInvalidateAll();
if(interlaced)
{
void* s0 = globalVramBase;
void* d0 = frameBuffer[displayBufferNumber];
void* d1 = d0 + 262*3072;
int i;
for(i = 0;i < 240;i++)
{
memcpy(d1,s0,3072);
d1 += 3072;
s0 += 3072;
memcpy(d0,s0,3072);
d0 += 3072;
s0 += 3072;
}
}
else memcpy(frameBuffer[displayBufferNumber],globalVramBase,1474560);
sceDisplayWaitVblankStart();
sceDisplaySetFrameBuf(frameBuffer[displayBufferNumber], 768, PSP_DISPLAY_PIXEL_FORMAT_8888, PSP_DISPLAY_SETBUF_IMMEDIATE);
displayBufferNumber ^= 1;
}
void guStart()
{
sceGuStart(GU_DIRECT,dList);
}
MysticWhiteDragon,
I have completed my update of the Graphics lib. It will now display Composite, Progressive and Interlaced modes. Feel free to reference my version. I ran a few test to see the performance of my graphics lib. Mind you these results are based on my own application.
LCD Screen: 200 fps
Component P: 197 fps
Component I: 120 fps
Composite: 120 fps
You will see that you get better fps with my implementation for Interlaced modes but there is no way to make it as fast as Progressive mode due to using system ram for interlacing and vram for progressive.
http://openbor.svn.sourceforge.net/viewvc/openbor/psp/
Good Luck!
I have completed my update of the Graphics lib. It will now display Composite, Progressive and Interlaced modes. Feel free to reference my version. I ran a few test to see the performance of my graphics lib. Mind you these results are based on my own application.
LCD Screen: 200 fps
Component P: 197 fps
Component I: 120 fps
Composite: 120 fps
You will see that you get better fps with my implementation for Interlaced modes but there is no way to make it as fast as Progressive mode due to using system ram for interlacing and vram for progressive.
http://openbor.svn.sourceforge.net/viewvc/openbor/psp/
Good Luck!
So, using your library could someone make a plug for the CFW to play games using the composite cable in TV.SamuraiX wrote:MysticWhiteDragon,
I have completed my update of the Graphics lib. It will now display Composite, Progressive and Interlaced modes. Feel free to reference my version. I ran a few test to see the performance of my graphics lib. Mind you these results are based on my own application.
LCD Screen: 200 fps
Component P: 197 fps
Component I: 120 fps
Composite: 120 fps
You will see that you get better fps with my implementation for Interlaced modes but there is no way to make it as fast as Progressive mode due to using system ram for interlacing and vram for progressive.
http://openbor.svn.sourceforge.net/viewvc/openbor/psp/
Good Luck!
I only have televisors that support composite and I'm sure there are a lot of people too, so that could be really good to could connect it to those tvs.
At least don't stop trying to do that project as I read DAX gave up with that.
Thanks!
No,no,no - his library only changes functions in graphic.h file,which I bet sony doesn't use :P And as for enabling composite output in official games....someone already did it,but result was something like 2-3 fps,so completely unplayable.You see,interlacing takes processor time,and cannot be used while simultaniously playing games.el_yind wrote:So, using your library could someone make a plug for the CFW to play games using the composite cable in TV.SamuraiX wrote:MysticWhiteDragon,
I have completed my update of the Graphics lib. It will now display Composite, Progressive and Interlaced modes. Feel free to reference my version. I ran a few test to see the performance of my graphics lib. Mind you these results are based on my own application.
LCD Screen: 200 fps
Component P: 197 fps
Component I: 120 fps
Composite: 120 fps
You will see that you get better fps with my implementation for Interlaced modes but there is no way to make it as fast as Progressive mode due to using system ram for interlacing and vram for progressive.
http://openbor.svn.sourceforge.net/viewvc/openbor/psp/
Good Luck!
I only have televisors that support composite and I'm sure there are a lot of people too, so that could be really good to could connect it to those tvs.
At least don't stop trying to do that project as I read DAX gave up with that.
Thanks!
Would it be possible to render just the even lines and then just the odd lines at next frame?
So instead of interlacing frame 1 into odd lines and even lines and then rendering it,
Render frame 1 with odd lines, render frame 2 with even lines. Output the interlaced picture directly.
Of course this will lower image quality but, this would not require any memory copying nor as much cpu-processing. Since the renderer would just render half of lines every time, the render speed would possibly make up for the sloppy "interlace".
The hard part to implement is a renderer that will be able to switch between rendering odd and even lines.
Just for fun:
The Voodoo 2 cards was able to render odd or even lines from a picture. This was used in SLI-mode where the odd and even lines from the cards were put together into the progressive image on screen.
So instead of interlacing frame 1 into odd lines and even lines and then rendering it,
Render frame 1 with odd lines, render frame 2 with even lines. Output the interlaced picture directly.
Of course this will lower image quality but, this would not require any memory copying nor as much cpu-processing. Since the renderer would just render half of lines every time, the render speed would possibly make up for the sloppy "interlace".
The hard part to implement is a renderer that will be able to switch between rendering odd and even lines.
Just for fun:
The Voodoo 2 cards was able to render odd or even lines from a picture. This was used in SLI-mode where the odd and even lines from the cards were put together into the progressive image on screen.
-
OldPrisoneR
- Posts: 53
- Joined: Thu Mar 20, 2008 2:33 am
Moonlight, couldn't you provide source code of ur test programm?moonlight wrote:The data is not "sent". The tv-out gets it directly from the framebuffer.MysticWhiteDragon wrote:Couldn't it be possible to grab the screen data like remotejoy does, but instead of sending it via USB, resize it and send it through the video out?
The thing can be achieved by setting the DmaLcdcBaseAddr to your memory, destroying the function to avoid it being set again, and painting the screen (copying it to the true framebuffer that you set) in each vertical sync interrupt from the framebuffer that was set by sceDisplaySetFrameBuf but that didn't arrived to sceDmaLcdcSetBaseAddr because you avoided it.
I've done a test in which i simply copied the game framebuffer to my framebuffer (the "real" one), without scaling, just copying it like it is. It was TERRIBLY SLOW, even skipping some frames. Only in psx games the speed was fine (they use 16 bits color mode), but when i tried to do some scaling, the psx game also got slow.
Project canceled :)
P.S: I've just written a little plugin which switches the psp TVout On (in composite mode), when you are in the game.
But the picture is not good :p
because of the FrameBuffer :(
For interlace mode we need interlaced frmbuffer(240,22,240,1), Am I right?)
P.S.S:I've tested it with God of War, FlatOut and Patapon.
Speed was fine, surely playable!
With PS1 games (Tekken3) speed was not perfect (I think I now why :P)
All tests were done with 222MHz!
Hello,
the case is that i used moonlight dve sample for making my homebrew display on a big screen but compilers say that:
main.c:(.text+0xd04): undefined reference to `pspDveMgrCheckVideoOut'
main.c:(.text+0xd6c): undefined reference to `pspDveMgrSetVideoOut'
main.c:(.text+0x10b0): undefined reference to `pspDveMgrCheckVideoOut'
but those functions are included here:
int pspDveMgrCheckVideoOut();
int pspDveMgrSetVideoOut(int u, int mode, int width, int height, int x, int y, int z);
But im not sure excatly what part of code is important to changing to TV(coz' the sample display some random colors that I don't need anyway).
here's the psp-to-tv-changing-code:
the case is that i used moonlight dve sample for making my homebrew display on a big screen but compilers say that:
main.c:(.text+0xd04): undefined reference to `pspDveMgrCheckVideoOut'
main.c:(.text+0xd6c): undefined reference to `pspDveMgrSetVideoOut'
main.c:(.text+0x10b0): undefined reference to `pspDveMgrCheckVideoOut'
but those functions are included here:
int pspDveMgrCheckVideoOut();
int pspDveMgrSetVideoOut(int u, int mode, int width, int height, int x, int y, int z);
But im not sure excatly what part of code is important to changing to TV(coz' the sample display some random colors that I don't need anyway).
here's the psp-to-tv-changing-code:
Code: Select all
//tv
int pspDveMgrCheckVideoOut();
int pspDveMgrSetVideoOut(int u, int mode, int width, int height, int x, int y, int z);
int cable, u, width, height, displaymode;
pspDebugScreenInit();
if (sceKernelDevkitVersion() < 0x03070110)
{
oslFatalError("This program requires 3.71+.\n");
}
if (pspSdkLoadStartModule("dvemgr.prx", PSP_MEMORY_PARTITION_KERNEL) < 0)
{
oslFatalError("Error in load/start module.\n");
}
cable = pspDveMgrCheckVideoOut();
if (cable == 0)
{
printf("Insert a videoout cable.\n");
while (cable == 0)
{
sceKernelDelayThread(10000);
cable = pspDveMgrCheckVideoOut();
}
}
if (cable != 1 && cable != 2)
{
oslFatalError("Unknown cable %d.\n", cable);
}
if (cable == 1) // composite, sdtv
{
u = 2;
width = 720;
height = 503;
displaymode = 0x1D1;
}
else // 2, component, (and probably d-terminal too)
{
u = 0;
width = 720;
height = 480;
displaymode = 0x1D2;
}
pspDveMgrSetVideoOut(u, displaymode, width, height, 1, 15, 0);