That IS the final version (v1.1). The fact that it is called "Super Demo World" has nothing to do with it being a demo. It is called that because the game is a working demo of what could be done with the author's program: Lunar Magic. The lag isn't fixable by making a better hack, the SNES is just not fast enough to handle that many sprites/animations at the same time. You never run into this problem in SMW because there aren't 15 Koopa Troopers and 45 breakable blocks on the same time at once. You cannot fault a game for pushing the system too far and creating lag, MANY other games do it.
Yes, this run does look well done from what i've seen. Unfortunately it desyncs for me at the beginning of the jail level, so I cannot be the one who publishes it.
Shouldn't you loop back now and do the rest of the desert levels before the pyramid? Doing the pyramid next means you need more moves extra to get back to the levels you have skipped.
In terms of overall movie length I would say ~60% done. In terms of workload, I think after I complete what i'm working on now, I would say it is ~90% done.
I disagree strongly. When you lose 3 seconds because of lag, assuming the viewer can see no obvious reason for the lag, such as 20 enemies on the screen, it's easy to ignore. There is no "mistake" to see. However, when you waste 5 frames to pick up a shell for no reason at all, people can see the pause, and will ask questions about it. When you paused to pick up the shell I instantly thought "Why does he need that?". When the time came when you used the shell to jump over the pit, when you clearly didn't need to I thought "So he wasted time to pick up a shell, for no reason?". Sure you killed a few koopas with it, but you could do the exact same with the spin jump. This 'mistake' stood out way more than the 'entertainment' gained by killing a few more koopas.
Here.
I was too lazy to put error checking into it, so entering letters where it expects numbers will cause bad things. So just don't be dumb. ;p
I juggled datatypes and it can now go higher than 10d6. I tested with 13d8 and it seemed to work fine. Not sure what it can go up to now. Though it does take a quite a while to calculate numbers that high.
Last night I wrote a program to do it in C++ which just used recursion to do it. However it has a fairly low limit to how many dice can be rolled because of the way I sum up the numbers. I beleive it only does up to 10d6 fine.
A few days ago I got bored and recorded a bit of this game. You can get what I accomplished [URL=http://nvdata.pilif.ch/SuperMonkeyBallJr(U).rar]here[/URL] . The levels should be perfect now, as I was alot more daring than yaqs (In most cases a few seconds faster). A few of the levels might be improvable by a fraction of a second, such as level 1-2 and 2-2 because I think that bumping the edges (You will see) hurt me more than it helped me.
I don't plan on ever finishing this. I have other runs to work on. Maybe someone will get inspired though.
You might find it easier to run Shadow of the Ninja (The U version) instead... what with having an extra 10fps. There is also a submission done for Shadow of Ninja which you could compare with.
Currently the page is automatically generated to say "Download AVI". It is not possible to change it through the edit page function. The ones which do say "Download MKV", Bisqwit has manually changed.
The major problem with a run such as this one is that it is really easy to reproduce without the use of savestates. You just need to try a few times. There is no 'wow' factor.
The third save is left over data from a different run of his through the game. It doesn't really have anything to do with the run.
It is suppose to go through the intro sequence.
People seemed to like the previous image so I have made a few more.
Holding jump (old image):
Holding jump while running full speed:
Pressing jump for 1 frame (minimum jump height):
Pressing jump for 1 frame while running full speed:
That should end the arguement.
However, just asking people is an extremely inefficient way of doing this. As if you want to emulate the movement as close as possible your going to need to get people to take make similar pictures for each length of a jump that the A button is held. Up until you come up with an acceleration algorithm which is close enough to correct.
It would be way WAY faster to just download the emulator and test for yourself. Getting it to work isn't very complicated, and i'm sure people would be willing to explain how.
Both, and that is with nearly perfect (it may be possible to get it one or two frames faster) bomb jumping.
I suppose it's time for me to stop being lazy, and give an update on the position of my run myself. I have a WIP which reaches Tourain, and as for the question of which is faster: Kraid or Ridley first. I beleive I have the answer. Upon reaching Tourian with my Kraid run I am 35 seconds ahead of my currently published run. Now, the Kraid run has a ton of tiny movement optimizations over the Ridley run, but I beleive they could really only speed up the old run by a MAXIMUM of 10 seconds.
This is not a final time however, I think I might be able to change my route a little and gain another 10-12 seconds ingame time. So i'll be looking at doing that over the next few days (or weeks).
Some people might like to know that leaving the room with grip and going to the left - like one would normally do - is faster than than backtracking and going to the right by about 150 frames.
Even though you caught me on IRC a while back, i'll post it here too. I still am working on this run, but I have been very busy lately, and haven't been working on it lately. The new version is 911 frames faster where the new and the old published routes divide, and ~160 faster than my last version at that point.
~685 that I remember (I have an old screenshot of like 585), next time I download a video off this site I can take a screenshot if you want... Fastest http was 1106KB/sec from archive.org.