1 2
Posted: 1/11/2011 11:52 PM
Quote
partyboy1a
Player (137)
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.
Posted: 1/12/2011 1:59 AM
Quote
Dario_ff
Joined: 1/5/2011
Posts: 15
- 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...
Posted: 1/12/2011 12:22 PM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
Dario_ff wrote:
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. [...]And in fact, it'd be my first experience in setting up an SVN repository, which would be good for learning I guess.
If another person is going to read your code, you must make the code readable. The good thing is that your code will contain less bugs and it can be reused much easier. Learning is always a good thing, so I will let you setup some SVN repository. You'll have to give me writing permissions (so some username and password I guess), otherwise it would be useless. I only know Google Code for this purpose, but you're free to find another host.
Dario_ff wrote:
[The breakpoint] 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.
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.
Dario_ff wrote:
If you mean just open-source, available to use, no commercial purposes, I have no problems with it.
I'm not an expert for licenses, but as far as I know: Yes, all that applies to the GPL. It even prohibits to use the software in any non-GPL software. Everyone can modify the code, but such modifications must also distributed under GPL. The details are more complicated. For example, Firefox has some kind of open-source license, but no one except the original developer (whoever that is) may distribute modifications of Firefox under the same name.
Dario_ff wrote:
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...
That's exactly what my mark_object_test.lua file (in the nes-astrix package) does! It shouldn't be too difficult to find a way to implement the functionality directly into the emulator, but it might produce many side effects... If you can find ONE function which does ALL the drawing for the current frame, it might work to edit this function in a way that the drawing gets repeated for each set of layer settings. (Which layers should be used must be stated explicitly, because rendering all possible combinations will take much too long) Then you would write a function like getmultiframe(x) which does something like the lua function emu.gdscreenshot() That might be by far easier to implement. 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...
Posted: 1/12/2011 1:31 PM
Quote
Dario_ff
Joined: 1/5/2011
Posts: 15
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
Posted: 1/12/2011 7:32 PM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
here is a little preview for my task "movie dependent enemy placement": One necessary thing is to identify the sprites. It's quite effective, but it's not efficient. it takes about two seconds per frame... Edit: I also managed to create some code to save the sprites as PNG... another 260 lines of code...
Posted: 1/12/2011 9:58 PM
Quote
Dario_ff
Joined: 1/5/2011
Posts: 15
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.
Posted: 1/12/2011 11:48 PM
(Edited: 1/13/2011 7:34 PM)
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
Wow, that's much sourcecode... I could even find your ~1500 lines of almost completely undocumented code. I'll set up a new google mail address soon. And I might learn some more spanish... I can't compile anything (with CodeBlocks), it says "int32 does not name a type" for snes9x.h line 299... I'll have to get Visual Studio to get it running. (EDIT Check your inbox to see my mail address) EDIT2 First commit done! (almost everything is just requesting more comments...) I don't have enough time right now to get into the code AND to learn all the C / C++ stuff, it will take a few weeks before I can really help you there. I will stay with the lua scripts in the meantime. I will commit them to some folder...
Posted: 1/13/2011 12:29 PM
Quote
Dario_ff
Joined: 1/5/2011
Posts: 15
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.
Posted: 1/18/2011 12:09 AM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
I've got another idea comparison movies! Some of them have already been done, for example for Super Mario World. The problem is that they have been created with an extremely specialized Lua script which will work only for this game. I made a script which can extract sprites from the game. It may be modified to extract the main character sprites only. The sprite position in the "old" TAS should now be auto-detected and drawn onto the "main video". It shouldn't be too difficult to use a game-independent way for creating the comparison movie.
Posted: 1/20/2011 1:39 AM
Quote
andymac
Experienced player (623)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
For a large number of consoles there is a part of RAM called the OAM, which has all the sprite positions and attributes. It is in the same place for any game, and it is extremely accurate. It shouldn't take more than 1/1000th of a second to find and label all the sprites on screen this way, so instead of identifying sprites visually, which would take a while, use the OAM. Also, there is usually some RAM specifically for the graphics of anything on screen. If you find this, you should be able to draw any sprites onto an atlas map.
Measure once. Cut twice.
Posted: 1/25/2011 9:18 AM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
Hmmm... That's really accurate, but it's very console-specific. The code you gave me (thanks!) works for GB, but not for GBA. It'll be necessary to write some kind of wrapper for each console, and maybe an additional wrapper so that the code can be applied to other emulators with little effort. I'm thinking of some kind of interface like that: (pseudo-code) 
class spritedata {
   virtual sprite[] getsprites();
}

