Engine building. If we make it, will they come?

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
A few thoughts on portability:
If we want it more portable, then OpenGL is probably a good starting point. The other option is to keep the Rendering engine seperate from the content extraction.  Essentially each localized rendering engine is optimized for whatever system it's running on.  All optional enhancements should however are NOT be part of the rendering engine. Doing this would make a lot of descrepency problems.  The prefered method is querrying and passing the options to the engine.  This method prevents splintering of the base code and it's option handling.  It also makes the code for option setting universal instead of each option system different per platform.  Consistancy is important.  In fact it's more important that the UI be consistant for every port than how cool it looks. This leads to a lot less frustration to the poor guy having to use it.

A list of base options I would prefer for graphics:
Full screen
Windowed
Image resolution selection
'Driver' selection (IE OGL GDI DirectX X software etc.) This is a compatibility issue with the hardware and is obviously indicating the possibility of multiple rendering engines for each binary.

Audio support is another issue.  It might be a bit complicated to say the least.
 
Audio support is another issue.  It might be a bit complicated to say the least.
Click to expand...
You could try OpenAL. That should work fine for soundeffects, maybe even better than the original.
It will become tricky for the music. You could convert it internally to MIDI and pass it to the operating-system's synth, or write a soft-synth and write it out as a sound stream.
 
Why would you want to use OpenGL it is slow compared to DirectX?

EDIT: Oh right for other OS's i gotcha now.
 
Why would you want to use OpenGL it is slow compared to DirectX?

EDIT: Oh right for other OS's i gotcha now.
Click to expand...
It's all relative mostly it is faster but it can be slower depends on how cheap a card you are using is.  It's mostly dependant on the vendor's implementation of the standard.  OpenGL in general is simpler to deal with.  The big area of contention these days is the fact DirectX has become more like OpenGL.. ironic isn't that?

Back to the main subject, anyone have thoughts about the interface between the script engine and graphics engine?  Or maybe we should proceed with more discovery :)

Cyb
 
When the battle-field animation format is fully decoded I can finish my project’s battle engine (mostly; particle effects and camera motions are also not yet hacked, as well as sequence scenes for summons and spells), and I will at that time also begin the server code, which will make menus functional and drive the battle engine.

Because my progress depends on how much and how quickly we hack through the game, I have had plenty of time for planning and making sure that each new addition is done correctly and with stability.

After that, the 2-D backgrounds for the non-battle fields need to be more fully understood.

Then there is the over-world map/tree.

Particle effects and camera motion need to be hacked as well, as already mentioned.

This is my checklist.  I believe we have everything else we need to have.

And I think it could be more efficient to have some working on the engine while others are hacking.
And some who do both.


L. Spiro
 
When the battle-field animation format is fully decoded I can finish my project’s battle engine (mostly; particle effects and camera motions are also not yet hacked, as well as sequence scenes for summons and spells), and I will at that time also begin the server code, which will make menus functional and drive the battle engine.
Click to expand...
I'm getting close to starting with the battle animations with the PSX again.  A few more things to do with my current project and that will be up for working on.

Because my progress depends on how much and how quickly we hack through the game, I have had plenty of time for planning and making sure that each new addition is done correctly and with stability.
Click to expand...
Stable is a good thing.  Hopefully I'll be done with this project soon enough to my satisfaction, my real goal of dealing with the battle information will get attention.  Taking it steadily and working it out is always the best method.

After that, the 2-D backgrounds for the non-battle fields need to be more fully understood.

Then there is the over-world map/tree.

Particle effects and camera motion need to be hacked as well, as already mentioned.
Click to expand...
The background information on the PSX version is entertaining to say the least to find :)  If you resolve the world format for the PC version the PSX version is resolved as well. Which is a good thing no?
This is my checklist.  I believe we have everything else we need to have.

And I think it could be more efficient to have some working on the engine while others are hacking.
And some who do both.
Click to expand...
It might be but getting some coordination between the two might be challenging.  I know my 3d OGL usage isn't as swift as I would like.  I think however it's more an issue of knowing how to read the data properly than anything else.

