Messages

126

Q-Gears / Re: Current state.

« on: 2012-03-27 21:26:18 »

I use windows so If there can be some improvements that not breaks whole thing it will be great.

Makes sense, I'll let you know if I get things working under linux using code blocks. If I can I make it work with cmake or do the traditional iconfig or some sort of autoconfig variant. First is always getting it to compile.

I don't remember any hardcoded things. Examples? Maybe it's for test purpose?

It appears the window settings are 1280x720 in the code for example? That's not a big deal to make configurable really LOL. Hence "you probably just wanted the thing to work".

Audio not completed. I plan to use some library that can play mp3/ogg.

I thought that would be the case, hmmm ogg has better resolution and is license free.

Pugixml is a lot faster but tiny not so bad too. And it covers all things I need.

Well I am always concerned about impact on small systems, what is faster on a BIG system is not going to likely be faster on a small system. A perfect example is MS vista design was built on monster 64 bit systems and not tested on the most likely systems it would be on. This is the most common mistake people make. I have a monster system but I don't code to rely on it. I examine everything to be sure it has the least impact. I plan to port Q-gears to my beagle board which has 128M of ram and an SD card for booting and software. It can support up to 1280x720x16bpp, 3d graphics, real time audio, and video decoding. So I figure if it can run Q-gears, then Q-gears is portable enough. I am currently tweaking PCSX to run under it, always something I guess.

Extractors no works independantly. In future maybe I unite them as one large extractor that converts all ffvii data to q-gears and human readable format.

Well actually I was thinking from more a typical unix style package install perspective, where you make everything including the utilities all at once, and then install with the correct permissions etc.

If they optimize their models then we could use them directly in game.

In Q-gears it would work.
I don't know if FF7's PC engine would be able to handle it or not and also patching the existing data set is likely to be fraught with challenges.

Anything else beyond that ... Sir halkun I default too.

Cyb

PS: I do appreciate you persisting where many have fallen. Not everyone has the time, ability, or patience. That is much too your credit. Mine was the time (eating is an important aspect of life after school).

127

Q-Gears / Re: Current state.

« on: 2012-03-26 23:31:00 »

Akari, You made me have to put on new pants with your latest update.

Here's a mop?

I should talk with the guys on TA have them export one background in 3d and do a demo. I'd die of heart failure if that happened though haha.

Hmmm well I don't exactly know what that would do. If you look at the images Akari posted carefully, do you see those white and red lines? That is the walk mesh. The background is in 2d. I believe in only one location is there are actual 3d objects as part of the background that move. That would be the Midgard train yard. I don't recall how those are put in there off hand either. All the other places are 2d hand draw backgrounds. The reason I'm mentioning this is, how do you plan to support a large volume of 3d data in FF7 background system? It wasn't designed with that in mind so you might have some difficulty getting such backgrounds to work. The cameras are mostly static so the 2d drawings worked well in the original game.

The back ground format is well known, I don't know about the 3d content. The models in the field scene are contained in an associated BSX file (PSX) then the field palettes are contained in a file called FIELD.TDB (again PSX). That being said it would be extremely complicated to add that information especially if it had textures. Coloured vertices scale nicely but textures require a lot of tweaking and more importantly this is additional data the engine has to read from some place (FIELD.TDB). That means that the game data ends up being edited to be more than just replacing a background tile map. That has it's limits too but not nearly as much as a single file containing all the palette data. It has to work with the original binary executable (Team Avalanche's goal at least).  On the PC side data the wiki is a bit weak in terms of how the data is stored (although it should be there because people have been beating on it).

In simpler words, it's doable but not particularly practical and unlikely to work with the PC version of the game (or the PSX for that matter).

Cyb

128

Q-Gears / Re: Current state.

« on: 2012-03-26 21:03:19 »

Get lastest version from repositary and look at it )
There are a lot of new things there )

By the way just finish ffvii camera export and basic ffvii background support. looks nice in 16x9 aspect )

<cool images pruned>

all right I'll do a

Code: [Select]

hg clone http://q-gears.hg.sourceforge.net:8000/hgroot/q-gears/q-gears   then of the repository (somehow I feel another pun there ... hmmm).

