Author Topic: Current state.  (Read 115943 times)

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Current state.
« Reply #100 on: 2012-06-10 03:05:09 »
halkun got things rolling and Akari just kept going.

This is the story of my life... You should see the Minecraft Enterprise now.

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #101 on: 2013-08-17 23:39:01 »
hey,
just wanted to give a quick note on my progress
I'm currently concentrating on writing the code to read the data of the pc version (as this is the one I got) and learning Ogre meanwhile
with the wiki is a great help on most of the data formats, the rest I do by reverse engineering ( hail IDA )
what I got till now is more or less the characters, animations loaded by hand for now as I'm not yet reading the map files
I'm tightly sticking to the Ogre resource management so that I can read the data directly from the installed game into ogre
meaning you can do something like this
Code: [Select]
Ogre::MeshManager::getSingleton().load( "field/char/sd_red_sk.mesh", "Game" )and get a complete mesh with skeleton that can be added to a scene node like this

as you can see there is textures and shading but still an issue with skeleton proportions or placement of the meshes along the skeleton but I'm progressing :D

the most stuff is happening in the background, all found .rsd and .hrc files are parsed, materials generated from them, skeletons and meshes declared
with loaders so that ogre knows how to load em, and .tex files can be used directly as file formats, so all in all no conversion to ogres native format
needed, all is running directly from the game data with the possibility to do the conversion for faster loading
« Last Edit: 2013-08-17 23:42:09 by zerotacg »

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Current state.
« Reply #102 on: 2013-08-19 04:39:32 »
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. I would like to see native file formats used more. (Akari was more intrested in making an engine then a drop-in executable replacement)

If I was more motivated, I would start a new project using Unity. But that's just me.

Kaldarasha

  • *
  • Posts: 2449
  • Prince of Model Editing
    • View Profile
Re: Current state.
« Reply #103 on: 2013-08-19 05:31:34 »
Yeah, motivation is a a**hole...

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #104 on: 2013-08-19 06:17:15 »
I read about your vision but conversion is it's current state for PSX data :)
Conversion is somewhat more easy, as you don't have to care about Ogres resource management etc but it's not that hard to migrate Akaris code into ResourceManagers & Serializers etc.
For now I'm just concentrating on PC data and getting all assets to read into Ogre though.
As for Unity or some game engine in general, it might be easier in some parts, like input, menus, maybe animations, game states so it might be worth considering a complete engine over just a graphics engine. I haven't worked with any yet so I'm open to suggestions, I would like to stick to C++ though :D and it has to be expandable so that on can implement resource loading from native data without conversion. So I'm not certain Unity would be a good choice.

so I started a discussion on game engines :D Using available Game Engines?

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Current state.
« Reply #105 on: 2013-08-19 08:03:53 »
It's really easy to use native formats. Just build in converters into core and read data from native formats instead of ogre files.

Lately I start to work on battle system implementation in QGears Lua. But I don't have much time now.

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #106 on: 2013-08-24 18:01:41 »
current state for me
  • I did fix the skeleton issue just the day after posting of it, I did apply the bone length before applying the rotations :D, after figuring out it was an easy fix
    I'm glad my gf made me choose red 13 for the screenshot since the tail region led me to the issue
  • migrating some of my code, that wasn't written with Ogre Resource system, to Ogre resource classes etc, mainly FLevel and components



serialization of Background Texture might not be completely correct but I'm currently aiming for integrating it into map loading of Q-Gears
so that one can load the files directly, instead of the xml files

also it's not really usable for editing right now, I will be implementing some kind of sorting or similar to generate larger tiles that belong
together later on, as both exporting and ingame usage should benefit from it, no priority for now though

KnifeTheSky77

  • *
  • Posts: 548
  • Somnambulistic Paraphile
    • View Profile
Re: Current state.
« Reply #107 on: 2013-08-24 23:49:04 »
Yay progress! I didnt realize you had started doing work on the mercurial account, maybe ill finally be able to get it to build and run  :evil:

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #108 on: 2013-08-25 08:38:13 »
if you need help building, open a thread or use an existing and I'll try to help :)

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #109 on: 2013-08-26 17:00:43 »
just a minor status update
  • finished migrating FLevel Background and Palette
  • implemented Texture Generation from Backgorund & Palette
  • bugfixes!
  • starting implementation / migration of existing XML Background2D to Ogre Resources

I had an issue with the generation of the Texture from FLevel Backgrounds, I was using PF_A1R5G5B5 format which works in DirectX but not in OpenGL
I could save it as an image and it would look fine and all but not if I use it for rendering
so now I'm always using Ogre::ColourValue to store colors and convert from there to what I need, that also has the advantage of being more consistent
throughout the system, as the ffvii files have diffferent formats. So one doesn't need to care or be aware of the different formats, just for serialization
it needs to be accounted for.

another Issue I had which I didn't notice until switching to DirectX for testing was mesh colours. I'm quite sure the model exporter for psx data suffers the same
it just works around it by loading the exported meshfiles. problem is when you create a vertex buffer for colours, you should do so in the format the RenderSystem
uses (OpenGL ARGB, DirectX ABGR) that one is squished as well :D it's nice to have the choice for DirectX :D


an image with fixed skeleton :) and FLevel background texture, just for testing

next is migrating some existing code to Ogre ResourceManagement so that I can easily switch the xml files for ffvii original data :D

Rundas

  • *
  • Posts: 704
  • What do you even do?
    • View Profile
