Messages

1

Q-Gears / Re: Back to the ISO system

« on: 2007-01-03 07:05:55 »

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 
Where? How?

2

Q-Gears / Re: Back to the ISO system <warning long lines>

« on: 2007-01-02 20:13:14 »

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)

3

Q-Gears / Re: Back to the ISO system <warning long lines>

« on: 2007-01-02 17:40:14 »

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); // tricky

lba_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); // tricky

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


4

Q-Gears / Re: Can of Worms?

« on: 2007-01-02 16:05:45 »

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.

5

Q-Gears / Re: Q-Gears.0.10

« on: 2006-12-30 08:36:40 »

Yeah, I get the message  As soon as I have a write access (which I just have requested), I describe it in the wiki.

Done:

http://wiki.qhimm.com/FF7/WorldMap_Module

6

Q-Gears / Re: Back to the ISO system

« on: 2006-12-30 07:53:18 »

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)

7

Q-Gears / Re: Q-Gears.0.10

« on: 2006-12-18 21:10:20 »

You should also make sure all files get loaded correctly,

Actually we do not have a way yet to check if a File was opened
correctly except looking at the log file. Or checking the file size,
but it supposes that it is known at compile time. Hmmm, interesting
point.

maybe it tries to load a lsz you haven't copied from the psx cd,

(I'm directly accessing the PSX CDs in my CDROM drive)

OK I think I have tracked it down. I've launched valgrind, and (... drums ...):

Code: [Select]

== 1 errors in context 2 of 37:
== Mismatched free() / delete / delete []
==    at 0x401CCBC: operator delete(void*) (vg_replace_malloc.c:244)
==    by 0x808E9C6: MapFile::ReadMap(StdString::CStdStr<char> const&, unsigned, unsigned, unsigned) const (MapFile.cpp:57)

Indeed: in revision 109, to make VS2005 build q-gears, the following (ffvii/worldmap/MapFile.cpp):

Code: [Select]

uint8_t cell_data[sizeof_cell];

was replaced by:

Code: [Select]

uint8_t *cell_data = new uint8_t[sizeof_cell];
 // ...
 delete cell_data; // should be `delete [] cell_data'

Ouuups

Did the former code generate an error or a warning in VC++? Let me know so that I will not rewrite it (g++ does not complain at all)

Akari, could you give it another try? Thanks in advance!

If you post description of format on wiki - I could try to solve this.

Yeah, I get the message  As soon as I have a write access (which I just have requested), I describe it in the wiki.

8

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-18 11:34:58 »

Does it SEGV or does an assertion fail?
Could you precise the "crashes sometimes": does it always crash when running in a specific directory, and does it never crash when running in another?

It writes LOGGER->Log("Warning: extract failed, this is not lzs!"); many many times. Nothing else.

This is "normal", considering that the size of the lzs section is not known a priori, so the lzs extractor
is asked to guess all alone the size of the data to extract by reading the first bytes in the header.

Crushes sometimes during this.

OK will check this.

9

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-18 09:20:51 »

When I run it from my working directory - everithing fine, but when I copy it (the whole dir)
somewhere it crushes somewhere during LZS extruction.

It looks like a file access / path problem. Could you please show the last lines of the log file?

Does it SEGV or does an assertion fail?
Could you precise the "crashes sometimes": does it always crash when running in a specific directory, and does it never crash when running in another?

10

Q-Gears / Re: Coding style (discussion).

« on: 2006-12-15 18:47:52 »

Since we using SDL anyway lets not make things any more difficult than it's already is, and use SDL_types.h (which includes anyway).

In SDL int types defined as follows

Code: [Select]

typedef unsigned char Uint8;
typedef signed char Sint8;
typedef unsigned short Uint16;
typedef signed short Sint16;
typedef unsigned int Uint32;
typedef signed int Sint32;
This will work corectly on every platform that SDL supports.

Or we could also use openGL types:

Code: [Select]

GLuint, GLfloat, etc.

This would work as well on every platform that supports openGL.

11

Q-Gears / Re: File system.

« on: 2006-12-15 18:45:36 »

You cant tell where do you reading now and this will cause a lot of errors, expecially when format not understanded yet.

So you prefer:

// for each record:
s16 x = f.GetS16LE(offset + 0);
s16 y = f.GetS16LE(offset + 2);
s16 z = f.GetS16LE(offset + 4);

// Goto next record
offset += /* how much? let me count... 4? oh no 8. Oh no wait we read a 2 bytes variable; OK: 6*/ 6;

to:

Code: [Select]

filestream s(f);
// for each record:
s16 x = s.GetS16LE();
s16 y = s.GetS16LE();
s16 z = s.GetS16LE();

Hmmmpf. OK, I will change it ASAP. I will remove Filestream as well.

You still load whole file in memory and only then read it.

Actually, yes, because when "opening" an lzs data block it is effectively
directly uncompressed into memory. But when I looked at how it is decoded,
I had the strong feeling that it was meant to be read as a stream as well.

On psx they have inly 4mb memory for everything. We don't have this restrictions and must get profit from it.

(And then we will need 1Gb RAM, the last P4 and a GeForce8800 to run q-gears. OK OK I am exagerating  -- just kidding )

Almost all part of common classes needs to be rewritten. For example config must be setted seperately for each game, logger must have different type of errors, we need some math library, render class needs to be rewritten since a lot of new obstacles appeared. Input already rewritten to support new type of input event.

Ah OK

12

Q-Gears / Re: Create branch.

« on: 2006-12-15 18:30:22 »

I don't know if the normal SVN distribution has that feature

It does, that's the normal way of SVN branch merging.

but if it does, then I don't see any big troubles with merging branches into trunk when needed.

Consider the difficulties when you have conflict with one file. Multiply it by the number of files
you may have deleted/modified in your branch, and by the number of files all the other
developers deleted/modified. If we do not merge very often into the trunk, that's what we will face.
And if we do merge often into the trunk, we don't need one branch per developper.
IMHO, using this system simply postpone each atomic problem (ie file conflict) into one
single macro-molecular problem (branch conflict).

Just know that I am not convinced of the relevancy of such a system for such a little
amount of developers; this paradigm has its benefit, when reaching hundreds of developers
working on unrelated parts of a very big project, such as the linux kernel or cairo, which rely
on another concurrent versionning system natively supporting this, namely "git".
Anyway, I will follow the final decision; if it is having one branch per user, so be it.
I am just not convinced 

13

Q-Gears / Re: Worldmap info to Wiki.

« on: 2006-12-14 17:58:13 »

Can someone add description of worldmap to wiki? At least what already done in Q-Gears.

I will; the last time I tried to do it, I could not edit anything in the wiki, but
that's the time to make another try -- and to complain if I cannot

14

Q-Gears / Re: Create branch.

« on: 2006-12-14 17:56:54 »

I think we need to create few brunches.

1) Trunk are always stable working version. Merged from branches from time to time.
2) Branch for Field module development.
3) Branch for Worldmap module development.
4) Branch for Q-Gears core development.

