Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - G

Pages: 1 2 3 [4] 5
76
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 11:49:46 »
I "corrected" that HAVE_INTTYPES_H issues, this works for me and for you, but this isn't work for halkun...

77
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 09:53:08 »

Question about some preprocesser stuff.

why is it written like this?
Code: [Select]
#ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#else


it's so, because if autoconf found that header (inttypes.h), it define HAVE_INTTYPES_H and we know, if this HAVE_INTTYPES_H is defined, that we have this header on the system.

Quote
Are we saying if HAVE_INTTYPES_H is defined then incude it? Are we in essence defining it again? Shouldn't that be a #ifndef?
in q-gears I searched all code for possible defining that macro again - it is only in TypeDefine.h

autoconf developers prefer to define macros of type HAVE_<header name> to indicate, that this <header name> is on the system.



Quote
No, it doesn't....
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/postypes.h - I don't understand why in fedora (or redhat ;) ) - there are so many intX_t definition files are included...
as last thing you can protect all intX_t & uintX_t definitions with __int8_t_defined and it would work...


Quote
Anyways, I'm off to bed.
Ok, bye. In my coutry now is 13:00 - I am going to have a dinner! :)

78
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 09:34:29 »
Quote
I guess since we are defining the intN_t vars in our application. It would be safe to toss a #define __int8_t_defined in the header to keep from colliding with glibc.
yes, but if your stdint.h & sys/types.h is protected by __int8_t_defined and HAVE_INTTYPES_H is defined, that something other is wrong...
because if HAVE_INTTYPES_H is defined in q-gears, our TypeDefine.h would not allow to define our inttypes manually - I think problem is in those 2 headers in your system...
maybe for now we can simply do this:
//---------------------------------------------
#ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#endif // HAVE_INTTYPES_H

#ifndef __int8_t_defined
# define __int8_t_defined
#ifndef _MSC_VER
typedef unsigned char      uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned long int  uint32_t;

typedef signed char        int8_t;
typedef signed short int   int16_t;
typedef signed long int    int32_t;
#else
typedef unsigned __int8    uint8_t;
typedef unsigned __int16   uint16_t;
typedef unsigned __int32   uint32_t;

typedef signed __int8      int8_t;
typedef signed __int16     int16_t;
typedef signed __int32     int32_t;
#endif // _MSC_VER
#endif
//-------------------------------------------------

*dirty* - but works...

79
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 08:57:33 »
Please look into your q-gears config.h if you have declared:
/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1



my fragment of stdint.h (stdint.h is included by inttypes.h):
------------------------------------------------------------------------------------------------------------------
/* There is some amount of overlap with <sys/types.h> as known by inet code */
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char      int8_t;
typedef short int      int16_t;
typedef int         int32_t;
# if __WORDSIZE == 64
typedef long int      int64_t;
# else
__extension__
typedef long long int      int64_t;
# endif
#endif

/* Unsigned.  */
typedef unsigned char      uint8_t;
typedef unsigned short int   uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int      uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int   uint64_t;
#else
__extension__
typedef unsigned long long int   uint64_t;
#endif
------------------------------------------------------------------------------------------------------------------

my fragment if sys/types.h:
------------------------------------------------------------------------------------------------------------------
/* These types are defined by the ISO C99 header <inttypes.h>. */
# ifndef __int8_t_defined
#  define __int8_t_defined
typedef   char int8_t;
typedef   short int int16_t;
typedef   int int32_t;
#  if __WORDSIZE == 64
typedef long int int64_t;
#  elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
#  endif
# endif
------------------------------------------------------------------------------------------------------------------


hmmm...
maybe this headers from your version of glibc isn't protected by # ifndef __int8_t_defined, who knows?
dirty way to fix this is to define __int8_t_defined somewhere in q-gears source...

80
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 07:39:24 »
Fixed. Try to compile on your machine, halkun... rev.144

81
Q-Gears / Re: Problem with compile Q-Gears on Linux
« on: 2007-02-18 07:09:15 »
I had this problem earlier. For fixing I added checking for inttypes.h to configure.ac:

