Topic by adelikat

Posted: 10/27/2006 2:05 AM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3599)

Joined: 11/3/2004
Posts: 4739
Location: Tennessee

due to the frame rule, POM intentionallly delays the completion of levels as much as possible before the frame rule "kicks in" so he can do cooler less-optimized stuff and get the same overall time. It actually maximizes action and minimizes the time the the black screen is on while still achieving the fastest possible time. It is cool as shit as it shows even more pwnage to the game, while minimizing the time that the game is doing "nothing". AKA: You should try to understand a game more, and maybe even try to TAS some of these "ideas" of yours before you go around claiming that everything can be improved.

It's hard to look this good. My TAS projects

Posted: 11/1/2006 4:58 PM

Quote

SXL

Joined: 2/7/2005
Posts: 571

some of those ideas are not new, I saw them before. graphic examples of dream tools already posted previously : savestate tree (dopesheet ?) live button/savestate editor

I never sleep, 'cause sleep is the cousin of death - NAS

Posted: 11/1/2006 5:00 PM

Quote

Aqfaq

Editor, Expert player (2460)

Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!

This is what Gods level 1 looks in the memory when each memory value is replaced with some color. Red is impassable wall, green is ladder, the colorful dots are all kinds of triggers, loading zones, doors, switches, items etc. I wish I had a tool to view this part of the memory in real time while playbacking/recording a movie. That way I might get a better understanding of what's happening offscreen. The point is to (hopefully) get at least some new information that's not available while playing the game normally. This method will not work with all games, because the data is not always arranged that nicely.

Posted: 11/6/2006 7:32 PM
(Edited: 11/7/2006 7:04 AM)

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

I'm working on a library (DLL) that should allow easy sharing of memory blocks across application boundaries while taking care of the mutex stuff... If (when?) it's finished you'd be able to write a small application that just hooks into the emulator's shared variables (e.g. RAM) instead of having to modify the emulator's source. Might be useful to somebody, who knows. :/ EDIT: Typo.

Posted: 11/7/2006 12:41 AM

Quote

Ersatz

Joined: 8/9/2004
Posts: 139
Location: Washington State

creaothceann wrote:

I'm working on a library (DLL) that should easily allow sharing of memory blocks across application boundaries while taking care of the mutex stuff... If (when?) it's finished you'd be able to write a small application that just hooks into the emulator's shared variables (e.g. RAM) instead of having to modify the emulator's source. Might be useful to somebody, who knows. :/

I would assume that this would be the start of dozens of creative and useful tools... keep up the good work!

Posted: 11/14/2006 3:09 AM

Quote

JXQ

Experienced player (750)

Joined: 5/6/2005
Posts: 3132

Here's a neat idea. How about the ability to take a movie that you are currently working on, select a frame range, and export a movie that plays from a savestate at the beginning of that range? This way, you can show certain parts of your run if that's all you want to do, or you can update WIPs and people won't ask for savestates, all the while working from your master file. (This can all be done now, it just requires some annoying hex-editing in a process that wouldn't be too difficult to automate)

<Swordless> Go hug a tree, you vegetarian (I bet you really are one)

Posted: 11/14/2006 4:06 AM

Quote

DeHackEd

Emulator Coder, Site Developer, Former player

Joined: 11/6/2004
Posts: 833

http://dehacked.2y.net/savestateify.php Edit the (backup of) movie to mark the end point. Provide a savestate to indicate the starting point. Wham, bam, thankyou SRAM.

Posted: 11/29/2006 10:04 AM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

Here's a nice emulator for the technically inclined: http://acg.media.mit.edu/people/fry/deconstructulator/

Ersatz wrote:

I would assume that this would be the start of dozens of creative and useful tools...

That's the plan. :) The project'll have to wait a bit though while I'm translating a webcomic.

Posted: 1/5/2007 3:17 PM

Quote

Yrr

Joined: 8/10/2006
Posts: 289
Location: Germany, Bayern

Brute Force would also be a possible tool. The computer checks every possible combination of buttons pressed to find out the fastest way, for example to enter the next door. Of course, depending on the situation, it can take a long time, and it's quite inefficient.

Posted: 1/5/2007 6:06 PM

Quote

Titus_Kwok

Joined: 4/30/2006
Posts: 480
Location: the secret cow level

That's why we have Bisqbot.

Posted: 1/6/2007 2:30 PM

Quote

blargg

Emulator Coder

Joined: 6/8/2005
Posts: 14

JXQ wrote:

Here's a neat idea. How about the ability to take a movie that you are currently working on, select a frame range, and export a movie that plays from a savestate at the beginning of that range? This way, you can show certain parts of your run if that's all you want to do, or you can update WIPs and people won't ask for savestates, all the while working from your master file.

If you have a Mac, take a look at QuickNES (download link). All game play is recorded into a movie, which supports rewind and fast-forward to any point (including single frame stepping), and re-recording at any time. You can trim a movie down to a short segment and save that. You can even watch a movie backwards from end to beginning.