How this work. Each developer work with it's own branch. And when whole task that developer was trying to acomplish finished he merge it with trunk. And update his own branch from trunk. This way we always have complete and compilable version in trunk.

Doh. I love it, but I can't help but be already afraid of the difficulty we will face when merging into the trunk 

15

Q-Gears / Re: File system.

« on: 2006-12-14 17:36:39 »

To einherjar (because you already write it a lot)

I don't like the way how Files are created. I don't want to specify FileSystem every time I want read file. I think the best way will be create base file class and derive two classes from him. GameFile and RealFile (for example). And all classes will be derived from them. Specifinng filesystem in classes like TimFile are bad, because this file should always be readed from CD or others GameFileSystem, ie this is always ingame file.
Apart from that we have savemap (load saves in future), Xml files and images (bmp).

I agree; actually I had the same idea at the very moment I delivered the code

ps: do you need FileStream template? and for what purpose.

I do use it in .MAP file reading. I found awkward/dangerous to write:

Code: [Select]

s16 x = f.GetS16LE(offset); offset += 2;
s16 y = f.GetS16LE(offset); offset += 2;
s16 z = f.GetS16LE(offset); offset += 2;

// ...
u8 v0 = f.GetU8(offset); offset += 1;
u8 v1 = f.GetU8(offset); offset += 1;
u8 v2 = f.GetU8(offset); offset += 1;

So I just hide the offset handling in a wrapper, namely Filestream.  I
made it a templated class so that one could use the same mechanism with
any other file.

I know that you do not like streaming very much, but I think that
originaly, the game is meant to run on a Playstation 1, and the
developpers had to use streaming intensively, for two main reasons:
memory efficiency and CD access performance. I followed this
intuition, and used streaming when the file format was "natively"
"unstreamable". And this might a good way of avoiding loading screen,
don't you think?