# Check inttypes.h header
AC_CHECK_HEADER([inttypes.h],
                [AC_DEFINE([HAVE_INTTYPES_H])],
            [AC_MSG_WARN([[warning: defining fixed int types explicitly]])])

so if we have inttypes.h header on the system we define HAVE_INTTYPES_H and #include it in TypeDefine.h, else we
have to define them by hand

#ifndef HAVE_INTTYPES_H   -> I think this had to be #ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#else
#ifndef _MSC_VER
typedef unsigned char      uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned long int  uint32_t;

typedef signed char        int8_t;
typedef signed short int   int16_t;
typedef signed long int    int32_t;
#else
typedef unsigned __int8    uint8_t;
typedef unsigned __int16   uint16_t;
typedef unsigned __int32   uint32_t;

typedef signed __int8      int8_t;
typedef signed __int16     int16_t;
typedef signed __int32     int32_t;
#endif // _MSC_VER
#endif // HAVE_INTTYPES_H

Now me have this problem - I can fix it, but I don't want to break someone else compilation :)
 g++ -DHAVE_CONFIG_H -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -g -O0 -fomit-frame-pointer -O3 -march=athlon64 -Wall -W -fpermissive -pipe -MT display/actor/libcommon_la-Actor.lo -MD -MP -MF display/actor/.deps/libcommon_la-Actor.Tpo -c display/actor/Actor.cpp  -fPIC -DPIC -o display/actor/.libs/libcommon_la-Actor.o
display/actor/../../TypeDefine.h:22: error: conflicting declaration 'typedef long unsigned int uint32_t'
/usr/include/stdint.h:52: error: 'uint32_t' has a previous declaration as 'typedef unsigned int uint32_t'
display/actor/../../TypeDefine.h:26: error: conflicting declaration 'typedef long int int32_t'
/usr/include/sys/types.h:197: error: 'int32_t' has a previous declaration as 'typedef int int32_t'

82
Q-Gears / Re: Hello! Q-Gears is really hard to compile
« on: 2007-02-15 07:55:14 »
segfaults here:
field/DatFile.cpp:67
    Script* script = new Script(mpBuffer + offset_to_sector + script_offset, script_size);

83
Q-Gears / Re: Hello! Q-Gears is really hard to compile
« on: 2007-02-15 07:36:46 »
I fixed Linux autoconf/automake files and some stuff in xeno (please check someone, if I don't break another projects) - now project compiles under Linux again ;) - it's a good news, the bad news is:

Quote
So pretty much the game gets to that and just dies. (I don't see a splash screen at all) Any of you other linux geeks have any luck?
halkun, the same segfault for me. Maybe I will check it today...

84
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-14 19:15:50 »
Of course there is ioctl interface on Linux! It's not hard task to do grabber of filesystem in one step, I will do it, just bit later...

85
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-14 09:39:42 »
There is no problem for me to mount PSX cdrom - just insert CD-ROM and I have mounted automatically it. Maybe your distribution is outdated (I am using latest development release of Ubuntu (Ubuntu Feisty)) Of course when I try to copy mode2 sectors (for example video data [*.MOV]) - it copies it incorrectly. But I user another scheme: I insert cdrom and grab image using cdrdao, and then I wrote psx2iso converter, so i convert bin image to iso and mount iso using command: mount <filename.iso> /mnt/iso -t iso9660 -o loop,nojoliet,norock,block=2048 (we have to turn off joliet and rockridge cdrom extension to see normal files, then I copy all files except mode2 ones movies), and then I write another mode2 dumper to dump that interleaved sectors. If you need that tools, I will upload them today into q-gears/utils

86
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-14 08:05:01 »
I already wrote movie dumper, now it works only with image and doesn't support proper filenames (haven't much time to understand ISO-filesystem, later I will fix it) (*.MOV) - but it should not be hard to change it for work with cdrom, at least on linux :)
Actually I am too thinking about some installer, which by one click prepare FF7 data directory on PC to save time for users.

