Back to the ISO system

[Cyberman]

All right I have a few hours to work on this at my will so a few questions

1) Is autoconfig working? IE can I do ./configure and let Q-gears compile happily?

2) For autoconfig I will be ADDING code, so what do I need to do to make things compile happily and without much duress?
(I recomend giving a website with Autoconfig config et al for dummies and then a more detailed site.  As likely I will want to do a test of adding a file to the source and then incrementally add them).

The ISO FS code has been done for a while, I just never kept up with the constant flux of changes nor could I get Q-gears to natively compile on my developement machine.  Therefore tips on integrating the code and or making it work would be muchly appreciated.

3) Is anyone working on the battle model/engine? I have put some information on the PS1 models up.  However the animation format is the Achiles heel of all my work.  I know it was deciphered a while back.   I'm just wondering if any has bothered to put it in the ussual repository or if someone (IE me) will have to work through it and put it in the repository.

4) I'll be working on the PS1 FF8 image file information.  Since I have the ISO9660 information well ingrained into my head this shouldn't take too long. The background format will be a bit fun I suspect.  I already partly understand the battle and field model format used as well.  Ahem.

5) Do we need any specific documentation made for Q-gears. It appears we have volumes of source code but the documentation I canna find

The Q-gears Logo project is a work in progress as well.

See I'm doing things, just not what I expected too!

Cyb - (life is a series of deviations on our deviations from our deviation from the main point... which might be a deviation as well)

 

[einherjar]

1) Is autoconfig working? IE can I do ./configure and let Q-gears compile happily?

The autoconf/automake structure does work, but the generated files are not (and shall not)
on the repository, so you will have to do the following to compile q-gears happily:

From q-gears/trunk/HACKING:
Code: [Select]

$ svn co q-gears$ cd q-gears/trunk$ ./bootstrap$ ./configure$ make

The thing that differs from a distchecked' tarball is "./bootstrap", which invokes
autoconf and automake. So you (and everyone else actually) will need
automake version 1.9.6 or later and autoconf 2.59 or later.

This is the "way of the developper"; an end-user should only download a
distchecked tarball and "./configure && make"

2) For autoconfig I will be ADDING code, so what do I need to do to make things compile happily and without much duress?

Just edit "common/Makefile.am", "ffvii/Makefile.am" or "xeno/Makefile.am",
modifying the variables "libcommon_la_SOURCES", "q_gears_ffvii_SOURCES" or "q_gears_xeno_SOURCES",
respectively. You should only have to duplicate what you see

(I recomend giving a website with Autoconfig config et al for dummies and then a more detailed site.  As likely I will want to do a test of adding a file to the source and then incrementally add them).

http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html

Here you will find links to autoconf's and automake's manuals,
as well as a good (... maybe too much detailed) tutorial (look at "Using Automake",
page 295)

The ISO FS code has been done for a while, I just never kept up with the constant flux of changes nor could I get Q-gears to natively compile on my developement machine.  Therefore tips on integrating the code and or making it work would be muchly appreciated.

I hope you will be fine with the information above.

3) Is anyone working on the battle model/engine? I have put some information on the PS1 models up.  However the animation format is the Achiles heel of all my work.  I know it was deciphered a while back.   I'm just wondering if any has bothered to put it in the ussual repository or if someone (IE me) will have to work through it and put it in the repository.

(I am not)

 

[Cyberman]

>= libxml2.0
SDL  >= 1.28
libGL
GLU
ODE <-- Open Dynamics Engine (Cough)

Just in case, hmmm I miss anything odd there?

