Author Topic: Visual Studio 2005 Project Files and Patch  (Read 4876 times)

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Visual Studio 2005 Project Files and Patch
« on: 2006-09-22 20:37:08 »
I checked the svn today and saw you changed the structure to add support for xenogears, so I built new project files, this time for vs2005.

I only had to add 3 #ifdef blocks to make it work, and none of them change the code too much:
One in DisplayOgl.cpp, to make it include windows.h before gl.h
One in Main.cpp to "rename" main() to SDL_main, so it links correctly using SDL
One in StdString.h because vc doesn't have a va_copy function, and it has _snprintf isntead of snprintf

That means the code is (should be) 100% compatible with other compilers.

To build it you need win32 versions of libxml, libiconv and zlib (all with binary builds available) configured in the vs2005 C++ paths.

http://bin.mypage.sk/FILES/vs2005.zip

EDIT: forgot to say: the project files and the patch should be in trunk/src/ (the patch doesn't need to be there, but you need to CD there to use patch)

EDIT2: in case someone wants to use it, but has trouble with the libs, just tell me and I will upload the ones I used.
« Last Edit: 2006-09-22 20:41:44 by gigaherz »

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Visual Studio 2005 Project Files and Patch
« Reply #1 on: 2006-09-23 05:25:05 »
Thank you for this.

Where there any problems running the current state of the system?
And yes Akari added Xenogears fs support and some other things.
Hopefully I can get my ISO9660 support to work a bit better for it to be reintegrated :D

Cyb

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Visual Studio 2005 Project Files and Patch
« Reply #2 on: 2006-09-24 13:48:44 »
I don't have my ff7(psx) discs in here so I can't test it. When I get them back I will look at it.

I tried Xenogears (NTSC/US CD1) and the map renderer seems to work fine.

Has anyone thought about using psx emulator plugins for the cd reading? That would make it really simple to read the data directly from the cdrom drive.
I could do it for windows, it's easy, but I never used dynamically loaded libs in linux, so I wouldn't be able to make it portable (and AFAIK, linux doesn't need that anyway).

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Visual Studio 2005 Project Files and Patch
« Reply #3 on: 2006-09-24 17:57:29 »
I don't have my ff7(psx) discs in here so I can't test it. When I get them back I will look at it.

I tried Xenogears (NTSC/US CD1) and the map renderer seems to work fine.

Has anyone thought about using psx emulator plugins for the cd reading? That would make it really simple to read the data directly from the cdrom drive.
I could do it for windows, it's easy, but I never used dynamically loaded libs in linux, so I wouldn't be able to make it portable (and AFAIK, linux doesn't need that anyway).
Hmmm there are a few problems as you've guessed for Linux and other platforms.  Linux CD-ROM system is limited in the mode of reading that is supported although there are some alternative ways to do this.  The main problem comes with reading XA data off the CD-ROM which requires reading the sectors in RAW mode only.  This is why the ISO9660 FS support is being worked on.  This will also allow it to be migrated to other platforms more easily.
The data on the PS1 CDs that requires the special reading are the movies and in particular there audio data.

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Visual Studio 2005 Project Files and Patch
« Reply #4 on: 2006-09-25 00:54:59 »
With Linux PSX emulation, CD reads are not done with a plugin. We just provide the raw device and the emulator reads it directly. In a nutshell, this means that the plugin was "moved" to the driver in kernel space.

Windows can't nativly read a drive directly, that's why you need the plugin.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Visual Studio 2005 Project Files and Patch
« Reply #5 on: 2006-09-25 02:28:47 »
Hmm it's never worked right on my linux box. Kernal version 2.4 I suppose might be the problem?
Oh well until I figure that out I'll work with ISO9660 FS stuff and that will satisfy a lot of things (other than Linux and Windows being the primary platform).

Which reminds me I should WORK on it DOH!

Cyb - the extremely forgetful

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Visual Studio 2005 Project Files and Patch
« Reply #6 on: 2006-09-25 02:35:34 »
For the last five weeks I've been trying to find a new job, with little luck.

In the 14th on next month, I'll be going to Seattle for a week to see if there are jobs there...

I'll get stable one day. I feel like I'm negelting my responsibility again.

Dasaan

  • Guest
Re: Visual Studio 2005 Project Files and Patch
« Reply #7 on: 2006-09-25 17:57:02 »
Hmm it's never worked right on my linux box. Kernal version 2.4 I suppose might be the problem?

I'd guess that 2.4.x is the problem 2.6.x has changed a *lot* and some things simply can't be backported due to the neccessary infrastructure not being there.

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Visual Studio 2005 Project Files and Patch
« Reply #8 on: 2006-09-25 20:08:26 »
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.

Code: [Select]
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;
}
« Last Edit: 2006-09-27 13:43:24 by gigaherz »

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Visual Studio 2005 Project Files and Patch
« Reply #9 on: 2006-09-28 18:40:47 »
The build from akari made me realise qgears is supposed to be a console app. SDL_main seems to setup file pointers to "stdout.txt" and "stderr.txt" when you link as windowed (no console), so it works both ways. Given ppl usually doesn't need to see the console when they aren't debugging, I don't think I need to change that (anyone who wants to debug using my project files can go to project properies->linker->system and set it to console).

Sorry if you are against double-posting, but IMO, my previous post was getting too long.