Messages

1

Q-Gears / Re: How about moving to UNREAL 4.X?

« on: 2015-04-02 21:51:07 »

As there source it not open it's understandable that they can't have you bundle it with any GPL code as that would require you to open the rest of the code as well which you are not allowed. But afaik GPL permits linking.

I initially committed my code under MIT and since I am the copyright holder of my code I can, at least with my parts, do as I please.  And one can always ask if the copyright holders would grant usage etc. But as already mentioned rewrite is needed anyway so that shouldn't be much of a problem.

Reversing is with current versions of IDA Pro easy as hell, at least for the pc data.

- native format support may not be possible

I meant like in the original sense of a drop in replacement, so native format conversion on the fly, depending on the data structures that need to be filled it might just be hard, nothing is impossible

All in all I like the idea of learning Unreal but no matter the direction, time is of essence so don't count on me :/
Sharing code with current q-gears is unlikely in that approach though, sharing knowledge / reverse engineering  is more likely.
I can't quite imagine how collaboration works in case of U4 though.

Last but not least. It's you're time, enjoy, if that is with U4 great, if it is helping current q-gears fine, if you share knowledge nice

2

Q-Gears / Re: How about moving to UNREAL 4.X?

« on: 2015-04-02 06:06:51 »

I already suggested using some game engine. And despite current issues in q-gears, the advantage would be to have the "engine" part done for free, eg interface, scripting, sound, controls, settings, etc.
For the original intent of having a drop in replacement you'd need source code to make loading of native data possible.
To get a real impression of the benefits of an engine you should face all implemented features and there quality of q-gears with the engine of choice and see what benefits and drawbacks there are.

As for Unreal 4 I See:
 + sound
 + editors (live preview, visual scripting, ...)
 + networking
 + interfaces
 + input controls (Keyboard, Gamepad, Oculus?, ...)
 + settings screens (not sure what is required to get them though, ogre has only the minimal rendering settings window)
 + platforms (win, mac, *nix, android, html5)
 + possible future updates / bugfixes
 + proven architecture & maybe good quality code at least I'd assume it to be

 - porting efforts
 - learning efforts
 - native format support may not be possible

3

Q-Gears / Re: Q-Gears Field Module - Midgar Conversion Project

« on: 2014-12-16 19:25:12 »

it seems lua is bundled due to the git submodule integration of it and using the complete source
you could remove that and extend the initial cmake script to find the lua library as well and then just link against it similar to [2]

[1] https://github.com/q-gears/q-gears/tree/master/dependencies
[2] https://github.com/q-gears/q-gears/blob/master/CMakeLists.txt#L48

4

Q-Gears / Re: Q-Gears Field Module - Midgar Conversion Project

« on: 2014-12-11 06:07:44 »

If you don't do it from a github fork it can't be merged, if you don't like the changes everyone else is making then everyone else might as well stop working on the project.

behold the mighty power of hg-git, that is if akari does a push to the source forge repo [1] which seems to not have the mentioned changes by now

[1] http://sourceforge.net/p/q-gears/code/ci/default/tree/

5

Q-Gears / Re: Level Format

« on: 2014-09-22 07:33:14 »

the loading of native (pc) field is actually implemented already, what is missing is loading and processing of the scripts within and integration with the map list etc

6

Q-Gears / Re: Current state.

« on: 2014-07-13 20:17:24 »

you could check plugins.cfg and set the pluginsfolder to the ogre lib dir so you won't have to copy them over to the output directory or
on windows i let it at "." and add the ogre plugins directory to PATH so that the application finds them

7

Q-Gears / Re: Current state.

« on: 2014-07-08 05:28:54 »

data path is configured in resources.cfg not sure if there is still some hard coded paths but thats where you can add paths zips etc where models n stuff can be found at least for the stuff that I moved to ogres resource system

8

Q-Gears / Re: Current state.

« on: 2014-06-03 20:51:18 »

the initial idea, and I like it so I try to stick to it, was to have a drop in replacement for the original executable
so my priority lies with the original data, but the resource system of ogre encourages separation of serialization from the implementation of resource usage so it is relative easy to have multiple implementations of serialization meaning multiple file formats per data type
like there is a xml representation of the ogre mesh files or you can use png,jpeg,bmp ... for textures
so the ultimate goal would be to have it compatible with the native data and some more easy to edit formats
currently you can use ogre mesh files and ff7 mesh files (.hrc if I remember correctly)
but it is still a long way to go and there is currently not much development going on

9

Q-Gears / Re: Current state.

« on: 2014-05-18 06:21:12 »

really hard to tell, any hint on which file it is that's causing the error?

10

Q-Gears / Re: Current state.

« on: 2014-05-02 13:22:29 »

I mirrored the mercurial repo to github [1] I try to merge any changes from the git repo into hg maybe we could even let the source forge one die and just forward to github?

[1] https://github.com/zerotacg/q-gears

11

Q-Gears / Re: Current state.

« on: 2014-05-01 06:19:49 »

hg-git [1] to the rescue we could just fork and switch to github?
older launchpad [2] did support mercurial?