my only area of non compilation is with the Linux CDXA driver it seems to be
 error: no matching function for call to `cdrom_msf::cdrom_msf(unsigned char*)
Hmmm this mean my kernel is too old for it? Shouldn't such information be detectable by ./configure?

Cyb

Thanks so far I've only had to reinstal libXML and install ODE

 

[halkun]

When did ODE become a dependency?

Why do we need a Physics SDK?

Looking at the HOWTO, FF7 doesn't need ragdolls or gavity guns....

What exactly is this for? If it's for articulating the models, what was wrong with doing it ourselves, or using something a little less extreme?

I don't want to bloat the poor program... I'm already getting emails on how people would like to see a PSP port in the future....(not that I'm saying that should be a goal, but it's gonna look odd when the original system it was designed for was a around the same power as a DS)

 

[Akari]

When did ODE become a dependency?

Why do we need a Physics SDK?

Looking at the HOWTO, FF7 doesn't need ragdolls or gavity guns....

ODE was used for collision detection (line/box intersection). But since we know that there are no box in FFVII but range I rework all walkmesh/collision detection system and remove ODE dependency.

 

[Cyberman]

Woops? Did I open a can of worms?
(hides ducks blames halkun)

I guess this is a good thing, ( we need more rag dolls halkun the old fade the dead thing out is so like passe'! ) in any case I guess I shouldn't need ODE to compile it? (For now at least )

Ahem .. so for linux CDXA support I need to do what? And shouldn't automake be able to decipher which kernel version and options should be available for it not making a mess?

Cyb

 

[einherjar]

Ahem .. so for linux CDXA support I need to do what?
And shouldn't automake be able to decipher which kernel version and options should be available for it not making a mess?

Autoconf already checks if linux/cdrom.h is available on the system, I just did not imagine there could be
a version of linux/cdrom.h that does not have cdrom_msf (which actually is defined in the said file since
version 1.2.13 of the kernel Could you please show me the whole error message?).

I agree on the option to disable its building. I should be able to add it in the following hours.

 

[Cyberman]

All right here is the output, I'm current trying to get my ISO code working right on windows. <Mutter> I think the ISO9660 system is evil

Code: [Select]

make[3]: Entering directory `/home/cyberman/workspace/q-gears2/q-gears/trunk/src/common'if /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../..  -I ../../src -I ../../src -I/usr/include/libxml2     -O3 -g -O2 -Wall -W -fpermissive -pipe -MT filesystem/driver/libcommon_la-LinuxCDXAFileDriver.lo -MD -MP -MF "filesystem/driver/.deps/libcommon_la-LinuxCDXAFileDriver.Tpo" -c -o filesystem/driver/libcommon_la-LinuxCDXAFileDriver.lo `test -f 'filesystem/driver/LinuxCDXAFileDriver.cpp' || echo './'`filesystem/driver/LinuxCDXAFileDriver.cpp; \then mv -f "filesystem/driver/.deps/libcommon_la-LinuxCDXAFileDriver.Tpo" "filesystem/driver/.deps/libcommon_la-LinuxCDXAFileDriver.Plo"; else rm -f "filesystem/driver/.deps/libcommon_la-LinuxCDXAFileDriver.Tpo"; exit 1; firm -f filesystem/driver/.libs/libcommon_la-LinuxCDXAFileDriver.log++ -DHAVE_CONFIG_H -I. -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -O3 -g -O2 -Wall -W -fpermissive -pipe -MT filesystem/driver/libcommon_la-LinuxCDXAFileDriver.lo -MD -MP -MF filesystem/driver/.deps/libcommon_la-LinuxCDXAFileDriver.Tpo -c filesystem/driver/LinuxCDXAFileDriver.cpp  -fPIC -DPIC -o filesystem/driver/.libs/libcommon_la-LinuxCDXAFileDriver.lofilesystem/driver/LinuxCDXAFileDriver.cpp: In member function `virtual bool LinuxCDXAFileDriver::ReadFile(const RString&, void*, unsigned int, unsigned int)':filesystem/driver/LinuxCDXAFileDriver.cpp:146: error: no matching function for call to `cdrom_msf::cdrom_msf(unsigned char*)'/usr/include/linux/cdrom.h:169: error: candidates are: cdrom_msf::cdrom_msf()/usr/include/linux/cdrom.h:169: error:                 cdrom_msf::cdrom_msf(const cdrom_msf&)filesystem/driver/LinuxCDXAFileDriver.cpp:160: warning: pointer of type `void *' used in arithmeticfilesystem/driver/LinuxCDXAFileDriver.cpp: In member function `bool LinuxCDXAFileDriver::ReadPrimaryVolumeDescriptor(int, int, iso_primary_descriptor&) const':filesystem/driver/LinuxCDXAFileDriver.cpp:248: error: no matching function for call to `cdrom_msf::cdrom_msf(unsigned char*)'/usr/include/linux/cdrom.h:169: error: candidates are: cdrom_msf::cdrom_msf()/usr/include/linux/cdrom.h:169: error:                 cdrom_msf::cdrom_msf(const cdrom_msf&)filesystem/driver/LinuxCDXAFileDriver.cpp: In member function `bool LinuxCDXAFileDriver::ReadDirectory(int, int, unsigned int, const RString&, std::set<LinuxCDXAFileDriver::FileEntry*, LinuxCDXAFileDriver::FileEntry::filename_lt, std::allocator<LinuxCDXAFileDriver::FileEntry*> >&) const':filesystem/driver/LinuxCDXAFileDriver.cpp:290: warning: comparison between signed and unsigned integer expressionsfilesystem/driver/LinuxCDXAFileDriver.cpp:295: error: no matching function for call to `cdrom_msf::cdrom_msf(unsigned char*)'/usr/include/linux/cdrom.h:169: error: candidates are: cdrom_msf::cdrom_msf()/usr/include/linux/cdrom.h:169: error:                 cdrom_msf::cdrom_msf(const cdrom_msf&)make[3]: *** [filesystem/driver/libcommon_la-LinuxCDXAFileDriver.lo] Error 1make[3]: Leaving directory `/home/cyberman/workspace/q-gears2/q-gears/trunk/src/common'make[2]: *** [all-recursive] Error 1make[2]: Leaving directory `/home/cyberman/workspace/q-gears2/q-gears/trunk/src'make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/home/cyberman/workspace/q-gears2/q-gears/trunk'make: *** [all] Error 2

