Messages

276

Troubleshooting / Custom graphics driver for FF7/FF8 [v.1-.7.6]

« on: 2009-07-05 20:47:06 »

DOH! Yes, that's what I meant, per fragment lighting.
Nice to see you are already working on it.

277

Troubleshooting / Custom graphics driver for FF7/FF8 [v.1-.7.6]

« on: 2009-07-05 17:51:01 »

Impressive job Aali. To think how hard it was to get the original hi-resolution pacth done... and now that whole buggy graphics engine is redone. Great job.
By the way, would it be possible to add per vertex lighting? I'm not sure, but I think it could make some things look better.

278

Scripting and Reverse Engineering / Re: Missing rwda?

« on: 2009-07-05 17:46:20 »

Kimera doesn't write *da files rigth now. You should copy that file manually where you need it.

279

General Discussion / Re: An experiment to turn the 2D field files into 3D (w/video)

« on: 2009-07-05 17:40:37 »

I'm really impressed with your experiment halkun. If you get this done FF7 could look seriously better. Even if the camera doesn't move too much, it usually has some panning that would look far better with a real 3D background.

If I undestrand correctly, in order to get one of this backgrounds in game you should:
1 - Destory the original 2D background information so that it doesn't collide with the new geometry.
2 - Add a new entity to the level file.
3 - Modify the script so that it shows the model in the level.
If I recall correctly steps 1 and 3 are already possible. I don't know about the 2nd one, though. Backgound animations could cause some more problems though.

280

FF7 Tools / Kimera: FF7 p model simple editor

« on: 2009-07-05 17:19:24 »

squallff8: Nop, sorry, I don't know about any other programs that can do that conversion.

Xelane: The "Change animation" option let's you select a field animation to dislpay. Yes, I know it's a bit obscure. Provably I should change it's name. It doesn't have any
meaning for battle animations (that's why it's disabled).
Kimera can modify field animations and save the changes (it saves the changes when you save the model), but it can't change battle animations. The reason for this limitation is that battle animations should be recompressed and repaked, and I felt lazy for writing the needed code. In fact, I could even store them uncompressed but as I said, I felt lazy for writting that code. Maybe I should do it someday...

samsa_: What problem are you experiencing? Kimera is composed by a single executable, so no installation is requeried (nor possible...). You may need to register some kind of DLL though.

281

FF7 Tools / Kimera: FF7 p model simple editor

« on: 2009-06-24 13:13:33 »

The strange thing is that kimera should normalize the model just befor saving it so that it fits FF7 demands. Could I have a look at that some of those problematic models?

282

FF7 Tools / Kimera: FF7 p model simple editor

« on: 2009-06-22 18:57:18 »

I didn't know models created with Kimera could crash the game after version 0.8. Oh well, if you want to send me your models I could take a look at them and see what went wrong.

Sorry for the inconveniences.

283

FF7 Tools / Kimera: FF7 p model simple editor

« on: 2009-06-10 16:14:18 »

I never had such a problem. Are you using Vista or something like that?

284

FF7 Tools / Kimera: FF7 p model simple editor

« on: 2009-06-08 22:43:50 »

Sorry for leaving this topic and not comming back for so long. As some of you may have guessed, this project is dead.

I've reuploaded the last version to megaupload. Hope the links don't die too soon. If anyone knows about a better free hosting site, please, let me know.

I also uploaded the source code so anyone can continue working on it if he has the time to waste.

Again, all I can say is sorry.

285

Releases / Re: [Release] Higher Resolution FFVIIPC [v1.00] - Part II

« on: 2008-07-15 15:24:19 »

I may be wrong, but wasn't it possible to run this patch even if the resolution wasn't supported using the windowed mode mod? The image would get cut, of course.
As for adding new resolution, if I understand correctly what The Saint did, it's just not posible using the same method.

286

Archive / Re: New title menu pic for PRP project for those who are interested

« on: 2008-06-15 11:53:03 »

Are you sure there is a limit in the size ice_cold? I never tried, but since all the other textures can be pretty big I thought this one would be the same. But there is another problem: the color depth. You must use an 8-bit image.
By the way, I think the WIP one is the best. Great job.

287

Archive / Re: Modeler

« on: 2008-06-09 21:03:32 »

The battle backgrounds use the same 3d format as any other model in FF7. So basically it's the same as editing a character model. The main difference is that battle backgrounds are bigger and fully textured, and that certainly make things harder.

288

Releases / Re: [Release] Final Fantasy VII Phoenix Rejuvenation Project

« on: 2008-05-10 01:10:00 »

Stick, the last link for Kimera (the one provided by ice_cold513) it's still alive.

289

Archive / Re: Modeler

