How about moving to UNREAL 4.X?

[Ragna]

What the title says. Now that it is completely free for non commercial creations...
Would it be too difficult to recreate the PSOne era FF engines on it? Is it worth the trouble?

I think such an advanced yet seemingly simple to use and well supported tool would benefit the advancement in Q-Gears.

[Covarr]

What does Unreal 4 have to offer that the current engine doesn't that would actually be useful to Q-Gears? When you're cloning software from the '90s, using too advanced an engine would merely serve to raise system requirements with no real gain.

[Ragna]

Well, it all depends on how you want it to be recreated, either 100% equal to the original -including data format limitations- or
adapting it to newer standards, surpass limitations, and make use of toolset and data integration. You'd want runtime game editing too probably. 
I think another benefit would reside in the great community around UNREAL, which could help too in submitting work to Q-Gears. 

I'm no expert on this matter yet I can clearly see some benefits.
Anyway it may depend too on the expertise of the development team, or the willingness to throw away some or much of the infrastructure already built to support Q-Gears if any. 
Now that I think about it, this all is applicable to UNITY too... 

[KnifeTheSky77]

Unity 4 has infinitely better documentation and better support for a lot of standard game development stuff... reliable interoperability between a modeling/animating/texturing suites. Qgears is built around ogre3d which isn't technically a game engine, it is a renderer with some extras. Everything else is either coded or handled by another project, such as luabind. Switching over to unity would be a lot of work at this point, not to mention, ffvii wouldn't take advantage of a lot of unity's features

[paul]

Help make QGears work at all, then feel free to port to UE

Right now we need people that know the FF7 formats etc. I have an issue with model sizes/rotations, no engine will solve this problem.

https://github.com/q-gears/q-gears/issues/115

Rendering g-shaded triangles really doesn't need UE.

[Kaldarasha]

Help make QGears work at all, then feel free to port to UE

Right now we need people that know the FF7 formats etc. I have an issue with model sizes/rotations, no engine will solve this problem.

https://github.com/q-gears/q-gears/issues/115

Rendering g-shaded triangles really doesn't need UE.

Dont know if it helps but DLPB has found where the model size is handled in the FF7.exe.
http://forums.qhimm.com/index.php?topic=15595.0

[paul]

Thanks, its now a problem of rotation

[Cyberman]

Thanks, its now a problem of rotation

The FF7 models always had some crazy rotation scheme I think the wiki has some details on it not positive. The issue is with the bone order I believe you MUST follow it in order to get the model right. Animations consist of delta compressed data (spiro cracked that). Anyhow I believe one of the first animations is actually just the rotation to pose the character normally based on the bone lengths. The issue with the bone lengths has something to do with the direction of rotation. I believe both the models in battle and field are about the same in how they work.
Did Akari have some of the animations working with the cloud field model?

Cyb

[paul]

I think the animation and rotation seems to work, its just that the default roatation seeems to be wrong, have a look at the last screen shot here https://github.com/q-gears/q-gears/issues/115

Akari has them working yes - but that is with PSX models, this is PC data.

[zerotacg]

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

[sithlord48]

QGears using Unreal is not going to happen....

Doesn’t combine the Unreal Engine code with “Copyleft” open source licenses. See the FAQ for more details.

not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.

[Ragna]

QGears using Unreal is not going to happen....

not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.

That's for commercial purposes only.
And it would not matter if you port Q-Gears to UE4 since it wouldn't be the same code anymore with the same dependencies anymore, probably.

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

Not impossible at all.
You just need a data importer/exporter to reformat data at install time, like Q-Gears itself did: insert game disc and the game profile (for example FF7) installer will reformat all data and patch some of it after conversion, like field scripts, maybe.

That leaves it to the other two negative points. And as I said:

Anyway it may depend too on the expertise of the development team, or the willingness to throw away some or much of the infrastructure already built to support Q-Gears if any. 