Re: Current state.
« Reply #110 on: 2013-08-26 17:33:53 »
Nice to finally hear from someone. We were in the dark for a while.

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #111 on: 2013-09-01 21:09:27 »
nothing to show, but still a minor update
I'm currently digging into the source of qgears main part, refactoring parts of it to comply with Ogre::Resource management, which takes time
currently done is just the description of the map background (*_bg.xml) with serialization helper class so the other files should be faster
along side I implemented loading of the same file from flevel background directly from original data, walkmesh and camera data is still missing
so that will come next.
can't really commit though as I'm currently breaking some stuff in order to stick closer to the real data (ie no pre calculated stretching of background)

so long :)

Fischkopf

  • *
  • Posts: 217
    • View Profile
Re: Current state.
« Reply #112 on: 2013-09-07 11:27:04 »
So how far is the game playable now, with this implementation? I already dream of play FFVII withs all the graphics enhancement mods like on pc, on a tablet.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Current state.
« Reply #113 on: 2013-09-11 21:07:16 »
So how far is the game playable now, with this implementation? I already dream of play FFVII withs all the graphics enhancement mods like on pc, on a tablet.

I don't believe it is, just the content is extractable currently and you can script locations but not run in game script at locations.

Cyb

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #114 on: 2013-09-15 17:57:48 »
just a minor update, as I didn't do much this week. I implemented reading of Camera Matrix for PC Files and usage of it for Map Background loading.
I'm a lil stuck at how the Depth for the z-Buffer is calculated though, as I don't really know a bout 3D graphic code I can't make anything of what's happening in ff7 executable
I'd appreciate any pointer towards some good knowledge about such stuff :D
next thing is most likely walkmesh serialization for pc data, after that lgp archive reading, which should be easy as I can just take existing code and migrate it to Ogre FileArchive class

Hellbringer616

  • *
  • Posts: 1913
    • View Profile
Re: Current state.
« Reply #115 on: 2013-09-15 22:55:34 »
Download DLPB's menu overhaul, It's out dated but what you're after is the documentation, He pretty much knows everything there is about the FF7 exe

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #116 on: 2013-09-25 20:37:34 »
quite some time, not much done xD
I did play quite a bit of Tales of Xillia and Animal Crossing in the last weeks so coding was suspended a bit
I decided not to go for the walkmesh but did implement and Ogre::Archive for LGP Files, quite easy but still did take some time, I'm glad I have the motivation to stick with unittests makes it way more easy to change stuff and check if it's still working



so here some screenshots, background texture and camera settings are read straight from FFVII's flevel.lgp
as you can see I still have some issues with colors of the background and I didn't implement integration of
animation sprites for now
so all in all direct integration with original data is coming along quite well but still lot's of data that needs to be integrated into Ogres Resource Management system

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Current state.
« Reply #117 on: 2013-09-26 09:37:44 »
Cool. You progress quite well. I didn't have patience myself to get along with Ogre Resource system. Nice job. I watch your commits in merkurial )

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #118 on: 2013-09-26 16:09:47 »
yeah please do :D and tell me if I break something or should consider a different approach
I try to not break building, for your settings, but I'm not always sure, if I do so just tell me if you have any probs :)
at some point I considered using cmake to make building / setup easier but couldn't get my self to do so though as I don't have any experience with cmake but I really would like to so that I could switch to another IDE (namely QT Creator) as I'm not satisfied with code completion and some other bugs in CodeBlocks (random keyboard layout switching being one)

btw I noticed Q-Gears being gpl2 should I remove my MIT comments or change them to gpl2?
does anyone know what 's common practice with source forge projects, is the gpl2 mark on the source forge site good enough?
or any tools to automatically apply minimal license header comments?

sithlord48

  • Moderator
  • *
  • Posts: 1637
  • Dark Lord of the Savegame
    • View Profile
    • Blackchocobo
Re: Current state.
« Reply #119 on: 2013-09-26 16:35:36 »
GPLv2 is prolly the best option if you care about the code remaing open .  for the MIT stuff im pretty sure you can leave it as the MIT license is GPL compatible provided its not a BSD 4 clause style MIT license.

any code under the GPL should have a commented block saying something like

Quote
/****************************************************************************/
//    copyright <year>  <author>  <<email>>                                                         
//                                                                                                                                                     
//    This file is part of <project>                                           
//                                                                         
//    <project>  is free software: you can redistribute it and/or modify       
//    it under the terms of the GNU General Public License as published by 
//    the Free Software Foundation, either version <gpl version> of the License, or     
//    (at your option) any later version.                                   
//                                                                         
//    <project> is distributed in the hope that it will be useful,             
//    but WITHOUT ANY WARRANTY; without even the implied warranty of       
//   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         
//    GNU General Public License for more details.                         
/****************************************************************************/

and you also must also distrubite a file named COPYING.TXT containg the full license with your releases (source or binary).

and i would be more then willing to help switch the project to Qt creator because Qt creator is awesome an makes it much easier to build cross platform (even if not using Qt directly, since you can still beinfit from qmake, althought Qt is really good too)

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #120 on: 2013-09-26 20:27:45 »
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 :)

sithlord48

  • Moderator
  • *
  • Posts: 1637
  • Dark Lord of the Savegame
    • View Profile
    • Blackchocobo
Re: Current state.
« Reply #121 on: 2013-09-26 21:29:17 »
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.

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #122 on: 2013-09-29 21:24:31 »
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 :)

zerotacg

  • *
  • Posts: 41
    • View Profile
Re: Current state.
« Reply #123 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 :D patches are welcome, advise as well ;)

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

sithlord48

  • Moderator
  • *
  • Posts: 1637
  • Dark Lord of the Savegame
    • View Profile
    • Blackchocobo
Re: Current state.
« Reply #124 on: 2013-10-03 14:33:54 »
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]
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]
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 Edit: 2013-10-04 23:41:50 by sithlord48 »