Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I wish to see it.
I don't care whether it's NES or SNES. There are advantages to both.
The SNES version might allow completing all levels at once,
but the NES version might have more glitches to abuse.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I have updated the game again...
It should now work a little smoother. There was some lag in responsiveness since kicks were implemented.
It should also now detect a much wider range of blunders than before.
Timings or such were not changed.
Edit: Blunder "R" timing was slightly shortened.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
FODA wrote:
but h264 is obscure and isn't lossless
x264 has a lossless mode too. (Todays I always record the movies with it, and then later re-encode to a lossy format.)
I'm not sure if it's in the h264 standard though.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
samurai goroh wrote:
Why can't I save my record on level 7-3, I get the next message:
Record not saved! Timer was 0.
You made it with a version that was no longer supported by the serverside submission receiver.
If you still have it open, try again... I temporarily enabled the old timer code.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
KaitouKid wrote:
1: Phil's run rejected, Sleepz does a jig.
2: Phil's run accepted, Sleepz walks off a la oldschool TV The Incredible Hulk, complete with sad travelling music.
3: Phil's run accepted w/nod toward Sleepz, idiocy ended.
4: Phil's run rejected, Sleepz's removed, Bis puts up No SMB2 For You sign on main page, gives both gamers pink slips.
Thanks for the constructive post :)
Now, we just need to figure out whether this movie actually is better than the previous or not - and I have no word to that before I actually watch it.
As should be clear to everyone already, time is not the only thing that can be measured in a movie to see which one is better.
The completion time is only a hint for lazy judges.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
If all we cared about was the record times, my site could be accomplished without single image or AVI file for download.
All we would need is numbers, and the FCM files for proof.
http://tasvideos.org/Guidelines.html
The reason I created the site in the first place was to provide a place for downloading entertaining game videos. Later, I specialized it for tool-assisted movies.
But seriously, this is off-topic.
The issue at hand is not whether this movie is faster than it is entertaining.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
KaitouKid wrote:
The goal of this site, unless Bis changed it when I wasn't looking, was to present the most flawless run of Game X possible while making it as entertaining as you can. If doesn't matter how many seconds or frames New Version is in comparison to Last Version - if it beats the previous run, it should replace the previous run unless there are glaring flaws in it somewhere.
I have also a few times expressed my support for friendly competition and cooperation.
Friendly competition is that you don't suddenly come out from darkness and steal the honor of someone else's hard work by switching the place of a comma or some other such minor a change.
You may suddenly come out from darkness if you beat it with a significant contribution, or if you have discussed your idea beforehand with the previous work owner.
This isn't like a 100m sprint - in sprint, you compete on your own power. You can't beat someone's record sprint time by watching him run and then fixing a 10ms error he did.
In TAS movies, you compete with intellect, and you can always learn from other players' movies or even reproduce them entirely.
I haven't watched this submission yet, so I refrain from voting. In any case, I wouldn't hurry publishing this movie.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Bisqwit wrote:
So why is BoltR's timing different?
Apparently because there's a lag of 1 frame in checking whether the game is completed - a lag which BisqBot doesn't have!
I think I have to fix it!
Allright, this problem has been fixed, and all human records have been updated to remove this 1 frame.
Correction:
> Left, left, left, up, up, turn left, grab, push,
> down, left, turn up, grab, push,
> right, up, grab, push,
> left, up, turn left, grab, push,
> down, right, grab, push,
> up, right, turn down, grab, push,
> left, down, grab, push,
> right, down, turn left, grab, push.
You have 19 walks, 8 grabs, 8 pushes and 5 facing changes.
Walk is 0.2 seconds (6 frames), grab is 0.05 seconds (2 frames), push is 0.4 seconds (12 frames), facing change is 1 frame.
Therefore, 19*6+8*2+8*12+5*1 frames, that is 231 frames.
The game is rendered at 30 fps, therefore your time is 7.70 seconds - which is BisqBot's time.
[Edit]
So why is BoltR's timing different?
Apparently because there's a lag of 1 frame in checking whether the game is completed - a lag which BisqBot doesn't have!
I think I have to fix it!
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Nice to hear you got it working!
Thanks, but nope, I ripped all levels and graphics from the DOS Peterbox game, which itself seems to rip many levels from the original Sokoban game.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Vatchern wrote:
It can be done without rushjet as well. Sleepz mentioned it ealier on in this thread. i tried it out and only got it working once. is it really faster? or does shooting it cause lag?
It must be faster, because when you shoot, you can't slide during the jump.
With Finalfighter's method, you're can be mostly sliding.
Also, the explosions of the snake dying cause lag.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Truncated wrote:
I remember one of my programming teachers telling us about writing a Sokoban solver. And also that it ran out of diskspace while solving a particularly large puzzle, even though it only followed legal branches and had lots of methods for realizing when a move made completion impossible and stopping. Is yours better? Optimization is a favourite topic of mine.
I have applied lots of optimizations to my puzzle solver, and so far the bottleneck is the memory amount. Generally speaking, if the solving process takes longer than 4 minutes, the program will run out of memory and it'll only do 2 minutes worth of work in the next 10 hours when the OS is busy swapping the program's data in/out.
In terms of different states, the crawling speed is reached approximately when the number of simultaneously active states is approaching ~1.2M and number of analyzed positions is around ~9000k. (*)
The complexity of the program is defined by the maximum number of different possible positions the blocks may be on the level.
For a level with 7 blocks and little room of maneuvering, the solving is rather straightforward and takes only a few seconds, but for a level with 14 blocks such as 2-5, 1024 MB of RAM is too little.
The "BisqBot's corner" page in the game lists all levels that could be solved with the program with my current hardware.
Levels that are not listed there, usually contain too many movable blocks.
I believe 4-1 would be the next one to be solved, if I could compress the program's memory usage even further.
samurai goroh wrote:
Hi there Bisqwit, there are some levels in which the record time is just +0.03 secs from the theorical record, why does it has that difference? Is it just time presition?
0.03 seconds (1 frame) is all it takes for Peter to change his facing once.
The optimal solution apparently changes the facing one time less than the most accomplished player.
With mouse navigation, you can avoid most of the facing delays.
samurai goroh wrote:
Also, why not releasing those videos? The strat should be the same, wouln't?
As explained on the "BisqBot's corner" page, the videos are kept unreleased in order to not spoil the sport.
My original plan was to reveal the movies when a record has been made that runs the same route as BisqBot, but I haven't implemented this yet (and often, some alternative routes are equally fast).
samurai goroh wrote:
PS: Can you do something about the blunder repetition, it's annoying & you lose like 3 secs. I liked more when the text just appeared.
It's deliberately annoying. In the first versions, you could abort the animation by undoing, but currently it's not possible to do that. I might re-enable it later.
samurai goroh wrote:
Also, it doesn't reconize a blunder if you kick the box...
It does, but because of the graphical challenge to represent the blunder when the box moves a long way, it's not displayed.
------
(*) Technical stuff:
Analyzed positions are stored in a hash map, where the key is a N-byte array (state of level; N=number of blocks+1) and the value is an unsigned integer (best time so far to reach this state, or 0 if the state is not worth revisiting).
In C++, it's defined as __gnu_cxx::hash_map<CompressedLevelState,unsigned>.
When forming the CompressedLevelState, the array is sorted. The order of the blocks in the level does not matter.
Active states are stored in a hash map, where the key the level state (contains LevelWidth*LevelHeight*3 bits plus some caching variables) and the value is the history of moves to reach that position.
In C++, it's defined as __gnu_cxx::hash_map<LevelState,History>.
The history consists of an unsigned value denoting the cost in time to reach that situation, and an array of moves along with some caching variables.
New move candidates are found by
- trying to kick/push to every direction where applicable.
- trying to walk into every possible reachable location that is beside some block (using a Djikstra algorithm).
If the previous move was a "walk" move, only "kick/push" moves will be tried. If the "kick/push" move appears to be a blunder, it will be discarded.
After the forming of each candidate move, the resulting state of the level is examined against the Analyzed positions map:
- if the state has been marked dead, the move will be discarded.
- if the state has been reached before with smaller cost, the move will be discarded.
Otherwise, the cost will be saved in the Analyzed positions map and the move will be saved as a new active state for the next pass.
The hash of the level state is formed by first forming a CompressedLevelState (the N byte array where N = blocks+1) and then adding/xorring together the bytes in the array. The hash is only needed for speed. The "+1" in the "N" is there for the position of the player.
The moves in the history buffer are stored in a specially created linked list: when the list is copied, nothing is actually copied - instead a new branch is started. Therefore all the different states actually form a tree where every leaf leads to the single root.
The internal representation of the tree is a linked list with only a "prev" node, no "next" node. There is never need to locate sibling nodes. Reference-counting is applied to prevent leaking memory.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Less Ashamed Of Self wrote:
Is there an easy way/method of cracking open the code on these video files so as to change something somewhere in the middle without messing up everything? Like delete a frame here, extend a frame there... make sure everything lines up? Can I just pop this baby open in a text file easy enough? Problem solved?
You can do that kind of changes in a hex editor.
For this purpose, this guide was made by Blitzag: http://tasvideos.org/HexEditing.html
(I take no responsibility for the accuracy of that guide.)
Whatever method you use, you must know that all you edit is merely the recording of which buttons are pressed at which times. Deleting a frame from some point means that all the consequent button press data will happen 1 frame earlier. If the game isn't prepared for that, your movie will desync.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
AngerFist wrote:
I could almost promise that we would have finished this game within 1-2 months. Please consider :D
And I could almost promise that by that time, Finalfighter would come up with new findings that would make the movie obsolete before it's even completed :P