you are going to make me cdrdao an image of my FF7 disks too I can feel it.

then I have to read the directions (memory isn't so good these days).

....
Now that I have a look at it, the configuration seems predominantly oriented toward using windows, looks like I may have to make some modifications.

It doesn't seem to like the -mthread option I wonder what code-blocks is using at the command line as the GCC supports that. It vomits on compiling Main.cpp (heh did it first thing).

Erstwhile looks like a few things are hard coded, my guess is you did that because you wanted to see the bloody thing work after all that time spent?

Audio core is under works (looks that way) have you considered timidity for sequence playing?

tinyxml woo hoo. Nifty I always used xmlparser but its C++ builder specific so ... it did not work under Linux. Using a full xml parser probably would be ridiculous too.

I see all the utils have there own cbp files too. Interesting, the way it's set up likely take a while to build the whole thing and I probably would have to do it by loading each code blocks project in and compiling looks like.

even more stuff to do (apart from getting codeblocks to compile things correctly that is).

Cyb

129

Q-Gears / Re: Current state.

« on: 2012-03-25 16:18:07 »

2-4 hours for exporters and q-gears itself and 2-4 hours for reversing. And yes, I'm still the only one )

It is sad, but I am not sure what to help with these days.

My platform has changed 3 times since Q-gears started all with an associated WTF to do about tools for compiling testing finding the code I did write and pulling hair.
(Check need more hair to pull out.)

It is nice to see you have been progressing at least.

I've been more active on embedded systems et al of late (and mangling Oblivion).

The later is just too much fun.

Erstwhile for fun have you considered using the espeak software for a 'dialogue' plugin filter or what have you?

Or is there a way to pipe dialogue (with proper pauses emphasis etc) to espeak?

Ahhh you're making me think (LOL). If I remember you are using windows mingw and codeblocks for your build suite?

I can't do windows (pun somewhere in that statement) so I have ye olde Linux (and code-blocks of course).

I believe for the last few years my largest impedment went like this:
Time
figuring out what to look at first
documentation
but it's been about a year since I gandered at it.

Cyb

130

Q-Gears / Re: Q-Gears v0.20

« on: 2011-11-21 23:08:15 »

Q-Gears uses Ogre3d 1.7.2.
It seems that all errors come from wrong Ogre version.

So you are using the last build suit? I don't know how Ogre's versioning system works, and I know that 1.8 is due in January. However 1.6.5 is consider stable, 1.7.XXX was not.  I was going to ask that question but it seems to be self evident. You appear to like to use the latest and greatest. That can create some dependency issues (IE people have to go around grabbing newer version of software). My version of linux is a pain to use the latest and greatest with because it's considered unstable by the maintainers. I don't know if that is true however there are a huge number of bugs listed which relate to the 1.7.XXX and they don't specifically have to do with Ogre, mostly with the libraries it wants to use they have bugs that lead to security issues apparently.

It's a chronic problem with Linux one can end up having to update there entire library suite just to run one application only to find that those libraries make about 100 applications die horribly because the new versions are either incompatible or contain bugs that haven't been fixed that prevent them from playing nice.  I could build OGRE 1.7.3 however as I just noted that can create a long list of other problems (like I experienced with GTK 3 for example). Java apps API do not play nicely with GTK 2/3 and throw up with lots of green relish and onions. (LOL) Although none of my other GTK based apps complain just anything using teabag. Sigh things just got a whole lot more complicated for me.

Hmmm you use code blocks right? Can that generate an automake or cmake config script?

Cyb

131

Q-Gears / Re: Q-Gears v0.20

« on: 2011-11-21 00:06:46 »

What are issues with OIS? I thought I fixed mouse on Linux.

Now slowly work on 2d backgrounds. Didn't commit anything for few month. Maybe it is time =)

To be EXACT my problem was I didn't know what it was. I hunted down the library and installed it today. I can't do everything at once, don't even try these days.

Perhaps an INSTALL file for unix type systems?

I may make an 'gentoo' emerge package for it. So that If someone wants to build it under Gentoo linux it will be able to automatically grab the libraries necessary to do so. As for getting the 'official source' for Q-gears that is a different matter. I don't want it's source in a gentoo repository it's simpler to have the one location instead of duplicating stuff all over and 'fiddling around' with it. So I'll have to see how I can set up the 'emerge' script to do something a bit 'special' to build Q-gears (IE fetch the code from a NON gentoo repository). That is a VERY long and complicated discussion I doubt you really care to hear (LOL).

My current failure is here:0

Code: [Select]

Main.cpp:53: error: no matching function for call to 'Ogre::Root::setRenderSystem(std::vector<Ogre::RenderSystem*, std::allocator<Ogre::RenderSystem*> >&)'
/usr/include/OGRE/OgreRoot.h:278: note: candidates are: void Ogre::Root::setRenderSystem(Ogre::RenderSystem*)
Main.cpp:88: error: cannot allocate an object of abstract type 'DebugDraw'
core/DebugDraw.h:13: note:   because the following virtual functions are pure within 'DebugDraw':
/usr/include/OGRE/OgreRenderQueueListener.h:67: note:   virtual void Ogre::RenderQueueListener::renderQueueStarted(Ogre::uint8, const Ogre::String&, bool&)
Main.cpp:104: error: cannot allocate an object of abstract type 'UiManager'
core/UiManager.h:15: note:   because the following virtual functions are pure within 'UiManager':
/usr/include/OGRE/OgreRenderQueueListener.h:82: note:   virtual void Ogre::RenderQueueListener::renderQueueEnded(Ogre::uint8, const Ogre::String&, bool&)
make: *** [Main.o] Error 1
Which specific version and libraries of Ogre does it rely on? I need to make a list of libraries it wants I suspect.

I thought the 2d back ground code existed already? Or am I missing something? Probably am wouldn't be a surprise there!

Cyb

132

Q-Gears / Re: Q-Gears v0.20

« on: 2011-11-15 14:20:52 »

Got a round too it.
Hmmm there is no cmake .configure etc. running make of course generates lots of complaining but it does build 'stuff'

installing openal and OGRE was easy enough there seems to be issues with "OIS" which I have no clue what is.

It almost compiled took 5 minutes to do that much. The big problem was figuring out how to use mercurial to clone q-gears.

The main page needs an update. I suppose I should reactivate my sourceforge account huh?

Cyb

133

FF7Voice / Re: Cloud lines and other means to an end (suggestion)

« on: 2011-11-02 00:11:16 »

I'll definitely play around with the idea for filler lines and NPC's.

Thanks.

A bit late but sure. As I said it seems to work fairly well. You can add custom voices to it although it's not a simple 'plug and play' process it is functional. They support a large number of languages as well. Which can also allow you to make voice translation variants I suppose as well.

Cyb

134

FF7Voice / Cloud lines and other means to an end (suggestion)

« on: 2011-10-17 22:37:02 »

I've noticed the chronic issue of someone acting 1500 voiced lines. Apart from driving the actor insane (take 12 of line 1422 ) and hoarse in voice, it's a bit unrealistic. I concur that the major lines can be voice acted, more accurately put I suggest scenes that require inflection not just casual conversational tone. I would suggest a slightly different approach to the esoteric scenes that aren't required to do anything with much emotion.  Voice synthesis using the actors voice and some slight tuning something like espeak could be used to make esoteric speech (IE stuff that doesn't involve inflection etc.)

