Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Warp does have a point though. You don't "anti-alias to HD". You render the image in HD, using anti-aliasing. Your use of the terminology (in a sentence) does indeed make it seem like you're not entirely sure what you're saying.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I think it's weird to see how much I am behind Eszik on the penultimate level, then suddenly manage to finish before him. There's some weird stuff going on in this game.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
zeromus wrote:
redgreensonic, if you push the stick all the way one direction, then youll be feeding the game maximum analog input. if the game has you moving full speed immediately, then you have an issue with the game. you can determine whether bizhawk is at fault, or your understanding of the game, by turning on input display and watching the numbers that correspond to different positions of your joystick.
Also make sure you have actually configured the joystick as an analog control (in the "Analog Controls" tab, not the "Normal Controls" tab) and clear the "Normal Controls" bindings (A Up, A Down, A Left and A Right).
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
By marking the cut. Or, in more proof-y terms:
Let a number, x or y simply indicate an amount of cards, a J is a joker and A and B are the spectator's cards. The deck is set up like this:
9, J, 18, J, 25
By letting the spectators cut to 1/3 and 2/3, the deck becomes three piles.
1: 9, J, x, A
2: (17 - x), J, y, B
3: (24 - y)
These piles are restored in order 2 - 1 - 3:
2: (17 - x), J, y, B
1: 9, J, x, A
3: (24 - y)
Resulting in the following deck:
(17 - x), J, y, B, 9, J, x, A, (24 - y)
The deck is cut at the jokers (which are removed), resulting in three new piles:
1: (17 - x)
2: y, B, 9
3: x, A, (24 - y)
These are restored in order 1 - 3 - 2:
1: (17 - x)
3: x, A, (24 - y)
2: y, B, 9
Resulting in:
(17 - x), x, A, (24 - y), y, B, 9
or:
17, A, 24, B, 9
As such, the spectator's cards are in the 18th and 43th position, respectively. This works for other numbers than 9, 18 and 25, as long as the original setup can (almost) guarantee the jokers will be in the first two cut piles.
--------------------------------------------------------------------------------
-- (Atari) Dragster Bars --
-- Lua script that works around the issue of blue tach bars by drawing over --
-- them. --
-- By Scepheo --
--------------------------------------------------------------------------------
-- Point where green bar stops.
local GreenLimit = 19;
-- Point where bar is extra long
local BarLimit = 18;
-- Colours
local Green = "DarkSeaGreen";
local Red = "IndianRed";
local Yellow = "Gold";
-- Current tachometer
local Rev = { 0, 0 };
-- Y Position
local Y = { 70, 167 };
while true do
for player = 1, 2 do
-- Get bar sizes
local greenBar = Rev[player];
local diff = 0;
if (greenBar > GreenLimit) then
greenBar = GreenLimit;
end
if (Rev[player] > BarLimit) then
diff = 1;
end
-- Draw green bar
gui.drawRectangle(0, Y[player], (greenBar + diff) * 4 - 1, 7, Green, Green);
-- Draw yellow line
if (Rev[player] > BarLimit) then
gui.drawLine(79, Y[player], 79, Y[player] + 7, Yellow);
end
-- Draw red bar
if (Rev[player] > GreenLimit) then
local redBar = Rev[player] - GreenLimit;
gui.drawRectangle(80, Y[player], redBar * 4 - 1, 7, Red, Red);
end
-- Update rev (0x28, 0x29)
Rev[player] = memory.readbyte(0x27 + player);
end
-- Allow the emulator to advance
emu.frameadvance();
end
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I'm liking the TAS vs. Human idea a lot. Sure, it doesn't show to the fullest extent what TASing is about (the painstakingly picking games apart part), but it could be neat to see how TASes make up for their lack of knowledge by using not-run-safe strats. I'd imagine it could be an issue to get a good game though, as it'd have to be one that's reasonably TASable within the time frame and it'd have to be very sync stable.
Still, just dropping the game name into the TASvideos IRC and seeing what kind of run comes out within 4 hours would be neat.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
And from what you say, it doesn't necessarily seem that Aqfaq is wrong. Just because the traps' locations, types and such are fixed, doesn't mean their "stats" are. Your killing of the Troglodytes may well have cycled the RNG to the point of generating easy-to-disarm traps. Just saying it still sounds like a possibility.
Still, if you want to be sure, follow Truncated's advice. Using trace logging (does Genesis have trace logging on BizHawk? I'd think so) it should be quite doable to figure out what factors into the disarming logic.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
As Samsara asked me about this in his response to my PM, I thought I'd share my method of shifting in this thread. If you're going good, the game increases your speed with 2 every other frame. This appears to be because the game switches players every frame: it moves player one, it moves player two, it moves player one etcetera. It also does all other logic during these "turns". Now occasionally, the game will take 3 frames to increase your speed. Not an issue, as it appears to be caused by the game taking slightly longer to execute a turn.
However, every now and then the game will take 4 or more frames to increase your speed (for first gear, this happens when you hit 30, I believe). As shifting does the same, it shouldn't lose any time to do so at this point. For optimal acceleration after shifting, you want to do so before you hit the "stuck" speed (so at 28). You should be able to keep this up after hitting fourth gear, which would allow your speed to get to 242-244. After that, I haven't found a better technique than just holding the throttle up to 252.
There's still some stuff I'm trying to figure out, like how your tachometer increases are determined, or why it's so damn hard to push your speed to 252 (at which point, just hold the clutch and release throttle).
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
From my experience, nothing that they teach you in school will even be the tiniest bit useful for programming emulators. So I'd suggest just teaching yourself.
As for the programming language, C# might be a good idea, as you're aiming for a rerecording emulator. This means not speed but accuracy is the highest priority, and high(er)-level languages generally make for more readable code, which in turn makes it easier to debug and maintain (also, less memory management needed). As a bonus, you could easily program it as a core for BizHawk, taking a lot of the (IMO) most tedious work (interfaces) out of your hands. As a bonus bonus, the Amiga's processor (the 68000) is already in BizHawk.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
TheAxeMan wrote:
The method to adapt to the unknown initial state is pretty neat as is setting the names on demand.
Unless you (magically manage to create a movie file that sets the state to a known one, regardless of starting state, this is unlikely to ever work. Sure, you can figure out what the initial state is at some point, but that doesn't help. You'd have to adjust the entire movie file, load the new one into the bot and then reboot the console, at which point you're more than likely to have a completely different state already.
Also, seventy minutes is simply too long. Gradius should have synced too (hell, it did in the tests), but during the marathon there's simply too much electronics around. EMI will mess stuff up.
Disclaimer: This is what I think is true. It's quite possibly plain wrong, but I didn't want to write "I think" every sentence. Though this disclaimer was probably just as much work. Oh well.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Patashu wrote:
The Brain Age TAS doesn't aim for speed, but this one does.
My point, which was further explained in the rest of my post, was that speed isn't the only objective. I'm fine with a possibly beatable movie, as long as it is still clearly a superplay.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Patashu wrote:
As long as the TAS will save so much time over any RTA that it won't be beaten due to wasting 20 seconds.
The Brain Age TAS can be beaten too. Getting the Memo Pad would allow for inhuman drawing (or in-run commentary, explaining things along the way ("For run comments; see run" is something that'd be neat in a submission text)), which would still allow the run to clearly distinguish itself from normal play.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Flip: Have you tried setting the selected core in the movie file to Performance? If not, try that. Do so by opening the .bk2 with 7zip or another archive viewer, and changing the "Profile":"Compatibility" to "Profile":"Performance" in the SyncSettings file.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Patashu wrote:
Since the game is so short, why not write a bot to rapidly try variations on good paths and record the fastest one? Or would a bot never find the god strat?
I think that finding the relevant addresses/logic behind the game (when does speed stop increasing/start decreasing? How much does your tachometer increase when holding the gas?) would be a more relevant step. And at that point a bot would probably be overkill.
Also, I managed a run in which my speed kept going up a steady 2 every two frames (apart from the occasional shifting, but that can't lose a lot of time) and I got a 5.64. Unless someone can explain to me how to get the aforementioned speed boosts, I don't see how anything near 5.51 is possible.
Edit:
I just managed to get 5'57, using a slightly better start and managing to need slightly less throttle. You can download the file here. As noted in the comments: "I don't see how to bring this time down, unless a much better way of shifting gears is found or you can get the speed up faster than 2 every 2 frames."
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Has anyone managed to get speeds higher than 252 (address 0x40, which I think is speed)?
Also, how do you manage to get the speed boosts by shifting? I haven't gotten any speed boosts at all, if anything, shifting slows me down.
I just tried this and I get 13 and 7 respectively. Search results are very much tied to Google profiling you, and no two people will necessarily get identical results. Your results say more about you than how Google is handling things as far as tagging goes.
Even better: 10 with the first one, versus just 2 with the second one.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I never noticed that x360ce is open source, despite having used it often myself (until I bought a 360 pad for Windows, that is). They managed to correctly hook the Xinput calls, so there's a good chance there's some useful stuff in their code.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I think it's in part due to the amount of people that still vote on publishableness instead of entertainment: TASeditors' version is more optimized and as such more publishable, resulting in more yes votes.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
adelikat wrote:
Ok, fixed. Anyone who downloaded 1.7.4 before this post (there was 35 of you!) got a debug build. The symptoms are that it is about 50% slower, and snes has a weird command window. I highly recommend you re-download if you got this build.
Don't forget the executable being twice the size due to debug symbols (5853 KB vs 2757 KB). I was one of the 35 downloaders and if I'm being honest, I thought nothing of it when the libsnes window popped up. I might have run the svn version a few times too often.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Spelunky in Hourglass doesn't work for me at all: neither in native 7 or VM XP. Then again, Game Maker 7.x games are always a gamble on Windows Vista/7.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
First of all: thank you for the explanation of aleph numbers. Although you started a lot more basic than needed, the last bit was precisely what I needed.
Second:
Bobo the King wrote:
As for your guess that the cardinality of the set of all curves being 2|ℝ|, I wouldn't be so sure. A huge number of those "curves" aren't simple. In fact, if you were to pick a "random" subset of all ℝ, you would almost surely have disjoint set. This hints to me that the cardinality of the set of all simple, closed curves is actually strictly less than 2|ℝ|. I could be wrong, though.
To me this sounds a lot like: "a huge number of the numbers in ℚ aren't in ℤ, so ℤ must be smaller than ℚ". Although intuitive, incorrect (your disjoint set argument goes too, as a nice bonus). I'll stick with my guesstimation of aleph-2.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
A frame is marked as a lag frame at the start of the frame, then unmarked whenever the game polls for input (although this INPUT_NOTIFY message is never sent to the client by the performance core, the other core works fine). If no frame is ever marked as a lag frame, that means the game is polling for input all the time, so no frame is actually a lag frame. I find it hard to imagine a way in which this system could yield false negatives, honestly.