pss: i wang generally finalize Filesystem before cleanup and rewrite other part of common (config for example).

Well hmmm I'm not sure to understand you here 

16

Q-Gears / Re: Coding style (discussion).

« on: 2006-12-14 17:19:01 »

I want rise topic about coding style that we use. Now because of many
people working we have a lot of different styles of writing code.

I totally agree.

The only bad thing I see here are using "unsigned int" and "uint8_t" in same part of code.

My view here is simple:

- when one wants to use a variable with a very specific bit size, as
when reading or writing a file, or when doing low-level manipulation
(bitwsire operator, etc.) one shall use explicit integer type
(uint8_t, int16_t, etc.; I tend to prefer this style to u8 and s16 for
two reasons: (1) it is commonly used in other projects, it is
distributed by stdint.h so these types already exist on many platforms
"natively", (2) hey emacs colorize ".*_t" as a type )

- when one do not really care about the bitsize of the said variable,
then use the "biggest" native typenames, as int for integer, unsigned
int for integer that you know cannot be negative, and double for
floating point numbers.

I think that this particular "rule" matches what you just said:

but lately I start think that using of s16 and uint8_t are bad and
lowers readability of code. I think writing normal short and unsigned
byte are a lot better.

Regarding the second point:

names for class member, functions, variables and so on. We need to
select one style and use it till the end and force new members to use
our style.  The first thing to deside is - shal we need type of
variable in variable name. For example:

Code: [Select]

bool bEnabled = false;VS

Code: [Select]

bool enabled = false;

To my view, the type was written once, at variable declaration, and I
find this somehow redundant to "repeat" it at each variable use, and
compilers are able to track the type sufficiently correctly to warn against
an erroneous usage.

Regarding names, we will also have to choose between "case separated"
(MyVariable) and "lower-case, underscore-separated" identifiers
(my_variable). I do prefer using "case separated" identifiers for
classes, and the other style for functions/methods and variable.

Notice that this is just my current preferences, and I just followed
them as there was no "official" coding style yet. I don't know if it
may be relevant, but I follow many of the rules described here:

http://www.doc.ic.ac.uk/lab/cplus/c++.rules/

In a more general way, I think that using a "wide-used" coding style
is a good thing. Agreed, I do not have a definition for "wide", but
may be following some GNU guidlines might be good way not to choke
new developpers or potential hackers (in the good sense of the term):

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/C++STYLE

17

Q-Gears / Re: Hello! I am G ;)

« on: 2006-12-12 12:22:43 »

Welcome G!

18

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-10 17:28:40 »

Yes... needs to be 30 fps to at least be on par with FF7's field speed.

Speed ups
Abuse FF7 type fade geometry.
Use multiple DLists in sections, then use said DList when that section is viewed.
Add a horizon (IE fake curvature like FF7 used part of fade geometry).

I've added a "low-level display-oriented not-editable" mesh data structure that uses a
prebuilt vertex array. With this I get 60/90 fps on my machine. It is a GL-oriented structure,
in the sense that it is *not* an interleaved array, which is the prefered way of DirectX;
I don't know if it may be a problem...?

I am planning to do frustum culling, which is totally equivalent to what you propose.
I've built the bounding box of each mesh/cell, all we need is a camera with an explicit
frustum volume.

If I remember correct FF7 loaded sections of the map and unloaded sections of the map as one traveled over it.
This kept loading mostly in the background as you moved through the map.

This was/is certainly a way to minimize loading time (CD access actually) and memory usage (PS1... ).
It is pretty elegant, but right now I will focus on textures, as memory is not really a problem today,
and loading time is ... ah... "acceptable" when using PSX CD, and invisible using PC/HD version.

19

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-10 14:18:44 »

I've added .MAP file loading and some data structure to handle world map in q-gears
I've also modified world map module to make it draw the said structures:



I admit it's not really sexy but it's a first step. I will immediately start working on
speeding up the whole a little: it's around 4 fps on my P4 2.5Ghz / GeForce 6600 GT...

20

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-01 23:04:16 »

Hey I have tried to build the svn source, but I'm getting lots of errors from missing members, most of them from Geometry, TotalGeometry and Display, I'm not sure if it's some wrong file in the project or what