I have tested this with the generic MBROLA diphones provided with the program and the results were reasonable, for both male and female gender. I would suggest this as a reasonable means to an end. Especially for the casual conversation in the game.  With some diphonic tweaks you can create a considerably larger set of voiced lines, and reduce the voice actors 'wear'. This is what you have to do in any case (without the addition of speech synthesis), so I see it as a creative means to getting there faster.

There is an incomplete SSML interface on the synthesizer but to key you in IT WORKS, I've USED IT, for a simple project of giving personcom CM partners in Oblivion a somewhat artificial voice instead of a copy of Imperial race voices. Worked surprisingly well that I didn't erase all evidence I tried it. I still use it too. LOL

I wouldn't recommend it if I hadn't tried it already. The Carnegie Mellon speech website is fairly good, that is used by Microsoft (who shamelessly gives no credit to the creators as usual), they just used professional voice actors and tuned things a bit to make the Microsoft speech tools. Also there voice recognition software is a copy of the CMU sphinx tool kit. (blatant again but the licensing allows this). Just tweaked specifically for Microsoft products.  The issue is becoming familiar with the tool. I suggest espeak because it is much simpler to use and fairly straight forward. No need to compile anything for using the synthesis tool.

This would allow a lot of 'blah blah' lines to be generated without having someone speak them, and leave the more important lines to be tweaked and worked on by the voice actor. In addition any 'normal' lines can be generic or voice acted and or tweaked as needed.

