The Q-Gears Linux thread

[halkun]

Ok, This weekend I'm sitting on the "big computer" and have the goal to get the linux side somewhat stable.

Here a list of things on my plate..

1) Get the system compile.
2) iron out the resulting segfaults.
3) Take a hard look at mounting the PSX medium - I'm going to elaborate on this.

For the longest time, I have not been able to mount PSX media on linux using anything other than a select number of CD-ROMS. This is mostly because automount (and mount for that matter) takes a whole bunch of assumptions about the disk and tries to mount it as a mode 1 disk, when in fact it's mode 2. After getting the segfaults to stop, I'm going to see what we can do on the linux side to be able to seemlessly load the data. Do you think Linux could use an installer? How about a Q-Gears installer in general? This might save a lot of headaches if we simply pull the files directly off the disk. The only snag I see in this is that the movies are "entrenched" with XA data, and on the wondows side (That can, for some reason, correctly mount a mode 2 disk), are "unrippable" without directly reading the disk.

I'm really likeing the installer idea for the program in general. this has a bunch of advantages.

1) when installed on the hard drive, we can access the files with simple file open commands across platforms.
2) We can check for media (by running the installer first) and let the use know the original disks are needed.
3) We can build the run directloy with the installer, placing in it all the biniaries and support files needed to run the game.

Downsides.

1) Once again, UNIX-like systems are case-sensitive, and will cause problems if, for some reason, the case isn't preserved.
2) All the work done for the direct ISO reader in the filesystem class would be worthless.

Anyways, chat about this. I'm going to checkout a new copy of the code via SVN and see what I can come up with.

***EDIT***

Ok, I got this to *FINIALLY* work!

Akari, you did an awesome job. I feel really honored that you are part of the team. As it would seem, Q-Gears doen't know how to die correctly when there is a show-stopping error. The Linux segfaults were the result of not having a savemap to read from (I solved this by adding the savemap to SVN) I also made some tweaks to the code so that it will compile correctly under linux.

If Q-gears hits a show-stopping bug, such as a file missing, it needs to stop and exit The assertions are getting caught, but nothing happens besides a quick note in the game log and the next thing you know it's flinging around null pointers. I'm also nitpicking, but the walkmesh doesn't seem to be *exactly* lined up with the view. That's a silly cosmetic bug that I will blissfully ignore as it's bound to be solved later.

Also, with win32 version needs to have the Square data removed from it. We can't be distributing Square's stuff! It'si going to land us in trouble.

I'm going to hold off in the installer stuff and play with the core code a bit. Now that I have the linux side to compile, I'm going to look at some of the more intresting program flow stuff.

Comments?

[gigaherz]

"Do you think Linux could use an installer?" << The way linux is, you might need 4 installers or more... just only the diff rpm-based distributions might need diff installers!

You could obviously do a generic one, without using the packaging system, like just the "make install" part, in a tar.bz2
What would be nice would be a configuration script...

something like qgears-config.sh...

Welcome to the Q-Gears configuration wizard.

Please sepecify where the FF7 files are: /mnt/cdrom
Ok, good, this path seems to have FF7 data.

Do you want to configure other engines? No
No? Oh well then I'm done here...

Writing configuration file... done.

Do you want to run Q-Gears now? Yes
Ok!

Starting Q-Gears FF7 engine...


EDIT: Forgot to say, I can code that, if you want me to (I'm not a linux user right now, but cygwin's bash works just as well).

[Hades]

I am so happy. Could anyone do a screencast, of the current application running as sometimes its hard to follow progress here.
I'm sure there are plenty of people who browse this forum in anticipation who would love to see this.

[Cyberman]

If Q-gears hits a show-stopping bug, such as a file missing, it needs to stop and exit The assertions are getting caught, but nothing happens besides a quick note in the game log and the next thing you know it's flinging around null pointers. I'm also nitpicking, but the walkmesh doesn't seem to be *exactly* lined up with the view. That's a silly cosmetic bug that I will blissfully ignore as it's bound to be solved later.

This was discused when I was getting Q-gears to work myself.  These are actually bugs.  For example Q-gears does not check for GLX (or mention it on the command prompt), instead it runs and freezes because it can't find GLX.   They aren't serious bugs really, they are the boring mundane bugs that aren't fun to fix LOL.  Startup needs normal sanity checks, however the LOG FILE is a very unreliable method for finding what the program is doing. It's quite handy but, it assumes far too much.  Namely that someone has write access or the program does.  Granted I have been burried in anoying things myself recently. The real thing that does bother me on start up is no checking for the file system and reporting to the command prompt whats up.  That is really the best way.  You can't spam the user with a lot of things either.   A critical error is not being able to use OpenGL this is not a fatal error.  Yes we need a graceful exit too.  I would like to have a map of the program flow in Q-gears so I could follow it. (LOL)

Also, with win32 version needs to have the Square data removed from it. We can't be distributing Square's stuff! It'si going to land us in trouble.

I'm going to hold off in the installer stuff and play with the core code a bit. Now that I have the linux side to compile, I'm going to look at some of the more intresting program flow stuff.

Comments?

Removing all copyrighted/trademarked material from distribution and from the SVN would be prudent.  (first thing)  Next would be to set up a daily commit policiing or something along that line, too keep any such material from reappearing.  Q-gears needs to run with the media set that the person trying it has.  We might want to create some utilities as you were thinking to 'yank' the necessary files from the PS1 CD's. Most of the files are in MODE1 on the CD.  The STR/MOV files as far as I know are the only ones that might require Mode 2 access.  For the Windows system it might be good to make the same utility set (only for windows). Until such utilities are available some instructions need to be written on what Q-gears needs and expects to show pretty pictures.  I suppose in ernest I should actaully finish the ISO9660 image file code. (Well it's done just have a hard time keeping up with Akari's changes ).  I plan on redoing the code in any case to make it return sane things.

Cyb

[Dasaan]

Personally I'd like to see an installer as it'd save a little disk swapping and would, I'd hope, give better performance. Not to mention make it a bit easier for end users to get q-gears up and running.