Current state.

  • Thread starter Thread starter Akari
  • Start date Start date
Status
Not open for further replies.
thx I'll add the gpl header comment then :D

as for help, patches are welcome :)
adding cmake to the build process really might help going cross platform and I could switch IDE :D so that kind of settles it for me as to what do next
I really liked CodeBlocks the first time I used it (some years ago though) but I'm not that satisfied with the current version, well let's see how well it goes with cmake first :)
 
i have thought about switching building for Black Chocobo to cmake since many other Qt projects use it and decided in the end my building was simple enuff that cmake was going to over complicate it. so i never looked into using to anyfurther but  for something like Qgears cmake might be a really good solution . i was looking to build qgears on my daily ppa (would do for only daily now till a stable release if made then would release in my stable ppa). so i have somewhere a list of packages (from debian) qgears depends on. something like this dependicy list is needed for cmake if im not mistaken. if you can get qgears building via cmake i can have the ppa build us daily linux binaries for testing (or at least when chages are made) they would be ubuntu/debian compatible packages and should work on any debian or ubuntu deritivite.
 
CMake build support is comming along quite well, at least it feels like it does
main "game" executable did get a bit larger, might be some static linked lib, will check later
needs some more time for the other binaries and testing if CodeBlocks still works, after that I'll try building on linux :D
as I nether wrote any cmake please correct me if I'm doing it wrong or just not good :)
 
\o/ yey just pushed some further changes to the CMake build settings
Ogre it self suggests a CMake config [1] on how to build your apps with it, that made it quiet a bit more sophisticated to build QGears
and it seems to work quite well, I just had to update their script to Ogre 1.8



a screenshot of QGears running on ubuntu 13.04 :) as Ogre 1.8 is required you might have to build it your self, but following the
instructions on there twiki site makes it easy
I tested building and running qgears on win7 and ubuntu 13.04 works quite ok so far
there are still some issues but they mostly arise from my missing knowledge of linux and how to use shared objects etc

so happy hacking on linux :D patches are welcome, advise as well ;)

[1] http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Building+Your+Projects+With+CMake
 
cool ill look into adding a debian folder so that it can be auto build by my ppa. then we will have daily qgear builds :D

using the CMakeList.txt provided by Qgears i had to add a section for using the ubuntu  libogre-dev package as it installs the cmake stuff to /usr/share/OGRE/cmake/modules

Code: (added @ line 43) [Select]
Code: 
elseif(EXISTS "/usr/share/OGRE/cmake")    set(CMAKE_MODULE_PATH "/usr/share/OGRE/cmake/modules/;${CMAKE_MODULE_PATH}")
i was then able to generate a makefile using the cmake CMakeList.txt command .

i am however unable to build the program and around 36% into the build i get an error
Code: [Select]
Code: 
q-gears-code/QGearsMain/src/core/particles/ParticleSystemManager.cpp:12:75: error: ‘ParticleSystemManager* Ogre::Singleton<ParticleSystemManager>::msSingleton’ is not a static member of ‘class Ogre::Singleton<ParticleSystemManager>’
maybe i just picked a bad day to check the code out..

from stock *buntu/debian you should need the following packages

build-essential
libogre-1.8-dev (liborgre1.8-dev may also be needed)
cmake

creating the debian folder should be pretty easy task. i'll need to build it local so i can test my deploy scripts first.
 
Last edited:
the error you get is from Ogre 1.7 I had the same error and checked Ogre they did change the member variable name from 1.7 to 1.8
so 1.8 is a requirement for now
I noted that as an requirement in a readme.txt in the root path of qgears :)
I wrote boost 1.51 to be required but that's not exactly true, as Ogre is compatible with a variety of boost versions as one can grasp from their cmake
 
After some problems building on my home machine i realized something the version of ogre in raring is 1.8.0 and qgears uses OGRE::StringConverter::parseSizeT from ogre 1.8.1 . Q-gears will not build using the provided version of ogre using any ubuntu version <13.10 (saucy) . for versions lower then this any build script will first need to get libogre from outside the repositorys.Once i finally upgrade my desktop to saucy (possibly later this week ) i can work on the packaging some more.
 
a minor update from my side
I'm currently doing mostly just migration of building to CMake and cleanup ( lots of files moved, sorry for any inconvinience when updating )
I get along with CMake quite well it really does a great job, I did migrate some first Unittests to CMake + CTest and implemented Walkmesh serialization meanwhile
as building works good enough for now, I'll try and concentrate further implementing missing Resource files, next goal is loading of Field map completely from ff7 data, with exception of the script
 
a minor update from my side
I'm currently doing mostly just migration of building to CMake and cleanup ( lots of files moved, sorry for any inconvinience when updating )
I get along with CMake quite well it really does a great job, I did migrate some first Unittests to CMake + CTest and implemented Walkmesh serialization meanwhile
as building works good enough for now, I'll try and concentrate further implementing missing Resource files, next goal is loading of Field map completely from ff7 data, with exception of the script
Click to expand...
By the way I suggest you to get rid of my support for usual formats like XML and png, get rid of new directory structure, because it will be easier to support native FFVII pc formats only.
It will be easier to add battle and worldmap this way too.
I wanted to create all work through normal readable formats and export all data to this formats to make game easy to create mods and adding new content. If you move this to native data it's not nessasary leave my things in project. Though you still needs to think something for menu and special effects, cause they are all hardcoded.
 