Just a thought.

Cyb

135

Q-Gears / Re: Q-Gears v0.20

« on: 2011-08-27 14:21:41 »

so i would have to fork from your source to do a FF8 version...gotcha. well i might much later, so i guess i have to work with 7, 9, and xenogears first.

You do realize that's a fairly BIG arena. Also last I checked chrono compendium had made progress with Chrono cross.

It's not that simple to add some game. You can't compile with it or something. You need to create exporters from all data this game has to Q-Gears. now q-gears is mostly framework that can load models, music, scripts and allow some iteractions between them. it's still a lont way until this can be real game. Next milestone must allow anyone run through few start maps of all 3 games I want to support.

Exporters from FFVIII is posible, but it's a lot of work. I'm not a big fan of FFVIII so i won't do it. I work with FFVII FFIX and Xenogears. you can help anyway. There are a lot of things that anyone can do.

Someone can create all menu's from FFVII for example. It's not that much work =) I create just two windows.

Akari do you keep incremental source snap shots for when you make  a version change? I was muddling at that just a bit ago and it appears your versioned releases are binary only, (which I can't use since I'm on Linux these days). I'll have to just 'get the source code' hopefully you won't break anything in your updates so I can test it at least.

<opinion>
FFVIII was a big change, but for some reason I liked it better than FFIX
</opinion>

Erstwhile I was considering the addition of a pipe of spoken text to Qgears for speech (not recorded voice but synthesis). I haven't messed with microsoft speech tools but I have found a reasonable library for doing so apart from MS. MS tools are based on CMU's work (the licensing allows them to do this).  It appears they had professional voice actors to generate the based data and did some editing. All in all it would be about a few months of work by them from what I could analyse. Erstwhile I'll have to see what sort of DB engine you are using as well.

Source code peering time, I presume you use Code blocks?

Cyb

136

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2011-04-02 15:39:05 »

Odd. Ill look into it

Now if you were a salesman you would have said "that's the crotchless version it costs extra".

I can't find any way around the blinking.  The part added to bone will always be slightly larger than than the original model.  This means even if you reassign the open eyes texture to this new part it won't blink.  AABA is the only one that will blink.   I've tried more than a few work arounds and it seems the only way to make the blinking look right is to resize the head on the Y axis to be 99 instead of 100. 

Now this does mean his head will shrink ever so slightly in one direction, but I couldn't notice it except on the back of his head...staring very close up and with Cloud facing left.  Also, I'm sure NCS knows how to fix the transparency issue using Image2Tex, so that's no problem.

However, I would suggest looking into the c_eye2.tex file replacement.   This will eliminate the need for a second head on many models (saving file size), I'm just not sure exactly why the head still blinks slightly using this method...  the switch should be instantaneous. If the texture were smaller size it could possibly remedy the blink, but I'm not positive.  Test it yourselves and let me know what you think.  I'll be checking the smaller texture size to see if that helps.


EDIT
And another discovery,  after saving the head change to 99, reopen the model and change it to 101 on the y axis.  It will now be the same size as the open eyes model, but won't flicker during blinking.

EDIT2
Nope, reducing file size didn't work.  I went from 12mb to 768kb on the textures and it still flashes.  So the above solution is the only way to make blinking work correctly that I can find.  No need for me to upload the changed model since NCS hasn't quite finished everything and the solution is a very quick fix.