[1] http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and-push-to-hg/
[2] https://i.stack.imgur.com/hMcSR.png

12

Q-Gears / Re: Trying again :)

« on: 2014-04-29 19:23:18 »

I meant merely running the unit tests there is a build target for the tests if u enabled them in the cmake config and there is an executable for every test after building to run them separately

13

Q-Gears / Re: Trying again :)

« on: 2014-04-29 06:15:40 »

qgears should run in windowed mode all by it self, not sure maybe I changed it to respect the ogre config window, you could try to reverse your changes delete the ogre.cfg (maybe qgears.cfg) to get the config window again and just disable fullscreen in the ogre config dialog

as for what todo
only thing that comes to my mind would be to try and run qgears on some of the original ff7 files, check out the unit tests maybe, I left the resource paths etc in the code and I'll try to be available on irc, I'm on gmt+2 though
maybe we should try and get a ticketing system
source forge most likely has one the project owner would just need to enable it

the command line switches should actually work, I use the program-options package from boost for that, so maybe just the right version is needed, maybe you could come up with a unit-test for them?

14

Q-Gears / Re: Current state.

« on: 2014-04-29 05:51:48 »

the source forge site [1] states it is under gpl2, I released my code under mit until I found out it was using gpl2 but didn't change all files
but now as it comes to more developers we should really include a license and a contributors file and prepare a general source header with the minimalistic version of the license
I would stick with gpl2 just to not need the change it but I don't really mind

[1] http://sourceforge.net/projects/q-gears/

15

Q-Gears / Re: Trying again :)

« on: 2014-04-27 14:18:18 »

I'm working with QtCreator but since we use cmake you can create project files for lot's of ides and it should work
to get debug version change build type to debug and it should work quite well

as fore the linking errors I'll try and check them later on

16

Q-Gears / Re: Trying again :)

« on: 2014-04-23 19:43:22 »

dunno what errors do you get?
we should have the same boost dependencies as the ogre version we require (1.8 if I remember correctly)
I haven't done anything in quite a while so ...
as for (re)moving unused stuff etc I was actually aiming for the point where could load necessary data from ff7 game dir so we could remove copyrighted materials and still have something to view
but feel free to shuffle around as you consider appropriate  in the end it's version control, nothing is lost

17

Q-Gears / Re: Trying again :)

« on: 2014-04-23 04:58:36 »

try pressing f8 to get the menu
there is an initial script that is executed to do the key binding
q-gears/output/data/config.cfg

18

Q-Gears / Re: Interested in trying to contribute to Q Gears

« on: 2014-03-21 23:08:17 »

ah found the freetype libs, they should be enought for static linking
reminds me, dont forget to do release and debug build
u have to set CMAKE_BUILD_TYPE to Release, do configure ... generate .. make all install
and then the same for Debug

19

Q-Gears / Re: Interested in trying to contribute to Q Gears

« on: 2014-03-21 23:04:32 »

ogredeps only give u ois and cg
the rest should be source cod / satic linked
if u build ogre u can disable features u don't need or that don't work and don't forget to do make install, for ogre it will generate an sdk folder in the build folder that one is the one u want
I currently hang on freetype in configuration dunno what I did to fix that

20

Q-Gears / Re: Interested in trying to contribute to Q Gears

« on: 2014-03-20 06:28:20 »

well the interesting part is still missing xD
but I think it should be mostly just cmake configure/ generate
you just have to set some cmake variables manually, like all the directx libs, at least I had to
sadly ogre has a dependency to directx on windows even if you won't build the dx driver

21

Q-Gears / Re: Interested in trying to contribute to Q Gears

« on: 2014-03-19 06:34:44 »

i did use ogre 1.8 and boost 1.54 build from source
and for building boost I did go

Code: [Select]

> bootstrap.bat mingw
> b2 --layout=tagged toolset=gcc --build-type=complete --with-system  --with-atomic --with-chrono --with-date_time --with-filesystem --with-test --with-program_options --with-wave --with-thread

just cause not all libs did build for me but theese are enought

if you wan't to take precompiled ogre, u have to match the right boost version etc if u take the vc?? version, as most are for windows you might want to stick with vc check the tutorial from ogre [1] if u want to run visual c++ take the vc++ sdk of ogre [2] and boost [3] or similar

I have an unfinished how to on the dependencies I'll try and finish it this week here's [4] a preview

[1] http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Installing+the+Ogre+SDK
[2] https://sourceforge.net/projects/ogre/files/ogre/1.8/1.8.1/OgreSDK_vc10_v1-8-1.exe/download
[3] http://boost.teeks99.com/bin/boost_1_49_0-vc32-bin.exe
[4] http://pastebin.com/hAhFScRP

22

Q-Gears / Re: Current state.

« on: 2013-10-07 20:45:07 »

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

23

Q-Gears / Re: Current state.

« on: 2013-10-06 21:24:34 »

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

24

Q-Gears / Re: Current state.

« on: 2013-10-04 06:08:42 »

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

25

Q-Gears / Re: Current state.

« on: 2013-10-02 20:04:04 »

\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 patches are welcome, advise as well

[1] http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Building+Your+Projects+With+CMake