I think the issue might be that Mandriva doesn't include everything they should. I know I had to install hundreds of things after trying to compile something like GTK,  it's quite anoying when they want you to get there 'distribution with all the stuff they should have on the normal one' for a fee.

Cyb

 

[einherjar]

Please try the following and let me know if it kills the first error:

Code: [Select]

// LinuxCDXAFileDriver.cpp: line 146// lba_to_msf(entry_lba, (cdrom_msf_t &) raw_data); // trickylba_to_msf(entry_lba, reinterpret_cast<cdrom_msf_t &> (raw_data) ); // tricky

Or may be:

Code: [Select]

// LinuxCDXAFileDriver.cpp: line 146// lba_to_msf(entry_lba, (cdrom_msf_t &) raw_data); // trickylba_to_msf(entry_lba, *((cdrom_msf_t *) raw_data) ); // tricky

 

[einherjar]

I have just commited the reinterpret_cast usage and the configure option we talked about:
just invoke `./configure --disable-linux-cdxa-driver' (it is built by default)

 

[Cyberman]

Oh Freak... (Mutter)
I forgot C and C++ automagically return a pointer when you use a character array!

Geeez well I fixed lines
146 248 295

(Hangs head)
should some of the warnings be suppressed a bit? It seems any section that uses keyboard input has a huge list of warning messages about enumerators
Code: [Select]

warning: enumeration value `KEY_KP_C3' not handled in switch