If that's the reason... well, it's up only to the project team. I'd say it is probably better to do it sooner than later.
But I agree: currently it seems most efforts should be made on reverse engineering. Maybe, using the current Q-Gears implementation as prototype, and then much later when more is discovered move to a better suited engine with more tools and features.

PS: If I had to choose the 5 most important benefits of using such engine...

• Visual Editor:
  including the ability to test and edit at the same time.
• Integration:
  with Visual Studio X, for example.
• Multiplatform:
  more people can enjoy your work.
• High quality architecture:
  and the ability to be extended or modified.
• Support:
  by WhateverCompany Ltd. (like Epic), or the rest of the community.

Seems reasonable to you?

EDIT: I forgot to say it is free.

[Covarr]

- native format support may not be possible

As it happens, you CAN add native format support to Unreal 4, because they even make the engine's source available now.

+ editors (live preview, visual scripting, ...)
 + networking
 + input controls (Keyboard, Gamepad, Oculus?, ...)

Networking support? Oculus Rift? Those aren't remotely relevant to this project. And visual scripting is not going to be very helpful since the engine will be running old scripts from 1998 anyway. Any new scripting at all is pretty much outside the scope of this project.

QGears using Unreal is not going to happen....

not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.

This too. Not only would a switch to Unreal require literally the entire codebase to be rewritten from scratch for license compliance, it would require the new code to be licensed under something more likely to get it shut down. Normally I am adamantly against GPL, but the very things I dislike about it for most scenarios make it a great choice for something like this. Y'see, GPL makes it utterly useless commercially, a fact which Square Enix would have to be aware of. As such, they've got far less reason to shut it down than they would if it were licensed under any Unreal-compatible license, such as MIT. To switch to a license that allows for-profit sale would create a threat to Q-Gears' very existence.

That's for commercial purposes only.

No. Unreal's EULA explicitly forbids distribution with "copyleft" licenses, any license that forcefully attaches itself to other parts of the same piece of software. This is not just for commercial use; any distribution of UE4-based projects with GPL components is a violation of both licenses at once.

Ultimately, even if licensing Q-Gears under MIT were an acceptable option, the amount of effort it would take to rewrite all of it would far exceed the benefits of the engine change. Honestly, aside from the license, if Q-Gears were just beginning I might almost be tempted to recommend it myself just for the portability and far more robust settings screen support. But at this point, the project is far enough in and deeply enough attached to Ogre3D that I really don't think it's worth the effort to port.

[KnifeTheSky77]

Getting the original data converted to 'workable' formats is still the primary challenge atm i.e. models and animations, field/battle/world scripts buried in the.exe(?) to LUA, backgrounds... this stuff needs reverse engineered before thinking about moving to a real engine methinks

[zerotacg]

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

[paul]

Spending 12 months (probably more) to get what we have now working in UE4 really is a waste of time IMO. No matter what we need the FF7 format info, algorithms etc. This is always the blocker, always step1, we don't even have this yet so what would be the point in moving to another engine?

Fields are driven by lua scripts that can be reloaded on the fly, a visual editor only brings a couple of extra bits for free such as positioning entities etc, but we can easily add that if need be.

[Kaldarasha]

There are two other things which why I think that the UE4 engine is a no go.
1. The engine is free for non-commercial use, but the game is commercial - which would make the project indirectly commercial. Except you re-built the entire game in the UE4 engine -> We have seen on the Chrono Trigger Project how this will end.
2. If there is no one who can make use of the extra power the engine brings with it, where would be the benefits?

A small visual upgrade and a graphical timeless look is all what we should seek for now .

[Tom]

For such a simple game such as FF7 that all it needs is basic GL rendering UNITY and UNREAL is overkill.  We (probably) wont ever use any physics functions dynamic lighting or water simulation.   Also there are licensing issues with UNITY and UNREAL that could shutdown the project (ala chrono trigger resurrection).  The current OGRE system is expandable enough to do more than enough of what FF games need.

That's why UNITY and UNREAL are not going to happen any time soon with Q-Gears.