oh by no means would I get rid of that formats, I adjust them as I see appropriate and migrate them to Ogre::Resource etc as needed
easy human readable formats are a good choice for q-gears native format, the easier for content creators the better :)
my ultimate goal for resource files would be to have them all load / fill the same Resource(s) just by different serializers so that the export utilities
would simply import a resource with a game native serializer and export with the q-gears native one
 
Last edited:
i have created a package (it doesn't really install where it should yet). but in doing so i have discovered qgears repo is way to big to fetch for dailys. the repo will need to be slightly restructed so that the non essental stuff is not in the same folder as the stuff needed to build qgears (and its plugins)

A list of the files used to make the current package can be seen at the link below.
http://pastebin.kde.org/pa0rdikkn   (link good for ~1 month) these items (except for data folder) should perhaps be moved into a folder so its easier to grab the source thats needed for building.  (please note i didn't push the debian folder yet)

the files in "data" are temp and eventually should be replaced by Exports from a supported game or other user created content.

i also need to know the correct copyright info. development years , Name of copyright holder and their email , please PM me this info so i can place it correctly in the copyright section for the packaging
 
I am really glad you all are still actively working on this.  One of these days I can't wait to play the full game front to back using what all of you have built.
 
When I originally envisioned the engine, I wanted it to use the data files natively. It was Akari who decided to go the conversion route. I also wanted concentation on the PSX version as the PC version was really rare. Now that it's been re-released, and now the PSX version is the rare one.
Click to expand...
Regarding the re-release, I wonder if anybody has considered if there might be differences in the files between the old original release and the re-release?

The reason I ask is because the version I have is the PC version, the first original one:

g0201818dw1.jpg


Short of uploading ISOs to anybody, perhaps there are some things I could offer active developers that they might need?
 
Regarding the re-release, I wonder if anybody has considered if there might be differences in the files between the old original release and the re-release?
Click to expand...
Aside from the obviously different videos and exe, I'm pretty sure flevel.lgp is different. I don't recall if anyone ever checked the changes, but the format is exactly the same; files can be swapped pretty readily between versions.
 
They may have changed things to work with most of the mods here.  When I used the re-release most of the changes done there showed up.  The only thing I saw was the exe since I think most ones that use it are for the old one as the new release is different.
 
The 2012 flevel isn't that different in terms of changes made.  There are one or 2 bug fixes though.  Luksy also had to change ts to read it properly because of the compression.  He surmised that the reason for this was they changed flevel using their own tool, not using Makou Reactor.
 
oh by no means would I get rid of that formats, I adjust them as I see appropriate and migrate them to Ogre::Resource etc as needed
easy human readable formats are a good choice for q-gears native format, the easier for content creators the better :)
my ultimate goal for resource files would be to have them all load / fill the same Resource(s) just by different serializers so that the export utilities
would simply import a resource with a game native serializer and export with the q-gears native one
Click to expand...
One thing I always wanted to add was voice synthesis for the conversations. Not because it would sound good but because it would

[list type=decimal]
[*]be a challenge
[*]allow me to work on voice stressing based on the context (hints given by interpreting the script a bit perhaps?)
[*]Might end up actually being useful for other games
[/list]
I am not thrilled with so many games voice acted in fact I've found it annoying of late. It seems to have watered down the dialog in games immensly and really ruined the fun of moding games a lot. Adding new voices is difficult in that not many people can voice act (it is indeed an art). Most people sound ... terrible (not that thier voice sounds bad but it's difficult to have continuity and requires a lot of patience and skill to focus on the words correctly).
So my thinking was "perhaps game script hinting and context sensitive processing would help". Information from the game itself can alter tone pitch etc.

I would love to add other things such as new control inputs that translate into the game functionality (IE not just make the normal inputs but have a proper result in the game). Granted the turn base combat in FF7 can't make much use of something like the kinex however mousing through the menus might be interesting for example.

Just my thoughts ... and seriously that is something "I" consider fun working on :D

Cyb
 
I'd love ff8 to sound like that:http://www.youtube.com/watch?v=hOSMMn0BIpQ

If only a collab with Shudo would be possible in the future...
 
Just commited the debian folder as well as icon and .desktop file for q-gears.

Sorry about the icon . we will need a better one as mine is just the text "QGears Icon" in a 64x64 box. mainly it is a place holder.

to build the package you will need debian or a debian derivitive (like *buntu)

install the required packages

Code: [Select]
Code: 
build-essentialdevscriptsdebhelpercdbscmakelibogre-1.8-devlibois-devlibboost-program-options-devlibboost-filesystem-dev
you will also have to make a folder named "qgears_0.21" (0.21 is current version in debian/changelog) and copy the code into it you will need the following from the source. 
Code: [Select]
Code: 
debian/*debpendencies/*output/*Plugins/*QGearsMain/*SupportedGames/*CMakeLists.txtq-gears.desktopq-gears.pngCOPYING.txt
compress this folder to qgears_0.21.orig.tar.gz (use tar.gz replace 0.21 = current version from debian/changelog)
then enter the folder qgears_0.21 and run the command
debuild -uc -us to make the package and use dpkg -i to install it .

the current package will install to /usr/games/ and place resources in /usr/share/q-gears .  depending on your DE you may have to log in / log out to see q-gears in your application menu under games.

remember with 0.21 when you run it to press F8 to bring up the demo menu.
 
Last edited:
Status
Not open for further replies.
Back
Top