Cyb
 
There are many times I knew anything useful about coding and such.

Wish I could contribute.  :\

Also,
After that, the 2-D backgrounds for the non-battle fields need to be more fully understood.
Click to expand...
What needs to be understood, if I may ask?  There's already a program out that seems to be flawlessly interpreting the Pre-rendered backgrounds for the PSX version already (ff7mimic), including the various triggered animations (Doors open/close, smoke, lights, etc)
 
A google for this lead me to a frech webboard with an expired article. Where, pray tell, is this?
 
There are many times I knew anything useful about coding and such.

Wish I could contribute.  :\

Also,
After that, the 2-D backgrounds for the non-battle fields need to be more fully understood.
Click to expand...
What needs to be understood, if I may ask?  There's already a program out that seems to be flawlessly interpreting the Pre-rendered backgrounds for the PSX version already (ff7mimic), including the various triggered animations (Doors open/close, smoke, lights, etc)
Click to expand...
One thing that's always been bothering me is that in the PC version, our current understanding of the backgrounds leave little black dots in the output. I don't know if this phenomenon showed up with the PSX files as well during 7mimic's development, maybe the author could shed some light on that.

halkun: 7mimic can be found here. He made a similar program for FF8 (PSX), I think.

What's the current status of the various field file sections, anyway? I've got the first section covered (although not yet executable), and the background and walkmesh are reasonably understood. What about the other sections? Has any progress been made on the "unknown" ones (according to Gears' list)?

Also, one tiny bit of trouble for making the engine portable: how are we going to handle the movies? Write our own decoder?
 
For christmas I got a new RAID card. I figured i would use it as an extra IDE controller and plugged up a new hard drive....

Sadly, it would seem when I was writing to my MP3 drive, the contents were also being written to my root drive and, shortly after, Naru went into a flaming taildive and smashed.

Oops! (^_^);

Anywho, I have a muchly updated server now, (However my suck bandwith is still a constent) I've been forced to rebuild my home directory from a backup so everything is there, but not in the correct place. I did move gears to my home's WWW space and you can grab it here, but I haven't found a definitive place for it yet....

http://the-afterm.ath.cx/~halkun/

As far as writing our own encoders, we do have the source code for reading PSX movies. (Though you have to read the data by raw sectors as it's a mode 2 disk). I can play the PC movies in linux via Mplayer, (Abet upside down and backwards)

Keep in mind that on Linux, the CD-ROM driver will have to support mode 2. Many linux CD-ROM drivers can't mount those disks correctly, like DVD drivers and CD-R drivers. Mode 2 is only used for PSX games, CD+G disks, and PhotoCDs so there really isn't much support for them. The good thing is adding support is very trivial as all you need to do is tell the drive in kernel-space to read more bytes per sector. The bad thing is you have to patch the kernel to do it.

I'm emailing the 7mimic guy for some colloberation.

**-- EDIT--**

Either way, an installer will probably be the best method to deal with the game.
 
One thing that's always been bothering me is that in the PC version, our current understanding of the backgrounds leave little black dots in the output. I don't know if this phenomenon showed up with the PSX files as well during 7mimic's development, maybe the author could shed some light on that.
Click to expand...

Out of curiousity, have you been able to make the backgrounds animate as well, or just display in a default form (as Fice's LGPtools and Cetra display them)?  If not, might those dots be a side effect of the animation coding being wrongly interpreted as graphics information, or something like that?
 
Movies why would you need to worry about them? FF7 uses direct show which handles all that doesn't it? Providing the person has the needed decoder depending on what the movie was encoded in it'll be fine.

It's just like embedding a media player component or equivalent into your project and using it to play midi/wav/mp3/avi etc as long as the correct decoder for the file is installed no problem.
 
Chesso, their goal here is portability to Linux. I think that should answer your question.


ShinRa Inc, the backgrounds we have animate (optionally).
The block dots and even the disarrayed pixels are still a problem.
The current decoding process for us leaves the black dots and occasionally blurring of pixels half-way across the image. Highly distorted images indeed, on occasion.
This is shown in the most recent version of LGP Tools.


It is a good idea to get some information from that guy. He may even know more about the other sectors of those files.
halkun stated once that shop prices and general shop information are not yet hacked. Surely that is in those files.

It would be great if he can shed the light here; I would really like to make more progress on my own project, which has been collecting dust for 3 months now.
I would be very excited to get those 2-D images running in my engine because I could then proceed with the walk-meshes and get online interaction going.


I still work on the battle animation format sometimes but I make no ground.


L. Spiro
 
As far as writing our own encoders, we do have the source code for reading PSX movies. (Though you have to read the data by raw sectors as it's a mode 2 disk). I can play the PC movies in linux via Mplayer, (Abet upside down and backwards)
Click to expand...
Well yes reading the PSX movies and decoding them works... for PSX. :) I was more concerned with the PC movies, which as it looks does not have an easy solution (hey, the porters couldn't even make them run upside-up on a single computer platform). I'm not sure how Mplayer works but I'd assume it somehow uses win codecs (or is Truemotion a standard format now?)... in which case we're left with some ugly code for linux. Windows gets by nicely with DirectShow, but I don't know a similar standard system for linux platforms.

Either way, an installer will probably be the best method to deal with the game.
Click to expand...
Well... once we have something that can actually be made to run on anything but one specific linux configuration ;) Nightmare scenario: "download installer: Updated FF7 engine v1.00 for halkun's computer" :P

Anyway after a weekend of research I can probably reconstruct much of the movie handling system for the Windows platform, in theory. The upside is that it's not that complicated, the downside is that it's because it relies so much on DirectShow. I don't even know where to begin to make efficient movie playback within OpenGL.

ahhh sorry i don't know much about Linux at all.
Click to expand...
We can tell.
 
Well, for that movie decoding problem there is possibly a solution...
Remember someone called phaeron on this board? He helped us hacking the animations (IIRC), and he's the author of VirtualDub - a famous video editing software. Maybe he's got some solutions for us (?)

 - Alhexx
 
As far as writing our own encoders, we do have the source code for reading PSX movies. (Though you have to read the data by raw sectors as it's a mode 2 disk). I can play the PC movies in linux via Mplayer, (Abet upside down and backwards)
Click to expand...
You could include a utility that dumps the mode2 sectors into a file once. I've got such a utility for MacOS, if anyone knows how to read mode2 sectors on Linux or Windows it would be trivial to convert.
The position of each movie is given in the iso 9660 filesystem, so all my utility does is scan the directories for the movie extensions, get start and size, and dump the sectors into a file with the same extension on PC.
This still doesn't help decoding them, the latest version of ffmpeg doesn't seem to support the ff7-specific format, even though it contains code for both raw and compressed mdec data.
 
Well, for that movie decoding problem there is possibly a solution...
Remember someone called phaeron on this board? He helped us hacking the animations (IIRC), and he's the author of VirtualDub - a famous video editing software. Maybe he's got some solutions for us (?)

 - Alhexx
Click to expand...
If you have the codec for it your fine with Vdub. Are you considering reencoding the movies?  If that's the case you might consider heading to virtual dubs forums :)

The position of each movie is given in the iso 9660 filesystem, so all my utility does is scan the directories for the movie extensions, get start and size, and dump the sectors into a file with the same extension on PC.
This still doesn't help decoding them, the latest version of ffmpeg doesn't seem to support the ff7-specific format, even though it contains code for both raw and compressed mdec data.
Click to expand...

You need to know the matrix information for decoding the FMV's SONY made.  The format of the sectors is rather complicated as well.  Essentially it's different.  The audio and video are interleaved as well.  Perhaps you can use the information from PCSX to decode the data in real time from an image made from the original media for Linux?

Cyb
 
Status
Not open for further replies.
Back
Top