class sprite {
   int x,y,width,height,id;
   BITMAP imagedata;
}
I haven't had a look on VBA's source code, there may already be some functionality like that... It's still be necessary to do some kind of collision detection, but it's much easier... And it will be necessary to detect "sprite groups". Otherwise, some parts of an enemy may be drawn at the right location and others not... I'll give it a try, but it will take some time.
Posted: 1/25/2011 9:39 AM
Quote
andymac
Experienced player (623)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'm not sure exactly why you need collision detection and detection of sprite groups. Most in game characters are a collection of sprites, but their positions are accurate. Also, if you want to you can basically externalise your own custom PPU, using bitmaps straight from VRAM. If you just render exactly as the PPU does, then you should have no problems whatsoever. (In all seriousness though, for emulators with a layer disable function, why don't you just disable any BG layers, dump the video and overlay it onto an atlas map?). Also it turns out that the GBA also has the OAM in the normal address space:
GBA Specifications wrote:
OBJ Attributes There are 128 entries in OAM for each OBJ0-OBJ127. Each entry consists of 6 bytes (three 16bit Attributes). Attributes for OBJ0 are located at 07000000, for OBJ1 at 07000008, OBJ2 at 07000010, and so on. As you can see, there are blank spaces at 07000006, 0700000E, 07000016, etc. - these 16bit values are used for OBJ Rotation/Scaling (as described in the next chapter) - they are not directly related to the separate OBJs. OBJ Attribute 0 (R/W) Bit Expl. 0-7 Y-Coordinate (0-255) 8 Rotation/Scaling Flag (0=Off, 1=On) When Rotation/Scaling used (Attribute 0, bit 8 set): 9 Double-Size Flag (0=Normal, 1=Double) When Rotation/Scaling not used (Attribute 0, bit 8 cleared): 9 OBJ Disable (0=Normal, 1=Not displayed) 10-11 OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited) 12 OBJ Mosaic (0=Off, 1=On) 13 Colors/Palettes (0=16/16, 1=256/1) 14-15 OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited) Caution: A very large OBJ (of 128 pixels vertically, ie. a 64 pixels OBJ in a Double Size area) located at Y>128 will be treated as at Y>-128, the OBJ is then displayed parts offscreen at the TOP of the display, it is then NOT displayed at the bottom. OBJ Attribute 1 (R/W) Bit Expl. 0-8 X-Coordinate (0-511) When Rotation/Scaling used (Attribute 0, bit 8 set): 9-13 Rotation/Scaling Parameter Selection (0-31) (Selects one of the 32 Rotation/Scaling Parameters that can be defined in OAM, for details read next chapter.) When Rotation/Scaling not used (Attribute 0, bit 8 cleared): 9-11 Not used 12 Horizontal Flip (0=Normal, 1=Mirrored) 13 Vertical Flip (0=Normal, 1=Mirrored) 14-15 OBJ Size (0..3, depends on OBJ Shape, see Attr 0) Size Square Horizontal Vertical 0 8x8 16x8 8x16 1 16x16 32x8 8x32 2 32x32 32x16 16x32 3 64x64 64x32 32x64 OBJ Attribute 2 (R/W) Bit Expl. 0-9 Character Name (0-1023=Tile Number) 10-11 Priority relative to BG (0-3; 0=Highest) 12-15 Palette Number (0-15) (Not used in 256 color/1 palette mode)
Measure once. Cut twice.
Posted: 1/25/2011 7:24 PM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
In all seriousness though, for emulators with a layer disable function, why don't you just disable any BG layers, dump the video and overlay it onto an atlas map?
Because the results aren't good enough... If you have a map from VGmaps and just show the sprite layer, you will find non-existent enemies in the final result. On the other hand, if you have a map without any enemies and just show the sprite layer, the result will be that the map looks unnaturally empty. And there's even one more thing which makes it really complicated: Background has a different scroll speed as the normal game. So that's what I did for my SMV video: I took a "nothing" video, a "sprites only" video, a "map only" video (the part of the background which scrolls with the right speed), an empty map, a non-empty map, created an "enemy mask" for the non-empty map with gimp, dumped the background picture, and made a png of the same size as the atlas pictures... And finally I connected them in a way so that it worked... You can imagine that's way too complicated for creating long videos. I'm aiming at making that more easy so that everyone can do it. Writing my own PPU processor... No, it would take forever to adopt it to different emulators. It should be as emulator-independent as possible. And I think it would introduce many new bugs... (At the moment I don't have enough free time for coding... I will continue coding in about two weeks)
Posted: 2/6/2011 10:33 PM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
The idea with using the sprite data directly was quite nice... I made a new video which shows how good it works already. I'm sure that would even be a nice feature for normal TASing... Note: This is absolutely console-dependent and completely game-independent.
Posted: 2/6/2011 11:48 PM
Quote
Dario_ff
Joined: 1/5/2011
Posts: 15
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.
Posted: 2/10/2011 1:25 PM
Quote
partyboy1a
Player (137)
Joined: 9/18/2007
Posts: 389
I submitted the Lua script and the AVIsynth script, they can be found in ./lua/etc/ You should use a RAMdisk for best performance, then the emulator will run at ~50 fps (for my computer at least). I haven't tried to implement this thing into the emulator directly, but it would be very useful for normal TASing... The emulator already supports "extend height" just to do some custom drawing in the bottom area of the screen, so it should be easy to create an emulator hack which does offscreen rendering... Best would be to do some kind of "early render", so that the offscreen content is drawn 10, 20 or 30 frames in advance. This would allow to fire bullets in such a way that the enemies get hit in the first possible moment (you might be able to kill enemies when they are still completely offscreen), and other useful things. I'll give that a try.
Posted: 3/3/2012 9:40 AM
Quote
XTREMAL93
He/Him
Active player (445)
Joined: 1/6/2012
Posts: 585
Location: Azerbaijan, Baku
wow! it is great!
Posted: 3/1/2014 1:36 AM
Quote
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
Flash TASer of 2022 PSX TASer of 2016
Well I attempted a map with Adobe. I have no idea how to replicate the fade in... because bomberman fades from dark. This is the TAS which was used. Obviously I didn't go for High Quality because it was a mini test. Link to video
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Posted: 4/1/2014 3:06 PM
Quote
NESAtlas
He/Him
Player (57)
Joined: 7/4/2010
Posts: 115
Location: Gales Ferry, CT
Spikestuff wrote:
Well I attempted a map with Adobe. I have no idea how to replicate the fade in... because bomberman fades from dark. This is the TAS which was used. Obviously I didn't go for High Quality because it was a mini test. Link to video
Looks great! To get the fade-in effect, you should create a solid white layer underneath the map, then simply adjust the map layer's opacity from 0% -> 100% in time with the video.
http://youtube.com/NESAtlas
Posted: 4/1/2014 3:29 PM
Quote
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
Flash TASer of 2022 PSX TASer of 2016
AndyDick wrote:
To get the fade-in effect, you should create a solid white layer underneath the map, then simply adjust the map layer's opacity from 0% -> 100% in time with the video.
I did that ... but the way the fade in works with bomberman is different. It isn't just fading in. It is also something going on like contrast or something...
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Posted: 4/1/2014 4:28 PM
Quote
NESAtlas
He/Him
Player (57)
Joined: 7/4/2010
Posts: 115
Location: Gales Ferry, CT
It was more of a quick band-aid fix rather than a true emulation of the effects since (I believe) most of the older systems don't even have the ability to adjust opacity levels. If you really want to recreate it faithfully, then you'll have to play with the RGB values most likely. It takes a lot more time to figure out, but it's definitely possible. EDIT: Here's a video where I heavily modified RGB values on the map to try and emulate the lighting changes. I'm happy with how it came out :) Link to video
http://youtube.com/NESAtlas
Posted: 4/2/2014 7:33 AM
Quote
CoolKirby
Editor, Experienced player (570)
Joined: 11/8/2010
Posts: 4036
Exotic platforms TASer of 2014 NES TAS of 2013
AndyDick wrote:
If you really want to recreate it faithfully, then you'll have to play with the RGB values most likely. It takes a lot more time to figure out, but it's definitely possible.
To make this process easier, you can always take a screenshot at each frame you want to find out the RGB values for, open the images in MS Paint, and use the eyedropper tool to find the exact values you need to use for your Atlas map. (I'm not sure if this is what AndyDick meant in the quote above, but it definitely saves a lot of time over guessing the values.)
Posted: 4/2/2014 2:26 PM
Quote
NESAtlas
He/Him
Player (57)
Joined: 7/4/2010
Posts: 115
Location: Gales Ferry, CT
CoolKirby wrote:
To make this process easier, you can always take a screenshot at each frame you want to find out the RGB values for, open the images in MS Paint, and use the eyedropper tool to find the exact values you need to use for your Atlas map. (I'm not sure if this is what AndyDick meant in the quote above, but it definitely saves a lot of time over guessing the values.)
Yeah, that's exactly what I meant, but After Effects already displays RGB values! Here's a quick screen shot of what I was doing as it's a bit more complicated than just RGB. The lighting changes multiple times in that quick beginning sequence when MJ walks in the door. Here's a timeline: 1. RGB values start where the screenshot is 2. MJ opens door & RGB adjustments go to 0 3. Outside lighting causes brightness to increase by 35 3b. MJ does a sweet spin jump 4. Door closes so brightness is back to 0 & RGB back to screenshot values 5. MJ flips a quarter in the jukebox causing indoor lighting to function & RGB adjustments go back to 0 So it's a bit more complicated, but hopefully helpful anyways. The 4 "change to color" were necessary as I think the color space of the atlas map was different than the footage which seems to always be the case. I can see you had the same issue too, but it's barely noticeable.
http://youtube.com/NESAtlas
1 2