Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
About the GUI
- I think the GUI shouldn't display all the settings at once. Tabs may be a better solution.
- I don't understand the meaning of RAM Watch Index
- "Mask color" seems unnecessary to me. Comparing a "layer-x-only" image with a "no-layer" image is more reliable -- and it is game independent too. Then, "Correction RGB" won't be necessary too. (I think at least the higher "perfection" levels would require the alternative concept)
- I think it will be sufficient to support only one format for the images PNG. Every computer I know of can open that, and it's lossless. Those who want a different format might transcode the result. And I think it makes sense to support only two framerates native framerate and half framerate. Everything else is most likely to introduce stuttering and other problems.
We need a central place for all those files. Exchanging files via Mediafire or the like is just a temporary solution, some SVN repository would be better. For example, Adelikat hosts big parts of his TAS projects at google code.
Oh, about the breakpoints Does saving and loading settings for all the breakpoints works? If you close and restart the emulator, will those settings be restored?
And just a sidenote You're editing the sourcecode of Snes9x... This might require you to publish your code under the terms of the GNU general public license.
My idea for the Multiframe support
Invent some commandline option like "--multiframe OBJ BG1 BG4". It tells the emulator to be a "slave" turn on graphic layers OBJ, BG1 and BG4, turn off all the others, hide all the menus, fake-mute audio output, ignore all "create savestate" commands, and disable all user controls Instead, it accepts input only from the "master" emulator. This especially includes commands like frameadvance, controller input data, and when to load states.
When Multiframe mode is to be started, the master would just have to call another instance of the emulator and send "controlling data" to the slave.
I was researching a bit on how to create good documentation for all this code. I strongly recommend you to use the JavaDoc documentation conventions (or any other system of that kind) so that your code will be easy to read and easy to improve (if that becomes necessary, for example to implement new features). And it would allow you to auto-create some good documentation which can be converted to PDF or HTML or whatever you want.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Dario_ff wrote:
first some core points should be defined before implementing anything else. Otherwise, lots of conflicting ideas appear, and it'll become quite messy. Once some core ideas are set well, we can improve upon it.
Even though I like fancy ideas such as offscreen-synchronization with camhacks, I fear they might be: a) too game dependent. b) might cause more problems than it solves. c) probably easier to do with video editing.
I took a closer look at it, and I think it can be done without any kind of camhack. Instead, we would need a system for automatic sprite extraction. My little mark_object_test.lua script (which depends on FCEUX functionality right now) is one step for that.
I want do avoid editing the video manually as far as possible. This will make it way too complicated to create a good video. And: each time the movie gets updated, all those steps must be repeated.
I'm aiming for a script (or external program, or a combination of it) that does almost everything automatically. Best case would be that everyone who can create HD encodes can also create an Atlas Video in little time. It doesn't matter at all how fast the automatic routines are -- as long as no user interaction is needed during that time.
"Dario_ff wrote:
There is one problem which can't be solved that way: The sprites may contain some pixels which have the same color as in img_bgonly AND the same color as in img_nothing. Those pixels MAY be necessary to mark some parts of the object, but they can't be detected just by using one frame.
This exact same problem happens to me when I apply the mask color as well. I was trying yesterday with TMNT 4, and guess what? The BG was black, as well as the enemies clothing. It really can be a problem, and I wonder if there's some way to control the color of the background using snes9x...
Instead of setting the offset, you define a region of the big map bitmap, to act as a single world map. How does that sound?
I think that's pretty much the same as I suggested. The only difference would be that telling "only display this part" will hide the rest.
I can't really say what will be better in the end. The extreme case would be that you have ONE map for ALL levels and subareas. I think it's better to have each world as (at least one) separate PNG file. This way it's easier to fix errors in the maps.
"Dario_ff wrote:
It should be possible to auto-adjust the breakpoints.
I'd say to try this:
1 - Record movie using Atlas video.
2 - When the emulator detects a sudden change of the RAM Watch values(like going to 0) that is quite a big difference, pop up a message asking the user if he wants to define a new breakpoint there. Or if you want to redefine a breakpoint's frame there
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
How do you think about "Atlas Movies"? Will it be possible to publish them besides the SD and HD encodes?
I created an Atlas Video for [1349] NES Super Mario Bros. "warpless" by HappyLee in 18:41.70, see here http://www.youtube.com/watch?v=i8u4SyclFNs
I don't expect this particular video to be good enough for publication here. There are still many things missing for a "perfect" video -- movie dependant enemy placement on the maps, "cool" intro, object updates on the map (broken blocks, latest enemy position etc). The necessary tools for that are being developed right now. Some of them might be even useful for TASing.
Would "perfect" Atlas Videos get a chance for publication?
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
I'm currently testing if my code works as expected... At the moment I'm talking of...
1) mark the object
"img_normal" is an image for the current frame rendered with all layers
"img_bgonly" is the same with bg layer only
"img_spritesonly" and "img_nothing" also exist.
The current code works for FCEUX only because it's using emu.setrenderplanes four times for a single frame, but the detections seems to work quite well. It compares if img_normal is different from img_bgonly. All pixels which are different belong to some sprite.
The same is done for img_spritesonly and img_nothing.
There is one problem which can't be solved that way The sprites may contain some pixels which have the same color as in img_bgonly AND the same color as in img_nothing. Those pixels MAY be necessary to mark some parts of the object, but they can't be detected just by using one frame.
My test script works the following way run some game in FCEUX, run the script, click on some sprite you want to get marked. The "search area" is marked blue, the object is marked pink, undetectable pixels are marked gray.
With the multiframe support, this code becomes more efficient.
When I extend the functionality of this code, it can be used to auto-extract sprites (and background too!) from the game. This would be really useful even for many other things! It won't be easy to do, but completely game-independent. Some problems will be
- sprites can collide. If there are multiple sprites on a single frame, the script needs to detect the individual sprites. This means some kind of motion detection is necessary.
- if the sprite is almost completely off-screen, there might be no reliable way to reconstruct the sprite by only using a single frame.
When ALL sprites (that appear in the movie) are known, it's possible to reconstruct all sprites which are almost completely off-screen. With this approach, camhacking isn't necessary... but for some specific parts of the game, camhacking might be a good idea -- thinking of boss fights where the boss goes off-screen, or the battletoads video. The camhack could be done in such a way that it auto-follows objects which are (manually) marked as "extraordinary important".
Right now, I can't access my code, I will post it in ~14 hours. I will also give you my ~1000 other lines of code...
-----
I think that the editable breakpoint system will be much easier to do than automatic area detection. However, I think it's a bad idea to use a PNG file + OffsetXY directly. It's better to tell the program something like "this is area 1-1, subarea 2 subsubarea 1" or "this is area "yoshis island world 2" subarea "down pipe A". Another data structure says "yoshis island world 2" maps to "YI-W2.vgmaps.png", "down pipe A" says offsetXY 600/200.
It should be possible to auto-adjust the breakpoints. Let's say you click "breakpoint" anywhere while the movie plays "yoshis island world 2". The breakpoint is set to some earlier frames as long as the camera has done a "smooth move"
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Thanks SXL... I think when the tools we create here become good enough, these movies might get published on this site.
---
My idea for the movie-dependant enemy placement is the following (one of the concepts for the "higher levels")
(0) find all objects (or sprites) on the very right. This can be done
by comaring each pixel on the very right from the "no bg" render against the "normal" render.
if an object on the very right could be found:
check if it might be (one of) the character(s). if yes: ignore!
otherwise:
1) mark the object: hack the camera for that frame so that the object is completely on-screen, then mark all object-pixels. (compare all neighbor pixels the same way as above, then their neighbors, neighbors of the neigbors.... until all are detected)
2) try to detect the first frame the object appears by doing the following:
(assume that an object doesn't move more pixels per frame than its own size)
for the PREVIOUS frame:
3) check each marked pixel if it might be from this object. if that's possible, mark the whole object!
4) check if this can still belong to ONE object. if not: split them!
5) recheck with the PREVIOUS frame (recheck, recheck...) until that fails.
if the object has been completely on-screen on ANY frame: ignore! otherwise:
6) draw the object onto the map!
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Your videos look very impressive! And right now, you're still faster -- and I like the style of your intros.
as far as i know, Youtube transcodes everthing if the resolution is LESS THAN OR EQUAL to 1080p. If you encode with 1100p (for example by adding some black borders...), youtube should offer an "original" option.
(or you may take your current encode and double the solution, which would be 2160p... no current computer would be able to playback this, but youtube might create a better 1080p video)
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
OK, then let's go!
DEFINITIONS (you may give suggestions for better names)
"movie" is a key input file or an encode for it.
"atlas video" is what we created.
"map view" is the part of our videos which shows big parts of the map.
"main view" is the part which shows a big picture for the TAS itself.
(1) My idea about the "area watch" code is
If the following conditions are met
- ONE atlas video for this game was created which these scripts
- it becomes obsoleted
- the NEW movie visits only those areas which were included in the old movie
Then
- the NEW atlas video can be created completely automatic!
Examples where this will be useful
- SMB1, SMW
(3) The camhack is possible for many games (at least I think so), but one problem is that there are multiple copies of the camXY values in RAM. Another problem is that many games render garbage background if the cam is moved too much at once, but sprites are rendered correctly. It would be really useful for (E).
Here are a few more ideas
(A) create a "multiframe output" support for snes9x
- HOW with Lua it would be create savestate, save, render next, load, render bg only, load, render obj only, load, render nothing (yes, this might be more than just one color -- see DKC), load...
If it is possible to implement such a thing into the emulator directly, it would be much faster.
- WHY With such images, you can mark all the enemies on the map, and you can render the background image.
I have used multiple videos for creating my SMW video (1) normal (2) camhacked-spritesonly (3) nothing. They were combined through a more than 100 lines long AviSynth script which is really slow -- it renders ~0.8 fps... At least you can see the final result before the final video gets created.
(B) Bisqwit has created a program called "AnimMerger". It will try to align the images without any dependencies on RAM values. If it is used on the "only BG" image from (A), it might be possible to fix such errors as you see in my "The Mask" video automatically.
(C) preview for the final result. This should be very easy to do.
(D) alternative form of my "area" detector simply define breakpoints and let the script run some kind of auto-detection which area is visited at the moment
- render BG only and render nothing, compare which pixels are different
- use the "different" pixels for some kind of comparison to all known maps.
And It might be possible to find the breakpoints automatically by detecting black screens.
(E) automatic "new sprite" detector. That would be great for movie-dependant enemy placement on the map. At the moment, my best idea for this is
- scan the very right (left, top, bottom) part of the screen in the "sprites only" image compared to "nothing" image. If they are not equal, place it on the "enemy" map once it gets visible completely, i.e. not touching the very right(left, ...) line of the screen.
(F) define "levels of perfection" for the atlas videos, somehow like this
level 1 use a map from VGmaps, generate simple dualview (or "zoomview") like in your videos -- this might be enough for most people and can be done pretty fast
level 2 fitted background (maybe like in my videos, but another option would be non-dynamic background in the "map view" part and dynamic in the "main view")
level 3 self-made maps with movie-dependant enemy placements
level 4 off-screen syncronization
...
level 50 good enough to be published at TASvideos besides the normal encode
BTW, is your interface portable to other systems like linux? I used "auxlib" and the "iup" libraries, they seem to be completely system independent.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Cool things you posted there! Let's combine your script with mine, because
My script
(1) will be designed to create maps with movie-dependant enemy positions
(2) will support multiple "areas" ( <- quite hard to find good RAM values for this...)
(3) supports offscreen syncronization
(4) supports "cam delay" (see below)
- requires MSU video codec (or any other true RGB codec with lossless compression)
- depends on AVIsynth
Your script
(5) has a much better interface right now
(6) doesn't depend on MSU or AVIsynth (at least I think so...)
- doesn't do any attempts on synced background or enemies
- will only create videos for individual levels
At the moment, I'm writing and testing the scripts for NES - Asterix.
I don't have much spare time right now, so it might take until February to get finished.
Features which would be nice
- The map should be updated for all the "visited" parts
If you collect coins they should disappear on the big map. Unfortunately, that's not possible for the maps from VGmaps...
For my Mario movie, I used maps I found somewhere on the internet, but I think the movies will look better by using (1).
About (4) Pause your SMW video at ~4sec, you will see that your video is slightly misplaced.
If you apply the CamX / CamY values to a different frame, this get fixed.
Try what happens if you read the values and use them not for the current, but for the next frame!
As far as I know, Sega Sonic would require a delay of 2 or 3 frames...
Determining the cam position is most likely not that easy if seeking for a perfect alignment.
My "The Mask" video demonstrates that quite well Most frames got aligned perfectly,
but some single frames got misaligned. For that game,
reading one RAM value for CamX and one for CamY isn't sufficient.
SMW uses multiple values too ("ingame" and "map mode")
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Ilari wrote:
Not hopping on that one block but instead taking the long way [in the very last part of level 9]? That's because that one block is a trap (one has to look very closely to see it). IIRC, video shows me hopping through that block, no normal block would allow that.
OK, I couldn't see that even when watching again... It should be noted when you submit this run.
--
I liked the movie with the added soundtrack a lot more than the original. It might be possible to publish it together with the "official" video, since something similar was done for [1616] N64 The Legend of Zelda: Ocarina of Time by Bloobiebla in 56:54.20
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
1) The sound effects of this game are absolutely terrible.
2) There is no music.
3) The very last part of level 9 looks quite "wrong", as if you could improve it by 2 seconds or more.
In my opinion, 1+2 qualify for bad game choice. The technical quality of the TAS was quite good.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Sync offscreen movement like that?
look at the plant in the top and bottom part of the map
http://img576.imageshack.us/img576/5357/smwwipoffscreensync.png
basically it was created with a "camhack" video: I recorded a "normal" capture, and a "camhack" capture where I let the camera jump to the farest right position possible.
sorry, the picture is a bit too large... The source code for this video is 140 lines, a bit too long to post it right here... The source code for the "camhack" part is a bit shorter, see here:
s = savestate.create()
while(true) do
savestate.save(s)
camxpos = memory.readshort(camX)
camypos = memory.readshort(camY)
xpos = memory.readshort(charX)
ypos = memory.readshort(charY)
snes9x.frameadvance()
gui.register(gui.text(0,0,string.format("original frame %i (after save)",emu.framecount())))
function camhack(x,y)
memory.writeshort(camX, x)
memory.writeshort(camY, y)
snes9x.frameadvance()
gui.text(0,0,string.format("%i, %i",x,y))
snes9x.frameadvance() --required for video capture
savestate.load(s)
end
camhack(xpos,camypos) --math.max(0,ypos))
camhack(math.max(0,xpos - 240), camypos) --math.max(0,ypos))
--camhack(xpos,math.max(0,ypos - 200))
--camhack(math.max(0,xpos - 240), math.max(0,ypos - 200))
memory.writeshort(camX, camxpos)
memory.writeshort(camY, camypos)
snes9x.frameadvance()
gui.register(gui.text(0,0,string.format("original frame %i",emu.framecount())))
end
MOD EDIT: Removed overly large picture in favour of image link. Don't place very wide images in posts.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
It's been a long time since I posted the last Atlas Video.
At the moment, I'm creating a Lua script. When it is finished, creating Atlas Videos will be done like this:
BEFORE using the script:
Search (manually) for the RAM values of: CameraX, CameraY (if applicable), characterPositionX, characterPositionY.
Find some RAM values which identifies each "area" of the game uniquely (I think that will be the hardest part. This requires some trial-and-error.)
MODIFY the script. That's necessary because
The script needs to know the above values.
It's very unlikely that simply reading RAM values will do it all right.
Even if you find something representing the current position, it's possibly just a copy. The script will move the character around. This won't work for the "copy".
USE the script.
First, you will use some mode called "create map" or something like this. It will be necessary to create one for each area in the game. The script will show you when it detects an "unknown" area. You will just have to change some graphic settings then, and afterwards, you just say "START!". If you're lucky, the result will be a perfect PNG for the current area. If not, you need to modify the script.
The distinct areas need to be connected. The game engine doesn't care about that, so this must be done semi-manually. I'm planning to write a separate program for this step.
You may skip creating your own maps if you find some, but the final result might be worse. I think I will write some functionality for using such maps.
When all maps are created, you restart the movie. Then you will use the "avisynth" mode. It will create an avisynth script. It will create something like my
DualView SMB video, or alternatively a view of the video with the map around it and some kind of zoom for the video.
I'm also writing some documentation on how to use it. I hope that someone else will also use these scripts.
I think that creating an Atlas Video with these scripts would take about three hours (for finding the RAM values and setting up the script) + (videolength * 10) + time for final encode.
If the script AND the maps are "ready-to-use", I think it will only be about (videolength * 3) + time for final encode, so if a run gets obsoleted, it's easy to create a new Atlas Video.
"time for final encode" can be really long, it may take (videolength * 80). But since it will run automatically, it's not too important.
QUESTIONS:
Do you think the above instructions are easy enough?
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Almost all the enemies look the same, but I liked the music. The game choice was good. And it seemed to me that you played it quite well. It was nice to watch.
But...
- It has been proven that this run is improvable by at least a few seconds. (I don't consider that to be really important since no one tried this game till now. The first run for a new game can't be perfect ever.)
- It was played on normal difficulty, and there is no good reason for it. (Less lag is a bad reason.)
I recommend redoing this one in hard mode, even if it includes more lag. I will vote yes for the improved version.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Technically well done.
However, I will vote no on this one. The first "victory" after being defeated was quite funny. Seing the glitch repeated over and over again was boring. This bug skips all the gameplay.
I think that movies skipping almost all the gameplay (like SNES zelda or GBC pokemon yellow) shouldn't be longer than ~5 minutes. 13 minutes is just too long. And most of the action (~8 minutes) is just going through menus.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
I did all the levels multiple times using slightly different strategies. This could save small amounts of lag. Unfortunately, most lag can't be avoided. Most parts of this game are deterministic, so there's no way to manipulate enemies to let them not appear. The more sprites on-screen, the more lag. Therefore I try to minimize the amount of enemies on-screen. Killing enemies will stop your "running" status, so the only way to do that is to jump either lower or higher. It only makes sense to kill enemies if they are blocking your path.
EDIT: now completed, but the second half needs some more optimization.
See here
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
One of the strange things I found in Snes9x 1.43 and 1.51 is that it produces different images for screenshots and AVI files. It might have something to do with the 2^16 colors limitation of the SNES. 1.52 will do the same at the moment.
The following Lua script (which works for 1.43 and 1.51, but not for 1.52, there it says "gdscreenshot" is nil) demonstrates the problem.
require "gd"
--produces the same as using the "save screenshot" function
normalScreenshot = gd.createFromGdStr(gui.gdscreenshot())
normalScreenshot:png("normalScreenshot.png")
--produces the same as extracting an image from lossless RGB(!!) encoded AVI
snesXsize, snesYsize = 256, 224
videoScreenshot = gd.createTrueColor(snesXsize, snesYsize)
for j=0,snesXsize-1 do
for k=0,snesYsize-1 do
videoScreenshot:setPixel(j, k, videoScreenshot:colorAllocate(gui.getpixel(j,k)))
end
end
videoScreenshot:png("videoScreenshot.png")
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
DOS Lada wrote:
Apologies for the shortness of the game... There wasn't much time!
Sorry, this game isn't only short, but the sound effects are really annoying. Good run on a bad game. Voting no.
A "pacifist" version of this run might be more enjoyable. I don't know if that's possible.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
I think this game is good enough to deserve a TAS.
I made a new WIP. It's about 40% finished. You can find it here. Up to this point, it's more than 20 seconds faster than the TAS you can find on speedruns.net.
Bonkers can walk, run and drink something spicy which makes him run for a longer time and makes him invincible. The "drinking" animation is quite long. Therefore, it's a pretty bad idea to collect every drink.
The "ghost" enemy can be manipulated so that he doesn't move too much on the top of the screen. That's why I don't hit him at the first possible frame. I tried to minimize the ghost movement.
I think I found some kind of bug in the very first level. Normally, Bonkers can't run through the whole first part of the first level. It might have something to do with touching the water at the right place, but I'm not sure about it.
Is this WIP good enough to be continued from the point where it stops, or does it need a complete restart? If you can find improvements, post them please.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
One hour per minute? Then you're much faster than me at the moment... The SMW video took about 8 hours, and it's still not as perfect as I want it. I will try to animate all animateable objects around. (But When the script works well for the first level, it will work well for almost all the others too...)
You can also suggest other games which could make even more interesting Atlas views... I'm sure I will create one for Road Runner "all flags" when I get it finished.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
These maps look pretty nice. Donkey Kong would still be very hard to do because
In the first few levels, you can't remove the "sun" animation from screenshots or video capture. It will even stay with ALL graphic layers turned off...
The water levels will be even worse to make look good.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
(SNES) Super Mario World, second level (the first one to be played in TASes)
EDIT: updated again...
I'm not sure if I'm ever going to finish making a complete Atlas for this game. I'm pretty sure it would require me to rebuild all maps by hand. This encode uses the maps of Stefan Mahrla which I found at VGmaps. They might be completely useless for the final version.
Experienced Forum User, Published Author, Player
(136)
Joined: 9/18/2007
Posts: 389
Thanks for telling how to turn off all those texts in the video, they are really annoying for me. Even if I could read it, I would turn it off.
Most of the action looked very well optimized. I was only wondering about the very last race. Isn't it possible to do some more luck manipulation so that you don't stop twice in the last race (at positions 12:40 and 13:28 in the second part)? (Submission text explains that now).
I dislike the ROM choice although there is a good reason for it.
(yes vote)