87
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-14 04:35:35 »
I want also to ask, what format of saving interleaved sectors is better? I can grab full interleaved sectors for every movie from cd-image and save as is, however we don't need sync (0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00), cd-header (4 bytes) and last 280 bytes of sector (actually I don't know what we have there, but in video data this is not needed). But on the other hand if we leave sectors as is, we will save compatibility with other players (such as ffmpeg, which wants psx data to be raw sectors dump) [need also to send patch for ffmpeg to play FF7 movies  :-D ]

88
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 21:37:33 »

89
Q-Gears / Re: Sound output method
« on: 2007-02-13 21:35:48 »
 :-D - I like call_some_function naming convention, but I like callSomeMethod naming convention! I think for C it's better first variant, for C++ second. Just my way of coding. But I think you'll agree, that using SDL_xxx is a LOT easier than writing another output class for each platform. I can write for you wrapper  - you would not see that _ in function calls! :)
I want to decide together what we will use - that is not my choice...

90
Q-Gears / Re: Sound output method
« on: 2007-02-13 20:18:38 »
Sorry, I am saying this, but I think, that if we can use GNU/GPL code better use it (I have nothing against fmod, except it's license). Own mixer is better thing, but do we need to rewrite module for each platform, if we can simply user higher level API such as SDL?

91
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 20:01:52 »
Quote
Cool! Is it just the extra camera data, then? And are the mdec packets modified in any way?
As halkun posted, this data is user data, so Square can incapsulate what they want there to be. I think that there can be camera information and possible sound timing for another channel played during video play (see my topic about sound system). For now I will skip this, later I will look what is there.
MDEC packets isn't modified. There is 3 slightly different variations of mdec coding (presented by Sony(tm)) [type/version field in beginning of video frame data]. This "type" seems determines a way of decoding DC coefficient (upper-left coefficient in macroblock). Final Fantasy 7 is of type 1. I haven't seen any other PSX movie of type 1. My version is that when Square begins development of FF7 (one of the first games for PSX, or I am wrong?) they only had given tools for encoding movies to type 1, later games used type 2/3 (it's only my explanation - it's just my fantasy :) ). Actually I don't see difference between type 1 & 2, but who knows...

Quote
You can add some test module to ScreenTests module (DisplayTest and GuyTest like). And we could start adding movies to field module. At last =)
Ok, I will do it after cleaning the code.

