Messages

1

Scripting and Reverse Engineering / SEQ and VAG files

« on: 2005-03-21 02:11:08 »

It's not finished, but it's usable. FF9 might be more difficult to work with since it uses one big image file, so you'll have to use raw CD sectors to mess with the data. (I wrote it with plug-in support in mind for games that don't use the ISO filesystem, but that's part of what doesn't work yet)

Anyway, it's not too hard to use -- pick a destination on the CD to replace, pick a source file on your HD to be the replacement, and go. It's probably best if you extract a copy of the data you want to modify beforehand.

At this point I'm looking for feedback on it. I've put it here for now.

2

Scripting and Reverse Engineering / SEQ and VAG files

« on: 2005-03-13 08:13:07 »

Yeah, I know how Linux works; I run it myself on one of my other machines. Though I don't think the iso9660 filesystem can be mounted as writable, can it? I thought the only way to create one was mkisofs or some similar program (you can mount it rw, but it still won't let you write anything). And many Playstation games use data from outside the ISO9660 filesystem anyway.

But you're right; this plug-in is Windows-only for the time being.

3

Scripting and Reverse Engineering / SEQ and VAG files

« on: 2005-03-13 04:20:50 »

Do you want to try my disk editing emulator plug-in? It sits between a PSX emulator and a another CD plug-in and lets you edit the files on disk before they're loaded into memory. That way you won't have to search for them.

4

Scripting and Reverse Engineering / FF7 - Filtering with HQ2x or similar programms

« on: 2005-02-22 17:13:52 »

I haven't played FF7 in a long time, so correct me if I'm wrong on this, but I think even the animated backgrounds were not particularly complex -- maybe flashing lights or small waves on water or whatever. A few extra tiles could probably still be preprocessed.

Filtering makes the most sense when you don't have complete/direct control over the original data. This makes it perfect for emulators, where you're going to have many different games from many different sources. The emulator author doesn't know how the graphics will be stored in any of those ROMs or whatever, (and they'd probably be different for every game anyway) and so cannot modify the graphics there. But the emulated code knows how to read them and get them on to the screen, at which point the emulator can filter them. This works on any game the emulator can play without having to modify the games themselves.

For anything written from scratch, however, or anything where you can already change the resolution and graphics files, the only place I could see filtering being useful is if your game was designed for a lower resolution and you wanted a quick and dirty way to jump it up to a higher resolution without redoing everything. I see a lot of talk around here about delving into the guts of FF7, so I'm not sure how much control you have over the actual 2D graphical assets and how they're used. If "none" or "very little," then I'd say yeah, go for filtering. If "lots" or "everything," then preprocessing is definitely the way to go, since it would be less processing to do at runtime.

Incidentally, I'm wondering how those real-time filtering algorithms would look when applied to a movie suffering from compression artifacts...

Edit: Actually, I see that your intent is to continue to use the original CDs and disallow running from any writable source (i.e. someone's hard drive) to prevent piracy and such. So in that case, yes, filtering of the 2D data would be useful (but if you end up writing your own engine, it can still be done just once at load time).

5

Scripting and Reverse Engineering / FF7 - Filtering with HQ2x or similar programms

« on: 2005-02-21 21:04:17 »

Those filters are pretty much meant for real-time pixel-based images. This means that, for the most part, they are unnecessary for anything 3D (because 3D data is described geometrically rather than by using pixels, and thus can scale to any resolution with no problem) or for any static 2D images (because these could be preprocessed with a filter that would produce higher-quality images).

Long story short - for a game like FF7, which is pretty much all 3D, I don't think they'd help, and they'd in fact probably make it look worse. Yes, there are 2D backgrounds, but those are static images, and thus if you wanted to filter them, you could preprocess them instead of doing it in-game.

6

Scripting and Reverse Engineering / Need help with C file streams

« on: 2005-02-15 00:53:21 »

Anyway, look what I found while looking through stdio.h:

Code: [Select]

/*
 * The structure underlying the FILE type.
 *
 * I still believe that nobody in their right mind should make use of the
 * internals of this structure. Provided by Pedro A. Aranda Gutiirrez
 * <[email protected]>.
 */

You see what I mean, then. Any library that doesn't allow any flexibility/abstraction in where it gets its data from is probably one you want to avoid.

7

Scripting and Reverse Engineering / Need help with C file streams

« on: 2005-02-14 04:31:52 »

If by "strings" you mean binary data in memory, then yes, it does -- that's what I meant by BLOBs (Binary Long OBjects). As for it crashing, my first guess would be that maybe you forgot to initialize the library at the start of your program? It's an easy thing to forget when you're concentrating on everything else, and that's the only reason I've ever had it crash when loading anything.

8

Scripting and Reverse Engineering / Need help with C file streams

« on: 2005-02-13 19:22:18 »

DevIL has worked as a pretty good image library for me, and I've used it to load from BLOBs in memory without having to have a separate file on disk. On the other hand, I suppose it's been a while since the last release. It does work with all of those file types you listed, however.

9

Scripting and Reverse Engineering / Need help with C file streams

« on: 2005-02-13 04:37:30 »

I would suggest using another library, then. I'm sure there are plenty of free ones out there. Any other solution is most likely going to be a hack; FILE*s are supposed to be an opaque type (that is, you're never supposed to access any of their fields directly, because they can be completely different on different platforms) and thus you can't really make any custom ones without digging into undocumented and totally unportable stuff.

What platform are you trying to make this for, anyway?

10

Scripting and Reverse Engineering / Need help with C file streams

« on: 2005-02-09 03:08:57 »

If you want to generate a temporary filename, you're probably better off using tmpnam(). Can you make a FILE* without a temporary file? Other than with fdopen() and a socket or pipe, not really. If you're using Windows, the socket part won't work, but the pipe part should. Create a pipe with pipe() (or _pipe() for Windows) and then use fdopen() (_fdopen() for Windows) on the read file descriptor. Anything you write to the write file descriptor will then come out on the read end. This is not a great solution, but it's the only one I can think of off the top of my head that works.

If you have control over the function that needs to use this FILE*, I'd suggest abstracting the streams instead; you'll get a lot more flexibility that way.

11

Scripting and Reverse Engineering / Question about Xenogears CD File System

« on: 2005-01-19 05:46:49 »

Right, like PEC except that it works for disc accesses rather than memory, and it's focused more on figuring out file formats than cheating.

12

Scripting and Reverse Engineering / Question about Xenogears CD File System

« on: 2005-01-18 08:18:48 »

I'll have to look at my Xenogear CD's sometime to see what's going on with there FS.  Xenogears was finished after FF7 if I remember correctly. Both games were too long in developement and were axed to get them to market. The Xenogears team was also fired I believe because they took too long.  Now Xenosaga (which is by the way a really good game) is out and the second episode I hear is close to release.  Xenogears they cut 90% of the second half of the game out and replaced it with those REALLY REALLY long movies that didn't have much in them.

Ahhh I am too trivial .. bleah!

I'm new here (been lurking a while), but I suppose now's a good time to bring this up. I started on a CDR plug-in for the various Playstation emulators out there that sits between the emulator and another CDR plug-in and can log and modify the disc accesses that the emulator makes. It's not done yet, but it is at least somewhat usable. I wrote it to try and figure out what Vagrant Story was doing with its 3D models and other files, but that game doesn't do any special things with the ISO filesystem. However, in the process of writing the plug-in, I also knew that many Playstation games bypassed the ISO file system and made their own, so it can also handle raw disc accesses. Maybe you'd want to try it out?