« on: 2008-04-18 10:28:05 »

Hello Hironaga.
I worked for quiet a while on the old NPC RP and I never found any hard limit on the polygon count or the texture size. FF7 will eat mostly everythig you throw at it. Of course, as you correctly guessed it doesn't support any fancy effects. Only plain textures, vertex colors and the old local vertex lighting. It doesn't even support the specular component.
Nice sword, by the way. I'm pertty sure your help would be very welcome.

290

Releases / Re: [Release] Final Fantasy VII Phoenix Rejuvenation Project

« on: 2008-04-10 22:56:49 »

I'm pretty sure all those who get crashes accesing the menu wouldn't have such a problem if they tried the Windows 95 compatibility mode.
If you want to use any other patches in conjunction with this one, you can try converting them to IPS (using snestools) and applying them. Or you can do the files swaping trick, don't know if you would get all the models that way.
By the way, nice to see you are going to try to contribute the project Viashino. Now that Stormmedia and me are unavailable, your help will be very valuable.

PD: Nice to see someone still remembers me.

291

Archive / Re: Technical question about original FF7 concerning field models

« on: 2008-04-10 22:40:00 »

As Akari explained, you can't expect much better graphics from a game that started it's deveolpment in 1994. I'm pretty sure Square could have done some better job with the graphics, but most likely by the time their libraries could support better models it was too late to redo every NPC.
The problem with FF7 isn't that the field models are SD (I like the SD look). The problem is that they are very low poly and nearly untextured. FF8 had certainly higher poly-count, but not much. They were textured though, and that helped a lot.
As for the NPC RP, the models are still mostly untextured, but have a lot more polygons. I'm quiet sure that the PSX wouldn't be able to render such models fluidly, no matter how hard they tried. If you ask for the time needed to redo an NPC... well, I can only talk for myself. It took me from one day of work to more than one week, depending on the model. Then again, I'm much slower than ice_cold513 and stormmedia.
Anyway, it's not fair to use the time any of us can spend reworking a field model to aproximate the time Square empolies would need to do the same. We aren't professionals and have no experience modeling (hell, I don't even know modeling actually). We don't get paid either.
If we talk about the PC port... well, let's face it. Square didn't even add the much needed higher resolution backgrounds. Not even a crappy bilinear filter. Neither did they add 32/24bits color depth, nor better movies (in fact, they are even worse). It's amazing they were kind enough to throw in a 640x480 mode and hardware acceleration. No, they certainly didn't put much effort in this port.

292

Archive / Re: Would it be possible...

« on: 2008-03-04 16:15:28 »

I think L.Spiro was working in something similar long ago. But I think I heard he got a C&D order or something like that. He was doing it from scratch of course, because modifying the exceutable to that extent would be sensless.

293

Archive / Re: Kimera Problems

« on: 2008-02-22 10:02:49 »

When suposedly when the paint bucket is selected the color of the polygon you click at should be replaced with the selected color. If it doesn't work, I guess you found a new bug (as if there weren't enough...). What version of Kimera are you using and what model are you working on?

294

Archive / Re: Kimera Problems

« on: 2008-02-20 22:05:12 »

That sounds strange Shadz.
What are you trying to do exactly? Are you using the paint bucket tool or are you changing the pallete in the palletized mode?

295

Q-Gears / Re: Working on Field models.

« on: 2008-01-27 21:05:42 »

Yes, the PC version animations also keep the Z axis root position for every frame.

296

Scripting and Reverse Engineering / Re: Field Models, Animation & 3D/Walkmesh opcodes solved.

« on: 2008-01-22 10:51:41 »

Thank you very much for the info Akari. You and the rest of the Q-Gears team are doing an impresive job.

297

Completely Unrelated / Re: The end of emulation?

« on: 2008-01-18 15:59:54 »

Actually that's not a new idea. The XBOX emulator that got further (CBXC) tried to emulate the loader and the DirectX calls. Unfortunately, it looks like there were changes on every SDK version. I think they only got Turok working.
Anyway, this trick could only work for machines that share the same architecture. If the target machine has a CELL and the host machine has an x86 architecture, for example, then there is no way to bypass the CPU emulation.
By the way, the GBA emulation it's a really impresive case. 3 months befor the machine hit the market there already was an emulator. It was very primitive, but it even ran F-Zero when it was released!

298

Scripting and Reverse Engineering / Re: [FF7 Batlle model] Weapons...

« on: 2008-01-18 15:41:17 »

Hope this helps you Mirex. This is what Kimera gives me when I open Hi-Res Cloud's animation pack (rtda):

Code: [Select]

