May 2, 2012 at 3:44 PM
Edited May 3, 2012 at 4:29 PM
"Does the PSP not implement FILE *, fopen, and the likes? If so you're going to have to rework lots of things, sendfile.c and var.c being the most important ones, if you want to load a ROM"
Actually no, sony implemented their own functions. but it's necessary since there are different drives on the psp: internal storage (for the pspgo only), flash card, flash0 (holding all modules like the one which handles the wlan), flash1 (mostly user settings
as PSN password (not encrypted !!!)), flash2 (blahblahblah...).
I think it won't be that hard to change but I actually didn't look how you handle this, if you dump the whole file to the buffer to process this or if you do much reads to the file.
"Timer *timer = CreateTimer(TPF, TimerFunc, (LPVOID) lpCalc);
Sony does also have their own functions for that and they don't work in the same way but it shouldn't be hard to handle.
"I don't know, you'll have to play with it. I think some users will prefer one way, some the other. Make it an option eventually, but code it whatever way is easiest to start. I personally like the idea of a custom V200 style skin, but that's extra work
of course :P"
Probably :P I'll first try to get the emulator to work (without skin or anything) before doing the GUI ;)
What do you mean by "lcd->active" ?
Do you mean if the calculator is active or ?
By the way, psp has two memorys for image processing: the RAM and the VRAM. The VRAM is the GPU internal's ram and it is faster than the RAM. Counter part is that it's only 4mb size so it should be used only for images that are often used. I've calculated
that the the array's image of the calculator is actually 65 536 bytes. That's not much, so I think the best is to put it directly in the GPU's buffer.
Does this return directly the black and white screen or does it return the screen according to the contrast and the font (green) ?
I found the image formats accepted by the library I'll use:
Defines the screen resolution.
- OSL_PF_8888: 32-bit render, very precise and nice, especially when it comes to gradients. However requires twice the memory required by the 16-bit mode (1088 kilobytes in double buffer
mode, half in single buffer mode). Also uses more bandwidth and thus is slower.
- OSL_PF_5650: 16-bit render, can only display 65 thousand colors instead of 16 millions. Requires 544 kB in double buffer mode, and half in single buffer mode. It's the recommended mode.
Use oslSetDithering to simulate more colors with dithering."
Since I don't use visual studio, can I delete this with no problem ? (is this really need for the program?) "#include "stdafx.h"
Red = (0x9E*(256-i))/255;
Green = (0xAB*(256-i))/255;
Blue = (0x88*(256-i))/255;
I didn't understand it, but explain me on Gtalk.
I accepted you on Gtalk.
-display an img from memory: void oslDrawImage(OSL_IMAGE *img);
-create an img to memory (returns an OSL_IMAGE *): oslCreateImage(int larg, int haut, short location, short pixelFormat); <-- location can be either OSL_IN_VRAM or OSL_IN_RAM, pixelFormat can be either