That's the exact same problem I have. As I stated before, I believe that the problem lies in movieDlg.c in the Play Movie code. DeHackEd should add a check to make sure the function runs correctly
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
I'm getting the exact same results. no button presses at all, I even tried to go crazy with it. I think there's something wrong with the begin playback function in movieDlg.c, DeHackEd. If it begins playback, shouldn't it lock input from the watcher? Because while trying to play a movie, it still accepts input from myself.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
No, I mean that I made my own puzzle using the game's built-in creator. Meaning I link the file, you download it and put it in Homemade folder, then you can load it in game.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
I think the most recent "version" put out was Contraptions for PC... runs fine on WinXP.
Mostly on-subject, anyone wanna try out a homemade I put together? If so, I'll post a link...
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Nononono, that struct is already in the emu. I mean I can get the button status and stuff with it. But anyways, progress is halted until I can find the function that gets button status from the plugin...
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
I don't think I can. The emulator emulates everything properly. There's only one function to read a file from a CD, and no real way to prepare a disk ahead of time without re-writing the entire disk read functions. What will happen is when recording, when you change disks with the emu, it will write a flag to the movie file instead of input that frame. When the playback gets to that point, it will pause the emu and ask for the next disk.
The info window is ever changing. The "Movie You" thing wasn't even there until I wanted to take the screenshot. I'm working more on the code than the looks right now. On that note, I'm looking into the actual recording aspect now. After I get it to record and replay some input, I'll compile the exe and post a link to the exe and source.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
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;
Also, here's what it looks like so far.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
If my assessment of the source code is right, the emulator just dumps the raw data on the plugin, and leaves the decoding and rendering of the data to it. Graphics are one-way, while sound, pad, CD, and BIOS are all two-way exchanges. The point is though, that most options in the plugins themselves don't effect the emulation process. Only the Special Game Fixes effect it, the rest just determine how the decoded data is sent to the computer's hardware(IE DirectX or OpenGL, resolution, or in the case of sound, output quality). Any options in the plugin that effect emulation are for that plugin only, and not in all plugins. Besides this, there is no way to get plugin settings from within the emulator. When the emulator gets settings, it consults the DLL on-the-fly to open it's configure screen. The configure screen isn't in the emulator, it's in the DLL.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Right now, I'm not really concerned with that. I can debug things like that later and try to track down errors. The entire point of this is to impliment recording that works.
On that note, I'm looking into how the emulator handles input, so I can see how to properly record it. I still can't read the long value properly, because fgets is for strings and doesn't return hex or anything else, which I could use. If anyone can find the function to read hex from a file, that would be great.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Hmm, is it possible for you to make movie file to remember what plugin's config are?
I can't see the point, the GFX plugin settings only really determine how it looks, not how it emulates. Besides that, the config is loaded by the plugin itself and not the emulator, so it's out of my reach.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Doing it that way is considered bad form. sizeof(long)==4 on 32 bit systems, sizeof(long)==8 on 64 bit systems. If you want to call fread() to bulk read the structure, here's what you should do.
First, use sizeof(MovieHeader) rather than assuming the size of the structure. Second, if you're using GCC to compile this, make sure you use __attribute__ ((packed)) to prevent dead space from being added. Finally, use the various uint32_t style fields to ensure fields remain the same size.
Or even better, read fields individually and use ntohs and ntohl class functions to regulate byte ordering. Not all hardware orders bytes the same way. This is the little/big endian system problem. Pentium and compatible hardware are little endian, and that's the major platform, but that might not be true for everybody.
I only understood about 50% of what you just said O.o
Using the following sample file and file read code I can get what's in the screenshot.
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).
struct MovieHeader {
char Sig[4];
char Ver[4];
long InputCount[4];
long FrameCount[4];
char DiskID[14];
long Controllers[1];
long Disks[1];
char RunName[16];
char RunnerName[16];
char GfxPlugin[32];
char SndPlugin[32];
char CDPlugin[32];
char BIOS[32];
char Pad1Plugin[32];
char Pad2Plugin[32];
char RunComments[256];
char ReservedSpace[512];
};
You know "long" is 4 bytes (8 on x86_64). Why are you using an array of size 4 for these? Do you need the frame counter to have a range from 0 to 340282366920938463463374607431768211456?
So should I change the longs to ints or drop the [4]? Do I need both input count and frame count?
-----EDIT-----
Like this?
struct MovieHeader {
char Sig[4];
char Ver[4];
long InputCount[4];
long FrameCount[4];
char DiskID[14];
long Controllers[1];
long Disks[1];
char RunName[16];
char RunnerName[16];
char GfxPlugin[32];
char SndPlugin[32];
char CDPlugin[32];
char BIOS[32];
char Pad1Plugin[32];
char Pad2Plugin[32];
char RunComments[256];
char ReservedSpace[512];
};
-----EDIT-----
Forgot the rest of the post ;)
The header totals 1024 Bytes. The movie file's input should start immediatly afterward for this and all versions until recording from a savestate is implimented.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
OK, I understand the sig thing now, and can define a structure for the header. Is this the function you were talking about? I also see I'm going to have to take note of the plugins and stuff. If I can find a way to md5sum the PSX executable from within the code, I could also use that along with CDID and omit the orig file name. The MD5sum would be of the playstation executable file on the disk's image, and not the image itself, once again getting around the different format/container problem.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Site rules state that parsing the full file must not be required to determine the length of the movie. It is acceptable to have the file's size as part of the calculation (FMV movies are filesize - 144 bytes, for example).
One of the variables(RunLength[12]) is supposed to be the Run's length in frames. The focus right now is getting it to read from/write to a file.
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.
Don't forget to include:
number of rerecords
length of movie in inputs
length of movie in time
version of emulator (You'll need it for backwards compatibility)
ALL settings that may affect playback
and FREE SPACE to add something later (like things from previous point that you might have forgotten)=)
...and please, don't store numbers as strings, or I'll kill you :E sorry )
I'm not quite sure what you mean by the 4-byte header.
The header length with information about the run was to be a set size(512 bytes). Input was to start after that. I'm not familiar enough with the emulator's code yet to do much. Just code that read header info from the file and assigned it to variables like I posted would be great. The code to create the files would be even better. This is the first time I've had to read and write from files like this, so I'm still a bit out of my depth. I originally created the header file from scratch using a hex editor. I don't have code to create the file when it isn't present.
Phil wrote:
Well, I remember some database to help identify PS games. If it's SLUS-555 for example, then it tells you the full name.
The S***-##### CDID is included in the header. The Original file name was included for convenience. The CD-ID is stored in the game's exe file on the disk/image. This will allow us to tell different versions. Googling for a second brought up this big list of discs and their IDs. The first part(SLES/SLUS/SCES/whatever) show the region of the game, and the second part shows the game ID.[/url]
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
Really all I'm working on now is recording itself. I figure 512 bytes should be good for the header, considering it's just some simple text and stuff. I have no experience actually writing to file though. I could make a file manually in a hex editor, I could parse it with PHP and handle it properly, but I've never had to do this in C++ before. Anyone here have some experience with this that wants to contribute some code? A simple function to create the header of the movie file would be great.
-----EDIT-----
Here's a sample header file. The actual file should be padded with 00's instead of 2D's(-). I padded it with 2D's to show exactly how long each part should be.
-----EDIT2-----
OK, I've coded a function to read the header of the file. I also modified the code above to reflect the changed test movie file. Any input on the read code?
If I let the already-coded plugins system handle everything else and just take over input while it's playing back... I could include the SLES/SLUS/whatever ID in the movie file's header. This will allow different image files to work, because after all the data is the same, the container just changes.
Maybe the header should contain controller amount, frames recorded, and other things needed. The amount of controllers would tell the emu how to process the movie file. My question is how should I record that input to the file?
For multi-disk movies, the movie file will have a flag that tells the emulator to prompt for the next disk.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
I'm currently looking at the source code for PCSX and wondering how to accomplish this. If someone could point me to source code where this has already been done on another emulator, preferrably with comments for each section edited/added, that would help immsensely. Currently, 70% of my programming experience lies in web developement. PHP, MySQL, HTML, CSS, and some javascript are what I'm most well versed in. Besides these, I have some previous experience in C++(mostly editing code, I haven't programmed anything myself yet), so I can make some sense of what I'm seeing.
I have MS Visual Studio 2003, so I have a capable editor/compiler to work with. My current goal is simple: Add a way to record button presses and automatically play them back. This means no savestates will be incorporated yet or anything of the sort. I am only focused on recording the input and playing it back, and savestates/other things can come later. After implementing recording/playback, I will ensure that playback doesn't desync because of loading times or other things that may vary wildly from user to user.
After implementing the above, I will work on savestates and other features. The more help I get with this, the faster it will get done.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
While I'm not too good with programming (I can do PHP/MySQL really easily but I'm not very good with C/C#/C++ yet) couldn't someone add re-recording to PCSX? They're open source and according to the latest post on their website...
Wednesday, September 17, 2003
Pcsx news... - posted by: linuzappz
hi everyone, long time since i posted anything, also i haven't coded for pcsx in some months, i don't have the time anymore, due to pcsx2, work, life and so on... i'll still be around, so if somebody wants to continue our work in pcsx you can drop me a mail (linuzappz@hotmail.com) or contact me on #pcsx2 (#Efnet), you can grab the latest beta sources at the downloads page, but don't ask what's new in there, i don't remember anymore :P.
if you're worrying if i will still continue on pcsx2, yes i will, so relax :).
i also want to thank everyone who helped us in all these years, i would list all you, but as the list would be too long and i'm sure i'll forget some of you i rather not :).
well, this is it so far, hope you all liked my work on pcsx :D
logoff linuzappz
As I said above, I'm not too good with programming yet but couldn't someone who has experience adding these features put them into PCSX?
--------EDIT-----------
Came back 12 hours later to check for a reply and noticed the link to PCSX website didn't go through properly.
BoltR : I'm not bothering with no fairy demons
BoltR : I'm going right for time itself
BoltR : Right in the eye
