Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Raiscan wrote:
I've noticed that while theres a somewhat noticable pattern to the alternate mood numbering, the ones at the end are a bit random. I was wondering if there was a reason for this?
40..255 are those I originally planned for my private use only. Only later I enabled those numbers for other users. In the same run, I also decided numbers for the alt avatars, i.e. 1000+main number.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
superjupi wrote:
Hmm... the mood report page seems a bit broken again; the page is saying that I don't have images specified for avatars that I most certainly do have specified.
But you haven't used them anywhere.
There are only two ways for the page to detect which avatars you have actually defined:
-- Just display them all, all 34 images for each user. And cause lots of redundant web access. Some 404 messages may be huge images. Not worth displaying them.
-- Try to download them on the server and interpret the results. Not going to do.
So instead, it just displays those avatars that are being used in some posts. This way, if you have to complain about someone's oversize avatar, at least you're complaining about something they actually have posted.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
alden wrote:
I'm using a hack that allows joypad input by the way... If you could get the actual mouse working that would be a huge time saver right there as I assume you could move arbitrarily fast between points on the screen.
Yeah. The problem is that there is no correspondance between the emulator's knowledge of mouse cursor's position and the actual position in the game.
The movie file describes an absolute position of the mouse cursor. When you make a movie, this position is clamped to the range 0..255 horizontally and 0..239 vertically, assumed to represent the entire screen. But this is not what the console gives the game. The console gives the game delta values, and the game is free to interpret those values as it pleases. snes9x calculates the delta by comparing the previous and current mouse positions.
The consequences of this design is that if your cursor is at (220,220) (as snes9x thinks) but in fact, in the game it is at (220,150), and you attempt to move the cursor down, when snes9x thinks your cursor is at (220,239), you no longer can go down, even if the game cursor is only at (220,180). If you try to go further down, the mouse escapes the snes9x window. In order to get the game's mouse cursor further below, you will have to move the cursor up very quick (jump immediately to snes9x coordinates (220,80) for example), which will cause the game to ignore the movement: the game's cursor stays at (220,180) or somewhere nearby. Now you can move it further down.
This problem makes mouse-using movies practically impossible to create "normally".
In the movie file this problem is mitigated by the fact that the 0..239 clamping does not happen. Instead, it is clamped to -32768..32767 range. (Hope your best that this range is sufficient!) This enables you to roam the cursor freely.
However, the problem is knowing where the cursor is:
When you feed the game a delta of 1, it is safe to assume that the cursor moves by 1 pixel. However, when you feed a delta of 20, the cursor might move by 15 pixels, or 40 pixels, or 0 pixels, depending on how it is programmed. This makes it very difficult to predict where your cursor is, and more importantly, to predict what kind of input you need to generate to place the cursor in some specific location.
In Mario Paint, I did some testing, and I found the following
-- If you move the cursor vertically more than 1 pixel per frame, a slight vertical desynchronization will happen and very soon the cursor is not where you think it is.
-- You can move the cursor horizontally as fast as you like -- well, almost. Moving more than ~80 pixels per frame will cause the game to ignore your input, but otherwise, it's desync free.
-- Unless the game is busy. Mouse events, including movements, are ignored when the game is busy. Such as after setting a pixel, or after clicking an icon.
-- Clicking something for 1 frame does not register. Clicking for 2 frames usually is enough.
-- Occasionally the game forces your cursor to some position on screen. For example, when you click "save" on the custom cursor editor. Your input generator must be aware of this fact, or you'll experience a desync.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I don't get it. How do you even draw pixel by pixel in Mario Paint? All tools I have tried have at least 2x2 pixels footprint on the canvas.
Or is it that there isn't any choice, and you must thin the lines by overlapping them with different color lines?
EDIT: Ah, figured it out. Use the "special stamp" feature to create some handy brushes for the movie.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
To utilize the paint/floodfill tool effectively, you should first run an edge detection filter to the image (basically, plot everywhere where neighbouring colors differ), then draw the sections indicated in that image (using the image's intended colors, of course), and then floodfill everything that was missing.
When you detect the edges, you should probably ignore the individual pixels in dithering patterns and concentrate on the perceived color.
For gradients, there's no other way than to plot the dithering patterns manually (hopefully utilizing the predefined dithering brushes where possible).
Using the copy&paste tool would be neat, but I don't think there are many places in most images where that would work.
For generating a natural looking method of drawing the edges you could apply a floodfill style algorithm. Just follow the edges in the direction that is in the same color and has the least angular change, and when you hit a dead end (a point that has no surrounding pixels that are yet to be traced), choose another yet unprocessed intersection / edge (preferably one that is closest to where you stopped) and repeat, until you have traced all the edges. When choosing another point to trace, try to choose one in the same color; and if none are remaining, then choose a different color.
When drawing the edges, estimate the width of the brush needed, and draw on the center of the edge. If the brush is wider than needed at some point, keep drawing; you can later come back and tidy the overdrawn portions. Keep track of what you have drawn by simulating the algorithm on a virtual canvas, so you can see what still needs to be done. Just be careful that you don't create an infinite loop by overdrawing on two overlapping locations in turns.
For the floodfill, you should research on the algorithm used by the game to perform the floodfill, and choose a floodfill point that is fastest by the game to perform. If there are no differences, then choose the point by artistic concerns.
To find the end of lines, you could use a an algorithm that checks each remaining pixel of the image and plots a virtual line to each eight cardinal directions along that line, and chooses the pixel where the average length of those lines is the shortest. To avoid embarrassing misestimations at jittered edges, you should probably do so for every the 5-pixel star shaped groups.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
alden wrote:
scolorq looks great, however from the page it looks like it does not support custom palettes as of yet... unless I missed something. Any other suggestions for good palette reducing? I'm on Windows XP btw :S
Hmm, you're right. If you've got a fixed palette, then it's just the matter of selecting the best dithering algorithm. http://en.wikipedia.org/wiki/Dither#Dithering_algorithms
My recommendation is to use little to no dithering, e.g. ordered dithering with 2x2 pattern at most. This would also enable you to use the predefined dithering patterns in Mario Paint to speed up the painting.
I did some testing with Imagemagick and Scolorq (these were not captured from Mario Paint):
Image 1: Image with Mario Paint palette, no dithering
Image 2: Image with Mario Paint palette, hilbert-peano dithering
Image 3: Image with Mario Paint palette, o2x2 dithering
Image 4: Image with Mario Paint palette, o2x1 dithering
Image 1: Image with Scolorq custom palette and default dithering, one would naturally change the colors to closest approximates in Mario Paint
Image 2: Image with imagemagick custom palette and o2x1 dithering, ―"―
Image 3: Image with imagemagick custom palette and o2x2 dithering, ―"―
Image 1: I think imagemagick's ordered dithering algorithm is broken somehow. I wrote a custom program. This image has a 2x1 dithering pattern and Mario Paint palette.
Image 2: The same, but color comparisons done in YUV colorspace.
Mario Paint palette for reference:
A few more:
Re: Adjusting the images, I suppose a neural network program could be developed to adjust the image's colour curves (i.e. saturation, lightness, contrast and hue) to optimize it to best fit to Mario Paint palette with or without 2x1 dithering patterns.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Warp wrote:
Programs like imagemagick can take a user-defined color palette and then color-reduce + dither an image using that palette. It should be fairly easy to automatize, given that Mario Paint uses a fixed palette (AFAIK).
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Let me take a moment to remind everyone that it is a bad idea to force the use these of any of these keys for any hotkeys:
[ ] \ + ` * - / ; :
Unless you intend to limit the use of the program to users of certain particular nations.
On Finnish keyboard,
/ is shift and 7 (scancode 0x08)
[ is altgr and 8 (scancode 0x09)
] is altgr and 9 (scancode 0x0A)
+ is the key next to 0 (scancode 0x0B)
\ is altgr and the key next to 0 (scancode 0x0B)
` is shift and the key next to the key next to 0 (scancode 0x0B), followed by space
* is shift and the key next to the key next to the key next to L (scancode 0x2B)
: is shift and . (scancode 0x33)
; is shift and , (scancode 0x34)
- is the key next to . (scancode 0x35)
altgr is the rightside alt.
FCEUX had ` as a hotkey for turbo. It is hardly a convenient hotkey ― especially as it wouldn't work at all. I had to edit the source code to make it recognize at least something.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Warp wrote:
When all of this has been created, it would be possible to convert any image to an optimal Mario Paint movie file. After that it's only a question of searching the coolest possible images. All automatic (ie. basically bot-created), no rerecording needed.
Of course this task would be far from trivial.
This would definitely be interesting, but far from trivial indeed.
I can see a number of large programming challenges in the making of such program. For example, the drawing of a simple stick figure is already a variant of a travelling salesman problem :)
Mario Paint's large number of tools doesn't make it any easier, either.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Yesterday for the first time I tried a bit of Lua too.
I'm making a bot for beating Yie Ar Kung-fu in the fastest time.
I posted some source code at http://tasvideos.org/Bisqwit/LuaFunctions.html ― it contains many functions and a framework that might be useful for other bot makers as well.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Randil wrote:
NesVideoAgent wrote:
* Emulator used: FCEU 0.98.12 or compatible
You used 0.98.12 for making this movie? Isn't that emulator pretty obsolete, or did I misunderstand something here? Just curious. :)
"Or compatible" is the key here...
I'm not using any standard version of FCEU, because as everyone knows, those version releases are strictly Windows-only. When you go and try to port it to Linux, it's no longer the same version.
My approach has been to extend the once-got-working FCEU version (which happens to be 0.98.12) with minimal changes to get newer movies to play -- the latest patch I have applied has been that of 0.98.15. But that doesn't make it 0.98.15, it's just a Bisqwit version. So I could just as well label it as "0.98.12 or compatible". That's the one I have used for making all the FCEU TASes I've made and for encoding all the FCEU submissions that I have encoded.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Swedishmartin wrote:
This got me wondering, though. If libc-dev is for source code compilation, then what's the regular libc for?
For providing the machine code that is used by programs using libc.
Library provides the machine code. Dev library (which is, the #include files) tells a compiler how to use the library. (Also, the dev package includes those libraries that are normally linked statically to the binary, as opposed to loaded runtime from the disk.)
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
According to NesVideoAgent, you have used a Chinese translated hack version, not the original version.
However, because of shortcomings in the VBM movie format, it is impossible to verify the ROM version with 100% certainty ― this means that it is possible that NesVideoAgent hit the short straw again and you did in fact use a proper ROM.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Ersatz wrote:
That is amazing work and awesome, but I gotta be the guy who says... Now, can we get it for the dreamcast?
Is there a Dreamcast emulator?
Edit: Or rather, is there a Dreamcast emulator for Linux? (Because this technique is not ready for use on other platforms such as Windows yet.)
Edit 2: There is at least one ― lxDream. It even has source code available! Source code makes things so much easier.
Now, the next questions to be answered are:
― Can it play games?¹ :) How well?
― Does it output synchronized sound (i.e. 44100 samples of audio per 60 frames of video regardless of host system lag / turbo)? Does it have a no frame skipping option? (It doesn't matter if such option makes the emulator run slowly.) If it does not have those features, then it becomes difficult (or impossible) to record a smooth video.
― Does it have savestates?² How robust?
After satisfying answers to those questions, adding a multimedia rerecording to the emulator is just a matter of some coding, which is best done by someone who is motivated with working with that console. Right at this moment, that excludes me. (But I can help with information concerning the code I already have written.)
Edit 3:
¹ Seems like the game compatibility is even worse with lxdream than it is with Mupen64. Hopes for playing <insert game name here> are rather low.
² Seems to have. Robustness is an unanswered question.
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I am being reported by "TheVoid-" that "In the newly added Double Dragon 2 TAS, adelikat forgot to change the information stuff in the video. It still says it's "Kick Master by dragonxyk".
Editor, Experienced Forum User, Published Author, Active player
(296)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Baxter wrote:
Since this topic was bumped, I guess I can ask again after a year. Aren't there any opinions on the idea I posted above? It would be nice to get some reactions on that... I still think it's a good idea. Bisqwit said he wanted ideas, and wanted changes... and while he somewhat responded, he didn't say whether or not he thought it was a good idea.
Sorry for ignoring your idea.
I am still a bit uncomfortable with the idea of putting the players on a scalar line. But still, it is slightly better than nothing at all.
Maybe I'll still end up implementing that in a form or another, since it's the most complete idea of all that we have had.
Image 1: Image with Mario Paint palette, no dithering
Image 2: Image with Mario Paint palette, hilbert-peano dithering
Image 3: Image with Mario Paint palette, o2x2 dithering
Image 4: Image with Mario Paint palette, o2x1 dithering
Image 1: Image with Scolorq custom palette and default dithering, one would naturally change the colors to closest approximates in Mario Paint
Image 2: Image with imagemagick custom palette and o2x1 dithering, ―"―
Image 3: Image with imagemagick custom palette and o2x2 dithering, ―"―
Image 1: I think imagemagick's ordered dithering algorithm is broken somehow. I wrote a custom program. This image has a 2x1 dithering pattern and Mario Paint palette.
Image 2: The same, but color comparisons done in YUV colorspace.
Mario Paint palette for reference: 
A few more:
Re: Adjusting the images, I suppose a neural network program could be developed to adjust the image's colour curves (i.e. saturation, lightness, contrast and hue) to optimize it to best fit to Mario Paint palette with or without 2x1 dithering patterns.