You might want to consult the QGears information on FF7 and the wiki?
The blinking is an animated texture if I remember correctly.
The flicker is because of the distance the eye plane and blinking plane are. The blinking texture is over the eye data. In the battle model you have no blinking but in the field models you do. The problem has to do with the PSX hardware being PIXEL dependent. So if you offset the blinking plane an exact fixed distance from the eye plane it won't flash (this is actually inter-modulation of the distances between the eye plane which is white and the blink plane). Basically you need to offset the face so the eye plane doesn't intersect.

If you think about how FF7 is structured only one set of bones and data can be manipulated to make the blink work for all characters with minimal code. That is what I suspect they did. I would do the same. Remember these guys didn't just have a financial budget but a time budget. So they had to make it work not necessarily in the BEST method (as they didn't know what the best method was at the time). I realized all this when I was wondered why when I tried to render field models they had no eyes (LOL) but white spots instead. It was a moment of ... DUH. Anyhow sounds like ye olde occlusion issue.

Anyhow I believe you need to create a fixed offset from the original plane in one direction (the direction perpendicular to the face) to prevent the blinking and eye plane from colliding. The original FF7 data is likely exactly 1 or 2 pixels different in the perpendicular plane to accomplish this.  I've done this by accident in several game mods I've done too (except I mixed the surface of the eye and eye lid, looked hilarious to see an eye poking out suddenly during a blink). If you already know all the above ... woops? Didn't mean to blather then.

Cyb

137

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2011-01-24 21:37:05 »

Oh yes, sorry got on a little side track....

Oh heaven forbid that happen LOL it's always good to do something other than the same thing over and over again and expecting something different, I've heard that is the definition of insanity by the way.

but progress...
pretty much finished the warehouse

time to sleep...now.
 

Sleep that elusive rest thing!
LOL,
Warehouse during sector 8 roll in ...
The second I don't recognize, hmmmm.

Cyb

138

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2011-01-23 00:29:03 »

Personally I don't think there was a lot based on real science within FF7, the annoying flaws keep piling up within several backgrounds...impossible buildings, impossible sizes, impossible renderings.... etc etc.

but non the less, we'll keep having fun (when time permits) 
PS Happy new year everyone. 

I believe that FF7 was meant to be surreal in many ways.

Progress progress, apart from my myriad of things I'm doing myself, I spend a little time working on each hobby project every so often.
Erstwhile glad you've not lost interest.

The bombing mission being the start of the game, I'm interested in assisting in any generated video content that might be made.

Cyb

139

Team Avalanche / Re: *OFFICAL* Battle Scene Reconstruction

« on: 2010-12-03 22:02:58 »

How about this sand?

Well if you look at it carefully it's a sunset beach setting. IE the beach at sunset. The angle of the sun at that time is close to the zero angle (angle at which anything and everything reflects off a surface). This creates some unusual visual effects on the beach surface. I believe that was what the original creators of the scene were trying to do. Beach sunset with weird sea creature I guess?

Cyb

140

FF7 Tools / Re: World Map to .Obj Converter (and back!)

« on: 2010-11-01 01:13:41 »

Just checking up and seeing what the progress is? Any clue how much more to complete before a release

All things considered why are you so bent on the progress?
The last post from the author was well within the week. I suggest you exercise some patience (any will do). Aali has been VERY faithful to post progress on ANY of his projects when he had any. If he had any it is very likely he would have posted something to let people know.

He even took the time to place the information in the wiki, if you want something to read or modify the world map just read the wiki and DIY then?

Cyb

141

Team Avalanche / Re: GUI v2.0

« on: 2010-10-27 02:28:52 »

I am sure this is doable, but would require a lot more magic from aali.

Aali magic I hear is in short supply.

Just like I don't have a lot of time to learn a whole new modeling system. LOL

You get busy and the business makes your life frustrating at times I guess.

Cyb

142

Team Avalanche / Re: GUI v2.0

« on: 2010-10-26 20:36:24 »

Just whipped up a quick upscale of the original wide font, looks much better in regards to spacing!
http://screencast.com/t/2rn1eEoKi

Can't wait, Sl!