anim  0
+Base offset at byte 5
 860
   -First frame at byte 22
   -Frame 2 at byte 136 (Bit 912 in the frames chunk)
   -Frame 3 at byte 175.25 (Bit 1226 in the frames chunk)
   -Frame 4 at byte 214.75 (Bit 1542 in the frames chunk)
   -Frame 5 at byte 253.625 (Bit 1853 in the frames chunk)
   -Frame 6 at byte 288.625 (Bit 2133 in the frames chunk)
   -Frame 7 at byte 323.875 (Bit 2415 in the frames chunk)
   -Frame 8 at byte 358.375 (Bit 2691 in the frames chunk)
   -Frame 9 at byte 398.5 (Bit 3012 in the frames chunk)
   -Frame 10 at byte 440.375 (Bit 3347 in the frames chunk)
   -Frame 11 at byte 480 (Bit 3664 in the frames chunk)
   -Frame 12 at byte 517.75 (Bit 3966 in the frames chunk)
   -Frame 13 at byte 557.375 (Bit 4283 in the frames chunk)
   -Frame 14 at byte 598.625 (Bit 4613 in the frames chunk)
   -Frame 15 at byte 641 (Bit 4952 in the frames chunk)
   -Frame 16 at byte 679.25 (Bit 5258 in the frames chunk)
   -Frame 17 at byte 713.375 (Bit 5531 in the frames chunk)
   -Frame 18 at byte 750.5 (Bit 5828 in the frames chunk)
   -Frame 19 at byte 792 (Bit 6160 in the frames chunk)
   -Frame 20 at byte 834.375 (Bit 6499 in the frames chunk)
anim  1
+Base offset at byte 877
 768
   -First frame at byte 894
   -Frame 2 at byte 1008 (Bit 912 in the frames chunk)
   -Frame 3 at byte 1044.25 (Bit 1202 in the frames chunk)
   -Frame 4 at byte 1080.125 (Bit 1489 in the frames chunk)
   -Frame 5 at byte 1120.375 (Bit 1811 in the frames chunk)
   -Frame 6 at byte 1157.125 (Bit 2105 in the frames chunk)
   -Frame 7 at byte 1193.25 (Bit 2394 in the frames chunk)
   -Frame 8 at byte 1228.375 (Bit 2675 in the frames chunk)
   -Frame 9 at byte 1260.875 (Bit 2935 in the frames chunk)
   -Frame 10 at byte 1289.125 (Bit 3161 in the frames chunk)
   -Frame 11 at byte 1312.375 (Bit 3347 in the frames chunk)
   -Frame 12 at byte 1336.625 (Bit 3541 in the frames chunk)
   -Frame 13 at byte 1365.375 (Bit 3771 in the frames chunk)
   -Frame 14 at byte 1398.375 (Bit 4035 in the frames chunk)
   -Frame 15 at byte 1434.125 (Bit 4321 in the frames chunk)
   -Frame 16 at byte 1470.75 (Bit 4614 in the frames chunk)
   -Frame 17 at byte 1507.625 (Bit 4909 in the frames chunk)
   -Frame 18 at byte 1548 (Bit 5232 in the frames chunk)
   -Frame 19 at byte 1583.875 (Bit 5519 in the frames chunk)
   -Frame 20 at byte 1620.5 (Bit 5812 in the frames chunk)
