That doesn't do anything to help out with the problem under discussion, though. You can record at a different framerate than the game plays, but you can't slow anything down.
Yeah it doesn't, the recommendation was bad because the user just happened to have good hardware. It kinda misses the point of what I was asking, so sorry.
I'll keep using KKapture, I just need to figure something out with it and I'm all good. Thanks for the help!
Neat program, but it seems it has some problems when closing down fullscreen applications and then the output video gets invalid.
I'm currently trying out this guide tho using VirtualDub and a fair share of other software. Looks promising, a friend said he had really good results with it. Thanks for the help tho!
http://www.genadmission.com/vdubguide.html
So I was wondering if there's any programs out there to do recording of PC game footage, but halts the game until the next frame is recorded and dump. Audio is not a priority, but I'd like every single frame to be dumped. I don't care about lag while recording as bad as it can be(it's a replay I mean so no input is required), I'd just like to not miss any frames regardless of how bad my hardware is at recording in real time.
I've heard of Hourglass but it seems it's not designed yet for most modern 3D games so that's a no-go I guess(got some bad graphical glitches when using it, but it's fair, it's not designed for it, still an impressive tool tho). The point is I'd just like to get some pretty smooth 60 FPS footage stitched together, and audio recording isn't important at all since it'll end up overwritten anyway.
I doubt this is really feasible given that any game might handle timing however they please, but since I've seen programs that can apply manual FPS caps I was wondering if it would work as well. If the only solution is to just throw more hardware in and just do real time recording I understand. : P
Thanks in advance.
Partyboy1a, I'm sorry I didn't work on this anymore, it's just that I lost the interest on it. :( I do think it's in a usable enough state though, so feel free to add anything you want. It was a fun project, but I just don't feel like adding some of the proposed stuff.
Oh and that video is very nice, may I ask how did you build it? :) If that stuff is on the LUA script you submitted, I guess it would be easy to add to the video rendering code.
Well, yeah, that's the whole source code from the snes9x-rr project. All I added was the "atlasizer" files in the win32 root, and made some changes to the .rc, win32.cpp and wsnes9x.cpp to add the GUI and set the variables. I'll start documenting it now and maybe split those files. I didn't have much time yesterday...
I couldn't even build snes9x-rr on Code::Blocks with MinGW either. I don't really like Visual Studio 2008, but since it already had the dependencies compiled for it, I just said what the heck, I'll use it.
Using VS2008 you should get it built without any problems IMO. Just opening the .sln in the win32 folder and building the solution.
And I might learn some more spanish...
Hehe, why? I'm Argentinian(spanish), but did I leave something untranslated there? AFAIK I always code in English...
EDIT: Noticed the PM. I added you. I guess you can commit any changes you want now.
I've set up an SVN Repository over at Google Code.
Clicky!
I just need your google mail to add you to the project. If you have any fear of spammers, just rot13 it, or send it via a PM. Or just make a comment in one of the commits.
I've added various fixes and features today, check out the commit's comments. I suppose it should build out of the box by using the .sln in the win32 folder. Use Visual Studio 2008 just in case instead of 2010.
There's no guide, though there's an old PDF I sent nesatlas the last time in the __bins folder inside win32. Check it out if you want. It's functional for the moment, though I need to implement the background masking back using the multiframe support we talked about.
Oh, I think that's a bad idea. Binary data can become completely useless just by small changes in the internal data handling. I recommend to use the same format as Snes9x uses, or some kind of XML file. I'm sure there are libraries available for that, but I can also write a parser if that's necessary.
Mmm, I can move back to INIs without problem, I was just lazy to write out each single parameter all the time... But you're right, you can say bye to backwards compatibility that way.
I can't help that much for developing those functions. My programming experience for C and C++ is practically zero. I learned some Java, but Java doesn't use any * or & operators...
Don't worry, C/C++ ain't really that hard once you've learned another language. Just some minor quirks regarding syntax, pointers, classes, etc.
I'm trying to figure out how to set up the repository now, but first I need to make this code readable. :P
- I think the GUI shouldn't display all the settings at once. Tabs may be a better solution
Aye, and a good chance to learn how to handle tabs as well for me.
- I don't understand the meaning of RAM Watch Index
Oh, maybe that's a left over I should try to do in some other way. Snes9x has a list of Ram Watches to load. If you want to specify which of the two addresses are the values to use for the camera, you can set them here. 0 means the first watch obviously. But now that you mention it, maybe it'd be better to use a RAM address, or both choices. I don't know.
"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)
Agree with you here, once I get the chance to do the "Render Nothing" frame, I can use that as a background. It'd require next to no input from the user as well. And as you said, game independent, just what I'm looking for.
- 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.
Sounds right. Snes9x even requires PNG to build anyway, so it'll be supported no matter what. Those options can go for all I care, I always use PNG.
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.
Ok, sounds right again.
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, I'd love to, I just feel a bit embarassed about my coding style and that I'm using an external library, which will prevent people from building it easily. But I shouldn't really care anyway, I doubt more than 2 people will look at the source, just put a stable build on the downloads page and call it a day.
And in fact, it'd be my first experience in setting up an SVN repository, which would be good for learning I guess.
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?
Those settings are saved in the Atlas/cfgs folder. Single files for each game actually. They're not human readable anymore like at the start(INIs), they're binary data. So yeah, if I had a new TAS of those two levels, all I had to do is turn on the breakpoint detection, play the movie, and set the frame whenever it asks me to.
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 knowledge about licenses is next to none. :D If you mean just open-source, available to use, no commercial purposes, I have no problems with it.
And to the last Multiframe support idea, wouldn't it be easier to just do a savestate, render with different layers, load savestate again, render different layers... Repeat until it's done for this frame? Of course it'll increase the overhead more already, but it's multiframe support after all...
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.
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".
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.
You might want to try if the emulator supports recording the game well without any frame limit too(AKA turbo mode)! It can make encoding a playthrough a very short task!
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.
(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.
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.
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.