Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: halkun on 2005-01-13 22:51:25
-
First, lets get everyone up to speed. This was ripped from another thread I started...
There have been lotsa engines that have been rebuilt and updated for newer computers.
xu4 (http://xu4.sourceforge.net/) for Ultima 4, Exult (http://exult.sourceforge.net/) for Ultima 7, Sarian (http://sarien.sourceforge.net/) for Sierra AGI games, FreeSCI (http://freesci.linuxgames.com/) for Sierra SCI games, ScummVM (http://www.scummvm.org/) for Lucasarts games.
I really don't see any reason why a new FF7 engine can't be written. Of course, you would have to start small. I mean, loading and parseing "STARTMAP" can be a start. It's not like it's expected to play the movies and do video overlays right out of the gammit.
I mean, we can load the little SD entities, and animate them. We can load the backgrounds, we can sort of load the walkmesh and sort of set the camera angle. Qhimm's workingon the field script, I'll plug along at the rounding out the data. It's really trvial to alter FF7 in a PSX emulator once you know where the data is.
All these engines have a lot in common, and, dare I say might even be a precursor, to the FF7 engine.
To build an engine like FF7, you need to start small. Basic libaries need to be created. Basic memory management needs to be done. We can cover the basics. I would be happy with a program that just loaded "STARTMAP" or some arbitrty field file for now.
Truefully, I would be happy with a program that just loaded Kernel.bin, created a savemap, and incremented the system clock every second.
So who would like help with some idea tossing. I'm not expeting you guys to drop everything and start coding on my behalf.
I come from a Linux background, so cross-platfrom would be nice. Also, the PSX version of the game is much more previlent than the PC version, but both media should be able to be used. (PC's menu system with PSX's movies ^_^) Also, we should support an "uncompressed" data tree
Should we set up a sourceforge account? Can you guys use CVS? Should we set up a mailing list?
You guys know right now I suck at programming, but I can give it a good shot. I can at least build Linux makefiles and maintain linux code. Most of the beginning stuff will be console apps anyway.
Let's toss out some ideas.
-
im all for modeling for you guys should the need arise...
theres no point having a nice shiney new engine with no graphical enhancements to show it right?
*ducks*
-
Well, first of all we should clearly state which language to use (C++ would be good since it's easier to "port" the information we got from the original FF7). CVS is a good idea, although since the people here are spread out and, dare I say it, rarely communitate, we should clearly define who does what. This brings the added benefit of a high degree of modularization, since each person needs to write code that integrates well with someone else's (details of which currently unknown).
I agree on the cross-platform, which basically means ANSI-only C++. I have a nasty habit of exploting MS-specific compiler extensions, but I'm keeping the field script module "pure". :P Oh yes, makefiles. Hrm well I'm building my code with the MS compiler, but if the code is standard I guess it should be easy enough to write a few makefiles for it later.
Though I'm still a bit unsure about the legalities of the whole thing (especially since anything FF7-related might draw extra attention now with AC, BC, CC and DC around). These things have been done before I see, but were they legal or just ignored? Since setting up on sourceforge would mean a relatively public display, I think this is a relevant issue.
Well anyway, an update on the field script module: Since many commands directly utilize various other aspects of the engine, a lot of stuff is being replaced by simple stubs for now. I should soon have a prototype ready that will parse the scripts OK though, even if it won't execute the game-specific commands.
For structure's sake, I'm proposing heavily using namespaces within our code. We should start from halkun's basic modularization of the engine (field, menu, battle, etc), and create a more specific structure tree. This will also help us distribute the work. For example, my script module might reside in the namespace Field::Script, but access the save map in the namespace Global. Suggestions on this?
-
im all for modeling for you guys should the need arise...
theres no point having a nice shiney new engine with no graphical enhancements to show it right?
*ducks*
The problem is, it needs to be a seperate download, unrelated to this, for legal reasons. If we were to do new graphics, and a new engine, people could download the movies, and not even NEED the FF7 discs. (This would break copyrights and stuff.)
You can be responsible for new models... They're gonna do a new engine. But the less you need the FF7 game discs, the less legal it is.
I support the new engine concept, and I look forwards to it, despite the lack of a graphical upgrade, in terms of models and such.
-
hmm well if you guys find a way to legally build a new engine, ill find a way to release a small fan built model pack >_>
-
I think we are putting the cart a little before the horse...
I want to use Sierra's AGI interpriter as a source of answers to engine questions.
AGI was reversed by looking at the machine code that made it up. It's new engine Sarien, is just a winner of a program, with new extentions, (such as 256 colors and mouse support, 320x480 mode) It's a really neat toy and with AGIStudio, people make make new content for it all the time. Sarien even comes with it's own fan-made game.
There is even a GBA port...
Sarien is not owned by Sierra, either is the custom content. However Sarien can play and dissasemble the old Sierra AGI games.
Anyway Graphics and other 3d stuffs can wait. Engines are actually borning little things that are worthless without content. I'm not really intrested in anyone "making 3d models" or new menus or fonts right now becuase I have Square's, thank you very much. I'm much more intrested in getting a new engine to load the FF7 models than some abstract fan model right now.
Actually, I'm more intrested in loading kernel.bin right now. I am absolutely stoked to see how I can use zlib to access the file, and allocate little memory spaces for each of the data sets! Wow! I'm sitting here, in almost a state of deamfull bliss, imagining the routine for allocateing memory for the savemap! And look out! I might even uncompress section 3 into it and have the bare bones of something the field script could access in about a year when it's written. ^_^
Making new content is step number 743, I'm on step 1, deciding if C++ is a good programing language to use, (It is), if CVS is a good idea, (It is, but not until I snake Qhimm's code and place it in my own privite repository, and contine to post diffs until everyone else gets the idea that I'm not going to be downloading zipped incremental chanages to a source tree.) I'm also wondering if zlib supports gzip formatted data within a file.
Using .dlls (which in Linux speak is an .so file) is not a very good idea right now. Not only do .dlls and .so files link differently, and I understand you are looking ahead for future module management, we won't writing this for a 2 meg computer with no MMU. The point is to *update* the engine to new systems while keeping it compatible with old data. Keep in mind, I would also like it to accept "raw" uncompressed data too, but that's step number #345.
Anyways, square was able to make the FF7.exe program about 4 megs with lotsa cruft inside. That's not that big on the grand scheme of things.
I'm going to be making a DIA map of the dumped source filenames using UML and guessing what classes might of been inside. I'm sure that could be a cool roadmap to go by.
It should already be legal to build a new engine, it will be ours!
-
I'm much more intrested in getting a new engine to load the FF7 models than some abstract fan model right now.
Agreed.
-
Ow! great! I just started working with ff7 raw data, because I found this place not so many time ago. But already wanted to remake FFIIV engine. So this is just in time. You can count on me.
And CVS would be great!
*sorry. My English is really baaad*
-
although i agree with you for the most part... please dont call my models abstract >_>
in the end were both interested in the same thing, just from different angles. to make the game better. now, i know im not the best in my field, but i also know im better than the current standard for the FF7 in game graphics, both texture, and model wise.
while as a graphic designer ive always wanted to see this game shine through, you, as a coder/programmer have always been more interested in the inner workings.
so we both really want the same thing.
-
Uh I wont be able to directly contribute with writing the code, because I have a few projects on my hands, and I dont have enough free time even to work on them. But I could contribute with code that i've already written ... its all about 3d models and textures. Mostly written in portable and insertable way.
Using CVS or any other versioning system is cool idea, but be sure that everyone can use it, even dialup-users.
-
I did have a shot of writing my own engine for FF7 for the Remake project (http://www.ficedula.co.uk/remake/), after all, but with far less of the field format decoded it was obviously of limited use. Although if I had time it'd be interesting to update it based on what's now known about the field files.
That said, if any new development is in C++ and CVS it counts me out.
-
ANSI C++ - that's good
Well I've told people many times in game programing forums that your basic game needs to be thought out before you make it look cool.
Halkun - your perspective of DLL's I think is rather limited. You can use DLL's with Linux and or Windows quite fluidly. The difference is in the interface usage but that is something you can abstract with a standard interface for both OS's I don't see it as a difficult or added bit of work. Using DLL's you should realize has absolutely NOTHING TO DO WITH MEMORY. It's called divide and conquer. I am very adverse of piling the whole thing together in a code hodge podge. Especially with so many diverse hands potentially in the pot. I suppose for the initial developement cycle it will be fine however. Perhaps < 0.XXX.XXX.XXXXX will be pre developement. Then after there is enough understand 1.XXX.XXX.XXXXX can be defined developement. I can guess the initial code will have to be a potpori of mods. Doesn't mean I like it :)
I think the first order of business would be to define the interface, what section does what. The FIELD module is loaded by the kernel right? What files are used by the kernel? I think kernel.bin might be a good start point for looking at how the system boots.
Obviously creating custom substitute content might be something desireable in the future. That will require a database and method of handling alternate loading methods for enhanced models. This means it will have to wait tell the existing system is defined. I suppose things can be made with the idea in mind it would be added later.
CVS is fine. I'll have to brush up on it's use. I believe there are better tools these days for managing such projects. My biggest issue with not using DLL's is too many fingers in the pie syndrom. This is why DLL's save your bacon. It creates multiple CVS tree's instead of one big mosh pit. I hate the mosh pit problems :)
CVS - fine
Title we can call it FF-Engine. with no definition of what F and F stands for. It doesn't use any trademarkable names. As for a description of the project. I would say 'engine to run original Final Fantasy content for 7.' Sufficiently vague that people won't be anoying and it's obfuscated enough that scan searchers won't find them and play 'alert the legal department'. Remember this is not a remake it's an engine to run there content. There is a BIG BIG difference.
Title - Make one that divorces itself from trademarked names and lawyers
Suggestion: FF-Engine
Description state what it is only nothing more. Engine for running FF content. No Final -- Fantasy etc in there. No 'We want to run FF7 with this engine and add custom content'. Bare bones. Those working on it will know what it's about. If someone joins because they understand what it is (and are bright enough to realize what it ISN'T), good. :)
Suggestion: Engine for running FF content.
As for Halkun's excitment hehehe that's fine if you enjoy that stuff. Sadly I think I would like the thing to just get to the point of the game start, no actual graphics given. So I suppose we are pretty much agreed on get the basics of the 'kernel' working before one worries of 'how do we draw that line!'
Cyb
-
That said, if any new development is in C++ and CVS it counts me out.
You know, I was thinking about this at work....
I admit, I once upon a time used pascal to teach myself programming, and as you use delphi, you are the odd one out.
Actually I am too.
You see, after three days of fighting with C++, I'm just having a bear of a time with it. It's not that I don't understand the tools, but I just can't figure out *when* to use them. Not only this, I'm getting really frustrated with having to follow the "rules" of C++. Especally when it breaks how I'm used to coding. You see "class", I see "struct with a function in it". You see "inheritence", I see "obscuring". You see "new", and I see "Fancy malloc()" It just seems redundent for things I know how to do to get things working.
Let me get some things off my chest... I know I'm gonna seem like I'm flip-plopping and it's natural to have an idea and quickly abandon it. The sad thing is I see everyone agree with me, and then I'm forced say "Oops, I'm sorry, I changed my mind"
I'm not really keen on any type of plugin system. I know there is a lot of "thinking ahead". (Can't we exted the engine to also handle FF8? What about PE?) This is something ScummVM does, but also doesn't use a plugin system. Square doen't use a plugin system either, they simply grab code from thier repository and reuse it. I'm sure there are bunches of FF6 code in FF7. I'm sure there is bunches of FF7 code in PE. (It's direct decendant, not FF8), but I'm leary of the complexity and am not confortable with it. I *bearly* know how to generate an .so file. (read: I've seen the insructions before) I'm not intrested in trying to catch a moving target right now. I do enough of that in WINE ^_^
Here's another issue. When I started drawing out my UML template in DIA based on the source filename dump from ff7.exe. I coudn't help but to feel that I was, in effect, ripping off thier system. I placed myself in the shoes of a Square employee who came across this infomation and showed it to his boss. I'm pretty sure if he saw the source filename dump, all kinds of bells and whistles would go off. I'm also sure an audit will get shot to edios to see who leaked thier code. (This is why I have a *ONE LINE* command in gears at the top showing it's tivial to gain the same information.)
Creating something so close I feel is a little warm for me. Heck, SCO is calling infringement on 5 lines of preprosser code.
I feel more comfortable doing it in a different language, and one that fits me like a warm glove that I haven't worn in a while. I'm also confident that my very unique module management will show it's a reimplemtation, and not a ripoff.
Here's what I'm going to do....
This weekend I'm pulling Naru (my server) offline for a much needed hardware/software uograde. I'll be diverting my webserver to, of all things, an old win98 box running apachie. (I found this on a hard drive I had lying around. ^_^)
After that I'm going to code up a really basic framework in the form of a console app. However, it will be in C, the way I feel confortable coding in. I'm just getting way too frustrated with C++ I have my own very unique way of coding and handeling modules. Even though it's C, I have methods to write manageable modules and orginazed code.. I'll post what I have and you all can gasp at it, point, roll your eyes, what have you.
It's gonna have a Unix-type makefile and depend on zlib (http://www.gzip.org/zlib/). It should compile on win32 using Cygwin (http://www.cygwin.com/)
We can have a code battle. The worst things that's going to happen is we learn something, even if it goes nowhere.
Anyways, I want to see somone say "Hal, that is the most insane looking code I've ever seen."
And I will smile quietly to myself...
^_^
### EDIT ###
Goddangit, I *REFUSE* to have C++ kick my ass! I'm gonna learn this language even if it kills me.
I bought a new C++ book, this one is ISO Standard compliant. It also has some other goodies.
-Design patterns
-Standard Template Library
-Whole chapter dedictaed to namespaces
--OO analyisis and using UML for proper code devolopment
This was not in my last book. The other on was written like "C and a bunch of new junk". This starts me out right I think.. Don't mind me, I'm just going crazy... ^_^
-
Ummm Halkun C is easy stuff. I learned in this order.
BASIC which I dumped for asembly and BASIC
then assembly then OS9 and assembly then BASIC09 then pascal then C then several languages then finally C++. I knew small talk before I used C++ in fact I used prolog before I used C++. So I had a lot of monkeying around done already.
You can use DLL's in C just nicely too ;)
I think you are just hung up on the mechanics Halkun once you understand the mechanics iit becomes more like "DUH why the hecked didn't I do it this way to begin with' type thing.
Delphi I can do it's just not overly portable to Linux :)
DLL's can work in Delphi and Delphi DLL's can work in C or C++. I think you are stuck with the fact its a DLL and it looks 'complicated'. It's not actually. You don't even need to use a SO notation on Linux DLL's just do some browsing and thinking.
Thinking will get you further along.
Now as for the original language I believe Square used C and Asembly with the PSYQ developement dohuckey. :)
I suggest Halkun you are killing brain cells unnecessarily on the C++ spectrum. Essentially C++ is an extension of C. Work from that point and things will make more sense. Deal with each aspect of OOP as you think abou tit. That's how I learned it. Took a while but it's like second nature now.
Cyb
-
Square used C++, look at Gears, I have a partial source code file name listing of the original code in the back. I always wanted to write a shell script to recreate the original source tree on linux with the "touch" command, but you can't touch a file in a subdirectory without making the subdirectory first.
This new book is cool. It's a revsion of the same book I was reading before, but all the WTF parts are now explained properly. That and the example code is all fixed. There are also, "Oh for you C coders...." that explains methods behind the madness of polymorphism and other C++ intrensics. They show example code in C and then in C++ to acheive the same thing. I can see why they put functions in stucts now.
dog.times_to_bark==5;
dog.bark();
or mre usefully,
file.type=="bin";
file.open(filename);
I'm getting it.
EDIT
Is it me, or when my book says that C++ is "strongly typed" I see a programmer slamming the keys when he's coding?
-
Well this topic just exploded while I was in the hospital.
A lot for me to cover, so I will miss a lot.
Okay, firstly, we might all know some about my project and if we don’t, well let’s not go into too much detail about its intent.
I can, however, go into full detail about its current capabilities, since they all fall within the “Model Viewer†category for now.
Firstly, I should mention that my project has been in the works for over 2 or 3 years now and when I started it I wasn’t solid at programming, and was looking for a fun way into DirectX®.
But because of my lack of experience when I started the project I did not modularize everything, or create .dll’s for any specific part of my engine.
In other words, most of it is written to work only within itself. Some things depend on other things, which are somewhat hard coded (though very rarely).
The things my engine can do:
Load .tex files and convert them into .bmp files for use with DirectX® (modular).
Load all 3-D model files, attaching colors and textures to them correctly (modular).
Load hierarchy files. Both on over world models and battle models (mostly modular).
Load over world animation files.
Load the first frame of most battle animation files.
Load Kernel.bin and/or Kernel2.bin, minus the save information because my engine will not use it (modular).
This information includes all weapon, armor, item, attack, command, accessory, Materia, and character names, data, and descriptions.
Load battle scenes.
This includes the battle world (3-D entities) and placing enemies in the correct positions on the scene (but not always the correct direction).
Enemy information both per enemy type and per enemy instance is loaded during the loading of a battle scene.
80% functional menu system. Buttons, images, bars, icons, text, etc., are done. But new controls and unique controls are not. These include sliding bar controls and text-input boxes.
Unpack LZS and GZ files as well as extract files from LGP archives.
However, my engine does not:
Show transparency in 3-D models (yet).
Load the 2-D field files.
Load the over world 3-D map tree.
Animate battle models.
Load any walk meshes.
Run battles or provide any engine for proceeding through the course of a battle, imaginary or real-time.
I already have C++ with DirectX® code for loading the 3-D model files, and ALL of my code is 100% stable with one exception: the maximum path length for Windows® is 260 characters, which means if you copy my executable into a folder tree with over 250 characters, it will not be able to create some of the files it needs to run. Okay, so that is a stupid problem which is easy to fix but other than that, it’s stable and runs with 0 memory leaks.
I often leave it on as a screensaver over night. During that time it will load a new map scene (3-D battle world, all monsters in the fight, all data for the monsters, etc.) about 1,560 times. Checks reveal no memory losses or crashes.
So, although the early code is a little sloppy, it is stable.
However, I do not use the same menu system as in the original.
I have made my own menu engine and my menus are reconstructed that way. This is for speed and size. My menus are extremely faster than theirs and at extremely high resolutions.
In their menus, for example, the text redrawn to the screen each frame.
In my menus, the menu is drawn once and saved as an image. Then the image is drawn. The downside to this is that some menus are huge and some video cards do not support that size of bitmaps.
So now to the point.
I’ve already got a lot done on an engine remake, although mine is not geared in the same direction as the one proposed here.
However, mine is geared similarly enough that it can be of use to this project as well, should everyone get organized and decide on a language and specifications.
I know that OpenGL® is favored here and my code is DirectX® (for compatibility), but the rest of my code, in C++, should be useable directly.
I imagine that my coding to load the 3-D models and texture files will work after a simple copy/paste and change from DirectX® to OpenGL®.
I can help in many ways, but I am afraid I can do no direct coding on the project, or little to say the most.
I am overrun by my job and my projects, and I am still working on the battle animation file format, all while searching for a female companion and sitting alone in dark loud pubs while my Japanese friends dance and hang out with rich kids who don’t know how to drive.
At the same time, I would like to ask for your assistance when your engine does something mine does not.
L. Spiro
P. S.: halkun, err, I can show you how to use zlib with this project if you would like. My engine uses those libraries already to get everything out of BATTLE.BIN and Kernel.bin.
And, as for Almighty_gir, well, in another topic I have mentioned that I would be willing to give my project to SquareEnix Co., Ltd., just to ensure that it sees the light of day, however, under the condition that they keep the original’s graphics throughout all of it.
The problem I have is with companies thinking every detail about games is in graphics, causing them to forget the game play. Well, that isn’t quite the case here, since we already know Final Fantasy® VII has game play, and we aren’t talking only about graphics.
However, Final Fantasy® VII, in any form, in any future release, MUST have the same graphics it has now in order to be worth mentioning at all.
These are the graphics people loved.
These are the graphics people remembered.
The corny square-armed creatures with tiny elbows are exactly what gave the game its graphic appeal, and now it is more about nostalgia than anything else.
If the graphics are changed, just forget the project. Consider it a flop before you even bother to release it.
Well, that’s where my project stands anyway.
You guys can do as you like with yours.
-
Wow, I'm impressed.
Sadly, I don't think square will ever accept your engine, even if it was 100 polished with all the bells and whistles, simply for legal reasons alone.
Most of the companies I know either see such a project as benign (Sierra AGI) or with a degree of legal trepidation. (With ScummVM, LucasArts kept saying "We like it, but we have Lawyers" when the project hit critical mass. This caused new versions to be delayed with things were "negotialted", in the end ScummVM started releasing updated versions to the silence to LucasArts.) Many original creaters have come forth and said "good job" to all these engines, but have long been stripped of power to do anything. I have seen more than my share of programmers say "I wish I could give you the rights to the game, but I don't own them, XXXMegacorp does when my company was bought by them."
--- WILL POST MORE WHEN I GET TO WORK --- ^_^
I took a little look at how C++ does files (I skipped to chaper 19) and I'm not very happy with it. I'll have to burn that bridge when I get to it. I brought my laptop into work so I can work on C++ programming. I'm going to take it day-by-day for a month to get everything down.
Did you use streams to open kernel.bin? In that case at my current level, I won't know what it does. I'm figureing out what constructers and destruters are right now. (Heck, I'm not even in pointers yet, and really stron math based systems like recursion I don't understand as I'm innumerate.
Why don't you create a savemap? Is it that online thingy you are trying to make?
Here's omething you should read written by a guy who was in chagre of the "Utima Online" launch and the "Sims Online" launch.
http://archive.gamespy.com/gdc2003/top10mmog/
I would like to see the code on how you loaded kernel/2.bin
-
I don’t think they will either, which is why I stay low.
As for how C++ does files, well-
There are several libraries available that handle files, and most likely your books goes through <iostream.h>.
Of course you would be looking at cout and cin (oh God how terrible) in that case.
Some people prefer streaming with stdio.h’s file streams.
FILE * fIn = fopen( "C:\\Kernel.bin", "rb" );
for ( int I = 0; I < iTotal; I++ ) {
fread( &iChunkSize, 4, 1, fIn );
}
fclose( fIn );
I prefer using Windows® own CreateFile() and ReadFile(); they are lower level and thread-safe.
I had a major threading problem with my project when I gave maps the ability to load on seperate threads in the background caused by fread(). I converted my entire project to use CreateFile()/ReadFile().
So, the answer would be that I do not use streams to load the file.
Yes, it is the online project.
Kernel.bin:
First I read into the file to get the starting offset and size of the chunk (section) I want to get.
Then I call a function with those parameters to take that area of the file and save it to hard disk as a seperate file.
On the new file, I use the GZip library to read the bytes as a decompressed stream.
This stream works in exactly the same way as fread (as mentioned above) except that it is “gzread( gzFile, byte *, int )â€.
The way the GZip library works-
You never have to call anything to decompress the files.
Once you open the file, it is fed into a memory stream as a decompressed data automatically, from which you read the bytes you need without worrying about whether or not they are decompressed.
I can supply hairy coding to this but it relies on a lot of other areas of my project, which may in turn rely on others.
If you want it, I can send it somewhere.
L. Spiro
-
That's fine, I can use fopen(). It's nice you can mix C and C++ sometimes.
Can you do me a favor, it's a request, not a demand, but could you please drop the "®" at the end of trademarked names? It makes your posts a little painful to read. I think that everyone on this board can nod thier head and agree that "all trademarks are property of thier respective owners." This information is kind of a given. We all know that Final Fantasy is a registerd trademark of SquareEnix. One of the cool things about free speech is that you dont have to legally check yourself when simply talking.
-
Sure, sure, we don’t have to legally check ourselves when we talk regularly.
But when I regularly talk in person I say “Final Fantasy registered trademark Sevenâ€. You know it’s proper.
Actually you see I jest. Hahaha. It’s humor in the form of sarcasm.
Well, ever since my severe beatings as a child I have had to type as properly and punctually as possible. That’s why I spell-check everything before I post (except my last post, because I had to call a girl so I fell short on time) and use proper characters (for instance character 133 instead of “...â€).
I am not doing it to be annoying or because I feel I must legally guard my back.
I do it because it is proper. It’s part of the name of the game.
I’ve been banned from chat rooms for the same thing.
I’m not lazy. I don’t slack on my typing. Appearance, punctuality, and properness are important.
Anyway, I will try to avoid it on this forum but no guarantees.
It’s more than habit.
It actually hurts me to not type all names in their full and proper.
L. Spiro
-
Comment: It would definitely be handy if we had a more real-time way to communicate for this project to work. Particularly at this early stage we need discussion meetings, which in all honesty is a bit hard if you have to wait 24 hours for everyone to nod their head. Of course everyone can't attend the meetings (silly time zones), but at least some person-to-person discussion needs to take place (preferably logged for future reference). For example, I'd like to have a talk with halkun about the guidelines for the kernel and surrounding framework, as well as any source formatting / file naming rules, before any serious coding work is started (to prevent unnecessary work later). Now I've heard you have a Yahoo IM account, but never seen you online, so perhaps you can suggest a better means... ^^
-
I know there are buttons along each of my posts which will allow anyone access to my Yahoo! Messenger, MSN Messenger, and ICQ account names, but in case some do not want to hold the mouse over the button an jot down the little text at the bottom of the screen, I will post.
ICQ: 36242040, named “L. Spiroâ€. I do not use ICQ because it is nothing but fucking porn bots.
Yahoo! Messenger: shyamarakeensunderjayaramenen. On daily.
MSN Messenger: [email protected]. On daily.
IRC: irc.dynamix.com, #FF7. On daily.
Skype: L-Spiro. On daily.
My IRC server is very good. I am not the owner but it has good IRC services and I know the owner/operator. It is an official server operated through Vivendi for game purposes, but it is not overrun as are Enter The Game, EFnet, DALnet, etc., so it is very fast.
IRC of course is a way we can all be there as we are available and have a backbuffer to check on things we missed, as well as logging, and of course it is capable of group meetings.
It is definitely the best I have seen, and I have seen a lot.
If we want to set up there I can arrange a private locked room without problem. I know everyone on the server so if we ever need anything, well, we have 800 resources.
L. Spiro
-
All this talking about doing stuff made me actually break out my FF7 data again ;)
I don't know whether it would be of any use to any new project but for what it's worth, I recompiled the Remake engine and fixed a few display bugs in it, so get it while it's hot (http://ficedula.uwcs.co.uk/release21.rar).
In terms of what's done ... the menu system is essentially complete of course (and that includes equipment, materia, and items affecting your command list, stats, resistances and so on). The field system ... somewhat. The backend is all there - scrollable layered 2d backgrounds, 3d characters, collisions between models, and so on.
The bad news, such as it is, is naturally that it doesn't read scripts or walkmaps etc. out of the field files because they weren't decoded 3 years ago ;) That said, it reads the field backgrounds and the models from the original LGP's, so it's not entirely useless...just that a fair amount of information is written in the Remake engines own data formats (especially scripts, since for a remake, you wouldn't necessarily use the original ones anyway, so I never really looked at decoding them...)
If anyone wants to test it, download, unrar it, run the config to at a minimum set your FF7 data path, and then run it. The best thing to test would be to load game 3 from save slot 1 (Wall Market).
I do tend to use IRC myself more than other networks; I'm usually on irc.uwcs.co.uk / #anime, but I could join another network to talk about stuff, perhaps.
-
ficedula, I tried to make my engine load the overworld 2-D map files and so I went to your site, got your explaination of the file format, and started a quicky mIRC project to run through and see if I could load any of the 2-D field file images.
Well, no, I couldn’t, and I could’t follow your code either.
And I also know that your current version of LGP Tools is much further along than that document states.
I was wondering if you had any more recent or more full explanations of how to load the files.
L. Spiro
P. S.: I am testing the remake now but it will not work for me.
I open remake_config.exe to be greeted by the following message:
Access violation at address 004768F4 in module 'remake_config.exe'. Read of address 00000000.
After this, all of the text boxes are empty, devoid of all options, except a few, and I am not able to select any languages, so it will not allow me to save my changes.
-
Yeah, the document isn't fully up to date.
However, for the walkmap and camera, you want Kero's explanation (http://forums.qhimm.com/viewtopic.php?t=3247&highlight=walkmap) - I haven't really even tried his data yet.
Background wise, the description I posted is very nearly complete to what I know; all it's missing is that basically Sprite.Sfx != 0 indicates a transparent tile. I personally treat transparency as a third layer over the two normal background layers. There might be other meanings to Sfx, but so far, all I know is that treating the tile as transparent works pretty well (ie. looks good) ;)
-
Now that I killed Mozilla for firefox, all I can say is WOW it's SO much faster and better.
Now a lot of discussion here. Perhaps IRC is best for everyone? I need to get wine working on my box because my IRC client uses it.
Halkun - I'm pretty sure if they used C++ they didn't use many objects. Why do I say this? Or how could I say this? None of the bios level functions lend to C++ encapsulation. Sure the compilor might be C++ compatible but you can still use the entire C library of functions from within C++. More importantly because it's a limitied platform, the problem with C++ is it's not memory conservation freindly ESPECIALY when you hit inhieratance and overiding functions of prior defined objects.
As for using OOP for dog barking well I would do something like this
class doggie
{
private:
int MyBarkCount;
public:
doggie() { MyBarkCount = 0; }
void Bark(void) { MyBarkCount++;}// bark once
void Bark(int Count) { MyBarkCount+=Count; }
};
// usage
// Dog.Bark();
// Dog.Bark(5);
I've never heard of C++ as strongly typed. I've heard it as 'Strictly Typed' :)
As for files you can use <stdio.h> just fine. It depends on how fancy/portable you want to be. Using fstream has low overhead and works quite well for me. As matter of fact TV uses fstream. It might be advantageous to use streams instead of normal files. However that can be done later in a refinement phase. Since we are probably going to be going toward a Kernel based system the Kernal code hands file access and streaming for everything else. So this makes it a lot more generic.
L. Spiro - I started my data gathering for FF7 about 2 years ago. I guess I'm just slow. ;)
Your engine is based for the PC version of FF7 right? Windows based software I assume as well. There are a few things one will need to do to get toward a more generic system with such code. However I don't think it's too big of a deal. Having had to read other peoples source code and knowing a bit about what's going on makes a big difference. All of my work has been done on the PSX version although I do have the PC version of FF7 it's just not as stable or fun to play as the PSX version too me :D
As far as 'global meeting' thing. I can pop on IRC or I can use MSN mess I prefer Yahoo's IM myself. Let me know what you people want to attempt. I'm flexible if I know in advance. I'm quite time zone concious. Halkun I believe is in my TZ (GM-6) Qhimm L. Spiro GM+9 right? Most others are GM or GM+1?
Cyb
-
P. S.: I am testing the remake now but it will not work for me.
I open remake_config.exe to be greeted by the following message:
Access violation at address 004768F4 in module 'remake_config.exe'. Read of address 00000000.
After this, all of the text boxes are empty, devoid of all options, except a few, and I am not able to select any languages, so it will not allow me to save my changes.
I get the same thing but first I get another error saying:
Runtime Error 217 at 00013E20
Shame, it would've been pretty cool seeing a release of the remake. I didn't get that error at first either, just when I moved it into my Final Fantasy directory to see if fixed the original error...... just reinstalled the remake and I don't get that error........ wierd, still get:
"Access violation at address 004768F4 in module 'remake_config.exe'. Read of address 00000000."
though
-
Hmm. Interesting. Seems that error can be caused because the EXE's are compressed ... although it's a bit bizarre, I always compress my EXE's and it doesn't usually happen.
If you download UPX from http://upx.sourceforge.net/ then you can decompress the config tool with it ... or just edit the INI manually. Now I'll just have to work out why the config program doesn't like being compressed when nothing else cares... ;)
-
Well if we're going IRC there's already the #qhimm.com channel on irc.esper.net... I don't know what further things we could do with improved access to the server itself, it seems that all we want to do is discuss and log anyway? That having been said, I remember something from last time we were having this discussion that halkun were the one with the most trouble connecting to the various places, so I guess his voice will carry the most weight this time on the decision.
ficedula: That compression tool seems kinda cool, does it handle DLLs and exported functions transparently too?
-
Qhimm: Yep, it handles everything transparently, more or less. Of course, obviously something screwed up this time, but it's the first time I've seen that happen ... all the downloads on my site are compressed with UPX.
(We use it at work, too - the main application is 14MB(!) compiled, and ZIP/RAR can only get it down to 5MB - UPX compresses it to 3.5MB with the added bonus that of course, it can just be run without unzipping first...)
I'll drop into the espernet channel today and see who's around. You've all got my contact details otherwise...
-
Well, I'm lost in all those engines here... :o
However, if you're going to build up a programmer team - you can count on me, too. I've got my exams in 3 weeks, but after that I'll have a lot of free time - so much time for programming. I'll continue reading the following posts (but I think I won't post much...) and I'll try to keep myself up-to-date.
As for halkun's question:
Sourceforge: If we're going to make an open-source egine, then this will be the best solution, I think.
CVS: Yes.
Almighty_gir (respresenting for that "Creating own models" thingy):
We first should build a "naked" engine, which will need ALL of FF's game files to run, and will use just the original content.
But, I think it would be a nice idea, to let (when the engine reaches its first *final release*) the user decide (during installation or at the config menu) to use the original FF models or self-made (!) high-quality models.
As for the engine name: We should maybe think of a codename for the engine before thinking about its final name... maybe FinalFear or Jesse or whatever...
So, as I said in that other topic before:
Someone (maybe halkun) should make a little "diagram" of the engine framework, and which objects need to be created and what they have to do.
Once this is done, and we have a theoretical framework model for the engine, we can create a programmer team, and look who can program what, so (s)he can use his/her special skills.
Good luck. I hope this will be a successful project...
- Alhexx
- edit -
And I've got a question about the topic title?
Who will come???
-
Message
-
Whoa there, I'm still not convinced about the complete open source approach here... We need to be pretty sure what we're doing isn't legally offensive (new term I just invented meaning "will catch Square's evil eye") before we expose (i.e. globally distribute) source code largely based on reverse-engineering a copyrighted product. Are we that sure utilizing the original game data will prevent us from going the same way as Chrono Trigger: Resurrection? CT:R wasn't even built from the game data itself, and got shut down real quick once they got publicity. Are we planning to call this a mere "technical demonstration" or something, to keep us from ending up in the infringement pit?
-
Whoa there, I'm still not convinced about the complete open source approach here... We need to be pretty sure what we're doing isn't legally offensive (new term I just invented meaning "will catch Square's evil eye") before we expose (i.e. globally distribute) source code largely based on reverse-engineering a copyrighted product. Are we that sure utilizing the original game data will prevent us from going the same way as Chrono Trigger: Resurrection? CT:R wasn't even built from the game data itself, and got shut down real quick once they got publicity. Are we planning to call this a mere "technical demonstration" or something, to keep us from ending up in the infringement pit?
As far as I know we are only runing SE's original content on it. You'll have to specify where an infringment comes in? Heck instead of FFEngine we could name it SF-Engine. Some Fantasy Engine, just never mention Sqenixes trade marked names. As for what to call it, engine that runs original content for some popular games. Shrug. That's what it's for.
Open source is a bit dangerous, creating a team is not. I would consider keeping it closed and see if there are free CVS services that aren't open source only.
I don't mind open source, it's just that first there has to be something there that is carefully cleaned up to be open source. Prior to alpha this means mostly messy code :)
Cyb
-
By the way, if you're going to set up your own repository it may be worth evaluating Subversion (http://subversion.tigris.org). I used to use CVS at work and privately, but I changed to Subversion for private development.
-
My advice: Keep it quiet. CT:R was shut down extremely quickly once Square found out about it, and FF7 is - comparitively speaking - a much newer game than CT was, plus with Advent Children and the other spinoffs coming out, Square will likely be ever more anal about anyone using their intellectual property in whatever form.
So... keep it quiet and just beaver away at it in private :) And I'd be with Almighty_gir on this one, and offer to assist in a modelling capacity if/ when the time comes.
-
I like this discussion alot, and so I'll add my two cents in.
I really like the term "Naked Engine" as that discribes to a "t" what I'm looking for. Other concepts came up that I want to elaborate on.
One of the more misuderdstood aspects of Open Source isthat people use it to *respect* other ideas, not to steal them. (Much to the shagrin of what Microsoft and SCO might say otherwise). The fact of the matter is we do not wish to steal anything. However we come to the barrior that is "Intellectual Property" (IP)
Now I'm going to lay my personal opinions down on the whole subject, there is a point, but it's best I lay my cards down first.
I'm under the opinion that the concept of "owning thought" is Intellecually void. I personally think the words "Intellectual Property" was invented in order bend culture to give property rights to ideas. Property, I believe, are things you can possess. Like chairs, forks, land, a car, and the like. You can even possess thought.
The problem with possessing thought it you have to keep it in your brain. Once it comes out your mouth, (when it is expressed, if you will), you have pretty much gave it to someone else. Then comes the delmma. How can you say something was stolen when you were not devoid of that taken from you.
Trademarks, patents, and copyrights serve as a balance. They are also incredibly selfish. Don't worry though, it's a good thing in this case. Trademarks, (I named this), Copyrights, (I wrote this), and Patents(I built this.), ensure that the one who orignally came up with the idea doen't have to keep them in thier head. It's a layer of protection to make sure that the creator is the one properly reconized.
To go furthur I have to introduce a legal term, called a "Tort"
A "Tort" is a "Twisting" of the norm. (The word "Contort" comes from "tort") For example, I came up with an idea and expressed it. That is the norm. However, say I came up with an idea and someone overheard and expressed the same idea and said it was thiers. That's a "tort", or a twisting of "fairness" where I am harmed and the other has artifically gained.
Copyrights, patents, and trademarks protect against torts. There is a real reason for thier existance.
However, IP has been bent into something it's not, which is to say property. I understand what's yours is yours. Protected by copyright or what have you. But when I have recieved, for example, a game, and I decide to tinker with it, your idea is in my posession. I know it's your idea and I repect that you want to be the one who all fingers point to. However, I'm still going to rip the damn thing apart to see how it works.
Why? Not out of mallace, but out of awe. I get to see, just for a bit, what it must of been like to arcitecture something like that. You want us to see the cathedral, and I want to look into the walls and see the mice. That's just how I am. It's still yours, I know that. No tort has taken place. Especally when I do it all by myself in my little darkend cave.
The problem starts when expression starts to grow and it's not from the "original mind". This is where torts start to appear.
The 3D chono trigger was doomed at it outset. Why? Becuase, in the end, a question would be raised on who wrote it, who named it, and who expressed it. The 3D chono trigger fails many of these tests, reguardless of if they wanted money for their work or not.
Part 2, the Naked Engine
Square is not an engine maker, they are a game company.
On the same side of the coin, Honda isn't an engine maker, thay make cars.
Of course, both of these fail the logic test. They both *OF COURSE* make engines, and have to in order to make thier product. Square, however, is not reconized for thier engines, at least not on the same level as ID software is.
Engine building is an odd sort. It's mechanical with lots of pistons and cogs. They are rather unattractive, and it's not untill you place square's artwork into the mix does it become "Something square did"
Open source programmers tend to seperate "Art" from "Function" and tend to focus in "Function". It's intresting that when "Art" becomes involved, that's when you tend to see torts. It wasn't so much the engine in the 3D Chono Trigger that Square had a problem with....
It was expression of the art.
There is an art to engine building too. However, this art isn't visual, and if we use our own cogs and our own pistions would be *our* engine. A Naked engine, that when left in the wild, all by itself, would be useless.
C:\jessie.exe
JESSIE.EXE: No Media Found
You *NEED* Square's art, or make your own, but we arn't making a final fantasy were you get to revive Aries. That's why I oppose the idea of "hey, I can make new models for you.."
Models for what? For square's game? That's no better than making new content Ala the failed Chono Trigger experiment.
Now if you were to make your own end-to-end game set in space for example. I'm Sure square woudn't mind at all, reguardless of the engine.
You can't copyright *function*. You can patent it, and lucky for you guys in the EU, there is an explicit banning of software patents. Also, as far as I know, Square has no patents on thier engine in the U.S. Our expression of the engine is copyrighted, but fundementally differnt from Square's expression of it. The fuction is the same, but you can't copyright that.
Now I think I rambeled on enough. Keep in mind this is in no way legal advice, just on-the-table talk of how I see the world. Is this something I'm willing to go to court for (again?) well, I'll burn that bridge when I get to it.
What was I talking about again?
-Halkun
P.S. JESSIE == Jolly Enlightened Square Soft Interactive Engine. ^_^
-
I think you had a few twinkies there Halkun :)
Anyhow onto the subject, IP was developed by lawyers for companies that wish to expand the enforcement of there rights. These days the internet has made it easier for them to enforace there rights. However it's a two edged sword. the DMCA (which has many explitive laced varitatons) is not only anoying, it was invented by lawyers to give them something to do. The idea of IP quite LITERRALLY comes from trial lawyers and has diddly to do with what they are actually trying to enforce. It's an intimidation word. IP came into being circa 1999 in a patent dispute between two well known companies. Since it's coinage people like SCO have had expansivist ideas of 'protecting' things.
Software patents came about due to the US against called the NSA. RSA encryption gave them a problem so instead of fixing the problem the turned to the patent office to save there diffcient thinking. Now we all suffer from it world wide. Sad isn't it?
JESSIE sounds Ok. SFE Some Fantasy Engine sounds OK too. I suppose it could be also said a few other ways :)
Cyb
-
There is an art to engine building too. However, this art isn't visual, and if we use our own cogs and our own pistions would be *our* engine. A Naked engine, that when left in the wild, all by itself, would be useless.
Our enginge... which we made very much by cracking open the original one and copying its function (while it's not a direct copy of the code, which would frag us under copyright any day, it will at places be a direct copy of the low-level functionality like battle mechanics or field script). We're not reproducing a copyrighted book here, but we're writing our own book with almost the exact same plot. I've seen people get sued for less, although I might wager a cent or two that "art" you mentioned might again have something to do with it... not for the legality, but for the readiness to sue.
You can't copyright *function*. You can patent it, and lucky for you guys in the EU, there is an explicit banning of software patents. Also, as far as I know, Square has no patents on thier engine in the U.S. Our expression of the engine is copyrighted, but fundementally differnt from Square's expression of it. The fuction is the same, but you can't copyright that.
Which is all well and good, except that we also have 30,000 granted software patents here. The only reason the software companies don't go on infringement spree is that the patents probably wouldn't hold up in a court (since the patent office is really breaking current regulations by granting patents on software processes). This could change very soon though, because all those big companies are lobbying politicians to revise the law (http://swpat.ffii.org/), essentially explicitly allowing software patents and thus legitimizing all those patents already granted. There's already been some dirty doings in the politics of EU to try and sneak or push the new law proposal into effect, thus far fortunately they've been prevented though. Yeesh.
P.S. JESSIE == Jolly Enlightened Square Soft Interactive Engine. ^_^
Heh, stretching it a bit are we? ;) I actually started on a similar project quite long ago (basically FF7 + modern, non-crashing engine). I sort of abandoned it because I figured I'd never finish it on my own and wasn't sure what the legal status would be... *checks* and it was called "Tiphareth".
Ooh, ooh, let's get into a discussion on what the name should be, be unable to agree and have the entire project stall because of it! ^_^
EDIT: Just remembered another thing I wanted to toss into the discussion... what about the copy protection? By making a secondary engine to run the game, we have essentially circumvented the original copy protection scheme (even if we implement one in the new engine as well). Under the DMCA and other funny laws in various countries, this is quite a vulnerable spot for a project like this...
-
I’ve found that replacing critical words with “Something†works wonders.
Hence my project is “Something Something VII Onlineâ€.
L. Spiro
-
About legal things.
I think that what square cares most are money and square's image.
So in building custom engine we must think that this engine should be used only with oryginal, legal version of ff7. In ff7 there is only a cd check protection. So in my opinion our engine should have cd check protection that would check if oryginal cd is in the drive.
I would'nt call engine as an engine but i would call it a "FF7 FRONTEND GRAPHIC INTERFACE" becouse it is using oryginal ff7 data - animation , story , graphic and only displays it with different way (different resolutions, different codecs, sound plugins)
New 3d models should be an option as ad in module (in this case cd check is guaranting that user has got oryginal ff7 game and that Square earned money) models should be packed and protected so no one could extract them normaly and used in wrong way.
In creating new models we must think about Square's image. New models should be based on Squares concept art (can be found in net) or ff7 AC and should be of high quality. Of course models creators should state that they only created models and That Square has at least partialy rights to this models becouse of Squares ideas and concept arts.
While building this" engine" it is important to -
1 make sure that users have orygiinal ff7 so Square earned money
2 Make sure that story of ff7 is not altered in any way.
3 In creating graphic ensured that this graphic is of high quality ant that it has the spirit of FF7 and this way it is not altering Square's image as high quality games creators.
-
The graphics will not be altered at all, and “in the spirit of†will do nothing to ease their tempers.
Chrono Trigger: Resurrection had fine graphics in the spirit of the original.
Yet graphics were 80% of why it got shut down, with story being the remaining.
If you change the graphics at all, then the better you make them, the worse it makes your situation.
The more professional they look, the more “threat†your product poses to their property.
L. Spiro
P. S.: We have mentioned this many times.
It won’t be my project but they already stated, no new models.
No new art.
No new content.
You CAN’T create a legal product if you recreate their visuals.
This isn’t about remaking the game with flashy graphics.
This an engine that runs their existing content, possibly so far as to allow people to play through the game entirely on this engine, with the only additions being up-to-date code, higher resolutions, and faster framerates.
-
Look if graphic will not be altered then i see no point in creeating ff7 engine other that learning coding ( of course for people writing this engine)
I have geforce 4 and i can play ff7 with fsaa and only new engine will not make it better.
Any higher resolution or anything (without changing graphic, media content )will not make ff7 better. Why ? Becouse movies, backgrounds were created in shity 320x340 resolution and rising resolution even to 1280 x 1024 can't make it better.
And if you have problems with compatibility you can play ff7 on playstation or even on playstation emulator in 1280 x 1024 resolution.
I am sure that many ff7 fans will not be interested in engine without upgrading content at least i will not be interested. Since i have no programing skill so i will be not working on engine - i only wanted to share my opinion.
This legal things are insane . If you want to do something legaly then you can do nothing.
Square is to lazy to remake ff7, or it can see no profit in it.
And if you a ff7 fan you can't remake ff7 for free becouse it is illegal . That is the world
-
Look if graphic will not be altered then i see no point in creeating ff7 engine other that learning coding ( of course for people writing this engine)
I might point out is your sole interest in the engine is different than others. This is your perspective always keep in mind your perspective may not be shared by everyone.
I have geforce 4 and i can play ff7 with fsaa and only new engine will not make it better.
Mmmm better is highly subjective. I enjoy playing games that do not have cool graphics. Perhaps we aren't interested in cool graphics? I think the idea was running the content provided in a stable manner, with the way we want it to run. New models etc. are additions to the basic work done. I think you are putting De'Cart before De'Horse in this case. It's something you can worry about once the content can be even run.
Any higher resolution or anything (without changing graphic, media content )will not make ff7 better. Why ? Becouse movies, backgrounds were created in shity 320x340 resolution and rising resolution even to 1280 x 1024 can't make it better.
First off it's actually 320x214 to be precise. Secondly you appear to be only interested in changing game esthetics which are actually the LAST part of developement. Again you are interested in something way way way down the road in possibilities. I don't think you are interested in actually getting it to work. That is actually the BIG challenge.
And if you have problems with compatibility you can play ff7 on playstation or even on playstation emulator in 1280 x 1024 resolution.
Whiich I do all the time. What has this to do with the original idea? It's not to play the game it's to be able to even run the game to begin with. I think you are disolusioned about the purpose, most are intersted in learning how the engine works to begin with. I love the game but the engine is pretty facinating too. :)
I am sure that many ff7 fans will not be interested in engine without upgrading content at least i will not be interested. Since i have no programing skill so i will be not working on engine - i only wanted to share my opinion.
You are entitled to it, but I think you have recast Halkun's idea into what you want. I'm sure other people want it, but to be honest it's probably not what the people working on it would want. Does that make sense to you? It has nothing to do with 'popularity', to be honest most people could care less about the project in the general population.
This legal things are insane . If you want to do something legaly then you can do nothing.
Square is to lazy to remake ff7, or it can see no profit in it.
And if you a ff7 fan you can't remake ff7 for free becouse it is illegal . That is the world
It's always best to take yourself off there hit list first. Then you can work and acomplish something. You can't finish what you never start, and you can't start tell you have a plan. So this is called PLANING. Sometimes things aren't practical. Anything is possible just not practical. Everyone has other projects and things they do to make a living as well.
Cyb
-
You'd be better off decompiling it and updating it to take advantage of newer hardware etc that would be awsome i think. Course i know pulling that off succesfully wouldnt be easy.........
-
I might point out is your sole interest in the engine is different than others. This is your perspective always keep in mind your perspective may not be shared by everyone.
I never said that may point of view is shared by anyone . It is only MY point of view
Mmmm better is highly subjective. I enjoy playing games that do not have cool graphics. Perhaps we aren't interested in cool graphics? I think the idea was running the content provided in a stable manner, with the way we want it to run. New models etc. are additions to the basic work done. I think you are putting De'Cart before De'Horse in this case. It's something you can worry about once the content can be even run.
I like games with outdated graphic if content is right, but Square made terrible work with ff7 and ff8 transfering it to pc almost exactly like they were on psx. In ff7 models have 1000-3000 polygons without almost no textures (there are few exceptions).
In ff8 models are only 1000 poly with textures. Becouse of texture use and other things models have generaly less polygons then in ff7 and are blocky.Backgrounds in low resolutions. Only ff8 movies are good.
Square does not care about pc. Terrible ff7 translation into english.
Square should make ff7 and ff8 for pc first and then convert it to psx. Of course in Japan psx is more popular.
Square cares little about other markets then Japan. In Japan they will sell any game even without marketing and in high quantities.
And about models as addition - L .Sipro stated that this engine will newer has any (or hypoteticaly will never has) any new content becouse off legal issues.
First off it's actually 320x214 to be precise. Secondly you appear to be only interested in changing game esthetics which are actually the LAST part of developement. Again you are interested in something way way way down the road in possibilities. I don't think you are interested in actually getting it to work. That is actually the BIG challenge.
I had in mind resolution 320x240 (340 typo) .Movies are in 320 x 224 exactly. I am not interested in getting it to work becouse for me ff7 works now (i know that it is selfish) , and knowing how this engine works is not important for me becouse i know too little about programing and has no practice and can't learn from this project . Of course i would like to help in programing engine but it would take too long for me to catch up with programing level of many people on this board. So programing engine is not for me .
It's always best to take yourself off there hit list first. Then you can work and acomplish something. You can't finish what you never start, and you can't start tell you have a plan. So this is called PLANING. Sometimes things aren't practical. Anything is possible just not practical. Everyone has other projects and things they do to make a living as well.
Cyb
Planing is important but i have seen people who were planing on such big scale that planing was more important than engine and they newer went beyond planing.
Of course everything above are only my opinions.
-
You'd be better off decompiling it and updating it to take advantage of newer hardware etc that would be awsome i think. Course i know pulling that off succesfully wouldnt be easy.........
Actually decompilation is a nontrivial task. I've done it when I had to convert an old controler based on a Z80 to a new system based on a PC104 module. It took the better part of 5 weeks to convert 32K of ROM code it 53 C modules and 54 headers. This was just decompilation working about 9 hours a day 5 days a week. There is no way something as large as FF7 would be as easy as that. Decompiling also hits on an ethics problem. DMCA essentially torpedo's this idea.
Remake actually worked somewhat. We know something about the original content (browse this forum). We also know something about the scripting engine etc. I believe it will take less time than attempting to decipher there original code. This is because we create the specs from the presented data, more importantly this is not Reverse engineering and doesn't consist of 'stealing there code' which is copyrighted.
I like games with outdated graphic if content is right, but Square made terrible work with ff7 and ff8 transfering it to pc almost exactly like they were on psx. In ff7 models have 1000-3000 polygons without almost no textures (there are few exceptions).
In ff8 models are only 1000 poly with textures. Becouse of texture use and other things models have generaly less polygons then in ff7 and are blocky.Backgrounds in low resolutions. Only ff8 movies are good.
Square does not care about pc. Terrible ff7 translation into english.
Square should make ff7 and ff8 for pc first and then convert it to psx. Of course in Japan psx is more popular.
Square cares little about other markets then Japan. In Japan they will sell any game even without marketing and in high quantities.
1) Square soft did not port FF7 OR FF8 to the PC and yes FF7 was a really nasty port :)
2) Translation to English was actually fairly good. It's hard to translate between langauges especially expressions, gestures even are a problem.
3) Starting with the PC first and porting to the PSX can have mixed results. It's better to leave things open for later porting than code for one platform and then attempt to port to another. It's a difficult situations irreguardless to make the game that way.
4) I know a LOT about the FF7 model information there polycounts I suppose I could give you exactly if I took the time to gather statics from them. I could also give animation count texture size (if any) etc. Been playing with them for well over a year now (scarey now that I think about it).
5) FF8 has several different model sets There are high res models and low res models for the field for example. Battle models I've no clue about but I know where they are located at least :) The hi rez sets have 2 texture's that are 8 bit depth and palatized. All textures are 128x128 pixels. Vertex counts I can get as well as face count. They are stored a bit differently (ok a LOT differently) than in FF7. The have no lighting characteristics nor any vertex normals etc. So yes they are limited, but in my view they are pretty good considering they were made quite a while ago.
6) Japan is a totally different world than the US. Same as Europe and the US. That's the way things are.
I had in mind resolution 320x240 (340 typo) .Movies are in 320 x 224 exactly. I am not interested in getting it to work becouse for me ff7 works now (i know that it is selfish) , and knowing how this engine works is not important for me becouse i know too little about programing and has no practice and can't learn from this project . Of course i would like to help in programing engine but it would take too long for me to catch up with programing level of many people on this board. So programing engine is not for me .
214 was a typo I didn't notice for a while yes it's 224 for everything. Ok so you basically have no interest in the project. That's cool. :)
Cyb
-
Cyb: Squaresoft *DID* port FF7 to PC.
The porting process was done by a contract team, but under Square's control. Edios at no time had the source code, they simply distributed the program.
Actually, what Square did was "up-port" the code. At the time, Square's sharefolders were chomping at the bit because of the exclusive contract with Sony. They wanted the company to diversify and Square started to rewrite thier old games to more portable and device-independant code. FF7 was kind of in a quasi-state as it was written with a moderen language, but was still tied to it's propitary platfrom. In effect it's port suffered because it *WAS* a port, and not a rewrite of the engine. The FF1/2 code is *EXTREAMELY* portable. (These both use the same engine, with different data, it's why they are always bundleled togeather). On the flip side FF6's rewrite, using the SNES engine program flow as it's base, was still a rewrite and not the same engine as the remakes of FF5, 4, or 1-2
It was, at the time a good business desision, but bad timeing on chosing FF7. They should of waited and ported FF9 to the PC as it as it was just beginning deveopment at the time.
-
First Cyberman . I see that you like saying everything precise. anything said generaly is wrong
1) Square soft did not port FF7 OR FF8 to the PC and yes FF7 was a really nasty port :)
Maybe not Square but someone made ff for pc for Square and Square aproved that ff version
3) Starting with the PC first and porting to the PSX can have mixed results. It's better to leave things open for later porting than code for one platform and then attempt to port to another. It's a difficult situations irreguardless to make the game that way.
I was speaking here about media,graphic. When you have high resolution backgrounds,movies,textures on pc then it is easy to convert them to low
resolution psx. From low resolution media you can't make high one.
You need to render them again in high resolution. People creating pc version has got generaly psx media . (only movies in ff8 were rendered again in 640x480) or maybe they had high res movies in first place and encoded them to psx native resolution.
4) I know a LOT about the FF7 model information there polycounts I suppose I could give you exactly if I took the time to gather statics from them. I could also give animation count texture size (if any) etc. Been playing with them for well over a year now (scarey now that I think about it).
I am also playing ff7 models for long time and i was speaking generaly. I was not speaking about exact numbers. From watching ff7 models and few ff8 models i got felling that they could be better on pc becouse pc is not limited by strict specifications like psx (of course pc is limited by economical boundries). For example - today no one can release game that is playable only on geforce 6800 ultra .( one can release such game but will not earn much from it)
Ok so you basically have no interest in the project. That's cool. :)
What is cool about it? I don't know . You know this is as cool as saying that nick 'Cyberman" is cool becouse word cyber is in it (not that i do not like nick Cyberman). no offense but i heard little flaming in your words.
-
I for one don't want to see a remake with half-assed fan made models. It'd be a great challenge to make a new engine with Square's original content that has greater compatibility.
-
You can certainly make custom models for FF7 already, with enough knowledge of the file format. The new engine will not provide any additional functionality to make it easier than that. It should do the exact job the original engine does (but better), not take on any new "additions" to the game. halkun: ...right?
This is, as someone may or may not have said, more of a technology demostration. Sort of like writing an emulator, but emulating the game environment instead of the console environment. I'm still not sure about the reverse-engineering issues though, even the current base of FF7 information is certainly in many places the result of reverse-engineering/disassembly. We (at least I) base the new code on the functionality of the original, not the code of the original; but it's a bit murky since a lot of the existing knowledge of the functionality comes from observing the original code... :-?
-
I think the guys making CT:R made a serious mistake: they were about to, with their project, make freely available a game, that is in all aspects better copy of the original, AND (if I remember correctly?), it being functional did not require the original game.
So if you can make the new engine unconditionaly require the original game (data?) to function... But then again, big companies sometimes just shut down projects for no good reason at all, so I can't say anything for sure :roll:
This is, as someone may or may not have said, more of a technology demostration. Sort of like writing an emulator, but emulating the game environment instead of the console environment.
One thing: the PS emulator needs the BIOS, which isn't supplied with it. So officialy, the thing doesn't work and is not supposed to. That makes it pretty safe from being shut down, don't you think? An emulator of a software enviroment might not have that luxury, though. Except if you successfuly translate the concepts: BIOS >>> original game data?
-
Here are the goals I would be intrested in.
1) Update the engine for modern computers and graphics cards.
Why? beause the old one has atrophied. It can't run on XP, and now Duck has dropped support of TrueMotion.
2) Create a cross-platfrom engine
A native engine will always prefrom better than one in an emulated environment. Using FF7 on a PSX emu example, even if you play the game at 2048x1024, you are stil using a 320x224 "grid" and the polygon vertexs "snap to the grid" even though the edges are in higher resolution. It would be nice to be truely scaleable. I also, selfishly, want to play FF7 as a native Linux game.
3) Create an extendable engine that you can write your own content for
What the difference between FreeSCI running Sierra's "Hero's quest" and a new engine running the FF7PC? Geep in mind there is also the "SCIStudio" where you can make your own content. I'll jus be happ if you could use somewhat sane formats and real directory tree.
I have to get to work. I'll probably whine later, I have to dig my car out of the snow now....
-
First of all, I'd like to say I like this discussion. Both because it's important, but because the people in it have very well-formulated opinions. :)
3) Create an extendable engine that you can write your own content for
What the difference between FreeSCI running Sierra's "Hero's quest" and a new engine running the FF7PC? Geep in mind there is also the "SCIStudio" where you can make your own content. I'll jus be happ if you could use somewhat sane formats and real directory tree.
Now this is where we it starts getting dangerous... that being getting close to a point where the FF7 original data is just a "game pack" and our engine and future development tools (?) allows people to toy with Square's original content. They're leaving people who do small-scale hacking alone, but while the distinction between the small-scale "providing a new engine for FF7" and the slightly larger-scale "providing the ability to use FF7 data in a new, extendable context" is a small one, it's a most important difference of motive. We're talking about taking something entirely based on SquareEnix's ideas and property (the engine) into entirely new uses. Let's not kid ourselves that any soul out there would create a new game using this highly primitive and restrictive engine, the main public interest would clearly be to make (half-assed) customizations to the FF7 game itself. And since I'm assuming we'd have to figure out a way to prevent such use of the original data just as a "please don't sue" gesture for SquareEnix, what would then be the point to spend even more huge amounts of work to build a game customization engine that either no one will or can use legally?
The challenge is to build something that will run FF7 as it was intended. That's a rather specific and unique goal, with plenty of work involved. If we want to make a general-purpose engine (which would also run FF7), we're talking incredibly more work for very little reason. Any team willing to spend the work to create the amount of content needed for a game running in the FF7 engine would most likely want to write their own engine too, to get exactly what they want. Sure we could start a new project later for a RPGMaker-style engine that would let you make games similar to FF7, but I really feel we should keep the two concepts entirely separate. If we actually get together and create the latter engine (using what we've learned from this project about engine design), we would actually have a viable product. It would be a real shame then not to be able to do anything with it or even protect it, due to some legal issue regarding its origin because it was developed from the FF7 engine.
My point, which could probably have been written much shorter, is mainly that the new FF7 engine and the extensible RPG engine are and should be two entirely separate projects. If nothing else, than for the simple reason that the FF7 engine by necessity is messy, while a new engine (especially an extendable one) should be written "by the book" so to speak. You would not want to try and combine the two philosophies in a single software development project, trust me.
-
It seems like we've got a two-problems-discussion in here:
1. Argueing about who ported FF7 to PC and the Quality of the Port.
2. Writing our own Engine
I'l try to concentrate on the second one...
I've got to agree with Qhimm. I thought that making self-made additions to the engine would be an option, however, I've been tought here that this is going to be a risk for the whole project. So let's forget about this one first.
A "Naked Engine" is what we have to work on.
This is one of the points that makes my head ache:
1 make sure that users have orygiinal ff7 so Square earned money
The engine *should* have a cd-check or any sort of pseudo-copy-protection to ensure the end-user has a legal copy of FF7.
Problems:
1. If this is going to be an open-source project, then we can totally forget that. Everyone could download the source and recompile it without the protection. (what means that Open-source isn't such a good idea at all)
2. AFAIK FF7 did not have any copy protection on their original discs, so there won't be a way to check if the end user has a legal copy. But this is Square's Problem I think...
And something else:
Some months ago I was trying to write a 2d-jump-and-run engine, however, the project was cancelled.
But I was writing some sort of "Virtual Directory Manager", and I think this maybe could be helpful for that FF7 engine...
That manager consist of 2 Classes: A Directory and a File class.
Once you specify a path to the directory and "mount" it, the directory class scans the path for files, and creates an array of File classes.
Then, it checks if there are any archive files (LGPs in FF7), and if there are, it reads out the Header of the archives and add the files inside of that archive to the File class array. Of course, this only works when the archives are not compressed, but AFAIK, all LGPs are uncompressed in FF7 PC.
Advantages:
1. You do not to decompress those archives to tempory files, you can access them directly from the archive (as use it as a usual file that is not packed into an archive). Of course, this is only working well if you want to have Read Access to those files - it's tricky when you want to change a file inside an archive.
2. Because of that File array, you do not need to search for the files you want to open - you just get them from your array.
Disadvantage:
Once a directory was "mounted" it does not recognize any changes in that directory until it is "remounted", which means closing all files, destroying the file array and mounting again.
(However, I was thinking about making an "Silent Remount" which will not require closing and destroying *all* objects...)
Unfortunately, my last file backup f**ked up, so I lost the source files.
However, I have already started rewriting those two classes. It will take some time until I can send you some code, however, maybe this would be a way to solve some of our cross-platform problems...
What do you think?
- Alhexx
-
First Cyberman . I see that you like saying everything precise. anything said generaly is wrong
If you say things generally they generally are wrong. It sounds odd but it's true. It's best to be specific so people won't be misled or get wrong ideas.
Maybe not Square but someone made ff for pc for Square and Square aproved that ff version
Ummm Ok in any case we agree it's a crummy port. ;)
I was speaking here about media,graphic. When you have high resolution backgrounds,movies,textures on pc then it is easy to convert them to low
resolution psx. From low resolution media you can't make high one.
Mmmmm maybe there is a detailed discusion about FF7's porting to the PC somewhere in this forum read that. Porting is very difficult. Even with highly portable code (See Nethack as an example) is quite difficult to port, I can attest to that. It really depends on what you are developing for. PC games about the time FF7 was released were not as good as playstation games in terms of developement and quality. Keep in mind you are looking backwards on the progression and not what the authors had to do. It's not what people can do now it's what was available then. At the time of the initial game writting the playstations video hardware did much better than the PC's. That's just the way things were. Now it's reversed.
You need to render them again in high resolution. People creating pc version has got generaly psx media . (only movies in ff8 were rendered again in 640x480) or maybe they had high res movies in first place and encoded them to psx native resolution.
Please read the discusion of the porting of FF7 it's somewhere in this forum. I think you'll understand things a lot better. I would also like to point out that if you don't make a game with the intent to port to begin with, this will be the typical situation.
I am also playing ff7 models for long time and i was speaking generaly. I was not speaking about exact numbers. From watching ff7 models and few ff8 models i got felling that they could be better on pc becouse pc is not limited by strict specifications like psx (of course pc is limited by economical boundries). For example - today no one can release game that is playable only on geforce 6800 ultra .( one can release such game but will not earn much from it)
Well I've not been manipulating models I've been rendering them from the original content. As for if they could be better sure, Qhimm posted some rather startling images from FF8 content rerendered. We know enough to grab the PSX data from the disk and give an OK rendering of it as a result. This is without enhancements. The whole point of the engine is to actually get the data and make it work correctly. Doing additional things to the data won't help unless the engine can run the original content to start with. That's the primary focus of the project.
Cyb
-
ummmm i doubt this is any help but....... what if this newly made engine just applied special effects on top of the original gfx to get a nicer or different look then there's no content modification.....
Im not sure what you would call it and whether it would work for this but you might be able to enhance the graphics and stay out of trouble somewhat.
-
Some special effects such as distance blur and stencil-depth shadows could be applied (assuming there was a light source, and in the battle scenes there are none), and I personally have little opinion about whether it is a good idea.
I consider it with my own engine but never get around to doing it, primarily because I need more done.
Changing the graphics is not acceptable, but applying modern graphics-enhancing effects, well, depends on what the makers of the engine want.
I am completely against modifying the models or game content but for my own engine I am considering making shadows and blur to be options the user can select if he or she wants to see a more modern game.
Besides that, right now, with a fully-loaded battle scene and all characters on the field, I am getting over 1,000 frames-per-second at 1280×1024.
I need something to slow that down.
L. Spiro
-
Enhancing as in how emulators enhance (2xSAI filtering, increased resolution, anti-aliasing) should all be relatively OK. These are merely ways of showing the original content, and do not depend or interact with the content in question. We could, for example, apply a gauze effect (a la Prince of Persia: SoT) for the world map, but say adding motion blur to the Bahamut summon would be a bit closer to the edge of "manipulating original content" -- the only difference being that we let the engine do it in real-time without modifying the Bahamut summon files. I don't know, but this is in any case definitely something to think about late in the project, not during the planning stage.
-
Ahhh yes of course i just wanted to suggest it as it doesn't brake any laws or atleast not to my knowledge and it shouldn't.
-
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.
You could try OpenAL (http://openal.org/). 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.
-
Message
-
Why would you want to use OpenGL it is slow compared to DirectX?
EDIT: Oh right for other OS's i gotcha now.
That isn't necessarily true.
-
Why would you want to use OpenGL it is slow compared to DirectX?
EDIT: Oh right for other OS's i gotcha now.
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.
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.
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.
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.
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.
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.
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)
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 (http://snailrush.online.fr/soft/7mimic/). 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.
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
-
ahhh sorry i don't know much about Linux at all.
-
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)
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.
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.
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)
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
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.
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
-
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?
You should be able to grab the matrix information from a player, or get it from the game.
You don't have to worry about decoding the sector format or error correction, the drive does that for you. The raw sector is 2352 byte. For a mode 1 sector you can just skip 16 byte from the beginning and save out 2048 byte, for a XA mode 2 you have to skip 24 byte and depending on form can save either 2048 byte or 2324 byte.
The psx codec in ffmpeg works on data extracted that way.
-
You should be able to grab the matrix information from a player, or get it from the game.
You don't have to worry about decoding the sector format or error correction, the drive does that for you. The raw sector is 2352 byte. For a mode 1 sector you can just skip 16 byte from the beginning and save out 2048 byte, for a XA mode 2 you have to skip 24 byte and depending on form can save either 2048 byte or 2324 byte.
The psx codec in ffmpeg works on data extracted that way.
Your information is partially correct. Those first 24 bytes (the header) contain weather it's audio or video in the remaining data, and what channel it is (for audio). You can have up to 32 channels of audio in one interleaved file (not that you would ever use it). This is the best method for extracting the video and audio. Because not all PSX movies/formats are the same. Some of the movies for example are not 320x240 but can be 160x60 with no audio in them (basically just an animation). So it varies :)
If you want to play the original media information you need to know the matrix to decode the MDEC data properly as well. If you are going to RIP the data PSXmc works just fine with the codec of your choice. You can then use Vdub and precise bilinear filtering to enlarge the image then add a light sharpening affect.
Cyb
-
As we can't bundle the converted/enhanced files with the engine we would need to write a player, or at least a decoder that allows to transcode into divx or similar.
-
As we can't bundle the converted/enhanced files with the engine we would need to write a player, or at least a decoder that allows to transcode into divx or similar.
If you tried to convert the current movies into another format, wouldn't you just lose more quality? Anyways, I'm probably gonna rip the movies from my PS1 version and try using them in FFVIIPC, I've never heard of anyone doing it before but for some reason, the movies have been bugging me so much lately... they are just so ugly
-
Why are you discussing converting the files to another format as a solution to the problem of reading them in the first place...? -_-
-
Why are you discussing converting the files to another format as a solution to the problem of reading them in the first place...? -_-
Well, there are bigger problems at the moment. But the reasoning could be this: Accessing XA data on a CD is a pain, so it makes sense to rip them to get normal files. Then you can safe a lot of time developing a real-time decoder if you just transcode them into a format that has already quality codecs available. Then you can use existing software to render them into a texture and DirectX/OpenGL to draw them in the game.
-
Well, there are bigger problems at the moment. But the reasoning could be this: Accessing XA data on a CD is a pain, so it makes sense to rip them to get normal files. Then you can safe a lot of time developing a real-time decoder if you just transcode them into a format that has already quality codecs available. Then you can use existing software to render them into a texture and DirectX/OpenGL to draw them in the game.
EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode). I believe the best bet would be to do the following for the movies (which happens to work GREAT on the enhanced PSX plugins for ePSXe and PCSX).
Fetch video information take hoffman data and decode into PSX 8x8 blocks into a texture Paste texture with bilinear filtering to screen. The movies look better and do not require your computer to cough up furballs done 1 fps with a 2.2ghz Athalon. Not only is it processor intensive it requires MMX SSE 3dnow and several other instruction mixes to do so. It's a big gotcha and won't work unless you have a herculean computer (don't forget you still need to decode).
Cyb
-
I've been reading this thread with great interest, but it seems to be going off on a tangent/getting sidetracked. Could I possibly suggest getting back on track by doing something like opening a new forum here or some new stickies and putting all these suggestions for various parts of the engine in (potential problems/suggestions)? At least that way some headway would be made rather than getting stuck into very specific topics such as video playback, only for the thread to eventually 'tail out'. Just a thought. :)
-
EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode).
Don't worry, I didn't plan to do the encoding/decoding simultaneously! :wink: The thing is just, if you have them on HD anyway you can safe a lot of effort by doing any pre-processing off-line. You could run the highest-quality rescaling filter that you can come up with and compress with the highest quality encoder you can find. But as I said before, there are bigger problems to tackle than movie playback.
-
EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode).
Don't worry, I didn't plan to do the encoding/decoding simultaneously! :wink: The thing is just, if you have them on HD anyway you can safe a lot of effort by doing any pre-processing off-line. You could run the highest-quality rescaling filter that you can come up with and compress with the highest quality encoder you can find. But as I said before, there are bigger problems to tackle than movie playback.
Ahh Ok dokey :)
Suggestion for topic 'distribution'
the original thread started was 'is it possible' the answer is yes.
Maybe we should break off the various discussions such as MOVIE, field information, battle information and script execution? Or maybe there just isn't enough interest for that yet ;)
Perhaps we could discuse setup?
The big issue with the encoding and decoding isn't is it possible we all know it's very possible. The real issue is really 'is it safe legally'. I could for example RIP FF7 movies and reencode them with visual improvements etc. However I don't believe it's legal to include those with the game engine. AND asking a person to download all the stuff to rip and reencode the movies might be an impedance to using it. For windows or Linux this could be a problem. The only potential solution I can think of is using XVid and have the installer use some automated method of getting the XVID windows libs or XVID Linux libraries for encoding/decoding. Grabing an encoder then for CLI execution is the next step. This requires the media though. Under linux as halkun said this method would not work. Windows it would.
Technical aspects, we need a resolution independant method of showing the movies in any case that matches well with the backgrounds. I think the best method is as I mentioned a large background texture plastered onto a quadric. The same can be done with the game sprites (using transparency). All alignment can be done prior to rasterization. This is going to be the biggest issue of having a multi resolution output. 3D is easy to scale in the game. 2d is not. If any of you have played the PSX version under emulation you'll notice little regions where there are small lines visible in the background. I believe there are several ways of correcting this problem but we have to think things through carefully. 320x224 does not scale easily to 1024x768. So my first suggestion is to NOT use standard window resolutions such as 1024x768. Even if it's in a full screen viewing mode. I nominate picking ratios compatible with 320x224 which has an aspect ratio of 10:7 not 4:3. 800x600 window would actually be 800x560 or 1024x768 would be 1000x700 1280x960 or 1024 ends up 1280x896. 1600x1280 1600x1120. Not only does this make things simpler for the rendering engine. It also makes the display of all graphics MUCH better. There would be a significant reduction in alignment issues. (Like none).
Other things, the Kernel handles the low level IO access for everything correct? I know everyone seems to have a desire to glob everything together (grin) and believes this easiest. I will humbly submit from experience in a multi person project it's not. Modularizing the whole thing and defining control interfaces is the wisest but slowest path. If it's truely to be a multi system project, it's a must pretty much. Otherwise you will be playing fast and the furious with code. Everything up to the 'kernel' or basic system access should be identical. This keeps the basic engine running smoothly and consistantly. It has the added benefit of allowing testing to be MUCH MUCH easier. IE you can simulate the kernels access with whatever kernel code you have that works, until the kernel for a particular platform works well enough. This works both ways for testing. If existing code for testing the kernel is around, guess what? Making sure the kernel works is much easier too! (what a concept :D).
So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think. It looks like the Kernel is nothing but low level IO and rudimentary application starting. It appears to me that kernel.bin is the actually 'startup' code for the game. The kernel may contain internal references for all files in the game. So for the PSX version it make contain all references to sectors for each file on each game disk. For the PC ??? not sure probably similar data.
So my guess is the kernel grabs kernel.bin and loads the start menu which in turn loads the start of the game or the current field location.
For a Linux version it would be necessary to submit an update to the CD-ROM drivers for Linux to support Mode 2 access with disk drives or at least see if it is possible to do so. This is not easy but might be more legal than say having them make an Image of each disk to access. :)
Cyb
-
Is it possible for a utility that may automate the process of improving video quality? this might solve the distribution problem but obviously no where near as many options.
Anyway just a suggestion.
-
Kernel.bin consists of GZip files containing text and data for the game engine (armor data, Materia data, player data, etc.)
It has nothing to do with any in/out handling.
halkun, didn’t you say the shop prices and shop information is still missing?
You said that when I described that mysterious section in Kernel.bin (which was later discovered to be the savemap).
If that information is still missing, why wouldn’t it be in one of the unhacked sections of the non-battle field files?
From memory, I understand that the field files have 9 sections, several of which were understood at least partially, including the ones related to drawing the 2-D images and the text for each field area.
I am just assuming what you said about the shop information being missing still applies, and I wonder why they WOULDN’T be found in the field files, probably directly after the text for each field area.
I do not look into those files much because I do not have good tools for doing so, but I am pretty sure if you are looking for the shop information you will find it in those files.
L. Spiro
-
The shop varibles are glabal. Kernel.bin is mapped, so it's most likely in shup.mnt then, which doen't have PC eqivelent...
-
Yes, let's all preprocess the movies and store them on the users' hard drives, and while we're at it of course let the game run without the CDs, or even optimize it for the Ultima Version, or recompile the game data onto a DVD! Yes! Why not even let users download preprocessed files to use instead of the original game data!
Could we please get back to making it instead of making it "better"? We're in enough gray legal goo as it is without you guys start suggesting modifying game data and making the game run no-cd (as would be the case when the movies are on the frickin' hard drive already). You'd think you'd be able to add two and two together, i.e. a) games are made to be run from their original media and b) circumventing copy protection is illegal, which raises the rather interesting question why you would think the new engine (which would then allow you to play FF7 without having the original discs nearby) would be legal?
The very point was to make a technical demonstration of a new engine that would work as a drop-in replacement for FF7, not making a crack which "upgrades" your FF7 installation to "FF7 v2.0". If the engine tries to smooth movies in real-time while playing them, at least we could argue that it's just a display system. You're suggesting to actually modify game data, where enhancing movie quality is technically is no different from, say, modifying the game script. It's all bits of data, and we will not tamper with the for the sake of this project.
Oh, and I haven't compared notes on this with halkun, so I hope I'm not saying this on the complete contrary to his opinion on the matter. I'm not backing down though, I don't want this project shut down just because people couldn't get their chronology straight. Once we have a version complete, we can allow it to see the light of day, then you start worrying if it's safe to touch the game data for this or that purpose. The primary target is a modern, compatible engine for FF7. If the project is getting shut down, I at the very least don't want it getting shut down for anything else than that.
-
Hmmm Halkun I suspect BGINMENU.MNU might be the begining menu (NewGame/Continue screen) for the PSX version of the game I suppose I ought to add something to extract information from .MNU files. (which acording to your documentation that's it hmmm). Alrighty I don't see any reference to it's structure however (MNU). Are these just uncompressed script files?
Qhimm: I kind of thought I was gently hinting at that hmmm need to use a hammer next time?
Cyb
-
So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think. It looks like the Kernel is nothing but low level IO and rudimentary application starting. It appears to me that kernel.bin is the actually 'startup' code for the game.
I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.
Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?
-
I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.
Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?
I am as well as I'm fixing up some 'bugs' that are a result of my ineptitude in my scanner decoder peek-a-boo swiss army knife of FF7 ploinking (sorry I couldn't resist that).
The rendering layer I think needs to be abstracted from the kernel. It looks like the 3d engine is part of the kernel in the PC and PSX versions. I believe random encounters etc. are handled via the battle section.
The field files are a bit more known, the MIM files in the PSX contain the image BLOCKS for the backgrounds for example. The DAT files contain the field location information, script, and dialog information. BSX files contain field models for that field location. DAT files may contain the sprite information and background tiling information in them. Lots of fun there. Right now I'm cleaning up my code mostly so I won't have headaches later with it. Simple things like consistant decoding and the use of in memory decoding routines to improve speed. At least my TIM scanning algorythm is very fast.
Back to the main subject howsumever. Yes someone is working on the field stuff for the PSX. I think I am going to sit down with some code tonight and grind through the script/dialog decoding. Once I can seperate all the sections of the DAT file cleanly I think things will be more readily acertained for the PSX.
Cyb
-
As part of trying to keep the topic (and thus the project) alive, I'll start posting my progress as I continue to examine various parts of the original FF7. These are some of the more generic points I've come across:
- FF7 is written in mostly (if not completely) C-style code. As I've only seen compiled examples, I can't tell if it was compiled as C++ code or not, but they have at least not used C++ features as part of their main code structure. That having been said, the C code is many, many cases written to emulate C++ features (objects with associated access methods), so if we are to write a new engine to emulate the structure of the original one, using C++ from the start is, after all, more effective.
- As stated earlier, the original FF7 was compiled completely without compiler optimizations, making the code very ineffective in a great many cases. Considering the code quality that lead to the Chocobo Races XP vulnerability, the program was most likely kept in debug mode simply because it wouldn't run when optimized.
- FF7 relies heavily on DirectX for its interface to the system, from graphics to sound to input. I think our best bet is to design a highly modular engine where you can write specialized sound/input/window/graphics(?) management modules for individual OS:s when you want to port the project. The engine core would remain completely portable, but we could allow it to take advantage of several features not exposed through the "standard portable" libraries like GLUT, and probably also to a lot nicer and more managable code.
- Something for the more budget modder... FF7 already has a complete rendering plugin system, and from what I can see it is exposed to enable anyone to write plugins, if you had the API specifications. FF7 itself uses this plugin system to select between hardware/software rendering through two internal plugins, and allows the user to select an external DLL as a plugin as well by modifying the registry appropriately. By combining this with a highres/window patch you could probably achieve flawless high-resolution, windowed(?) graphics without rewriting FF7.exe. You would still have the same crappy code base though, so FF7 would still be as crash-prone as before.
[/list:u]
So, that's what I've come across lately. Any progress from somewhere else to report?
-
Hmmm Halkun I suspect BGINMENU.MNU might be the begining menu (NewGame/Continue screen) for the PSX version of the game I suppose I ought to add something to extract information from .MNU files. (which acording to your documentation that's it hmmm). Alrighty I don't see any reference to it's structure however (MNU). Are these just uncompressed script files?
Cyb
I have no idea what's in an MNU file. I tried picking one apart in PSX memory using savestates, but I didn't see anything rational in there. I can tell you that the MNU file is copied directly from the CD into RAM and executed. I don't know if it's native R3000A code or some kind of scripting langugae.
I don't think it's fieldscript as I don't recall the window() functions abe to do anything but display text.
However, the menu selector on the right is not part of the .MNU files.
The new game/continue is actually in the save menu module. That's where the buster sword graphics and the new game/continue text is. Save can actually load too.
-
So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think. It looks like the Kernel is nothing but low level IO and rudimentary application starting. It appears to me that kernel.bin is the actually 'startup' code for the game.
I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.
Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?
Kernel.bin consists of GZip files containing text and data for the game engine (armor data, Materia data, player data, etc.)
It has nothing to do with any in/out handling.
Are we talking about a different Kernel.bin?
I can’t say what is in the PlayStation® version files.
L. Spiro
-
Look at gears... You will see kernel.bin only contains game data. No executables. Kernel .bin is the same in both the PC and PSX cersion. the PC version has kenerl2.bin, but that's just sections of the text sections in keneral.bin (Part 10 and on) in LZSS format.
The kernel is responsable for the following.
1) Communictaion to the lower BIOS and PsyQ API.
2) Ownership it's own higher-level game API. (Play music, load model, user input)
3) System Memory Management
4) Thread managemant.
5) Loading and unloading of modules.
....along some ohther things, these were the big ones.
-
I had figured I was reading something wrong.
I was talking about the file while they were talking about the “kernelâ€.
I thought they were talking about the file because it is common practice (and laziness) to omit extensions when referring to common files.
L. Spiro
-
I was checking out the final fantasy remake thing in ficedula, I can script for like NWN and stuff, so if you guys have anything like that built in if you do this ill definitly help