My only problem is somehow my old SDL libSDL.so got nuked... so I had to compile libSDL (couldn't install the RPM Noooo <mutter>)

Right so the program compiles now and then segfaults.  Well I'll work some more (Wee!)

Cyb

 

[einherjar]

Geeez well I fixed lines
146 248 295

 :? I did not understand

should some of the warnings be suppressed a bit? It seems any section that uses keyboard input has a huge list of warning messages about enumerators
Code: [Select]

warning: enumeration value `KEY_KP_C3' not handled in switch

Yes, killing the warnings would be a great thing. The one you show here, only needs a "default: break" to be killed.
There are also lots of signed/unsigned comparison.

My only problem is somehow my old SDL libSDL.so got nuked... so I had to compile libSDL (couldn't install the RPM Noooo <mutter>)

(doh  :| )

Right so the program compiles now and then segfaults.

Rrrrrraaarrhh  :-D
Where? How?

 

[Cyberman]

Geeez well I fixed lines
146 248 295

:? I did not understand

Right these were the lines where a type char * was being passed instead of the array type you wanted to type cast into cdrom_msf_t. What puzzles me is why it should work/compile for you and not me? Did they suddenly change the standard?
Why does this work for you?
Code: [Select]

unsigned char raw_data[CD_FRAMESIZE_RAW] = { 0 }; // bzerolba_to_msf(lba, (cdrom_msf_t &) raw_data); // tricky

as opposed to ... (which works on my version of GCC)
Code: [Select]

lba_to_msf(lba, *((cdrom_msf_t *) raw_data) ); // tricky

From what I know about it your code just shouldn't work or compile?? Hmmmm something that needs investigation? Is Mickeysoft to blame?

Yes, killing the warnings would be a great thing. The one you show here, only needs a "default: break" to be killed.
There are also lots of signed/unsigned comparison.

I can change the switch statements and update the repository if you like (kind of mindless stuff anyhow).  I might end up commenting code is what I fear (serious code commenting habit I have).  Yes I noticed the voluminous 'signed unsigned' comparison complaints.  I think that's the result of gratituous use of int and compariing it with uint16 and uint8 values.  Comparing them with a constant won't spawn a complaint (well with a certain version of GCC it will LOL), unless the constant is a type defined one.
Code: [Select]

const int SuperTwiddleInt = 65;#define SUPERTWIDDLEINT 65uint16 MyLittleUint;MyLittleUint = 13;if(MyLittleUint == SuperTwiddleInt ){}

should bring up a complaint but
Code: [Select]

if(MyLittleUint == SUPERTWIDDLEINT){}

shouldn't are with using Lint by the way?

Right so the program compiles now and then segfaults.

Rrrrrraaarrhh  :-D
Where? How?

It just segfaults... here is the exciting run it has
[cyberman@localhost trunk]$ ./q-gears-ffvii
Segmentation fault
Erstwhile I'm looking for XML data schema for a simple HMI layout. (Oh... bad mental feedback I just visualized people wanting to SKIN <heh> q-gears).

Cyb

 

[Cyberman]

All right Segfault fixed (Thanks to 'G')

There seems to be a few bugs in q-gears in it's current inception.

Console output, if there is no OpenGL system etc. that can be used, it should say something like (on the CONSOLE)
"ERROR: No graphics context to open SEE game.log for details'
If the directory setup isn't as expected it should not segfault instead it should say
"ERROR: Directory structure does not match 'q-gears-ffvii' might not be in the right location ."
There should be something in a game.log file regarding the exact error point.
It should report errors if it can't find anything, it shouldn't segfault over those things.

The game.log file is where I found out I need to check GLX is installed for example
This is great, but what if the program doesn't have permission(s) to create game.log?

I'll be working on a few simple sanity checks instilled into the program that should be easy to test.

Critical Errors need (to be honest MUST is more like it) to be reported to the console or in some way to the user, and if active game.log. (I noticed in Linux it's automatic is that the same in windows as well?)

If it can't open a graphic context for visual output, this is a critical error because there is no way to close the program otherwise apart from CTRL-C or nuke it in someway using the OS.  These kinds of errors should be reported to the user, so the user has a clue.  Game.log should not be relied upon at all for exclusive  critical error reporting, because not being able to make the game.log file might be the fault that caused a critical error.

Although not a critical error a missing config.ini should be reported to the user (not in game.log) before continueing running (This could mean other problems).

Perhaps we need to stratify the criticality of reporting?

CRITICAL ERROR: the program should stop running or can't continue running. (IE SDL_SetVideoMode failed: Couldn't find matching GLX visual)
ERROR: the program might be able to continue running inspite of this (missing config.ini etc.)
WARNING: This could be a problem. (IE OGL information is missing or like it current says Warning: data/savemap not found! )
INFO: stuff that it is helpful but not actually the reason for stoping or panicing etc.

on a critical error the program should just stop. I'm not sure why the program segfaults when it's not in the correct directory structure.  I'll look into it (I'm sure this will be exciting work ).

Cyb

 

[G]

Of course it is a bad behaviour - first time I compiled and tried to run q-gears I had the same, but I don't look into game.log, I even don't noticed it ! So I begin to debug q-gears with gdb and figured it out... It would be great to write some code for output error messages directly to console.
And it would be great for another human type - "only users", who only want to run q-gears and see progress of developing. For them it will be more difficult to understand what to do to make things work.

 

[gigaherz]

There is a simple write to do that.

first write a (simple) function with the same params as printf + an extra "level" param, like log(int leve, char *fmt, ...)
then define the constants
or use an enum:
#define MSG_INFO 0
#define MSG_WARNING 1
#define MSG_ERROR 2
#define MSG_CRITICAL 3

then the user coudl specify the "logging level" and "console logging level", where the default settings would be 0 to file and 2 to console, for debug/testing builds, could be 2,2 or 2,3 for "release" builds.

then the log function would decide what to do:
if the file log couldn't be open it should write a warning to the console, and then set the console logging to min(file_level,console_level).