Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I didn't watch more than the first 4 or so levels. It could be perfect, but there aren't very many interesting things happening. I'm not voting since I didn't finish the movie, but this is a good example of a game to avoid.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Avast! Since it seems I be the only one of ye lubbers what says this movie should be sunk t' Davy Jones' locker, mayhaps I've got me a bit of of explainin' t' do.
Ye see, there be little that may interest one of them that's never seen this 'ere game before. To them (and I be in this group too, yarr) the game be lookin' like a handful of well-planned shots with some mildly interesting bonus stages in between 'em. Them enemies may be more fierce than the dread pirate Roberts, but I ain't seen none of it, what makes it look more like Duck Hunt. Ye may be smart as paint t' find such a quick dispatch fer ye enemies, but 'tain't much in 't worth watchin' fer lubbers such as m'self.
I thinks this be an example of them games what should nay be tas'd.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I can't give it more than a "meh". This just isn't that great of a game to tas. It was fun to watch and I don't consider the time spent watching it wasted, but there isn't that much you can do in a game like this.
Thanks anyway.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The first point is clear and looks like a good starting place for discussion.
The second point I don't get. Do you mind elaborating. I'm viewing the file as already having been read into memory, so I don't see what difference it makes one way or another.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Thanks for raising the (already high) standards around here. I watched Quietust's run right before this one, and I think you found every improvement I suspected might exist (plus a dozen others). Excellent work.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I appreciate that Nach is encoding and seeding. I just suspected that even at his 4KB/s rate, the initial upload shouldn't have taken as long as it did, and that perhaps an sub-optimal Bittorrent configuration was to blame.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Unless it's the expected behavior for a 160M file to take more than 20 hours to download with 100+ peers, the bittorrent tracker seems like it could use a little tuning.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Sounds like you may be using gcc-3.3 or earlier, which doesn't know about -Wextra. I only have it in there to make bugs a little easier to find, so you can safely edit Makefile and take it out.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
Compression is certainly possible to implement, but it's not crucial. It can be added later easily enough.
upthorn, you seemed to say that a GM2 implementation should only parse the first button list for a given controller, but you edited the wiki to say the last. Since the first is more consistent with your post, I changed the wiki.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
upthorn wrote:
Notepad can't load files larger than a few hundred k. And when dealing with filesizes in MB or larger, most text editors (on windows at least), become sluggish with loading, finding, or saving.
Also, I strongly suspect that base64 deencoding a 4 megabyte string will be somewhat sluggish.
In my XP virtual machine, both Notepad and Wordpad are quite usable for a 14M file. I wouldn't call them optimal, but they get the job done.
Also, b64 encoding/decoding is pretty fast. It took my machine (1.6 gHz Core Duo) about .39s to decode 14M of base64-encoded random data. Either way, I strongly prefer to keep everything self-contained in a single file.
upth wrote:
The other reason I prefer it this way is because it's faster to ignore redundant data.
In the implementation that only parses one segment per controller per frame, you can set a boolean flag for each controller, which causes it to skip to the next loop iteration if true.
This is probably true. Feel free to nuke your comment and add it to the proposed spec.
If they aren't case insensitive they ought to be capitals.
and case insensitivity is easily handled with
switch (ChrToParse)
{
Case 'U':
case 'u':
SetButton(Up);
break;
}
I was thinking of another way of implementing it, but it could also easily be adapted. Feel free to add this to the GM2 page too.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
in the wiki upthorn wrote:
There's an issue with this that needs to be addressed. If we're starting from a savestate, the start chunk alone could be larger than 4 megabytes. Not very helpful for our users who will need to go past this point to get to the frame data. For GM2text, we should probably save applicable srm and gst data into separate files.
Other chunks can become large, but manually scrolling to a certain frame is inefficient, especially when even Notepad has a usable search feature. Users will only need to search for "x:" to find frame x, since ':' isn't part of the base64 character set. Saving the file may take a second or two, but that's not a major inconvenience.
in the wiki upthorn also wrote:
What happens if it encounters the same controller number in multiple segments? I think that it should only pay attention to the last segment for each controller. EG: "testframe:1r,1lr,1lra,1ra,1rabc,1a" should produce the input "a" on controller 1. This would enable the user to test multiple sequences of input, and easily revert to prior versions if one version turns out slower.
I don't know how useful this would be. The way I'd implement it, your example frame would be equivalent to ":1rlacb". If you want to comment out a frame, you could just change the colon to a semicolon and ensure that the implementation silently ignores invalid frames.
upthorn the prolific wrote:
These [buttons] should probably be case insensitive. Also, the routine should be able to encounter the same button multiple times without barfing. (although I don't see how the routine would barf in that scenario unless it were specifically designed to)
I don't like case-insensitivity because it's an extra check on every button character in the frame chunk. If it becomes a problem then it's easy enough to implement, but I see it as unnecessary cruft until then.
I don't see how encountering the same button more than once in a frame could cause a problem either. ;)
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
As for Java vs. C++, it depends. C++ is excellent if you have enough experience with it not to get killed by the many, many gotchas, but Java is nice to cut your teeth on. I'd probably say C++, just not as a first language.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
nitsuja, that's how I've been thinking about it. A binary<->text conversion would only happen when loading a new movie or explicitly saving one as text.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I think I understand you better now, but I still have an issue with random seeks. If the frame size can only be dynamically determined, either a linear search from the beginning or something more complex will be necessary to find a given frame when playing/recording a movie from a saved state, which is a very common use case. The nice thing about having a constant-length frame is that finding a random frame takes one simple line of code with constant time.
Dynamically-determined frames would require more code with greater complexity, and I don't see any benefits to justify the change.
Take the following (unlikely but hopefully valid) example with several 3-button controllers. Each bold value starts a frame.
03 05 01 03 04 02 02 02 07 06 02 01
When searching for the beginning of an earlier frame, the code would need to either maintain a list of pointers to the start of every nth frame or be smart enough to search backwards, which would mean dealing with a significant amount of ambiguity. This is certainly possible, but is also a fertile source of bugs.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
A button configuration dialog is necessary. Some games act differently depending on which controllers are detected. It's not a good idea to depend on the user never accidentally pressing x, y, z or mode to determine a potentially important factor in gameplay. Additionally, Gens needs explicit controller configuration information in Controller_x_Type, so this would generally mean looking through the whole frame chunk to find that information for each controller.
This would also result in more complex frame chunk reading code. This is a bad thing because the frame count can realistically top 200K frames. The code for this chunk should be as highly optimized as possible.
Using odd controllers occasionally (e.g for Tails in Sonic 2) wouldn't hurt the compressed filesize much. I don't see uncompressed file size as a significant issue since it's intended only for local (i.e. user's hdd) storage.
I like your text frame chunk proposal. It will usually result in fewer characters which will make chunk processing faster. I think it also has better potential for optimized C code, which is important. I'll try implementing it and seeing how it fares agains my implementation of the current proposal.
BTW, please be sure to bring up any proposals for significant changes here for discussion before putting them on the wiki. The purpose of the wiki page is to record what's already been agreed on.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I posted a 3.9s improvement on the first race (same link as in the submission thread). I'm sure it's improvable, but hopefully it will demonstrate a more optimal technique.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
I'm curious why you didn't prejump. It also looked like there were several places in the first three levels where you could have glitched. I'm sure there's an explanation.
Glitching out of the boss fights was clever and bug abuse looked pretty thorough after the first boss.
Experienced Forum User, Published Author, Player
(80)
Joined: 3/11/2005
Posts: 352
Location: Oregon
The game is beautiful and more varied that any other Genesis game I've seen (though I'm no expert), but your tas didn't seem polished. The tire-bouncing fight may not be optimal, damage seemed random (or even lazy), star collection wasn't consistent and necessary waits didn't even try to be entertaining.
The first racing section is also improvable. By watching memory to try to keep my speed up, I got ~2.5s ahead of you by the time this movie (state) stops. That's just a quick demo, and I'm pretty sure it could be improved by slowing down for certain corners too.
I'm voting no, but don't get discouraged. This game will make a great tas. It just needs more effort.