Posted: 1/6/2007 3:37 PM

Quote

moozooh

Senior Moderator

Joined: 8/4/2005
Posts: 5770
Location: Away

blargg wrote:

If you have a Mac, take a look at QuickNES (download link). All game play is recorded into a movie, which supports rewind and fast-forward to any point (including single frame stepping), and re-recording at any time. You can trim a movie down to a short segment and save that. You can even watch a movie backwards from end to beginning.

I don't have a Mac, but that compressing scheme looks very smart (at least much smarter than doing a complete memory dump each frame). How much space does it consume after, say, an hour of gameplay?

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.

Posted: 1/7/2007 2:45 PM

Quote

blargg

Emulator Coder

Joined: 6/8/2005
Posts: 14

Right, as you're playing, QuickNES saves state every second to a cache of the most recent two minutes (120 save states), and also saves state to the ongoing movie every 30 seconds. These are both adjustable in the code. As for movie size on disk and in memory, here are some data for complete movies, keyframes every 30 seconds (on disk they are gzipped and in memory compressed using a custom algorithm):

Time  Disk  Average    Mem    Average   Game
--------------------------------------------------------------
0:30   46K  1.5K/min   126K   4.2K/min  A Boy and His Blob
0:20   54K  2.7K/min   145K   7.3K/min  Batman
0:52  370K  7.1K/min   662K  12.7K/min  Bionic Commando
1:00  150K  2.5K/min   423K   7.1K/min  Blaster Master
0:23   84K  3.7K/min   232K  10.1K/min  Castlevania
0:43  182K  4.2K/min   420K   9.8K/min  Deadly Towers
0:57  222K  3.9K/min   621K  10.9K/min  Duck Tales 2
2:21  430K  3.0K/min  1165K   8.3K/min  Esper Dream 2
0:36   60K  1.7K/min   172K   4.8K/min  Fester's Quest
0:20   46K  2.3K/min   113K   5.7K/min  Gimmick!
0:51  138K  2.7K/min   459K   9.0K/min  Metroid
0:20   34K  1.7K/min   113K   5.7K/min  Mighty Bomb Jack
0:49   94K  1.9K/min   239K   4.9K/min  Ninja Gaiden
0:34  178K  5.2K/min   405K  11.9K/min  Rygar
0:43  118K  2.7K/min   355K   8.3K/min  Section-Z
0:52   98K  1.9K/min   282K   5.4K/min  Solomon's Key
0:59  180K  3.1K/min   518K   8.8K/min  Wizards & Warriors
0:19   42K  2.2K/min   116K   6.1K/min  Yume Penguin Monogatari

As mentioned on the linked Wiki page, the keyframe rate is entirely adjustable, allowing reduction in file size (you could save a movie with keyframes every 5 minutes, even if you recorded it with them every 30 seconds, for example). The in-memory compression is a custom algorithm I wrote to be extremely fast; using minilzo results in about 35% less memory usage (I imagine even zlib would perform decently, reducing memory usage further). The most recently accessed snapshots are kept uncompressed (and un-modified ones aren't re-compressed, similar to virtual memory), so compression doesn't affect performance much. Implementation is very straight forward; the emulator core exposes functions to emulate one frame, and save/load to/from a memory-based state snapshot. The movie functions are then implemented using these functions. The only reason this scheme might not work for a particular emulator is if it's relatively slow. On a 1.8 GHz Pentium 4 M laptop, my NES emulator runs about 3180 frames per second (5700 with sound and image disabled, as is done when skipping frames during seeking), so speed is not at all an issue in my case. EDIT: I see you were asking about memory usage, so I added that to the above table.

Posted: 1/7/2007 7:47 PM

Quote

moozooh

Senior Moderator

Joined: 8/4/2005
Posts: 5770
Location: Away

Thanks! The numbers are nowhere near the average Visual Boy Advance playing session (which happens to take megabytes worth of mem space with rewind enabled), and it's really good. One more question, though: what is the cause of such a great variation in average mem/disk space consuming? (I assume all of them were measured in the same conditions.)

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.

Posted: 1/7/2007 8:25 PM

Quote

blargg

Emulator Coder

Joined: 6/8/2005
Posts: 14

moozooh wrote:

One more question, though: what is the cause of such a great variation in average mem/disk space consuming?

The amount of additional memory in the cartridge itself is the main contributor. The NES has 2KB of internal CPU RAM + 2KB screen memory, and many cartridges add another 8KB of CPU RAM and some 8KB of CHR RAM (for graphics). This increases each save state by quite a bit. The increase is lessened due to the compressor finding common data between separate save states, since the games don't usually rewrite every byte that often. Another cause is that some games simply have a more compressible set of bytes in memory at most times. Visual Boy Advance save states are so much larger because the GBA itself has a lot of on-board RAM which must be saved each time. Wikipedia claims the GBA has 128KB of internal RAM (32K CPU + 96K VRAM), so you can only fit 8 uncompressed save states per megabyte of RAM.