it's a 3 step process (decode-edit-encode), versus a single solution (as with most editors)
Not really, you have to do the load-edit-save steps with all editors.
Btw. you could add a pagecontrol and let the user switch between GUI- and text-based editing. ;)
example
It's possible, though probably not just after a month.
Google wrote:
You may discontinue your use of Google services at any time. You agree that Google may at any time and for any reason, including a period of account inactivity, terminate your access to Google services, terminate the Terms of Service, or suspend or terminate your account.
But then again, is there free hosting that doesn't?
Can you open them in VirtualDubMod? You might need a codec pack or AviSynth for that.
You could then save the videos in a different format.
EDIT: Dunno though if these programs are available in Mac land. :/
I'll try to make an extra AVI that has this input display in it as some kind of overlay, hopefully in a slightly more readable format than that of snes9x's. :)
That would be great.
Maybe just squares for the "player x" rows, and a line of characters/symbols beneath it.
OK, let's talk movie file structure. How should the movie file be arranged?
Two paths to go: fixed offsets or variable-length blocks. Fixed offsets are easier for hex-editing, but not flexible.
I'd suggest that in any case the header has either a length field that describes its size, or a field that stores the offset of the input data.
zefiris wrote:
also if I remember right there's such thing as internal clock in ps, so you should set movie starting internal time and record it and always fix during playback as I am pretty sure that random number generator relies on it heavily...
Definitely.
zefiris wrote:
I think you should start with 4-byte header(PSX\$1A), then address of data start or header length and only then start data.
Why 4 bytes? It can be of any length, preferably the name of the movie file format.
zefiris wrote:
...and please, don't store numbers as strings
It doesn't really matter. ;)
Valarnin wrote:
I've tried these two functions. The first one doesn't load the data at all, and the second one crashes at the last line(because it's loading from file as string instead of long).
Use fopen(moviefile, "rb") for binary mode. (Not related to the crash.)
You shouldn't need any calls to fseek.
Valarnin wrote:
If anyone can find the function to read hex from a file, that would be great.
Don't look for built-in mega-functions. ;) Read the raw data and convert it internally with library functions. You could write your own functions though that do the converting.
Valarnin wrote:
This struct looks promising for recording and playing...
typedef struct
{
// controler type - fill it withe predefined values above
unsigned char controllerType;
// status of buttons - every controller fills this field
unsigned short buttonStatus;
// for analog pad fill those next 4 bytes
// values are analog in range 0-255 where 128 is center position
unsigned char rightJoyX, rightJoyY, leftJoyX, leftJoyY;
// for mouse fill those next 2 bytes
// values are in range -128 - 127
unsigned char moveX, moveY;
unsigned char reserved[91];
} PadDataS;
How about this?
typedef struct tPadData {
uint32_t ControllerType; // controler type - fill it withe predefined values above
uint32_t ButtonStatus; // status of buttons - every controller fills this field
uint32_t JoyL_X, JoyL_Y; // analog values of 0 to 255, 128 = center
uint32_t JoyR_X, JoyR_Y;
int32_t MouseMove_X; // values = -128 to 127
int32_t MouseMove_Y;
uint8_t reserved[91];
};
tPadData PadData
I also suggest using structs for Joystick L and R, and for the mouse.
It's a video. I want to watch it, not read about it. Seriously, it completely ruins the mood when you're not able to see what's going on. I don't know the game well enough to know every single attack animation/piece of equipment/item by heart. It's like watching a movie with subtitles, it's just so much more comfortable and makes watching the movie a lot more pleasant.
Well, that info could then be mentioned in the subtitles, right?
A TAS is supposed to show seemingly impossible maneuvers, right? Hard mode would serve that goal.
So, if you feel able to tackle hard mode after completing easy mode, go for it! ;)
I found most of my movies on YouTube some time ago, and it was Taipon who had uploaded them. I didn't really mind, he did mention all the necessary stuff in the comments, though he didn't ask me about permission before uploading them...
Really, this "permission to publish" thing is quite ridiculous, imo. You made it public. That's the point where you lose some amount of control. And I can't see what's wrong with that. Properly credited material sends the audience back to the creator, so that they can check if newer material is available.
Of course labelling stuff as your own when you didn't create it is wrong, or not provinding the necessary info.
Randil wrote:
The thing with sites like Youtube and Googlevideos is that if it doesn't say in the title who made the movie, people will usually think it's the one who uploaded it who made it, without even looking at the comments. Someone made a comment like "wow, nice movie you've made taipon!", which made me a little angry.
People make that all the time. :/ Well, the idiots are everywhere.
Law of the Mexican Mouse: Players can turn around in a fraction of a second, regardless of the weapons they're holding or the amount of equipment they're carrying.
Law of Perpetual Motion: No matter how long you've been travelling through the levels, you'll always be able to run at constant high speed without the need for pause.
Law of Personal Thermodynamics: Somehow, the thermal energy of this constant movement is stored somewhere and released when necessary. Icy water, chilly snow fields and cold weather have no effect, which is especially beneficial to the female protagonists.
gack... you'd have to build an emulator, that emulated an entire PC. The savestates would be enormous!
DOSBox, Bochs, VMWare, Virtual PC etc.
If the game uses only DOS real-mode and no XMS/XMS memory, a savestate would be 1 MB plus the hardware status.
With XMS/EMS it would be 16 MB max., afaik.
