Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I'm agreeing with Tangent here; a small optimization error isn't a problem, but it seems like he can't even explain it himself (although "oops" would be perfectly acceptable), which (to me) suggests there might be a more substantial problem.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
FractalFusion wrote:
That's just the volume of the 8 protruding tetrahedra. The volume of the octahedron (whose edge length is also 1) is √2/3; add it to the volume of the 8 tetrahedra to get √2.
Ah, I don't know where my head was. I forgot to account for the fact that the intersection is an octahedron in the first case and that there is an intersection in the second case. Silly me. Thanks for the explanation, though.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Works fine for me. Just make sure you have the controllers plugged in (and recognized by the system: the xBox lights should have stopped flickering and indicate the controller number) before starting EmuHawk.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
FractalFusion wrote:
Wolfram Alpha is wrong. The volume is not 1/(3√2), regardless if unit edge length means the side length of the large tetrahedron that is intersected with its dual (volume is √2/8), or unit edge length means the side length of the tetrahedra extending out from the octahedron (volume is √2).
Huh, that's weird, using Google's formula for the volume of a tetrahedon, I tried taking two tetrahedrons and subtracting their intersection, which gave me 5/(16√2) and is equivalent to your first case (which you said was √2/8). If I, however, take it as the length of the protruding tetrahedra, it gives me (2√2)/3, not √2 ...
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Warp wrote:
That got me thinking, is it also true if the two initial numbers are complex numbers?
Although I lack the skills to actually prove it, I'm sure the answer is yes. You can consider the series as two separate series: one for the real part, one for the imaginary part. Both will converge to the golden ratio, as such the real part will converge to the golden ratio too, while the imaginary part converges to zero.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
It seems that if it's that "easy" for just your body to disappear, it should be possible to find a RAM address relating to it and maybe make it visible with a cheat. Would allow for easier TASing, and perhaps an alternate, no-invisibility encode.
But mostly I agree with AngerFist: this is pretty entertaining, and it's still very possible to follow your movements.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Open in Read Only mode, play back to where you want to continue. Pause, save a state, toggle to Read+Write and load the state again.
Save states contain the entire movie file up till then (to ensure a certain feature called bullet-proof rerecording; look it up), I presume some sort of mismatch in this data causes problems when you try to load your old state.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
What? Of course you can add subtitles/captions to the movie files themselves. Silly people.
Both of BizHawk's formats (BKM and BK2) and lsnes support subtitles. I don't know if there's currently an interface to add them, but the subtitle format itself is pretty straight forwards, so using a text editor should work.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
creaothceann wrote:
Scepheo wrote:
if you want to grab the first 4 bits of a number x (say, 0x7B = 0111 1011), you'd use bit.rshift(x, 4)
That's the last 4 bits of the byte though. ;)
Depends, I read from left to right, so the leftmost/highest/most significant bits are the "first" bits to me. Maybe I should have just said "the 4 highest bits".
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
The page I linked you to should open to BizHawk's bit manipulation functions. You can use Wikipedia's page to get a good idea of how you can use these to do what you want.
I'll give you example too: if you want to grab the first 4 bits of a number x (say, 0x7B = 0111 1011), you'd use bit.rshift(x, 4) to shift the bits 4 places to the right (in the example, 0111 1011 becomes 0000 0111 = 0x07). For the last 4 bits, use bit.band(x, 0x0F) to filter these out. (0x0F = 0000 1111, so 0x7B AND 0x0F = 0111 1011 AND 0000 1111 = 0000 1011 = 0x0B).
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
It's fun in a gimmicky way ("Ooh hey, a modern flash game ported to the C64, which isn't supposed to be TASable but it's done anyway."), but I don't see anything that makes it worth publishing.
First of all, the C64 core isn't released for a reason. This could easily desync on a correct version. This also implies that the kill screen may just be an emulator bug, rather than in the game itself. In my opinion, this alone is enough to disqualify the run from publishing.
Second of all, causing the game to crash where this could be prevented (by slowing down) means it's just a crash, not a kill screen. As such, the game isn't completed in any meaningful way, making the game, at the very least, ineligible for the vault.
Third, although the game itself is neat, the run itself isn't really that entertaining. It's trivial to make with TASing tools, doesn't display anything inhuman and hardly manages to do anything unusual (sure, it goes fast, but not in a way that regular gameplay doesn't). Although highly subjective, this means it can't go to moons either.
Don't get me wrong; I like what you did here. And if it manages to draw more attention (and with that, work) to the C64 core, then I'd consider it a success. I just don't feel this belongs on the site as a published movie.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
RachelB wrote:
Also, can you not simply include the struct from https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/Movie.h#L60 and then just read the dtm file into that struct? Not sure if c# has a convenient way to do that, since i know nothing about it, but it will pretty much just make everything work automatically, including keeping unknown values (so it doesn't totally break if the format is updated).
You make a good point. As long as you make sure to alter u8, u32 and u64 to the correct types (unsigned byte, unsigned int and unsigned long, respectively), that struct should be directly usable. The reading will be more complicated, but if you read (and write) the file as a byte[], it's conversion to the struct is doable with some magic from the Marshal class.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I agree with Personman: apart from following the rules, it looks a lot better. A lot of the run has this "wait for it" feel to it, after which it ends with some very fast combos.
Yes vote.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Dyshonest wrote:
Interesting. Is the specific DV combination used here the only such one that is useable for this or are there others? And does it have to be Charmander with those specific moves?
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
It seems that itsPersonnal's console just loads a lot slower than those of other people. There's no solution to this problem, unless you want to write different code for each and every version of the Wii and GCN. Which I don't think will happen, so I suggest people just come to terms with the current load times being "just" close.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
After this added explanation, and hearing that it works (though I still fear that 70 minutes is rather long for a run to sync under xGDQ conditions), this actually sounds pretty awesome. Looking forward to video footage, either way.