If that's the manliest music video ever, then this is the gayest music video ever: http://youtube.com/watch?v=6UV3kRV46Zs
(Btw, is it just me, or does the dork with the blue shirt look a lot like John Carmack?)
i will make myself clear, like when i press "x" or "y" button, it will determinater deferents things on the events.
but the point is how to find the address , and how to manipulate.
If what you want to do is, for example, manipulate an enemy to drop a certain item when it dies, the oldest and simplest method to achieve this is the following iterative process:
1) Save a savestate a bit before killing the enemy.
2) Kill it.
3) Did it drop the object you wanted? If yes, you are done.
4) If not, then load the savestate.
5) Kill the enemy again, but press different buttons and button combinations down (preferably without sacrificing speed, although if nothing else seems to work, try a 1-frame delay).
6) Jump to step 3.
It may sometimes be tedious (depending on the game, it can be *really* tedious), but in most cases it works, it's the easiest to do.
In some games if you can find the random number generator and the memory location which determines which object the enemy will drop, it might help you narrow down your work (ie. you don't necessarily have to iterate so many times and guess at random). However, this is not easy in many games. In many games the dropped item will be determined *after* you kill the enemy, so there's no memory location which you can watch to see into the future. The only way to do that would be to analyze the RNG and deduce from it what will happen with different key combinations, but that can be as difficult as the iterative approach.
How about this:
Find the largest n for which:
1) n is a prime.
2) The nth prime is smaller than 4200000000.
As the answer, provide both n and the nth prime.
(Ok, not really a math puzzle per se, but a programming task (or a 'using appropriate tools' task), but interesting nevertheless. Btw, I wrote a program to find the answer and it took 74 seconds to do so in my computer, using only standard C++.)
Easy one:
Deduce the (minimum) number of moves required to solve the Tower of Hanoi puzzle with 3 pegs and n discs.
Harder one:
By their nature, factorials tend to accumulate trailing zeroes. For example, 5! (120) has one trailing zero, 10! (3628800) has two trailing zeroes, 25! (15511210043330985984000000) has six trailing zeroes, etc.
Write a function which, for an integer n, gives the number of trailing zeroes in n!.
I'm surprised there are half as many SNES movies as there are NES. Both systems have comparably sized libraries.
NES TASing has existed for longer and thus has an older history. I suppose that an additional reason might be that SNES games tend to be much longer and be much more difficult to TAS (because of all the possible variation). SNES games also usually have less bugs and glitches to exploit.
At any keypoint of a movie, I make a "rewind" savestate, manually. This is usually save state 1 in the emulator. So whenever I need to redo something within the period of that state and the current frame, I press shift+8 (usually that's the shortcut for read-only) and I load the "rewind" state. When I think I've optimised a part of the movie, I put a new "rewind" state and keep playing. It really is that easy.
Nothing would stop it from being even easier: That is, completely automatized. No need to manually save "rewind states" when they could be saved by the emulator. Also, it would allow you to backtrack to any frame, not just the frames where you saved.
Do you know that little about C++ in particular, or about programming in general? There's a big difference.
So my question is, how do i go about making any videogame, not just an nes game. What program languages will i need to learn, and what programs will i need?
Assuming you have near zero experience about programming, I would say that you can right away forget about making NES games.
If you want to make simple games (of the type tic-tac-toe, connect-5, simple tetris) some high-level scripting language will be more than enough for that. People have used things like javascript to make such games in webpages, although standalone games would need some other language (but the language would need to have some support for graphics and mouse reading or, alternatively, unblocked keyboard reading). One very good alternative is the ActionScript of Flash, which can be used to create the flash games you can see all over the internet (although that doesn't mean that making such games is simple or easy).
Don't expect it to be easy because it won't be, regardless of the language you choose.
To make a bit more advanced games Java could be considered. It has standard GUI and graphical libraries which can be used for creating games. There are many examples of Java games or game applications out there (cgoban2 comes to mind as a good example). In the Windows side of the world you could also consider C#, although its problem is that it's not portable.
While personally I love C++, I can't deny that C++ is a beast. It's not a good language for beginners, and it doesn't have standard graphical libraries. There exist quite many good (and even platform-independent) graphical libraries for it though (such as wxWidgets or SDL). But, again, that doesn't mean that creating a game with them is easy. Again, in the Windows side of the world there exist many free C++ libraries which make creating small games (ie. of the casual game type) easier (such as HGE and PopCap). The advantage of C++ and these libraries is that they can be used to make more advanced (and more efficient) games than you can do, for example, with Flash ActionScript.
Anyways, creating a game is not easy. It requires years of programming experience. Creating something visible on screen, even something which is interactive (ie. something which can be controlled eg. with the mouse or the keyboard) is relatively easy. However, the larger the game becomes, the more the beginner programmers stumbles across his own inexperience at programming, and the code becomes an unmaintainable mess which is really hard to enhance.
Well, rewinding, say, 100 frames back will take you noticeably more time than loading a state you made there, no? Assuming you won't go to options screen to readjust rewind intervals each time (that would kinda defeat the purpose of making stuff handier).
So what? If you want to go 100 frames back, then load that savestate of yours. If you want to go go 2 frames back, rewinding may be handier for that purpose. Why are you talking as if the rewinding function would *replace* savestates instead of existing besides them? If you don't like rewinding nobody forces you to use it.
Besides, nobody says there couldn't be a key combination (eg. ctrl + the rewind key) which goes back eg 10 frames to make it faster to go further back.
I don't understand why rewinding couldn't be instantaneous (or at least so fast that you can't tell the difference). And it's not like rewinding would substitute normal savestates. It would just be an additional tool to make some things handier.
As all variables on the machine state have to be preserved on each frame, it'll affect the speed while playing, and also have a buffer that limits the ammount of "undo" that you can do. You can use tricks like storing differentials ("on frame X value Y changed from A to B") instead of simply dumping all the same values every frame, but the space available still imposes a limit to the feature.
Speed and memory usage can be optimized more than that. For example, the emulator could store in memory a savestate for example for each 10th or 20th frame. When rewinding, it loads the previous savestate and silently "plays" it until the desired frame is reached. If, for example, it stored in memory a savestate each 20 frames and it used eg. 100 such savestates, the amount of possible rewinding would be 2000 frames, or 33 seconds. Tuning those values can allow even more.
Phil wrote:
I don't see how rewinding 1 frame would replace them. I don't find that feature to be useful.
One frame *at a time*. Naturally if you press it repeatedly, it will go back that many frames. This way if you made a mistake 5 frames earlier, you press it 5 times to get there.
(Naturally some maximum limit for going back is probably necessary in order to not to run out of memory, but we are still probably talking about thousands of frames which can be rewinded.)
IMO in this type of game aiming for 100% kills is much more interesting than simply having a half hour of repeating acrobatics. With tool-assistance passing this game and doing acrobatics is extremely easy (I have experience). However, aiming for 100% kills is quite laborious (again, experience). Also, trying to kill everything results in a movie with a lot more action and, IMO, consequently more entertaining.
I don't know if anyone has ever noticed it, but in my 100% kills run of this game I miss one enemy which I shouldn't have missed (I noticed it only after it was published!). I wouldn't mind if someone obsoleted it with a run which kills more (at least 1 more, it's definitely possible) and is faster (I probably didn't kill all bosses as fast as possible, and I didn't even try to avoid lag, which in some cases may be avoidable).
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
Btw, those things would mostly go away if someone finally created a rewinding feature to the emulators (ie. like frame advance, but instead of going forward one frame, it goes back one frame).
I pointed this out long ago to Bisqwit (it happens also on the all-movies list). He basically didn't give a shit because it works in Firefox. Yeah, whatever.
I like your attitude. It's the perfect attitude to encourage admins and developers to make things better because of the positive feelings they get from their hard work.
I play the guitar a little, and I made a post some time ago where I gave links to me playing the guitar and the ocarina.
I have also made original sequencer music in the past. Here's a sample:
http://kapsi.fi/~warp/Sunshine_remake.mp3
The CPU and PPU run off the same 24MHz master clock, so they are perfectly synchronized. They just get different dividers.
Maybe the PPU is, but the TV isn't, and the NMIs are launched at horizontal and vertical retraces, if I'm not completely mistaken. The NES has to send the TV video signal at 50/60 Hz (give or take some small fraction), regardless of the CPU clock, and the horizontal/vertical retrace interrupts must obviously be synchronized with the TV, not the CPU or PPU.
I didn't get it. It was difficult to watch the entire video through because it was so boring...
(There aren't many things which are more exasperating in videos than a constantly shaking camera. If you are going to make a video, keep the camera as stable as possible and focus on the subject. There's nothing more irritating than a constant random shaking and the subject being half the time out of picture.)
I think that's one of the problems with trying to emulate such a system. Unless I'm completely off-track, I assume that the chip inside the NES which draws things on screen and launches NMIs for the CPU works independently, regardless of what the CPU does. In other words, the chip is most probably not synchronized in any way with the CPU clock. This means that an NMI launched by this chip may happen at any time, but the CPU can only handle it no sooner than at the next clock cycle.
What this means is that, given the right conditions, a lag frame may happen or not, depending on how the graphics chip happens to launch the NMI. This means that in the real NES the lag frame may happen or not even if the input was exactly the same. It all depends on when the graphics chip started drawing the screen, which may not be completely synchronized with the CPU clock (but most probably with the 50/60 Hz AC electric input of the system, while the CPU simply has its own clock chip which starts when the system boots).
Of course it's probably quite rare for this to happen, but it's quite possible.
An emulator, however, will always emulate the system in the exact same way (else the movie files would always desync), which means that it's not emulating the original NES system 100% identically. The emulated graphics chip and the emulated CPU are actually perfectly synchronized in the emulator (which causes a lag frame to appear every single time with the same input and the same conditions), which is something which probably doesn't happen in the original system.