It's too bad that can't be a true type font so it could be made dimensionless. This makes rendering the texture for the font a snap if you want to scale it to any resolution you want. In addition you can add alpha data for the AA around the edges as well. Having made some renderings using free type to generate bitmaps. That scheme might work. As for making the font heh, lots of people have made fonts on the net, and there are lots of tutorials. While you wait for sl1982 you could twiddle with that idea.  As I said this allows you to make it dimensionless and scale to a texture as needed using freetype (which can render to a bitmap). The hard part might be font placement in generating the output data.
You would have to look at the original texture that the font is loaded into to tweak that kind of thing. Then be sure the rendering point (XY coordinate) relates to the XY coordinate in the font data. I don't recall how that map data is utilized within the game it's been 2 years since I've played FF7 (too many other games like Front Mission 4 From Mission 5 and From Mission CE). Anyhow a lot of twiddling but you only have to do it once, after that your font can be rendered for the final user resolution and always look correct.

Cyb

Cyb

143

Team Avalanche / Re: GUI v2.0

« on: 2010-10-24 15:49:50 »

I'm not sure if anyone else is noticing this but the new font has some serious spacing issues that weren't there before.
Also I know this is about half a year too late but I have a bit (huge) affinity for nixie tubes and though there technically they never made krypton nixies my quarrel comes with the brightness rather than color.  They seem too dim for nixie tubes and the hue seems slightly off from the original (I could be wrong here).  I know sticking to the original is more important that adhering to realism (final FANTASY etc.) but I think visually the timer could use a helping hand in sticking out.

<HUMOR_MODE>So you want the font to be 3d?< /HUMOR_MODE>
Perhaps screen capture both screens font output and cut out that section of the image that shows the time, for each. Then do a pixel test to see how far off it is (HSV or RGB based either way). I would be sure to use the identical time for both examples. You may want to also see if it is different per background as well.

Cyb

144

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-10-21 22:42:04 »

To be honest I havn't had much time to work on things these days. I have been working 12-16 hours a day and my wife is due to have our first child tomorrow. I do have some things that I have been planning on releasing but they are not related to the bombing mission (GUI v2.0).

Oh that means you'll have even LESS time LOL.
Congratulations, just remember family first, work second, ...

Cyb

145

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-10-19 16:18:34 »

Exactly right NCS, just like I haven't worked on Jenova FF7, Griever FF8, Dagger, Cross, Hideous (think Tidus from FF10 LOL). or  Ktjn (FF12) for a while  these are stuff I do in my rare spare time. I have house repairs to do for goodness sake, so  just think of it this way people have other stuff they HAVE to do first. Besides that just getting things set up to do takes time on such projects.

Realize these people have other commitments that are higher priority than this and that those take precedence. As much time as they have committed to doing this and have accomplished I can appreciate the effort (having had some such projects before).  Burn out is a serious thing as well. If you spend too much time doing something the rest of the things you need to do will hit you hard.

It's not the end of the world if it isn't done by Christmas (besides they aren't paid professionals they are volunteers, with a good attitude to boot).

Cyb

146

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-10-17 20:00:09 »

In bsx files. There ara one light and one color definition for each character.

The BSX data format in the Wiki? Just wondering suddenly.

I'm sure it's in qgears source somewhere.

Unfortunately POV does require light data for rendering. Fortunately you don't need it to do backgrounds. Irregardless POV isn't everyone's cup of tea. It's not the best nor the worst. Most people aren't familiar with it I've noticed. That being said no point porting stuff if people can't figure out how to use it. Also most people can use the tools they are familiar with (POV for me for example).

Cyb

147

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-10-11 23:26:25 »

If the background really are rendered as 2d, and it seems to be that way, then the lighting is indeed painted in or over, but it seems that it is possible to to reverse engeneer the lights in the backgrounds.

I remember someone at MIT was researching reverse ray-tracing to find the original light source information transform the page into 3d data and then re-render it with a different lighting. It was fairly successful. There was also a person at CMU who did some reverse ray tracing to get geometry data for things in pictures as well (2006 I think the later was and 2002 was the MIT person). That aside I believe you are right, since the scenes have 'overlaid' illuminations in the block data I suppose using the alignment can be used for best guess on spot illumination.  To get the original lighting an initial best guess will be needed and looking at the walk map will also help I suspect along witch camera data).