Yes: xeno does not compile anymore 
I fixed some errors, but was not able to fix them all -- I don't know the code of xeno/ and cannot test it...

So I've suspent compilation of q-gears-xeno on linux, until the situation is stabilized.
Current svn version does compile, but only q-gears-ffvii; q-gears-xeno is skipped.

21

Q-Gears / Re: Q-Gears.0.09

« on: 2006-12-01 11:09:16 »

ps: einherjar, some progress with world map? Can you finished it till the end of december? 

World *geometry* will be viewable in the wm module by the end of the month.
For texturing, it will depends on how well/fast I understand the way it should be done.

22

Q-Gears / Re: Problem in file path specification

« on: 2006-11-24 11:24:55 »

"Measure twice, cut once." A precaution, however stupid it may seem is good. That may just be me, but regardless of flexibility, if it can be more efficient in the end as to getting things to run properly i'd use it.

I agree, but I think the point of Akari is: original game file formats (such as kernel's format) shall only be found
in original game data. If we/q-gears generate/handle non-original data, we will certainly not use the cryptic formats
used by the original game .
So for the beginning I will add the filesystem to the File class, which will be initialized to GAMEFILESYSTEM in the
case of original game files. I ever we need to specify another filesystem, we would add another constructor.

23

Q-Gears / Re: Problem in file path specification

« on: 2006-11-24 07:47:03 »

Just being sure .. as for partitioning File space (which is basically what this discusion is about).

Absolutepaths with a specific game file system works fine however ISO variant the first will work just fine, the PC file system it will not unless it's translated internally
(I assume this is what you want to do?)

Yes: for the PC file system, we will add the "root path" as a prefix. Something like this:

if (use_native_pc_version_p)
 GAMEFILESYSTEM = GameFileSystem::NewNativePC("C:/Install Path Of FFVII/data");
else if (use_native_psx_version_p)
 GAMEFILESYSTEM = GameFileSystem::NewNativePSX(os_cdrom_drive_path); // "/dev/cdrom" for unix-like, "E:" or "D:" for windows
else ...

Hence, for the native PC version, doing:

kernel_file = BinGZipFile(GameFileSystem, "INIT/KERNEL.BIN");

Would actually open the file "C:/Install Path Of FFVII/data/INIT/KERNEL.BIN".

I'll write my inline CD plugin, since I know a bit about the ISO file system I will add in sector 'interpretation' of what the command is doing. (IE reading directory information, file information, volume information, random sector information from the disc etc. ).

(Are you talking about a CD plugin for a PSX emulator? Anyway, I don't know if it could help you nor if it is relevant,
but you may have a look at the linux CD XA driver I wrote, I've found some interesting things on the usage of ISO & XA)

24

Q-Gears / Re: Problem in file path specification

« on: 2006-11-24 07:31:07 »

I think the best way will be "INIT/KERNEL.BIN" instead of "/INIT/KERNEL.BIN".

OK.

  kernel_file = BinGZipFile<GameFileSystem>("/INIT/KERNEL.BIN");
  savemap_file = File<RealFileSystem>("data/savemap");

Mmm I don't like streaming files which moved pointer to next data as soon as you read it. There are many reasons for that. In general I need to read the same data twice sometimes. Sometimes I need skip something of read it from the end of block. So I think It's good only as alternative, not the replacement. But in this case I think that the best way is to use same file reading all over the project.

Understood. So, do we all agree on this replacement:
from:

kernel_file = BinGZipFile("data/INIT/KERNEL.BIN");

to:

kernel_file = BinGZipFile(GameFileSystem, "INIT/KERNEL.BIN");

25

Q-Gears / Re: Problem in file path specification

« on: 2006-11-23 17:27:56 »

Please also keep in mind we have the nacient code for an ISO image file system.  Thus if someone makes ISO images of the FF7 PS1 disc set it should be able to use the rudimentary file access objects Akari has provided.  I'm extending these for ISO images, I just stoped working on it due to the fact there was no automake for me to find what was missing to cause OGL to freak out on me (lazyness?).

Yes, and I don't think there is a contradiction. A FileSystem points to a FileDriver, which is the true responsible of the lowest-level stuff.
So when a File is read, it is through a FileSystem, which delegates to its FileDriver.

Thanks to this layering, we can have a GameFileSystem using either a RealFileDriver (which relies upon classical open/read/write/close)
or the said ISOFileDriver or a LinuxCDXAFileDriver without a File instance knowing.