92
Q-Gears / Sound output method
« on: 2007-02-13 19:36:59 »
All that movie stuff brings in my head problem with sound system we wiil use in q-gears.
Definitely q-gears must be crossplatform, so I think the best choice is SDL. SDL have built-in methods for output audio, but in FF7 we can have different sound channels play simultaneously (for those, who don't know what I am talking about, if any ;) - at first watch FF7 opening movie on PSX/Emulator - there is a sound theme beginning, when Aeris coming out from a passage; after this try to watch this movie using any PC PSX video player - you will hear only background noise).
So we need to do some mixing... I understand, that unnecessary project dependencies is a bad idea (right, halkun? :-D). But there is SDL_mixer library...  :evil:. Of course we need only 2 channels of audio (or maybe not?) and we can do mixing manually, but I don't know much about this yet, and I think this will take some time to write good methods for mixing. As we don't have FF7 game sound decoder yet we can skip mixing for now, but later we will have a problem.
What community thinks about it?, can we use SDL_mixer?, can we use something else crossplatform? or don't use any mixing?

93
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 19:06:43 »
!!! - I HAVE DONE IT - !!!
*FF7-enabled* open source PSX video decoder ready. Now I will clean up the code (I think this will take some time, need also to rewrite sound backend to SDL) & add it to q-gears source with XA audio decoder & I think I will add also some code to play movies from q-gears main screen (can I do this?)

94
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 16:52:38 »
Thank you, halkun for your info! About video frame format header I know, but about user data it is very helpful. Now I am 80% sure, that this user data is camera moving data. For example I was working with opening movie, and in the end we have camera moving and movie in background, so in that video frame there is user data, I checked some other files and there user data zeroed. So for now I will skip this user data and continue my work on mdec decoder (sony's utility decodes ff7 frame without this data, but my don't yet :( ). Thanks again for reply

, kupo

95
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 06:09:29 »
Today I tried to remove this unknown data from frame and convert it with Sony's movie converter - It works! But in libbs there is another problem. Trying to understand this a bit better...

, kupo

96
Q-Gears / Re: STR, XA, FF7STR??
« on: 2007-02-13 05:05:25 »
Micky, what version of ffmpeg you was using to successfully play FF7 movies? Or, better, do you have a source of ffmpeg, that works? ;) Or when you downloaded ffmpeg source - I will download specific SVN release of ffmpeg, and play with it. All I know is that on MPlayer users mailinglist people were complaining that FF7 movies are *entirely* different and nobody could play them.

97
Q-Gears / STR, XA, FF7STR??
« on: 2007-02-12 20:47:32 »
Hello all!

So about my progress in the ff7 development... Haven't much time to write here about what I am doing/done.
So
I decided to write some classes to play PSX FF7 videos & sound. I used various sources of info about PSX videos and now I know something about it.
In FF7 there is 2 types of movies: ordinary files with STR extension (these can be copied without problems directly from cdrom without any crc errors) & files with MOV extension. Files with MOV extension is actually a interleaved stream with video & audio frames. These sectors are written in CDXA Mode2. I wrote simple dumper to dump this sectors to files. Then I write some demuxing code (used ffmpeg sources ;) ). For audio stream I found some sources that analyzes and plays PSX CDXA audio data and write a simple command line utility to play any channel in XA file through oss interface (for now only linux  :evil: ). For video stream I used libbs from psxdev-libs (http://www.psxdev.de). Using demuxer I split video to individual frames and try to decode it with libbs. Here I have bad news. I successfully convert many different videos from various games (tested all games I have at the moment) using only my GNU [heheh] tools EXCEPT ff7 videos. Deeper investigating in ff7 video frame shows me, that there is wierd section of data at the beginning of the video frame:
DE 0D F9 07 00 00 25 02
45 FC 96 F0 51 F8 5B 0D
B2 FB B2 FB 11 00 00 00
F8 00 00 00 62 12 00 00
E7 FF 00 00 BB 03 00 00
Of course this data is different for every frame. After this data begins "normal" frame data. Removing this data from file don't help to decode frame.
I think that problem is in "another" VLC coding method used in FF7 movies. This data may be some VLC table in Huffman Coding, or something else... I am totally confused with this...  :|
I tried some windows PSX video players which works perfectly with FF7 (of course this is closed source :( ). Also tried to debug pcsx emulator - it may be very funny, but I cann't find in pcsx source where VLC decoding is taking place (only mdec decoder functions which already included in libbs). Also tried official Sony's program for converting psx videos (MC32.EXE) - it works for anything except FF7 video - when I try to load FF7 bs-frame I got from my demuxer, MC32.EXE fails with message "Invalid MDEC Mode 0x7f90000" - maybe Square interpret this unknown data manual??
My sources currently are not in SVN - code is dirty, I don't want to add something, that not working yet - if anyone want, I will upload it somewhere. I also wrote some documentation about CDXA PSX video frame data.
I heard about some official Sony's PSX video format documentation - maybe someone can get this for me? ;) So if anyone have ideas about decoding FF7 video frames, or can help somehow - post here.

98
Q-Gears / Re: Hello! Q-Gears is really hard to compile
« on: 2007-02-08 17:24:17 »
Checked SVN source. Someone replaced configure.ac with older version. I will fix it today.

99
Q-Gears / Re: Hello! Q-Gears is really hard to compile
« on: 2007-02-08 15:30:02 »
Quote
./bootstrap
configure.ac:30: error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O
It was fixed earlier. In SVN macros AM_PROG_CC_C_O is after AC_PROG_CC. Use SVN source.

100
Q-Gears / Re: Back to the ISO system
« on: 2007-01-06 09:31:13 »
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.

Pages: 1 2 3 [4] 5