Hi,
First of all, I'm sorry if I'm asking something stupid, it's not my intention (yes, that will cover my face from the punches xD).
I'm currently working on the Sam emulator of Antonio (it's really good). The primary goal is to make it run homebrew software (we all know that it will save us time) but I didn't found any documents about the gpu.
For example, pspDebugScreenPrintf will print text on screen by writing the video memory but...
Does sceGumDrawArray (for example) do the same?
At first Antonio was replacing all the video memory with the contents of the buffer of OpenGL this was resulting in no output of any "pspDebugScreenPrintf" so I decided to do an "or" between the pixels and that solve part of the problem but at the end I decided to blit them separately because it would be more like what the psp does.
Anyway, this fix is just to "look like" what the psp does, but I want it to be more accurately.
Here are more information about everything:
-Sam is coding on c++ using Borland compiler (Antonio is using borland, I've never used it) and MinGW (gcc) on windows xp
-The OpenGL output is saved in an off-screen buffer to being lately blit together with the psp video memory (we're using glReadPixels). The resulting buffer the is then written to an "unsigned char" buffer and then StretchDIBits put it on screen.
-I've a psp slim with cfw5.00-m33. As I said in another post, I've been doing some demos/games on it all these months and updating the emulator on the fly because of these demos/games.
That's all, I guess. Please, If I'm wrong, let me know.
Many thanks in advance.
how the gpu works
how the gpu works
---------------------------------------------------------
if you wanna survive you better learn how to lie
if you wanna survive you better learn how to lie
pspDebugScreenPrintf will always work as long as the display is initialized because it writes to the display buffer (this doesn't need to be in video memory, it can even be allocated in main memory). There are applications which use main memory for the display buffer, such as those which use the video out.
If the currently running application is using the GU and it swaps the draw and display buffers, then the text will disappear. Basically pspDebugScreenPrintf has to be called to redraw the text in the display buffer every time it changes.
Frankly you shouldn't be working on a function specific level at all...
Since the writing to display buffer approach is independent of the flipping rate, the only way to make it "Accurate" would be to make the update the psp display buffer to the pc display buffer as often as possible.
If the currently running application is using the GU and it swaps the draw and display buffers, then the text will disappear. Basically pspDebugScreenPrintf has to be called to redraw the text in the display buffer every time it changes.
Frankly you shouldn't be working on a function specific level at all...
Since the writing to display buffer approach is independent of the flipping rate, the only way to make it "Accurate" would be to make the update the psp display buffer to the pc display buffer as often as possible.
Thanks for the reply!
As you said, the emulator right now is doing that.
It will run a few ops and then it will blit the buffers (in the case of OpenGL will use the last rendered frame).
Maybe what the emulator is doing right now is ok, but I want to be sure.
The problem is if you want to capture the screen pixels (on the emulator and because you need to do that in your project) you will get the display buffer only contents and because of my fix the polys will be in another buffer.
Here is some kind of diagram of this:
display buffer (set by app)--| pc display buffer
opengl buffer --|
As you can see they don't blit each other, they join directly the pc display buffer by an "or" so the stuff drew by GU calls won't be at the display buffer address set by the application only those who write the memory like "pspDebugScreenPrintf" will be there.
If you want, you can check the code at: http://emu-sam.googlecode.com/
It's on the file named "lgpu.cpp".
Regards
As you said, the emulator right now is doing that.
It will run a few ops and then it will blit the buffers (in the case of OpenGL will use the last rendered frame).
Maybe what the emulator is doing right now is ok, but I want to be sure.
The problem is if you want to capture the screen pixels (on the emulator and because you need to do that in your project) you will get the display buffer only contents and because of my fix the polys will be in another buffer.
Here is some kind of diagram of this:
display buffer (set by app)--| pc display buffer
opengl buffer --|
As you can see they don't blit each other, they join directly the pc display buffer by an "or" so the stuff drew by GU calls won't be at the display buffer address set by the application only those who write the memory like "pspDebugScreenPrintf" will be there.
If you want, you can check the code at: http://emu-sam.googlecode.com/
It's on the file named "lgpu.cpp".
Regards
---------------------------------------------------------
if you wanna survive you better learn how to lie
if you wanna survive you better learn how to lie
It depends on the application.
The unlikely case is when an application uses only a single buffer (the display buffer), i.e. you draw into the display buffer. In this case, if using GU functions, then buffer MUST be in video ram. Any drawing to the display buffer, using either software or GU will show on screen. I assume that this will work properly even in the emulator.
If the application uses two buffers at address X and address Y.
When the display buffer is set to Y, the hardware will continuously update the screen with the data at Y all the time, whether the application is running or not.
When using software draw function like debug print, it must first find the display buffer address (it can be either X or Y at that moment) and then draw into the found address. This will show on the screen immediately. You must find the address every time you draw because you don't know which address the display hardware is mapped to since the program may flip any time.
When using double buffers, the GU functions are made to draw into the other buffer (which ever is NOT the current display buffer). These drawings will NOT appear on the screen until you call the set display buffer function to the address of this buffer.
So the emulator must detect whenever the display buffer is changed to the other buffer and it should now blit THIS buffer to the PC dispay buffer. This way GU as well as software drawing will show.
The unlikely case is when an application uses only a single buffer (the display buffer), i.e. you draw into the display buffer. In this case, if using GU functions, then buffer MUST be in video ram. Any drawing to the display buffer, using either software or GU will show on screen. I assume that this will work properly even in the emulator.
If the application uses two buffers at address X and address Y.
When the display buffer is set to Y, the hardware will continuously update the screen with the data at Y all the time, whether the application is running or not.
When using software draw function like debug print, it must first find the display buffer address (it can be either X or Y at that moment) and then draw into the found address. This will show on the screen immediately. You must find the address every time you draw because you don't know which address the display hardware is mapped to since the program may flip any time.
When using double buffers, the GU functions are made to draw into the other buffer (which ever is NOT the current display buffer). These drawings will NOT appear on the screen until you call the set display buffer function to the address of this buffer.
So the emulator must detect whenever the display buffer is changed to the other buffer and it should now blit THIS buffer to the PC dispay buffer. This way GU as well as software drawing will show.
For the emulator you need to do two things:
- Handle 156/157 GE instruction to set the current offscreen draw buffer. This is will GE will render to.
- Handle sceDisplaySetFrameBuf to set the current display buffer. This is used in sceGuSwapBuffers.
Apps using both pspDebugScreen and GU will be using the return value from sceGuSwapBuffers to always draw to the active display buffer.
- Handle 156/157 GE instruction to set the current offscreen draw buffer. This is will GE will render to.
- Handle sceDisplaySetFrameBuf to set the current display buffer. This is used in sceGuSwapBuffers.
Apps using both pspDebugScreen and GU will be using the return value from sceGuSwapBuffers to always draw to the active display buffer.
(+[__]%)