You said you tried adding an extention, but didn't say which one, try .wbfs if you havent.
I'm a little fuzzy on Wii games, but I'm pretty sure straight iso rip of wii games are always 4.6gb or so, even if the game itself just uses 50mb of that.
So either you have a *.rar, *.zip, *.zip, *.wbfs or a bad file.
Fair enough but this doesn't make a lot of sense to me. PC is on e of the biggest platforms however there only exists one tas software which is incompatible with most games...
Pc is the biggest platforms for games, but there is about 0 need for an emulator for it as you can still run all those game natively, as opposed to console/older computer.
Emulator themselves are in "big" demand, TASers are really small part of that demand.
Adding TASing tools to an already existing emulator is much easier then creating a Tool for a system without any emulator, that has multitude of different hardware/software/drivers configuration.
And the demand and interest is much lower then say, someone wanting to play N64 games on his computer.
Fail to see the appeal of the TASAttack channel, isn't it the same as a playlist of TASVideos Youtube Channel on random? I heard something about voting on their page, what's the point, just search youtube if you wanna see a certain TAS.
Much of the same could be said about the actual topic of a marathon, unless its a streaming of a bunch of never seen before TAS, but then games that would appeal to a wider audience already have a TAS (if it's TASable obviously).
I dont see a problem here, it's not like there is tons of game out there with "legit" unlockable by AR only stuff.
As long as step-by-step are included, so anybody can prove the run is legit.
Awesome run, accepting to Moons. When trying to obsolete this run, one would need to make it more entertaining, since the time given to the player is fixed (even though the current amount is the lowest).
Maybe I am missing something here, but time isn't fixed, only starting time is. Every time he pick-ups/drop a customer, some time gets added. A run that could manage to get 20000$ in one customer would be way shorter (obviously not feasible, but just an example)
Dream cast emulator is being worked on. Can't play games yet though.
Do you mean there is a Dreamcast emulator being worked on with re-recording abilities? If so, nice.
If you just mean there is a regular dc emu being worked on but can't play games, there is a few out there running quite a few game "decently", NullDC being one.
Goal choice
Must be clearly definable as having completed the game.
Games that loop endlessly can still be defined. The completion point is one where there is no new content, and the game is no longer increasing in difficulty.
Goal choice is limited to fastest completion time (any%), or full-completion (such as 100% or best ending).
Exception: for games with separate, independent level sets (modes, episodes) officially available from start, each level set can have its TAS in Vault.
Other goal choices are not eligible for this category.
Goal choice criteria must be clear and non-controversial (a clear consensus on what constitutes full-completion or when a game is completed).
Keep in mind that's only for Vault tier, so if you think the run will get at least Moon, then go right ahead.
The following only applies if the rules for publication haven't changed in the last year, since I can't seem to find em at the moment.
If you don't take the fastest route (in this case, I'm assuming it would be taking damage to save time), you have to hope your run is worthy of a star or moon, because it can't be published to the vault, where only fastest 100% and fastest any% are accepted, and any speed tradeoff is unacceptable.
Unsure about 1.5.3, but SVN version works for GBA. You need the gbabios.rom file in the firmware folder first, and then you'll be able to load your rom. *.gba might not be in the file type list available, but you can select "All files" and it will work.
It's just integration, nothing ground breaking, I do think a fix was done for a few RARE game and such, but nothing that will revolutionize TASing n64 games other then the fact that bizhawk's platform is much more friendly to tasing in general.
Bizhawk uses bsnes/higan core for snes, which is what is used for SGB emulation. The same graphical problem are present when using Higan to emulate those games. So in this context, yes it is normal.
Note that when Bizhawk supports N64 TASing it (should be? will be?) desync-free.
When could we expect this? Probably not until 2015-2016 since I can't find anything about implementing n64 emulation...
Hum, I think your estimation on a date is a bit exagerated, although desync-free still has to be proven.
Edit: And don't get too excited, this is just mupenplus core, with very little modification, so expect same accuracy/compatibility as mupenplus for the moment.
DVD recorder/pvrs don't care about source fps (nor do they have any idea what the supposed source fps is). They record at their own fps, set by standards or something. Probably something like 24 fps. They don't add/delete/duplicate, they just take whatever the source is feeding them at that exact point in time and encode it, not caring if that picture is the exact same as the last 3 or completely different.
Not very likely.
We have PAL (50 fps) and NTSC (60 fps) which older consoles output, so that's probably what they record with unless they want to add/drop frames.
For HD, it's a little more complicated, but it's likely to be 30 or 60 fps since those are the most common.
I might be overlooking something here, movie studio been recording movie in framerate lower then 30 for ages, just a handfull of movie decided to bump it to something like 48 fps (the hobbit is one). DVD standard have been set for a while (and compatibility force them to keep it)
https://en.wikipedia.org/wiki/DVD-Video
If you record using a DVD Recorder box (we are talking on the fly here), they have to follow the standard so the movie can be played back on other DVD players.
HD only means high resolution, blu-ray movies are encoded at 24 fps.
I might be totally wrong on this, but I wouldn't count on it. Pal and NTSC don't mean anything here, a movie can be encoded at the 29.97 standard dvd movie fps, and the box can still send the signal at 60 fps to the tv (no clue if it has to, I'm no video signal wizard).
Can't say for sure as I haven't tried, but I do believe Bizhawk only supports bin/cue format for cd games. Also the provided discohawk should convert the game for you, well unless I misread what discohawk does.
Do dvd recorders & pvrs add/delete/duplicate frames to lock it to a set framerate? I don't see how else they would create 30fps video from a N64 if the N64 keeps changing to 15-20 fps during lag. If they do, then on playback it'll be the correct time (which is no issue for RTS runs), but not if I want to edit the video to do a frame-by-frame video comparing the console to the emulator. I could be wrong. Idk much about editing.
DVD recorder/pvrs don't care about source fps (nor do they have any idea what the supposed source fps is). They record at their own fps, set by standards or something. Probably something like 24 fps. They don't add/delete/duplicate, they just take whatever the source is feeding them at that exact point in time and encode it, not caring if that picture is the exact same as the last 3 or completely different.
I'm not familliar with console to pc recording box, so I don't know if those alter the input fps before relaying it to the pc, but no matter what, the recording will be at a constant framerate, it doesn't care (or even knows) the current fps the n64 spits out.
Well, I'm assuming then, that if someone figures out a way to save the needed 140ish frame needed to be sub 5, it would be a major breakthrough and would save a lot more then those 140ish frames needed.
We are talking glitch/memory corruption to skip a whole level or two, or save a huge amount of time by skipping a big part of a level.
Was there any test/check on the console verification movie vs. the mupen run (using whatever exact framerate mupen is trying to emulate), or is it possible to skip those approximation and maybe the n64 bot can calculate the amount of lag frame the n64 doesn't poll controller updates?
One problem with sub 5 is the inaccurate emulator that Mupen is. Would the current TAS still be that fast on a good emulator? That would mean even more timesavers would need to be found.
SM64 is the only n64 game (well I think anyway) that the runs have been console verified, so the accuracy is fine, for the trick/bugs used so far anyway. Lag frame might be different, but I don't think the difference is that huge.
..................
...............: STANDARD CODES ::...............
: :\
: [a?] Alternate [p?] Pirate :\
: [b?] Bad Dump [t?] Trained :\
: [f?] Fixed [T-] OldTranslation :\
: [o?] Overdump [T+] NewerTranslation :\
: [h?] Hack (-) Unknown Year :\
: [!p] Pending Dump [!] Verified Good Dump :\
: (M#) Multilanguage (# of Languages) :\
: (###) Checksum (??k) ROM Size :\
: (Unl) Unlicensed :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
.................
................: SPECIAL CODES ::...............
: :\
: .-----Gameboy-----. .----Super Nintendo----. :\
: [ [C] Color ] [ (BS) BS ROMs ] :\
: [ [S] Super ] [ (ST) Sufami Turbo ] :\
: [ [BF] Bung Fix ] [ (NP) Nintendo Power ] :\
: `-----------------' `----------------------' :\
: .--------Atari---------. :\
: .-----Genesis-----. [ (PAL) Euro Version ] :\
: [ (1) Japan ] `----------------------' :\
: [ (4) USA ] .---------GBA----------. :\
: [ (5) NTSC Only ] [ [hI??] Intro hacks ] :\
: [ [R-] Countries ] [ [f_?] EEPROMV124 fix ] :\
: [ (8) PAL Only ] `----------------------' :\
: [ (B) non USA ] .--------Coleco--------. :\
: [ [c] Checksum ] [ (Adam) ADAM Version ] :\
: [ [x] Bad Checksum] `----------------------' :\
: `-----------------' :\
: .--------NES/FC--------. :\
: .--NeoGeo Pocket--. [ (PC10) PlayChoice 10 ] :\
: [ [M] Mono Only ] [ (VS) Versus ] :\
: `-----------------' [ [hFFE] FFE Copier fmt] :\
: `----------------------' :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
.................
................: COUNTRY CODES ::...............
: :\
: (1) Japan & Korea (4) USA & BrazilNTSC :\
: (A) Australia (J) Japan :\
: (B) non USA (Genesis) (K) Korea :\
: (C) China (NL) Netherlands :\
: (E) Europe (PD) Public Domain :\
: (F) France (S) Spain :\
: (FC) French Canadian (Sw) Sweden :\
: (FN) Finland (U) USA :\
: (G) Germany (UK) England :\
: (GR) Greece (Unk) Unknown Country :\
: (HK) Hong Kong (I) Italy :\
: (D) Dutch (Unl) Unlicensed :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
.......................
.............: STANDARD CODE NOTES ::............
: :\
: [a] This is simply an alternate version of a :\
: ROM. Many games have been re-released to :\
: fix bugs or even to eliminate Game Genie :\
: codes (Yes, Nintendo hates that device). :\
: ------------------- :\
: [b] A bad dump often occurs with an older :\
: game or a faulty dumper (bad connection). :\
: Another common source of [b] ROMs is a :\
: corrupted upload to a release FTP. :\
: ------------------- :\
: [f] A fixed game has been altered in some way :\
: so that it will run better on a copier :\
: or emulator. :\
: ------------------- :\
: [h] Something in this ROM is not quite as it :\
: should be. Often a hacked ROM simply has :\
: a changed header or has been enabled to :\
: run in different regions. Other times it :\
: could be a release group intro, or just :\
: some kind of cheating or funny hack. :\
: ------------------- :\
: [o] An overdumped ROM image has more data :\
: than is actually in the cart. The extra :\
: information means nothing and is removed :\
: from the true image. :\
: ------------------- :\
: [t] A trainer is special code which executes :\
: before the game is begun. It allows you :\
: to access cheats from a menu. :\
: ------------------- :\
: [!] Verified good dump. Thank God for these! :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
......................
.............: SPECIAL CODE NOTES ::.............
: :\
: **** SNES **** :\
: (BS) These Japanese ROMs were distributed :\
: through a satellite system in Japan :\
: known as the Broadcast Satellaview. :\
: They were transmitted along with a TV :\
: show which was connected to the game in :\
: some way. These games were only playable :\
: during the show, and thus stop after an :\
: hour, and many were timed so that only :\
: certain time periods were playable. :\
: ------------------- :\
: (ST) The Sufami Turbo device allowed two :\
: GameBoy sized carts to be plugged into :\
: the SNES. Certain carts combined into :\
: new games much like the Sonic & Knuckles :\
: lock-on technology by Sega. :\
: ------------------- :\
: (NP) Nintendo Power has been known to release :\
: games only available to its subscribers. :\
: Most of these ROMs are Japanese, as this :\
: practice occured mainly in Japan. :\
: ------------------- :\
: :\
: **** Genesis **** :\
: (1) Carts with this code will run on both :\
: Japanese and Korean machines. :\
: ------------------- :\
: (4) While this code is technically the same :\
: as a (U) code, it is a newer header :\
: format and represents that the cart will :\
: run on USA and Brazil NTSC machines. :\
: ------------------- :\
: (B) This country code indicates that the :\
: cart will run on any non US machine. :\
: ------------------- :\
: [c] This code represents a cart with known :\
: faulty checksum routines. :\
: ------------------- :\
: :\
: **** GameBoy **** :\
: [BF] Bung released a programmable cartridge :\
: compatable with the GameBoy which could :\
: hold any data you wished to play. :\
: However, many games do not function on :\
: Bung v1.0 carts and have to be 'fixed.' :\
: ------------------- :\
: :\
: **** Nintendo **** :\
: PC10 The PlayChoice 10 was an arcade unit :\
: which played exact copies of NES games :\
: in an arcade cabinet. The machines had a :\
: choice of 10 games to choose from and :\
: ran for about 3 minutes on 25 cents. :\
: ------------------- :\
: :\
: VS The Versus system ran on similar hard- :\
: ware to the PC10 machines, but simply :\
: allowed you to play against each other. :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
...........
...................: Credits ::..................
: :\
: Document written by Psych0phobiA / q^-o|o-^p :\
: :\
: All codes developed by Cowering for the :\
: Goodxxxx series ROM file renaming utilities. :\
: :\
: Visit #rareroms on UnitedUsers in IRC! :\
:...............................................:\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
I've tested every game in the Mega Games 10 in 1 and they all worked 100% accurate!
That's a big affirmation to make, you probably just mean they "looked right". Huge difference between looking good (playable) and being 100% accurate, which I doubt Bizhawk's Genesis core will ever achieve (or any of its core).
Edit: You can tell that there is not much progress being made to the genesis core lately by looking at http://code.google.com/p/bizhawk/source/list
http://www.youtube.com/watch?v=FgDqwa_pzmg
Sorry if this is too off topic, but in this video at 6:01 and 6:20 he traps a koopa in a block and has it go to the end of the stage without falling or hitting any blocks. Does anyone here happen to know or have a detailed explanation of how this works?
Also how do I find 0x000D and 0x0015? I don't know how to search for that. At 8 bytes per line shown is "offset (h)" 000000D0 00 CA 46 A3 4D 00 00 00 the 8 bytes I need to replace?
Both 000D and 0015 are circled here, look at the column header, add to the row header. Alternatively, click on search, GOTO, and type 000D or whatever, and it will move you to where you want to be.
As for finding line numbers, not recommended to go by lines number nor do I recommend changing to 8 bytes per line, 16 makes it much easier to find a specific adress as pictured above.
header is 256 bytes, all you need to find is 256 equivalent in hexadecimal to find the end of the header. Windows calculator (in programmer mode) can convert decimal number into hexadecimal. 256 = 0x100 (0x100 is the same as 0x0000100, leading 0 means nothing, just like decimal). So in this case, you wanna go to offset 00000100. Didnt count but this should be line 17 in 16 bytes per row (16x16 = 256).
Although what is above is just to help you learn, most likely not needed.
If you need to edit frame 1789 (made up number, I dont know the frame you need to change) and each frame is 8bytes, just multiply 1788 by 8 and add the 256 from the header. 1788*8+256 = 14560, convert that into HEX = 0x38E0 and use GOTO to get there quickly, or just page down until you get there using the method I mentionned above the picture. This should be the starting point of frame 1789
Just another tips: Hex number uses letters as a way to have more then 10 digits to make numbers up. A B C D E F actually means 10 11 12 13 14 15. So 0x010 (16) is the number right after 0x00F (15). The 0x notation is just to show the number after is an hexadecimal one.
Edit: And don't get too excited, this is just mupenplus core, with very little modification, so expect same accuracy/compatibility as mupenplus for the moment.
As for finding line numbers, not recommended to go by lines number nor do I recommend changing to 8 bytes per line, 16 makes it much easier to find a specific adress as pictured above.
header is 256 bytes, all you need to find is 256 equivalent in hexadecimal to find the end of the header. Windows calculator (in programmer mode) can convert decimal number into hexadecimal. 256 = 0x100 (0x100 is the same as 0x0000100, leading 0 means nothing, just like decimal). So in this case, you wanna go to offset 00000100. Didnt count but this should be line 17 in 16 bytes per row (16x16 = 256).
Although what is above is just to help you learn, most likely not needed.
If you need to edit frame 1789 (made up number, I dont know the frame you need to change) and each frame is 8bytes, just multiply 1788 by 8 and add the 256 from the header. 1788*8+256 = 14560, convert that into HEX = 0x38E0 and use GOTO to get there quickly, or just page down until you get there using the method I mentionned above the picture. This should be the starting point of frame 1789
Just another tips: Hex number uses letters as a way to have more then 10 digits to make numbers up. A B C D E F actually means 10 11 12 13 14 15. So 0x010 (16) is the number right after 0x00F (15). The 0x notation is just to show the number after is an hexadecimal one.