Working on Field models.

  • Thread starter Thread starter Akari
  • Start date Start date
Status
Not open for further replies.
This week brings almost nothing. I'm in the middle of reversing creating packet drafts and filling them with real data. But it liiks like I will need to parse eyes texture loading too. As I can see Square did all rasterization all by themself. During loading for all types of polygon packet draft is created. Packet draft is place in memory where all static data for specific packet is filled (packet header, texture data). During render vertex coords copied in there too and, i suppose, they sent to GPU. A lot of work lies ahead =)
Click to expand...
This is one of the reason why generating the textures for the battle models was hard.
First the TIM data has multiple palettes. At first one would think "no big deal they have a list somewhere right?" No. You have to use the polygon data to guess which palette to use.  So my guess is you have to render your textures like one would have to for battle models. IE render the texture data but iterating through the available data.  As for eye blinking, how is that handled? The mouths aren't animated (let me check) nope not animated in the least. So the script handles the eye blinking or does the game engine (automatically)?

Cyb
 
This week brings almost nothing. I'm in the middle of reversing creating packet drafts and filling them with real data. But it liiks like I will need to parse eyes texture loading too. As I can see Square did all rasterization all by themself. During loading for all types of polygon packet draft is created. Packet draft is place in memory where all static data for specific packet is filled (packet header, texture data). During render vertex coords copied in there too and, i suppose, they sent to GPU. A lot of work lies ahead =)
Click to expand...
This is one of the reason why generating the textures for the battle models was hard.
First the TIM data has multiple palettes. At first one would think "no big deal they have a list somewhere right?" No. You have to use the polygon data to guess which palette to use.  So my guess is you have to render your textures like one would have to for battle models. IE render the texture data but iterating through the available data.  As for eye blinking, how is that handled? The mouths aren't animated (let me check) nope not animated in the least. So the script handles the eye blinking or does the game engine (automatically)?

Cyb
Click to expand...
Blinking handled by engine, you only can turn it on/off from script. I don't found this yet, but it's not high priority.

The main problem not the textures, but dynamic model changing using KAWAI opcode. I dont fully understood it yet, but it is a sequence type opcode (as I understood). It copy control byte to header for model related data (can be 0-D) and copy pointer to folowing data. This pointer is read during kawai parsing on every model render. There are really great amount of hard to understand code. So first I try to understand how usual routine work.
 
Local field textures working. Now I try extract models and working on global eyes texture.

Screen of Potion in Ogre mesh viewer.
s320x320


Door with texture.
s320x320


Treasure chest.
s320x320
 
Akari have you defined an interface betwixt Q-Gears and the Ogre VI you are using or are they mingled together?
IE something akin to this (simplistic but affective)
Code: [Select]
Code: 
for(index = 0; index < ggears->scene->object_count(); index++) Ogre->CurrentScene->AddObject  (  qgears->create_object   (   qgears->scene->get_model(index)   )  );
Where create_object makes an object that the Ogre object can convert to whatever internal format is used (for Ogre).
A lot of 'magic' OOP stuff going on obviously in the background.
I can't remember if C++ (Gcc variant) allows properties. I know VC++ uses something like that and Borland C++ does as well.

Cyb
 
Last two weeks there is no much progress. I working on two separate task: first - I continued working on exporting models in Ogre format. This two screenshots shows some progress. I correctly exported animations and now work on exporting textures. PSX can set different rendering attributes per polygon but I cant do this using standart render, so I deside that I will use simple shader that will render texture using this additional data which will be stored with vertex. There one more problem with savepoint model (it has two same submeshes one move clockwise, other - anticlockwide, but they colated in same plase so there are a lot of z-fighting and other gliches) - i will solve this after shader =)

s320x320

s320x320


Second task - I continue reversing of battle algorithm. There are great amount of hacks  and I still don't know meaning of some structures so it not moving forward very quickly. Mainly I reversing battle initing and sense function.
 
It's been quite a while since I last wrote here.

Last month I implement console to q-gears engine and add posibility to load different maps with different scripts (earlier it was hardcoded).

I add animation support. Usual commands like play-animation is workind, but some things is not finished yet. Mainly it auto play during jump and ladder move. But things like auto play animation on usual move already done. Also I add run to manual entity movement.

Soon there will be second alpha release with animation support.
screenshots coming.
 
Tis good to hear from you. I have some new thoughts on Q-gears. Namely it may be possible to do some things without heavy C C++ or for that matter OGRE knowledge. However first things first. I have to finish my updates to Griever FF8 and Jenova FF7 and Dagger which will be the learning basis for possible addition to Q-gears.

Erstwhile it's good to hear about your work with scripts etc. I'm glad you are more persistent than other people.
Cyb
 
Wow, from the looks of things you will have all the hard work done before the end of the year.
 
never say that, the calamity will strike when enticed XD; It looks so much better than the q-gears I played with from sourceforge...
 
Status
Not open for further replies.
Back
Top