Messages

26

Q-Gears / Re: Current state.

« 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
as I nether wrote any cmake please correct me if I'm doing it wrong or just not good

27

Q-Gears / Re: Current state.

« on: 2013-09-26 20:27:45 »

thx I'll add the gpl header comment then

as for help, patches are welcome
adding cmake to the build process really might help going cross platform and I could switch IDE 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

28

Q-Gears / Re: Current state.

« on: 2013-09-26 16:09:47 »

yeah please do 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?

29

Q-Gears / Re: Current state.

« 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

30

Q-Gears / Re: Current state.

« 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
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

31

Q-Gears / Re: Current state.

« 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

32

Q-Gears / Re: Current state.

« 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 it's nice to have the choice for DirectX


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

33

FF7 Tools / Re: [1.6] Makou Reactor - a FF7 field editor

« on: 2013-08-25 20:28:37 »

nice tool
maybe I could lend you a hand with PC Field Models to get shading?
I saw you commented out the reading of the normals, not sure why though, and as I have it working for Q-Gears, maybe I can help

34

Q-Gears / Re: Current state.

« 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

35

Q-Gears / Re: Current state.

« 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 , 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

36

Q-Gears / Re: Using available Game Engines?

« on: 2013-08-19 17:06:46 »

I understand quite well the purpose of Q-Gears an existing game engine might still speed up the project if it fits the requirements

don't get me wrong, I'm not all for it, I'm just open to suggestions and if it speeds up the whole project reasonably one should consider it.
And to get compatibility with original data is a point on the list (how doesn't matter project speed is important)

no matter what, you have to implement gameplay and all, it's the same with an game engine as with writing it your self so that's not a reason
but a game engine might bring stuff that really helps and speeds it up. in general I'd say they bring ai, physics, graphics, user input, entity management (like making
entities react to user input or automagically play animations etc) and, not to underestimate, tools

nothing in there yet where I'd say that would help a lot, since ffvii doesn't use physics and akari already wrote lot's of stuff you get from an game engine, but as I already
stated, open for suggestions

37

Q-Gears / Re: Current state.

« 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 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 Using available Game Engines?

38

Q-Gears / Using available Game Engines?

« on: 2013-08-19 06:15:37 »

As halkun suggested it might be a better to use a complete game engine over just Ogre and writing our own.

In it's current state it shouldn't be to hard to switch to a game engine. We should think about stuff that's hard in general to implement and stuff that is a must and than see which options we have that make them easier to implement (with sticking to current self written engine being an option to).
Thinks that come to my mind are:

• Cross Platform
• ability to read native data PC/PSX, including Sound/Midi formats
• Mini Games
• Tutorials (only for menus? didn't play ff7 in a long time)
• Field Levels, 2D background with multiple layers, animations or video and 3D Data
• transitions between Field Levels, Battle stage, World map
• Vehicles

where as I think sound and video playback with overlayed 3D would be hardest

39

Q-Gears / Re: Current state.

« 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

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

40

Q-Gears / Re: using q-gears for testing team avalanch data?

« on: 2013-08-11 20:31:30 »

I'm not sure where akari is heading with qgears but it looks more like

• convert ogiriginal data to ogre friendly format
• run qgears on ogre files

I try to stick a bit closer to the original data using Ogres resource management etc so that one could run it solely on original data, in addition to necessary engine stuff.
Still I do implement loading of the file formats as I think is appropriate, and you would more likely want to check against limitations of the original games implementation?

41

Announcements and site development / Re: New Users Can't Register

« on: 2013-08-11 20:18:59 »

yey finally on board, was getting the same issue
kudos to alyza for helping me out

a short introduction, I'm me , a coder and wanted to join qgears
I'm already coding on it, but mainly learning Ogre and catching up on stuff

thx again for the help in registration