Yeah I know about block devices. Reading the user data in a cdrom should be as easy as opening "/dev/cdromX" or something similar, but I don't know if you can "tell" the device to use raw (2352 bytes) sectors, I suppose it's some ioctl call or something.
In windows you can't do that so easily, but you can open cdroms in raw mode using IOCTL (in win2k and newer), and also send SCSI commands. That's why I suggested the plugin system used in most psx emulators, so you don't have to code all that again (and users can choose the plugin that works best in their system).
Using an internal ISO9660 parser is fine anyway, specially since we also need raw reading for Xenogears, and using an external plugin won't affect that xcept in the way you read the data (you would need to call the plugin instead of using the f* functions or whatever you use), and it's also easy to give it an internal ISO image reader, and "link" the function pointers to it when no external plugin is used.
EDIT:
I got some files from a friend (while I wait for my ff7 discs), and tried to run qgears/ff7.
I only have INIT/KERNEL.BIN, INIT/KERNEL2.BIN and WINDOW.BIN. It crashes in OpcodesToRawScript, and I don't know if it's missing data, or the scripts part is still too buggy.
EDIT2:
Ok I kicked my lazyness out for a while and debugged the crash, and found out I was missing startmap.dat. That didn't seem to fix the problem though. It's not really a crash, the debug runtime detects an improper access to an unused memory location arround the variable "hex" (debug runtime checks areas surrounding allocated buffers and variables for invalid writes).
I narrowed down the problem to this:
u8 hex = 0x00;
sscanf(value.c_str(), "%02x", &hex);
sscanf is writing 32 bits to hex, when it's only 1 byte! so I changed the type to u32 for safety.
That solved the debug exceptions. After that, I then found out I also "needed" md1stin.dat, and that's all the story, it works well (at least the wireframe thing).
EDIT3:
I thought about a nicer way to do the project structure, it would simplify the editing and make building faster:
My project files have all the files needed for each project included, that means, if you compile both, you are compiling /common/ twice.
I will make "common" be a static library included brom both projects.
I'm going to bed now, I will do this tomorrow when I get up.
EDIT4:
New project files with common in a static lib.
http://bin.mypage.sk/FILES/vs2005-2.rar(this rar file doesn't include any patch, just new project files)
I don't know if the game also does this in the linux builds, but the dialogs were showing all black (no gradient).
I made the Gamestate constructor initialize them to blue gradient. As it can be later changed by the game scripts, it seems to be a good default value.
Gamestate::Gamestate()
{
mSavemap.WindowRGBUpperLeft[0] = 0; mSavemap.WindowRGBUpperLeft[1] = 0; mSavemap.WindowRGBUpperLeft[2] = 192;
mSavemap.WindowRGBUpperRight[0]= 0; mSavemap.WindowRGBUpperRight[1]= 0; mSavemap.WindowRGBUpperRight[2]= 128;
mSavemap.WindowRGBLowerRight[0]= 0; mSavemap.WindowRGBLowerRight[1]= 0; mSavemap.WindowRGBLowerRight[2]= 64;
mSavemap.WindowRGBLowerLeft[0] = 0; mSavemap.WindowRGBLowerLeft[1] = 0; mSavemap.WindowRGBLowerLeft[2] = 128;
}
Show Posts
)