anim  2
+Base offset at byte 1657
 1192
   -First frame at byte 1674
   -Frame 2 at byte 1752 (Bit 624 in the frames chunk)
   -Frame 3 at byte 1795.375 (Bit 971 in the frames chunk)
   -Frame 4 at byte 1828.5 (Bit 1236 in the frames chunk)
   -Frame 5 at byte 1855.75 (Bit 1454 in the frames chunk)
   -Frame 6 at byte 1894.375 (Bit 1763 in the frames chunk)
   -Frame 7 at byte 1928.375 (Bit 2035 in the frames chunk)
   -Frame 8 at byte 1950.625 (Bit 2213 in the frames chunk)
   -Frame 9 at byte 1976.625 (Bit 2421 in the frames chunk)
   -Frame 10 at byte 2007 (Bit 2664 in the frames chunk)
   -Frame 11 at byte 2039.625 (Bit 2925 in the frames chunk)
   -Frame 12 at byte 2064 (Bit 3120 in the frames chunk)
   -Frame 13 at byte 2096.875 (Bit 3383 in the frames chunk)
   -Frame 14 at byte 2130 (Bit 3648 in the frames chunk)
   -Frame 15 at byte 2170.125 (Bit 3969 in the frames chunk)
   -Frame 16 at byte 2210.625 (Bit 4293 in the frames chunk)
   -Frame 17 at byte 2248.125 (Bit 4593 in the frames chunk)
   -Frame 18 at byte 2280.25 (Bit 4850 in the frames chunk)
   -Frame 19 at byte 2302.875 (Bit 5031 in the frames chunk)
   -Frame 20 at byte 2324 (Bit 5200 in the frames chunk)
   -Frame 21 at byte 2341.375 (Bit 5339 in the frames chunk)
   -Frame 22 at byte 2357.875 (Bit 5471 in the frames chunk)
   -Frame 23 at byte 2373.875 (Bit 5599 in the frames chunk)
   -Frame 24 at byte 2390.625 (Bit 5733 in the frames chunk)
   -Frame 25 at byte 2406.5 (Bit 5860 in the frames chunk)
   -Frame 26 at byte 2422.875 (Bit 5991 in the frames chunk)
   -Frame 27 at byte 2438.125 (Bit 6113 in the frames chunk)
   -Frame 28 at byte 2454.875 (Bit 6247 in the frames chunk)
   -Frame 29 at byte 2469.125 (Bit 6361 in the frames chunk)
   -Frame 30 at byte 2484.75 (Bit 6486 in the frames chunk)
   -Frame 31 at byte 2500.375 (Bit 6611 in the frames chunk)
   -Frame 32 at byte 2516.125 (Bit 6737 in the frames chunk)
   -Frame 33 at byte 2530.625 (Bit 6853 in the frames chunk)
   -Frame 34 at byte 2544.75 (Bit 6966 in the frames chunk)
   -Frame 35 at byte 2560.75 (Bit 7094 in the frames chunk)
   -Frame 36 at byte 2579.375 (Bit 7243 in the frames chunk)
   -Frame 37 at byte 2602.625 (Bit 7429 in the frames chunk)
   -Frame 38 at byte 2623.125 (Bit 7593 in the frames chunk)
   -Frame 39 at byte 2648.75 (Bit 7798 in the frames chunk)
   -Frame 40 at byte 2678 (Bit 8032 in the frames chunk)
   -Frame 41 at byte 2710.625 (Bit 8293 in the frames chunk)
   -Frame 42 at byte 2742 (Bit 8544 in the frames chunk)
   -Frame 43 at byte 2775.125 (Bit 8809 in the frames chunk)
   -Frame 44 at byte 2814.875 (Bit 9127 in the frames chunk)
   -Frame 45 at byte 2843.875 (Bit 9359 in the frames chunk)
anim  3
+Base offset at byte 2861
 488
   -First frame at byte 2878
   -Frame 2 at byte 2956 (Bit 624 in the frames chunk)
   -Frame 3 at byte 2986.875 (Bit 871 in the frames chunk)
   -Frame 4 at byte 3030 (Bit 1216 in the frames chunk)
   -Frame 5 at byte 3056.25 (Bit 1426 in the frames chunk)
   -Frame 6 at byte 3090.125 (Bit 1697 in the frames chunk)
   -Frame 7 at byte 3134.75 (Bit 2054 in the frames chunk)
   -Frame 8 at byte 3158.375 (Bit 2243 in the frames chunk)
   -Frame 9 at byte 3182.5 (Bit 2436 in the frames chunk)
   -Frame 10 at byte 3217.875 (Bit 2719 in the frames chunk)
   -Frame 11 at byte 3250 (Bit 2976 in the frames chunk)
   -Frame 12 at byte 3282.625 (Bit 3237 in the frames chunk)
   -Frame 13 at byte 3316.875 (Bit 3511 in the frames chunk)
   -Frame 14 at byte 3337.375 (Bit 3675 in the frames chunk)
 ...

For some reason It's very easy to mess up trying to load these animations. I supose handling bit offsets is allways quiet confusing. It took me a lot of time to get my algorithm to retrive reasonable values. If you want to check my code just tell me and I'll upload it again.

299

Completely Unrelated / Re: The end of emulation?

« on: 2008-01-18 11:16:36 »

Well, that comparison is unfair. A Pentium D es much slower than a C2D even if they have comparable clock speed. But anyway, I think that the emulation of the current generation machines won't be possible at least for a long, looooooong time, because their power is nearly on par with current PCs and because they are very complex.

Anyway, I'm pretty sure there are still some slower systems that will eventually be emulated (some year..) such as the GC (the last version of Dolphin got quiet far), the DS (actually, the DS emulators are even in playable stages for a lot of games), the PSP or even the Wii. But even if this never happens, there will allways be ports of the old emulators for newer systems

300

Releases / Re: [Release] NPC Reconstruction Project

« on: 2008-01-18 10:51:38 »

Great news ice_cold513!
I'd like to remind everyone that ice_cold513 is working alone currently (yes, we are evil  ), so don't push him.