If you need any help I can do my best. I've been incredibly busy for some damned reason (oh wait I work 50 hours a week that might be it LOL). Anyhow between this and that I might be able to give educated guesses (or you can do so yourself since you should be able to make reduced polygon geomtry to do test lighting on). Honestly I think this stuff would look incredible in POVray

Cyb

148

Team Avalanche / Re: New Project: Bombing Mission!

« on: 2010-10-10 19:36:18 »

To answer your questions, I'm using Max as a modeller, therefor the dataset would be max-files 
On occasion I use a primitive, however most of the time I start with a single face and push vertices around to create an object.
Oh, and no lights yet, just a skylight of the renderer.

Then I assume all scenes will be rendered then recompiled for the FF7 engine?
I am assuming a lot probably

The hardest part is to guess the right position, some backgrounds are easy and detailed, but the current one is a real b*tch. I think many backgrounds do have faults in them. Probably due to time constrains (for instance compare NMKIN_2 with SMKIN_2, the upper right corner with the crane (or whatever it might be). The placement of the objects are overlapping, and not consistent with real space, but I guess that's why it's called Final Fantasy 

So without further delays, here's the update, enjoy.
<sniped image>

Well the original backgrounds were hand drawn (starving anime artists of the late 90's likely), scanned then pixel edited to make the backgrounds look good. The data then was carved up (cells were used for certain parts) into blocks and stored accordingly.  Since TA plans on using the original FF7 engine this is your process (accept you are generating 2d files from 3d scenes) and you need to use the original background information to put the animated data back in. Down side to some of that is the animation rates may need some correlation so you don't have a speeding background (LOL) torches shoot fireballs type stuff (like any game that's animated faster than it originally was designed for).

I had wondered about the lighting, now I know, FF7 I believe rarely used actual lights (more like overlays to brighten sections). This was debated, I am sure Akari or Mickey knows far more than I do.

All the lighting was done by the 'artist' who drew the original scene. So it may be necessary to adjust the lighting so it's correct.

Cyb

149

FF7 Tools / Re: [REL] Omzy's .MAP -> .OBJ Converter

« on: 2010-09-18 23:57:53 »

At this point my little project is finished and works well enough, so I think I'll leave it at that. Thanks for the offer, though!

Heh you just think it's done OK works for me, it would have taken me a bit of time as this stuff is over 6 years old.

Cyb

150

Archive / Re: FF7 PSX videos

« on: 2010-09-18 23:53:41 »

Thanks for your ramblings Cyberman!

Now that's a first LOL

I was actually pondering this very thing the other day: is there any value trying to scale at the DCT coefficient level? I wasn't sure how it would be possible, but now I see that the DCT equation is indeed dimensionless, so it could use 8x8 for the input matrix, and ANYxANY for the output matrix. I'm really curious what the results will look like. You have given me a lot to explore...

I don't believe playing with the coefficients will gain you that much. I believe the adding data (IE a second pass with sub pixel resolution) might be useful. What data to add is the problem (or issue). To give you more information the wikipedia article on JPEG is quite good.  SONY used MJPEG to perform is compression. JPEG compression is considered LOSSY because they throw out information that has low 'signal' in the stream of data.  Reintroducing this data by some method may be a way to enhance the sub pixel resolution.

My thoughts exactly, which is why jPSXdec uses floating-point math for all its operations (quantization, IDCT, etc) in the 'high' quality setting. Now if only it was possible to keep that floating-point fidelity in AviSynth and its filters, then my quality cravings could finally be satisfied.

Well aviSynth would have to use SSE3 or SSE2 instructions and I believe it only uses MMX level. This is how it achieves it's performance. I began using MMX code when I was making a software plugin for playstation emulators.  Moving to SSE2 instructions would resolve some of the performance issues you have when using floating point instructions for the DCT (basically you can perform 4 single precision instructions simultaneously instead of 1 at a time).  This would be a big performance hit using AVI synth but I've never seen people use it in real time anyways (shrug).