- 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.
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.
[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.
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...
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.
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...
Edit: I also managed to create some code to save the sprites as PNG... another 260 lines of code...And I might learn some more spanish...
class spritedata {
virtual sprite[] getsprites();
}
class sprite {
int x,y,width,height,id;
BITMAP imagedata;
}
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)
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?
+fsvgm777 never censoring anything.
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
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.
+fsvgm777 never censoring anything.
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.)
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.
