At first I was confused as to what a "Atlas" video was until I grabbed one and took a look. Really cool. Something similar has been spoken about in another topic. Albiet this is much more feasable.
To make it a simple footnote, someone requested a "GIF" version of an Atlas video, albiet nothing became of it other tan a cool GIF posted by Bisqwit.
Bisqwit wrote:
Ramzi wrote:
Like all great technology, this was inspired to advance pornography.
Wouldn't this work. At time t, take a screenshot of the frame, and give it a number based on some formula, perhaps based on color count and such. Then, at t+1 do the same thing, and compare the difference between the two frames. If they are close, group them together in the current animation. If they are far apart, a new gif sequence will be created.
I imagine, then, if we were to apply this program to Mario 1, we would -- if my memory serves correctly -- get
Gif 1: Title sequence.
Gif 2: Black screen that shows number of lives.
Gif 3: Level one part 1.
Gif 4: A few frames of black
Gif 5: Collecting coins under the tube
Gif 6: Left of level 1.
Gif 7: A few frames of black.
Gif 8: The walking to the pipe.
Gif 9: A few frames of black.
Gif 10: Start of level 2.
Yeah, that's basically the same. It shouldn't be too difficult to build a GIF from the PNGs these scripts produce, but I think it's much better to create high-resolution videos out of them. It's an automated method for creating videos like these. I'm sure you have already seen some of them in the "NES in 1080p" topic. He made them completely by hand, inserting each video frame into the map manually... And he says it takes at least four hours per minute of video. I would never ever have the patience for such a task.
Yeah, that's basically the same. It shouldn't be too difficult to build a GIF from the PNGs these scripts produce, but I think it's much better to create high-resolution videos out of them. It's an automated method for creating videos like these. I'm sure you have already seen some of them in the "NES in 1080p" topic. He made them completely by hand, inserting each video frame into the map manually... And he says it takes at least four hours per minute of video. I would never ever have the patience for such a task.
I'm really glad these are inspiring others to build upon the "Atlas Video" concept and I can't help but feel as though I've been obsolete'd already. What is most exciting to me is the possibility that this "feature" could some how be built into emulators in real-time as you play the game! Great work, partyboy1a, and keep at it!
this "feature" could some how be built into emulators in real-time as you play the game
That could only be done for each game individually, and it's much more difficult than creating an Atlas video. Implementing it into an emulator would mean that absolutely every part for the "map view" must be automated. This would have to include building the maps completely automatic. These scripts aren't even close to that. And you should not forget that there can never be a "perfect" map. For example, the way I designed 1-1 in SMB (actually the design was stolen from vgmaps...) is definitely different from the map saved on the cartridge...
AndyDick wrote:
I can't help but feel as though I've been obsolete'd already.
I don't think so. You got some cool ideas for presenting the videos. And: Your method is almost completely game-independent whereas the scripts need to be adjusted each time. That can take much more time or even fail completely... For example, I couldn't find a way to determine the CamX and CamY values for Yoshi's Island. A few hours of trial-and-error for no useable results at all....
(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.
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.
I'm most likely going to be attempting a level out of DKC2... but first I need to finish Blaster Master. I am down to about 1 hour per minute of footage now which just accounts for manually tracking, but that's the majority of work anyways. Still haven't given the Lua script a go though.
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.
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?
Hello TASVideos, that registration process was quite funny. :D (I mean the anti-bot protection)
Anyway, on-topic, I've been writing a utility(the "Atlasizer", original name uh?) to do these kind of videos into snes9x. I've sent a closed beta to nesatlas(known for the thread "NES in 1080p" since he inspired me to do this little project).
But why do I post in this thread? Because the style is mostly based in partyboy1a's videos as well!
The process doesn't involve any custom scripting. It consists of tracking the RAM Watch values for the cameras. Most games I've tried have simply 2 16-bit integers for the layer 1 position. Use some clever RAM search, and done! (Or search the addresses on the net, for games like SMW, they're mapped already).
You also need a custom atlas map with 1:1 pixel accuracy. Those can be found on vgmaps.com
During the testing of the utility, I mostly used Super Mario World. But to my surprise, it worked fairly well with Donkey Kong Country! A video follows:
Link to video
I didn't spend more than 2-3 minutes into tracking the values. They mapped accurately to the world map in vgmaps. com! Then just configure the options in the GUI a bit, and done! New atlas video! The recording in 720p took nearly 10 minutes.
Here are my test videos as well for Super Mario world, with included Vertical maps support!
Link to videoLink to video
I'll release the tool once more testing is done, and some more needed options are implemented. For now, here's a preview of the GUI:
There's quite a bit of overhead though, since I'm using an external library(Allegro) to process the images, instead of the native snes9x routines. The reason is: a) I'm lazy to learn how snes9x works with bitmaps. b) I want to easily port this to other emulators.
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")
(2) will support multiple "areas" ( <- quite hard to find good RAM values for this...)
I must say, that finding RAM values isn't that necessary IMO. I think a simple breakpoint defined system by the user would be fine. After all, you don't play this in real time, you use a TAS. You can't be lazy if you're going to encode a whole TAS like this, so a simple breakpoint system would work fine.
The breakpoints would just be different specific frames. You'd determine those from finding those parts in the whole TAS. When those frames are reached, another settings for the video take their place. That can be coded pretty easily, even more with the Windows GUI. Maybe even "stop" recording for world map areas too!
partyboy1a wrote:
(3) supports offscreen syncronization
You mean because of the Camhack? Isn't that a bit... too game-specific? I want to keep this as general as possible.
partyboy1a wrote:
(5) has a much better interface right now
Thanks! It's my first time using Windows GUIs really! I've always coded my own.
partyboy1a wrote:
(6) doesn't depend on MSU or AVIsynth (at least I think so...)
I'm just using a binary version of ffmpeg on snes9x's folder for encoding the final video. All frames are extracted to a "dump" folder in PNG quality if you want, which is lossless.
- 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...
Sadly, I don't really have any idea of how to approach this. Here's a thing tho, if you can contact the authors from VGmaps, they might have their editing files around, and may offer to turn off those layers.
I still don't have a clue of how could I leave the old map "written" without screwing up with some sprites, like Mario's, or just some enemies...
For my Mario movie, I used maps I found somewhere on the internet, but I think the movies will look better by using (1).
Will this process of yours be too game-dependent? I'd be interested in hearing how you want to approach it.
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...
Ah, thanks for that! I'll surely try it out. I was bashing my head against a wall wondering how those values didn't actually work. Of course, I even forgot the most silly game programming roots! The updated value AFTER the current rendered frame will obviously be the value for the next one, not the actual one. How silly of me, I guess that could be fixed with just a single delay.
SMW uses multiple values too ("ingame" and "map mode")
And that could probably be fixed with the "breakpoint" system. It should still be game independent and quite useful for encoding a TAS! Of course, it'll take some serious time to set up, but as long as you organize your maps pretty well, there's no problems.
Let's see if I can manage to code this! BTW, my tool is not a "script" actually, it's built in the snes9x code. Source is a bit horrible tho, I need to write this all in a single source file, so I can easily implement it in another emulator.
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.
Damn that's a lot of suggestions... But I'm interested in playing around with the multi frame render you speak of. Of course, some new options have to be added then. Not sure that every game would use the same layer, so you'd have to define the numbers of which layers to use. I fear that something like that would have a horrible performance though...
(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
Even though it sounds great, it's way too much game-dependent for my tastes. There's no universal way how games handle level loading sadly to have a clue where we could start. Sure, we can see that with SMW, since the values are already written on the internet...
Using your idea once again, the "breakpoint" defined user system could have their frames editable. You see, you would have a lot of pre-defined settings for the game, created by yourself.(Example: Yoshi's Island 2, Vanilla Secret 1, etc.) For encoding a new TAS then, what's necessary is changing the frames the player enters these areas.
(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.
That sounds pretty impressive. I'll give it a try.
(C) preview for the final result. This should be very easy to do.
That's already done. If you press "Test Frame", it renders a single frame, and even opens it in your default image explorer.
BTW, is your interface portable to other systems like linux? I used "auxlib" and the "iup" libraries, they seem to be completely system independent.
You mean the GUI? I doubt it, since I just used a resource editor and most of its code is Windows only. If you mean Allegro, it's completely cross-platform across OS X, Windows, and Linux.
Just a few words to congratulate each of you for the formidable work and atlas videos. It's like the next generation of tool assisted movies.
I hope the tools you are inventing will help make TAS even better, without being too tedious. I'm expecting Zelda 1 and its overworld and dungeons to make a really interesting result.
I never sleep, 'cause sleep is the cousin of death - NAS
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!
With some games the HUD is part of the sprite layer, with others it's part of the background layers.
1) Define HUD-free area on the sprite layer and background layers.
2) Turn off the sprite layer.
3) Move camx and camy across the map and make screenshots. Append the HUD-free area of every screenshot to a larger image at the appropriate position. If you do this for every frame, animated backgrounds and terrain changes will work.
4) Turn off the background layers this time.
5) Move camx and camy across the map and this time do the same for the sprite layer. Set the background color of the resulting image to be 100% transparent. Do this for every frame. (You can leave the space where camx and camy really are empty for every frame.) This will give you the offscreen NPC/objects movement for every frame.
6) Merge these two images for every frame. (Alternatively, you can just draw each individual shot of the sprite layer directly onto the corresponding background layer shot, obviously)
7) Now turn on all layers, and add the actual on-screen action to the video (including the HUD).
Voilà?
Problems with this approach:
- It may take a long time to create these videos that way.
- If the HUD is leftbound and part of the background layers, for example, it won't be possible to get a shot of the leftmost part of the level this way. (For the specific example below, this could be fixed by marking another area to the left and one at the top as HUD-free on the sprite layer. With the sprite layer this won't be as much of a problem as with background layers anyway though)
- If the area that the HUD occupies changes (pop up messages?), that would be a problem as well. You'd maybe have to set up extra breakpoints for every such change for it to work properly.
- A LUA function that lets you turn off specific layers doesn't exist for every emulator.
- Some games can't be cam-hacked so easily.
- It also doesn't work with games where there are multiple background layers scrolling by at different speeds.
Example:
HUD-free on the sprite layer is red and HUD-free on the background layer is blue for Sonic3&Knuckles.
There's even more problems with the approach you posted Kuwaga. For example, games like Sonic load graphics as the player progresses through the level, and unloads others. That means that even if the maphack worked, several parts of the map would look corrupted.
I think this is going a bit overboard with the over-engineering. As I always say, KISS!(acronym)
If there's any kind of off-screen synchronization possibly going to be implemented, it would be changing the sprite layer as the map goes. I guess some smart detection of the differences in the sprite layer would make it work simply.
And I mean really, there's no need of going so much around trying to detect the actual map/camera coordinates. As much as I'd like this to be automatic, it'd probably cause more problems, and I can find these RAM values with some 10 minutes searching.
Detecting each new area? Useless as well IMO. Too game dependent, and the breakpoint idea is far simpler IMO, and once you set it up, all you have to do is change some frame numbers based on the TAS.
So far, this is the only stuff I'm considering to implement next:
* My previously described breakpoint system, which would change the recording parameters when an specific frame is reached.
* Synchronization of an object layer as the player goes through the map. That way, object shall remain in the atlas map the way they were left(used blocks, killed enemies, etc.)
* Multi-frame output support dependent on different layers. This would be extremely useful for video editing later.
And a bonus one:
* Try out AnimMerger support.
Once I get those 3 core points done, I might consider some of the more wacky stuff proposed here.
EDIT: I wrote this all in the Quick Reply box, wow.
There's even more problems with the approach you posted Kuwaga. For example, games like Sonic load graphics as the player progresses through the level, and unloads others. That means that even if the maphack worked, several parts of the map would look corrupted.
I didn't count this as a problem because the result would show what's actually really happening in the respective games and I'd find that quite interesting to see. If enemies pop up out of nowhere and suddenly disappear, then that's just the way that game works and imo not a problem.
I may be the wrong person to talk about this issue though, as I honestly find atlas videos to be quite boring. I just saw partyboy1a's suggested algorithm and replied with my suggestion, which to me seems much less complicated. It also doesn't require bg-maps to exist or anything.
Dario_ff wrote:
I think this is going a bit overboard with the over-engineering. As I always say, KISS!(acronym)
If this is directed to me, then I don't quite understand. This is one of the most simple non-game-specific ways for adequate off-screen syncing that I can think of. You don't have to map out the whole stage for every frame using that approach, if that's not desired. In Sonic3&Knuckles, for a 3xwidth and 1xheight view, you'd only have to take 10 automated off-screen shots per frame using that method (4+4 for off-screen sprites and 2 for off-screen backgrounds) and the off-screen action would be 100% adequately represented for that area.
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"
If this is directed to me, then I don't quite understand. This is one of the most simple non-game-specific ways for adequate off-screen syncing that I can think of.
Oh sorry, it wasn't directed to you. Your approach was simple and mostly game-independent, but most of those game's logic would suffer from what I said. I would expect objects to pop out of existence, but seeing glitched parts of the backgrounds is almost assured.
What I mean with KISS(remove the "stupid" part, sorry :)), is that 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.
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...
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.
I think in those cases, you'd actually need to split the mapfile yourself. Or you could specify a region of one big bitmap to work as an independent map. 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?
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"
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.
With the above approach, imagine you once set up an SMW TAS using this encode. Then, a new, improved TAS pops up. All you have to do is use this option, and watch the entire TAS. When the message pops up, you simply say "redefine this breakpoint's frame to this".
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
I've implemented the breakpoints system now, so the other two core points remain.
You can create the breakpoints, put different stats to each of them, and you can set them to the exact frame thanks to detection. When a RAM Value changes suddenly and in a really big difference(like >10), the program will assume there's a breakpoint there, and ask you whether you want to set the frame of one of them(you can put names to identify them more easily), add another frame, or create a new one.
Here's a video example of the raw footage produced by the emulator. I didn't join nor edit the videos, they're directly from the Atlasizer.
Link to video
(Oh yeah, I set the lower map a bit too short. It should've been taller, but that can be edited easily on the GUI, it was just my second recording and didn't want to do this all over again since rendering is long and boring :P)
It's worth noting that breakpoints can use more than 1 keyframe. That allows you to reuse important settings without creating thousands of breakpoints. A good example would be the world map in SMW. All the sections of the video you see that look like the normal game have the settings of that breakpoint.
The other two core points will probably be the hardest though. I'll help myself by looking at your scripts, though I'd appreciate some guidance and as much technical details as possible.
Also, I need to redesign the GUI. If you want I can send you the current .rc so you edit it yourself. If you prefer another design or another organization, I'm welcome to all suggestions.
And yeah, a TAS can be encoded like this currently. It lacks some polish and the synchronization, but we're close.
There's quite a bit of overhead though, since I'm using an external library(Allegro) to process the images, instead of the native snes9x routines. The reason is: a) I'm lazy to learn how snes9x works with bitmaps. b) I want to easily port this to other emulators.
And yeah, a TAS can be encoded like this currently. It lacks some polish and the synchronization, but we're close.
