Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
If you want to add a RAM search to Gens/win32, it shouldn't be too hard. I've already got one in my Linux version. If you know a little win32 GUI programming you can probably use my code as a basis for what needs to happen. If you do this, make sure to coordinate with Upthorn, who seems to be the current Gens/win32 coder.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
This isn't dead, although I've been offline for the past couple weeks. I've tried to port upthorn's SegaCD changes, but they cause a segfault with SDL when playing SonicCD, which means there'll probably be lots of debugging to figure out what's broken. I'm also working on a few other Gens-related things, which will eventually include upthorn's other changes, where relevant.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
For the earlier levels, did you test whether it'd be possible to save a few frames by taking some damage as you dealt the bosses their last hit? It looked like you might be able to skip some of the time from your remaining hp being added to your score.
Other than that, I enjoyed the tas and the game. It has enough variety not to get too monotonous, and you clearly put a good effort into it.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I'm slowly progressing through The Silmarillion. I don't think it would be special if you didn't like LotR books, but if you do it adds a good deal of background information. It also has an index of all the names, so when you lose track you can easily figure out who's who.
The whole Hitchhiker's Guide series is available for free here. I don't know if it's legal, but the link has been up for at least a year. The text shas some signs of OCR errors, though.
Sherlock Holmes is in the public domain. There are also all sorts of other public domain books available from Project Gutenburg. Their top 100 lists are a good place to start.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
This and Gimmick are probably my two favorite NES games. I enjoyed watching the WIPs posted, and I enjoyed your version even more. I'm glad to be the first one to give this a 'yes'.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
After reading up some on byte alignment, it seems to me like the spec should be much more careful about alignemt or shouldn't take it into consideration at all.
I also don't understand the purpose of the byte alignment flag in the frame chunk. There are no guarantees about how chunks will be aligned, so it seems pointless to align the data within a chunk. I understand the spec as saying that each frame will have a variable length (but constant within a given movie) and will need to be read bytewise anyway.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The text format should be well-defined, but it may be easier to come up with something after implementing the current proposal.
As is, there's a minor question about internal BIOS names and some ambiguity about how frames are stored, but it looks like it's almost ready for implementation.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I was thinking that the text format would be a direct uuencoding (binary -> non-whitespace ASCII) of everything except frame data and the movie crc. The frame data would be translated to something like upthorn's suggestion or gmv2txt 's output, and the crc would be left out completely until the file movie was saved as a binary GM2.
This would make it relatively easy to write the code to load the movie and would allow for easy manual and automated hexediting.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
@Nitsuja:
I like the idea of a unique identifier to link movies and states. By date do you mean epoch seconds?
@Truncated:
Just for implementation's sake, I'd like to see no compression at all in the format, other than the requirement that Gens speak zip. It's true that there's not much space lost in compressing an already-compressed string, but there's no reason to add the extra complexity to the implementation.
I like the changes, except that the SMS stuff seems premature. I prefer that we make the format extensible enough to allow SMS compatibility, but don't actually do anything until a usable emulator is on the horizon.
State names are a good idea, but sorting by frame can easily be done internally by Gens at runtime.
I see no point in using a multitap when Gens already supports 8 controllers as is. I like less complexity.
I agree that some chunks need to be merged. There are definitely too many small chunks with similar or related data. I'm going to go on a little merging spree.
@upthorn:
I can't tell if the suggestion of a unified format was sarcastic or not, but I knew someone was going to say it eventually. It sounds like a good topic for debate. There's no reason not to make this extensible enough that new emulators can use it, but the formats used by most other rerecording emulators are adequate for their purpose.
Edit: I've got some chunks merged, although the new game requirements chunk looks intimidating. Other than the psychological effect, I don't think this is a bad thing.
I'd also like some more discussion about the text-based format, especially the advantages of the binary format over it.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Let's remember that not everyone uses windows. ;)
Somehow I missed that Gens can read zipped ROMs directly. I can't say that zip is my favorite compression method, but since the code is already there and since Bisqwit's submission system accepts zip files, it'd be best to eliminate all compression from the format and make Gens able to directly create zipped movies. This would solve a couple of issues.
@Nitsuja:
Peripherals? I can see how it already fits in, but it's worth explaining.
Feel free to fix this. My brainpower seems to be waning (and I still have to go to work).
The checksum should be optional, off when the movie frame data is uncompressed, otherwise it makes the format very hex-edit-unfriendly to need to manually calculate a checksum with every edit to avoid an error message.
If the text dump (which Gens could load/save directly) doesn't contain a checksum and is used as the only editable format, this won't be a problem. As it is now, even storing the length of a chunk makes manual hexediting trickier (though not unmanageably so). Assuming that Gens can natively read and write a nice text format, is there any reason the binary format would need to be hexedit-friendly?
Recording information...
I can't believe I forgot that.
Just for clarification, recorded frames is a rough indicator of how many frames the person recording the movie saw, vs. how many are in the actual movie?
I'm tempted to merge some of these small chunks into something like a "Movie Information" chunk just to keep the implementation's code size a little more reasonable.
I think this [sound rate] should always be 44100 for movies, eliminating the need to store its option here. 22050 can be used to produce a shorter movie in some cases, so leaving it in the format could be a liability, and 22050 sound quality can't be restored to 44100.
You're right. I was thinking that some current movies might need this setting, but we won't need to convert them if we keep the GMV code. If this is constant across all GM2 movies, there won't be a problem.
The same logic applies to the perfect synchro option.
sound options
I know some of these can cause desyncs. If you know for certain that some of the will never, feel free to take them out. I prefer to err on the side of caution since I don't fully understand how they all work.
Would not external CRC be more reliable?
If by "external" you mean "calculated," yes.
200-byte ROM filename (not including path) (null-terminated utf-8)
I'm hesitant to use the ROM filename for anything. It's usually reliable, but it seems more effective to rely on the ROM itself, which is harder to change. Storing it isn't a bad idea, since it provides a reasonably good idea of how the movie was made, but a name mismatch shouldn't generate any sort of warning, assuming that ROM checksums match.
Edit: I also fail to see the purpose of a unique identifier. What would this do that the movie CRC wouldn't?
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I'm responding here because the forums are better at facilitating discussion.
Truncated wrote:
This (u/d l/r enable) is only important while recording, not while replaying. Gens should not filter the recorded button presses so it is not necessary to save this variable.
I thought it would be a convenience to movie makers. Gens would only filter actual button presses, so the setting would be preserved across recording sessions. As long as Gens spits out a message when settings between its config file and the movie file are different, I think this will be useful without causing extra problems.
Truncated wrote:
<reset chunk stuff>
Good idea.
Truncated wrote:
Isn't it confusing, if editing with a hex-editor and also while writing the code, that the first byte changes meaning depending on controller type? Second byte could be x,y,z,mode instead.
Yes, it is. That was a strange decision on my part and I like your idea better.
Truncated wrote:
Pick a locale-independent character encoding system for these. Unicode?
I should probably do that. UTF-16 it is!
Truncated wrote:
Number of states (in state chunk)? Addresses to them, or traverse the list to find them?
A simpler solution would be to have the frame stored with the other two values. That way, it would be easy for Gens to make an internal sorted linked list of states when the loading the file, and it wouldn't have to decompress anything until they were needed. Having a more complex data structure in the file isn't a good idea because we want to read/write the file as little as possible, and we won't know in advance which states a viewer will want.
Truncated wrote:
* Should (upper right corner of first letter) be upper left?
* Number of strings?
Yes. I thought about that before I wrote it, but clearly not enough.
I can't think of any case when the string count would be useful. Care to elaborate?
Truncated wrote:
Things i can't find:
* Start from SRAM/savestate/reset (and which chuch would this go in?)
I made a new chunk for it. It also includes the state/srm, if needed.
Thanks for taking the time to critique this.
Jyzero:
I added a version chunk. I don't know if it will be useful for anything other than information, but it's there. I only added a string because it will be difficult to compare version across forks.
I reworked the config chunk to contain the sound chip information. Thanks for pointing that out. I've run into games that are picky about this too.
I also fixed the 3-player info.
Whether this is used for the SMS depends on who implements SMS rerecording. It's there if they want it.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The goals of space-efficiency and hexeditability don't have to conflict. They just can't be met in the same file. If Gens can natively save and load compressed, uncompressed and plaintext movies, I think everyone will be happy.
The text version of the format would take care of hexediting. All you'd need to do is set a "save as text" option in Gens and you'd be able to use Notepad for all your hexediting needs without any conversion overhead.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
This game is also known as Serei Densetsu Lickle and has a couple very good movies, although they haven't been submitted by the original authors. To be published, you'll have to improve on them, since it isn't acceptable to publish a known-impovable movie. This one is the better of the two if I remember correctly. I don't think it will be easy to beat. There's some discussion of it here and a search will show you two old submissions of this game.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Jyzero, I think your idea is has some potential if it's pared down a little. The first thing is that I don't see any reason for adding any metadata to modules other than size and checksum. My thinking is that requirements won't help Gens figure out what a module does if it doesn't know, and won't be necessary if it already knows. If a newer version of a module is likely (e.g. mouse support), the module can be renamed or can include version info in its data.
It seems like a good idea to include both per-file and per-module checksums. If the file checksum is good, we'd know that all the modules are good and could skip checking them. If it's not, we'd be able to figure out which modules were broken, either ignoring their data or failing gracefully.
Edit: In order to make the format both self-verifying and hexedit friendly, it will need to be possible to bypass checksumming and length checking and to store the frame data at the end, to be able to figure out when the data ends.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I'm still interested in this, but I agree that it's not publishable in its current state. It's great as a proof of concept and I hope you'll redo it once you're done.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The favored codec is H264. Someone else will have to answer on how to use it effectively.
Since I usually only want animated GIFs of short segments, I just take a bunch of screenshots and crop/animate them with ImageMagick convert.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
This is very entertaining so far. Please continue.
I wonder if you could manipulate enemies to throw their shuriken more advantageously on the first level. If you're stuck waiting, it'd be faster to duck under a tight cluster of shuriken than to have them more spread out.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
In the interests of lazieness, I'd like to point out that this will be a lot of work to replace something that's already good enough. The current GMV format won't win any awards, but it won't end up on The Daily WTF either. Perhaps the best way to overhaul this format is to consider everything from a user's perspective. A nice extensible module-based format may be the way to go, but we should think about how it will make recording and playing movies easier.
I'd like to see a new format and I can think of a few ways it could make life easier for everyone involved, but it takes a lot of energy to get started actually coding. There's no sense producing an unnecessarily complex specification that none of us will bother to implement.
