Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Data wrote:
nitsuja wrote:
but I think I figured out how to make the game use a more correct font. Standby for more info on that...
Oh, and the regular encode (non Youtube) will have the correct font.
I guess you figured out that the font should be "MS Gothic", and found a way to set it to that? (Just checking that we came to the same conclusion.) Future versions of Hourglass (r79 and up) will automatically use that as the default/system font when the locale being simulated is set to Japanese.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The commentary subtitles are done. Several comments from the earlier version have been changed, so don't try reusing any of the old ones. Again, the timestamps correspond with an unprocessed AVI dump, so to use this on an encode with an intro logo they should be shifted forward by the logo duration.
Note to encoders: Hourglass r77 has a bug with AVI splitting (if you dump a >2GB AVI) that could randomly drop a few frames of video and/or audio at segment boundaries. This should be fixed in Hourglass r78, so I suggest using it instead of r77. There are no other differences between the two versions besides that fix. Oh, but I think I figured out how to make the game use a more correct font. Standby for more info on that...
ALAKTORN wrote:
how did you manage 269327 rerecords
I guess it's just my style to burn through rerecords. And it takes more precision to properly TAS each moment in this game than it might appear. The ratio of rerecords per frame actually stayed consistently that high throughout the making of this TAS, partly because new techniques kept becoming available and some sections had to be redone several times as I learned about them. And there's a lot of trial and error with things like luck manipulation, damage boosting, and getting 5 or more shots to hit in a frame.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
By the way, I made some subtitles that can be viewed along with the TAS. This is not for translation, but for explaining each trick in (some) detail as it comes up. Actually, it's not done yet, but I thought I'd mention it now. The timestamps currently match up with my own encode but I'm sure they could be offset for something else.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I refined my reasons for the language choice a bit in this post. Also, I'm pretty sure that no matter which version is used, there would be people saying it should have been the other one.
EDIT: As for the "best ending" tag, I think it's a good idea because otherwise people who aren't familiar with speedruns of the game might see the completion time and assume that it's not the best ending. It's more for information than for classification. (Maybe that's abusing the branch tag, but the text shows up in the perfect place for it...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DarkKobold wrote:
Right before you return Choco's Key, you hit the wall, and are forced to jump again. Did you avoid a text box or something? It looked awkward, but I do remember him saying something...
I actually jumped over that wall, I didn't hit it. Maybe it looks awkward but it was faster than the alternatives so I didn't really have a choice there.
(I'm assuming that by Choco you meant Santa and by wall you meant the little block on the ground.)
Truncated wrote:
The one that stood out to me was around 32:35 in the encode, but then you are under water so the different maximum velocity might be what's fooling me.
Around 32:35 I enter a water stream that forces me down extremely fast and I do shoot some shots upward there to reach maximum speed even faster, then I exit the stream into the regular "slow" water where I'm falling at the new maximum speed there so shooting up wouldn't do any good. And the speed limit in this game of 1535 (or 767 in still water) is enforced so strictly that even if I make my velocity value higher than the maximum, the game still won't move me any faster than that for even 1 frame.
Sonikkustar wrote:
The only thing I didnt like are the missed fireball shots you occasionally do. Sure its a very odd nitpick, but given the amount of precision that you have on the bossfights, this just sorta struck out as odd for me.
Fireballs don't always disappear after they hit an enemy, and they can do burning damage from a little more of a distance than you might expect, so most of the apparent misses weren't misses. If there are any genuine misses then I could still hex edit them out of the movie, since that weapon doesn't affect the RNG unless it hits something.
I added these clarifications to the submission comments.
Patashu wrote:
P.S. when is this run being put on nicovideo?
I'd like to see it there too, actually. I think it supports higher framerates than YouTube, and the scrolling comments are almost always amusing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Warp wrote:
Btw, what happened to the (admittedly not-absolutely-strict) rule that the English version of a game should be preferred unless there's a good reason not to?
Or was it so that the English translation is not "official"? (I have played the game, but I don't remember if the English version was "official" or a third-party translation.)
franpa wrote:
I'd rather an english translation, using the unofficial translation. Aeon Genesis is best troop for translations.
Originally I was going to use the English translation, but I decided not to because:
There are some existing TASes of the Japanese version, such as this and this. They aren't published here, but using the same version makes it easier to compare (for me and for them).
I'd say it's not an "official" translation. This is arguable because the game's author supported the translation, but it seems he didn't request or otherwise instigate it. Also, neither the game's author nor the game's translators provide the English version as a standalone download, it must be applied as a patch or acquired elsewhere. I think it's a good translation and of course I could link to some pre-patched version or ask people to apply the patch, but I think it would be harder to convince people that both versions have been released in equally official capacity.
It would decrease the ratio of gameplay to movie length. (And I suspect that the part where I surprise the Doctor into falling off the balcony wouldn't happen in the English version.) This probably isn't a good reason on its own under normal circumstances, but both version choices have drawbacks anyway and it certainly doesn't hurt that it's faster.
That being said, I wanted to create a "translation" of this TAS to the English version, but the random numbers that get generated are different between versions so I would have to completely redo a lot of sections, and the gameplay would have visible differences all over as a result. But the main reason I haven't done this anyway is that it would take a significant amount of extra time and I didn't see a reason to further delay this TAS. Hmm, maybe it would be easier to create subtitles containing parts of the aeon genesis translation for every screen of text.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Derakon wrote:
Nitsuja: any idea what your time would be for the hell run?
It was 2'04"1 in this run, but I know that could go lower if I were aiming specifically to minimize that time.
moozooh wrote:
For instance, does shooting machine gun upwards give a small downwards boost? It looked so, but wasn't used everywhere you needed to hit ground down faster.
It does give a downward boost, but only before reaching the terminal velocity of 1535, which happens pretty quickly. (Any specific examples?)
moozooh wrote:
Then, there were many enemies you could seemingly take a damage boost off of, but didn't. Not completely sure why either.
Like which enemies? There are multiple reasons why I might not damage boost from any given enemy, the most common one being that it's impossible because that enemy doesn't have solid collision.
Nicos wrote:
btw, why 640x480 ? the tas ran just fine for me in full screen mode...
Because certain video drivers are incompatible with the way Cave Story renders in fullscreen mode when running in Hourglass. For most people it won't help to change that option, but I put it there just in case.
Dada wrote:
right before you hitchhike a lift on that flying creature (before Sue gets beat up by Igor), would it be possible to manipulate it so that the creature flies a bit lower, allowing you to move even further into the level?
I don't think it's possible. I tried it for a while, but even when standing on the lowest ground nearby, it seems to never fly low enough for that.
Dada wrote:
in Hell, after the first boss, if you allow yourself to get hit (and invulnerable), you can clip through the hole in the ground (the part of the ground that's about to collapse), before the big block falls through. I suppose there's no enemy around to get the invulnerability from?
There's no enemy around, and I wouldn't have enough health leftover to fight the first form of Ballos as quickly if I took a hit here, and what I did instead is almost as fast anyway (it's not as if I waited for the boss to fall past before jumping in).
EDIT: I missed Nitrodon's comments somehow.
Nitrodon wrote:
I've played through this game a couple times
This is such an innocuous statement that I almost forgot to check who it was coming from.
Nitrodon wrote:
in Grasstown, when you reach the trigger to give Santa the key, you are off the ground and traveling upward. If my memory doesn't suck, the text waits for you to land, and thus it looks like you lose time here.
He actually doesn't wait for you to land, and it would have been slower to land first in my case. As far as I know, all waiting periods in the game are simply counting down a number of frames (and in some cases skipping the wait if you mash Z/X) no matter what it looks like they're waiting for, so it doesn't matter where you are or where the camera is when you get there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
AnS wrote:
some units to measure entertainment, so that ego-people could compete for these units as well as for frames
Then I propose we compete for "maximum average audio volume" (while still beating the game) instead of "minimum frame count". I think that could approximate a measure of entertainment, while still having an emphasis on speed except in some pathological cases. (Anyone willing to try it for April 1st?)
Bisqwit wrote:
"If a child receives a box containing an expensive toy as a birthday present, it's possible that he will enjoy the box more than the toy.
This is creativity.
We're doing the same for these games.
Instead of walking on the paths created for us, we create our own paths, our own legs and so on.
And we're not listening to people who say "you can't do that!".
Just like children."
I've always liked that quote, by the way (at least, ever since I got past the initial strangeness of seeing it where I had expected to see some bland explanation of what TAS means). We're not playing games, we are playing with games instead, and it's useless to accuse us of having fun "the wrong way". (TASing can easily be less fun than playing a game, from moment to moment, but that's not the point.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Good luck. Well, luck manipulation will probably be the most annoying part, anyway. This is the first game I ever tried to TAS, and there's plenty of room for improvement, I know. One obvious thing I should've done (hopefully you're already doing it) is using bombs to teleport forward. Even if that means dropping lots of extra bombs that cause some extra lag, it still probably saves time, at least early on in the game before you have many speed powerups.
EDIT: I think getting teleported/nudged forward should save something like 4 (minus the number of speed powerups you have) frames each time.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Here are some sort-of interesting ones:
t>>6|t>>5|t>>2/(t&23+t>>11)*7
(t*t^t%513)/(t^t%513)|t>>3|t>>5
t&27|t>>5|(t<33000?0:(t-18000)*(t-18000))>>17
simple triangle wave: (((t&32)?31-t:t)&31)
Hmm, these sound a little different for me in Firefox vs. other browsers. I think I'm hearing two overlapping instances of the sound.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
FractalFusion wrote:
Interestingly, anything with dialog in it automatically uses 512x448 resolution. Anything without uses 256x224 resolution, which makes the graphics have less polish. I can't explain it, but if that's how the game works, then so be it.
It doesn't make the graphics have less polish. When the game is in 512x448, all of the pixels are simply doubled (so it looks exactly the same as when the game is in 256x224), with the exception of Japanese text in dialogs, which is the only thing that makes use of the extra resolution. That's why the game only switches to high resolution when a dialog is onscreen.
EDIT: if the two modes look different for you in the emulator, that's an artifact of the graphics filter options you have set, some of which look different or don't work at all in hi-res mode. Try setting the video filter to "Simple 2X" or "Blargg's NTSC".
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Normally I contribute to threads like this by not posting in them, but here's one totally off-topic comment:
I briefly misread the topic title as containing "SDA" instead of "FDA", since I had recently seen some of an SDA charity marathon where the proceeds were donated to a cancer prevention foundation, and speedrunning is closer to the topics that usually come up on this site.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I can't say when anything will be compatible, but thanks for letting me know that this game isn't. I might have seen another game with a similar issue, "Elona", since both games attempt to establish a network connection and wait forever on a title or loading screen. I wonder if these games run when disconnected from the internet... if so, Hourglass could simulate that. But it could also be an unknown problem unrelated to the network.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It's more common to compile Windows programs with Visual Studio instead of gcc, so it's possible that FCEUX isn't set up to be compiled with the latter on Windows (maybe it should work though, I don't know). You should be able to install Visual C++ 2008 or maybe Visual C++ 2010 and then open "fceultra\fceu\vc\vc9_fceux.sln" and hit Build or Run from there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Lex wrote:
That wouldn't be tedious if you could mark a frame (with a keybind) to replay and rerecord back to at maximum speed, at which point, the execution is paused and you may continue watching (and rerecording) any further input from the previous input and take control at any time (also with a keybind).
That's... almost exactly what it already does if you start replaying the movie and then load a savestate that's in the future. But that's not going to work well on Windows 7 or Vista until this mystery is solved. And I would still call it unnecessarily tedious for that to be the intended re-recording flow... some games aren't efficient enough to run at 1000s of FPS in fast-forward mode, and that's still a significant wait every time as you get into a moderately long TAS. I should just fix the savestates instead, which I think I already know how to do (in this case, the problem is that certain drivers spawn "un-savestateable" threads for DirectDraw, and the solution is to run it in another process so that it isn't part of the savestates).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The issue you're probably getting is that some video drivers (usually ones made for Windows 7 or Vista) conflict with the way Hourglass currently does savestates. Look at this post/thread for some workarounds you can try.
I think someone already made a TAS of that game in Hourglass (which you can see here) so the game is probably supported, but it looks like they might not have used the built-in AVI export so I'd want to verify that that works too before adding it to the list.
EDIT:
Nuy wrote:
As far as I can tell to get Read + Write working you have to load state.
Technically you can use "File > Resume Recording from Now" (and "File > Watch From Beginning") to create a TAS with re-records but without ever loading any savestates. But that would get tedious really fast...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I guess this case is from telling it to click when it can't because the cursor is frozen. Making clickat() look like this fixes the first instance for some reason:
Language: lua
function clickat(x,y)
click = false
while ismousedown() do next() end
if mousegoto(x,y) then
click = true
while not ismousedown() do next() end
click = false
while ismousedown() do next() end
end
end
But the clickat(60,207) still fails after that because isbusy() doesn't detect the cursor being frozen due to switching screens. Another check could probably be added to isbusy(), or clickat() could detect that the cursor isn't moving at all and wait a few frames before trying again... or of course a workaround would be to manually add a sufficient number of calls to next(). Maybe I can look at it again tomorrow.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
This is because the target position is off the bottom of the screen for the cursor that was active before moving (due to the changing hotspot affecting the position). One way to fix this would be to switch (everywhere) to using the hotspot-independent coordinates that you would get if getcur() uses readwordsigned(0x7E04DC),readwordsigned(0x7E04DE) instead of readbyte(0x7E0226), readbyte(0x7E0227). That would probably also allow the script to run faster overall (due to fewer retries when the cursor changes). Another way that appears to work fine is to put in a hack like this:
Language: lua
local sendx,sendy = 128,127
local click = false
local curx,cury = "?","?"
local function getcur()
curx,cury = memory.readbyte(0x7E0226), memory.readbyte(0x7E0227)
local absx = memory.readwordsigned(0x7E04DC)
if absx < 64 and curx > 192 then curx = curx - 256 end
if absx > 192 and curx < 64 then curx = curx + 256 end
end
local function isbusy()
return memory.readbyte(0x7E016A) == 0
end
local function ismousedown()
return memory.readbyte(0x7E00DE) >= 0x40
end
local function next()
joypad.set(1, { x = sendx, y = sendy, left=click } )
emu.frameadvance()
if isbusy() then
local s3 = savestate.create(3)
repeat
savestate.save(s3)
joypad.set(1, { x = sendx, y = sendy, left=click } )
emu.frameadvance()
until not isbusy()
savestate.load(s3)
joypad.set(1, { x = sendx, y = sendy, left=click } )
end
getcur()
local valid_location = AND(memory.readbyte(0x7E0426),1)
gui.text(10,160, "cur="..curx..","..cury..";send="..sendx..","..sendy..",valid="..valid_location)
end
function mousegoto(x,y)
local s = savestate.create(1)
local s2 = savestate.create(2)
savestate.save(s)
local joy = joypad.get(1)
sendx,sendy = joy.x, joy.y
getcur()
if y > 195 and AND(memory.readbyte(0x7E0426),0x12) == 0x12 then -- screen bottom hotspot hack
curx,cury = memory.readwordsigned(0x7E04DC), memory.readwordsigned(0x7E04DE)
end
for attempt=1,8 do
xoff,yoff = x-curx, y-cury
sendx,sendy = sendx + xoff, sendy + yoff
for frame=1,6 do
if curx == x and cury == y then
if frame ~= 1 and not isbusy() then -- TODO: sometimes this is safe even when isbusy() is true.
savestate.load(s2) -- save 1 frame
end
return true -- success
end
savestate.save(s2)
next()
if y > 195 and AND(memory.readbyte(0x7E0426),0x12) == 0x12 then -- screen bottom hotspot hack
curx,cury = memory.readwordsigned(0x7E04DC), memory.readwordsigned(0x7E04DE)
end
end
-- we landed in the wrong place.
-- this will happen if the hotspot changed on us,
-- or if some unknown force is preventing our motion.
-- we'll adjust our target and try again a few more times.
savestate.load(s)
if xoff == x-curx then
if x-curx < 0 then
curx = curx + 127
elseif x-curx > 0 then
curx = curx - 127
end
end
if yoff == y-cury then
if y-cury < 0 then
cury = cury + 127
elseif y-cury > 0 then
cury = cury - 127
end
end
end
print('mousegoto('..x..','..y..') failed. it could only get to '..curx..','..cury..'. rolled back.')
-- failure
end
function clickat(x,y)
click = false
if mousegoto(x,y) then
while ismousedown() do next() end
click = true
while not ismousedown() do next() end
click = false
while ismousedown() do next() end
end
end
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The only way I can reproduce those results is by first clicking on the T to switch to the pen tool on the title screen, but isn't 194 an invalid Y coordinate in that case? I can't get it to go below 190.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Bisqwit wrote:
Here is my Lua function for producing a mouse click at a given coordinate in Mario Paint. It usually achieves the movement in a few frames, but sometimes it gets stuck in an infinite loop, circling the intended coordinates in an everlasting attempt to compensate for the perceived error. Does anyone have will to try to improve it?
This is at the core of my Mariopaint TAS.
This seems to work better for me:
Language: lua
local sendx,sendy = 128,127
local click = false
local curx,cury = "?","?"
local function getcur()
curx,cury = memory.readbyte(0x7E0226), memory.readbyte(0x7E0227)
local absx = memory.readwordsigned(0x7E04DC)
if absx < 64 and curx > 192 then curx = curx - 256 end
if absx > 192 and curx < 64 then curx = curx + 256 end
end
local function isbusy()
return memory.readbyte(0x7E016A) == 0
end
local function ismousedown()
return memory.readbyte(0x7E00DE) >= 0x40
end
local function next()
joypad.set(1, { x = sendx, y = sendy, left=click } )
emu.frameadvance()
if isbusy() then
local s3 = savestate.create(3)
repeat
savestate.save(s3)
joypad.set(1, { x = sendx, y = sendy, left=click } )
emu.frameadvance()
until not isbusy()
savestate.load(s3)
joypad.set(1, { x = sendx, y = sendy, left=click } )
end
getcur()
local valid_location = AND(memory.readbyte(0x7E0426),1)
gui.text(10,160, "cur="..curx..","..cury..";send="..sendx..","..sendy..",valid="..valid_location)
end
function mousegoto(x,y)
local s = savestate.create(1)
local s2 = savestate.create(2)
savestate.save(s)
local joy = joypad.get(1)
sendx,sendy = joy.x, joy.y
getcur()
for attempt=1,8 do
xoff,yoff = x-curx, y-cury
sendx,sendy = sendx + xoff, sendy + yoff
for frame=1,6 do
if curx == x and cury == y then
if frame ~= 1 and not isbusy() then -- TODO: sometimes this is safe to do even when isbusy()
savestate.load(s2) -- save 1 frame
end
return true -- success
end
savestate.save(s2)
next()
end
-- we landed in the wrong place.
-- this will happen if the hotspot changed on us,
-- or if some unknown force is preventing our motion.
-- we'll adjust our target and try again a few more times.
savestate.load(s)
if xoff == x-curx then
if x-curx < 0 then
curx = curx + 127
elseif x-curx > 0 then
curx = curx - 127
end
end
if yoff == y-cury then
if y-cury < 0 then
cury = cury + 127
elseif y-cury > 0 then
cury = cury - 127
end
end
end
print('mousegoto('..x..','..y..') failed. it could only get to '..curx..','..cury..'. rolled back.')
-- failure
end
function clickat(x,y)
click = false
if mousegoto(x,y) then
while ismousedown() do next() end
click = true
while not ismousedown() do next() end
click = false
while ismousedown() do next() end
end
end
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
I don't know how much time it takes to apply the scolorq filter
It varies, but scolorq took 11 seconds on the color scale image on my system. I think scolorq can be optimized more as well (it seems to spend about 20% of its time on allocating and deallocating memory on the heap in inner loops, and about another 60% of its time on simply inserting elements into STL vectors, which is a lot of time to be spending on the bookkeeping instead of the actual computation).
I put the version of scolorq I'm using here. It's based on the Windows source for scolorq 0.4, and has been modified so that I can use "m" to specify the Mario Paint palette and so that I can use .bmp files as input and output instead of only .raw RGB. I run it with a command line like "scolorq orig.bmp m out.bmp 0.9 3". The source image must be already scaled to the correct dimensions (248x168). Also, "m2" can be used instead of "m" to add the extra colors that can be simulated with 60hz flickering (it will take much longer and should be run on a 120x80 pixel image). The algorithm has some randomized elements and the dithering amount can be tuned somewhat on the commandline so you're unlikely to get exactly the same output images as I did.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
I made another approach where I divided the picture into 2x2 blocks and looked for the best combinations of 2 colors (one color in the NW and SE corner, another in the other two corners) for each of these blocks. This took care of the grey-scale issue, but the resolution isn't very good now
This probably also makes it much easier to draw in-game. But maybe a hybrid approach would work better (where it looks for a match with either a solid color or a pattern, whichever is closer on average)? Or maybe this is simply approaching regular dithering.
I think these images aren't the best sort of thing to try putting in Mario Paint, but for some comparison with ones you posted, here they are with scolorq dithering:
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The color quantization tests Bisqwit posted are interesting (I hadn't noticed them before). They mainly show how great a job scolorq does. Of course, it doesn't looking as impressive when it's restricted to a fixed palette such as Mario Paint's, but it's still pretty good at dithering (these are mockups using the correct palette):
Not needing to dither would be better, but there are so many colors missing from the palette that you probably need to either use extensive dithering or be extremely picky about which source image to use.
As for actually quickly creating images like this in-game... I would guess that the fastest way is to use the "draw sprite" tool to draw 16x16 blocks of solid color (or the eraser for the almost-white background color), then switch to smaller tools like the 2x2 pen and (if necessary) custom stamps or carefully-planned spray-paint for the detail work. Actually, custom stamps aren't that slow to create so they might help a lot. I would avoid the paint fill tool since it seems to be very slow, although maybe it's still the best way in certain cases. And the fastest way to fill the entire image with a solid color seems to be the "new page" button, but unless the vast majority of the image is a single color, it's probably faster to go straight to 16x16 blocks at the start.
Also, here's an idea... you could greatly increase the number of colors that appear to be in the palette for any 120x80 block of pixels in the image, by using the animation tool at speed 13 to create a 60hz flicker effect to simulate having colors halfway in-between any two colors in the palette. Compare the region with Mario's face in this image with the first one above:
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
(Save states work now after doing which thing?) That's weird, are you sure it's the same problem? (If it is then some of the workarounds I suggested above might still apply to it.) Also, have you tried both slow motion and frame advance? What about simply pausing and unpausing? Does disabling multithreading or DirectSound make any difference?
Not needing to dither would be better, but there are so many colors missing from the palette that you probably need to either use extensive dithering or be extremely picky about which source image to use.
As for actually quickly creating images like this in-game... I would guess that the fastest way is to use the "draw sprite" tool to draw 16x16 blocks of solid color (or the eraser for the almost-white background color), then switch to smaller tools like the 2x2 pen and (if necessary) custom stamps or carefully-planned spray-paint for the detail work. Actually, custom stamps aren't that slow to create so they might help a lot. I would avoid the paint fill tool since it seems to be very slow, although maybe it's still the best way in certain cases. And the fastest way to fill the entire image with a solid color seems to be the "new page" button, but unless the vast majority of the image is a single color, it's probably faster to go straight to 16x16 blocks at the start.
Also, here's an idea... you could greatly increase the number of colors that appear to be in the palette for any 120x80 block of pixels in the image, by using the animation tool at speed 13 to create a 60hz flicker effect to simulate having colors halfway in-between any two colors in the palette. Compare the region with Mario's face in this image with the first one above:
