Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
sorry to bring this thread up again, but I did a short WIP of this game up to the part where you bash the key with the frying pan. Anyways, the game keeps desynching. I think it's to do with the length of the cutscenes when you hold down frame advance, but I can't put my finger on it, and I'd really like to TAS this game. So if anyone could help me out, that'd be great.
sorry to bring this thread up again, but I did a short WIP of this game up to the part where you bash the key with the frying pan. Anyways, the game keeps desynching. I think it's to do with the length of the cutscenes when you hold down frame advance, but I can't put my finger on it, and I'd really like to TAS this game. So if anyone could help me out, that'd be great.
what video plugin are you using, what are your processor/graphics card specs. (I doubt I can be helpful, but at least some information is better than "it desyncs too much" because that was said of Majora's Mask too at one point)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
EDIT: removed post
I figured it out, desynchs occur when loading a savestate during a cutscene. weird but true. BTW, found a little, (and possibly little known) timesaver, that allows you to skip some text and get the helicoptery tail thing (actual name) without invoking instructions. I also use chapters mode, so you don't have to watch two hours of cutscenes; I can skip most of them.
I caught your post before you removed it. please don't use jabo 1.5.2. Use jabo 1.6 or rice 6.1.4 or glide64 napalm. The reason being that if you play the game without special effects (like good transparency and shadows and dynamic light and bloom and anything that uses a framebuffer, like the pause screen) then no one can watch or encode the game with the best-looking options either. or else it will desync. (cf. latest ocarina of time run)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
glide napalm makes it look like shit and crashes, Jabos 1.6 generally crashes, so I don't use it, looks like rice video!
...
Holy shit! rice video is freaking awesome! OMG shiny brass effecs
EDIT: you were right, my extremely short video desynched ... At the menu! Now I have to do it all over again. For the 70th time. Funny tho, I just realized you can skip the intro by pressing L, which would have killed my run anyway.
also learned how to maintain straight lines even if the camera is turning through the use of lspiro's MHS.
Also rice video has a beer goggles! that was previously a black screen (first cutscene)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
This game is right up my arse:
EDIT: removed post
Okay, until mupen 64 plus comes out, this game is on hold. Why? this game desynchs so badly. I'm beginning to think mupen is not a robust emulator after all. With this game, desynchs can occur, at any time purely by rerecording.
I had this savestate where a cutscene was triggered in normal play, but with well timed jumps, you could avoid it. Loading this savestate would cause a desynch because some times when you loaded it, you would have to wait two frames to jump in order to avoid this cutscene, and other times you would have to wait only one frame. Therefore, giving the exact same input each time would give different results, only two frames after the state was loaded.
Therefore I conclude that mupen 64 is not robust enough to TAS this game, as there must have been an external factor (apart from input) that affects the game.
Damn, I really thought I was getting into something there. Perhaps in the future, I might do this game, but until then, I'm just going to have to find another game to TAS.
For interest's sake: here would have been my current WIP, what's supposed to happen is conker doesn't swim at all, but continuously jumps, and then skips the instructions cutscene and jumps to the log. It just doesn't work.
well there's the "mupen64-rerecording" thing with the red ".exe" icon, but some members here have created other versions all with blue icons, like the one that works with reset-recording or that splits recorded avis into 2GB parts to avoid corruption, and one made with an apparently better savestate system and more robus rerecording, called antids (antidesync). It's doesn't eliminate the problem but it alleviates it somewhat. Or so I've read.
EDIT: hmmm. I couldn't figure out what settings make it look correct (it looks best on napalm but oh well) so the motion blur and dynamic lighting don't seem to work at all. And flat stuff (fences, grass) just looks awful. But anyway here's a badly cropped, oversized encode: http://bkdj.net/index.php?dir=tas/cbfd
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
sorry if I got your hopes up, Antids mupen has the exact same problem, so does reset recording mupen. They're both crap anyway because they don't render with Jabos 1.6, which is the best for conker's BFD.
All I can do now is hope and wait for mupen 64 plus rerecording to come out. Come on guys! hurry it up already!
Thanks for the WIP, AndyMac & bkDj. Man, I forgot how awesome this game is. A drunk beaver doing all sorts of lewd things is really quite entertaining.
I hope you can figure out how to avoid desyncs - I would love to see a TAS of this game published.
This would make an entertaining run. Please keep it up. :)
bkDJ wrote:
EDIT: hmmm. I couldn't figure out what settings make it look correct (it looks best on napalm but oh well) so the motion blur and dynamic lighting don't seem to work at all. And flat stuff (fences, grass) just looks awful. But anyway here's a badly cropped, oversized encode: http://72.233.35.202/index.php?dir=tas/cbfd
I disagree with it being oversized. It looks much better at a high res. I wish encodes for publications could have this level of quality.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I watched the encode. all the 2d objects do look like shit and half of the objects are 2d anyway. All fire, grass, and liquid drops are all 2d in conker's bfd. and if it renders incorrectly you lose the conker's bfd feel.
quick comparison between plugins:
plugin, reflectivity, shadows, Gouraud shading,2d objects, beer goggles
Jabo's 1.5.2 no no no yes black screen
Jabo's 1.6 yes yes yes yes random pixels (can be seen through background)
Rice's 6.14 yes no no yes yes but slow
Glide 64 napalm yes no yes no random pixels
I watched the encode and saw I stopped running at some point. It turns out this wasn't my wip at all, but a desynch test. After the cutscene, nothing is optimised, and I just used a little tool assistance to do the tricks. BTW for clarification conker actually travels in (reasonably) straight lines. I found the direction variable in MHS, and I tried to keep it as close as possible to one number. (it generally oscillates between two numbers about half a degree apart.) Why don't I have perfectly straight lines?: cbf. It would probably take about 15 mins to traverse a single straight line perfectly. This way, I can traverse a short straight line in less than one minute real time, with very little speed loss (probably approximately the same gain as employing this technique.
This would make an entertaining run. Please keep it up. :)
yeh I know. This was the absolute perfect game to TAS.
The worst thing about this is that you can't use tasedit with conker's bfd because frames represent variable timeunits, so it desynchs anyway.
EDIT: I just had a thought: because I was considering doing a Rayman 2 TAS and reading up on it, it seems like it has a similar problem. Anyways, it was initially blamed on the expansion pak being used, but personally, I think it's because the frames represent variable timeunits. Games such as MM don't seem to have many desynchs, even though they are reliant on the expansion pak to run. guess what"? MM's frame rate is always 20, or it's a menu, when it doesn't matter what the duration of a frame is. Banjo Tooie, for example I believe is extremely prone to desynchs, and it's framerate can lower, without lowering the game's speed. Therefore variable timeunits again. super mario 64 is one of the most sync-robust games that exist, and the time between frames is constant, meaning when the frame rate lowers, so does the game speed. Most games that use the expansion pak use it for cosmetic use (graphics). it seems logical that games that have lower framerates due to graphics would resort to the expansion pak, hence a possible misconnection. My theory is that the emulator does not store an accurate enough timestamp of each savestate, so when framerates start becoming weird, the game represents the time as somwhere between time A and time B. Loading the state will either give time a or b, therefore possibly dropping a frame. Desynchs ensue. it's a theory, however incomplete, but I think in real life it goes something like that. This claim has no real base, so feel free to disprove me.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
Johannes wrote:
Frames in SM64 represent variable timeunits, and hexing works fine.
SM64 also happens to be one of the few N64 games that hexes properly, not to mention CBFD was one of the last N64 games released, when developers were squeezing as much out of the console as possible. This means there's a lot more stuff going on in it to affect sync stability (when compared to SM64).
Joined: 2/12/2008
Posts: 67
Location: San Francisco Bay Area, CA
mmbossman wrote:
Johannes wrote:
Frames in SM64 represent variable timeunits, and hexing works fine.
SM64 also happens to be one of the few N64 games that hexes properly, not to mention CBFD was one of the last N64 games released, when developers were squeezing as much out of the console as possible. This means there's a lot more stuff going on in it to affect sync stability (when compared to SM64).
Also, emulators tend to be better tested on SM64. So while if the emulator was perfect CBFD might be able to be hexed, in practice the emu devs spent more time on getting SM64 to work right.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
actually sm64's frames are constant in game time (not real time). CBFD's frames are inconsistent in game time, therefore meaning that the game does not slow. If you can hex edit the m64 and it still synchs, then the game's frames are constant in game time (or very close to it) or hex editing isn't possible. SM64 slows when entering the second part of DDD for example. whereas in CBFD, it lags, but the speed is the same.
Joined: 9/21/2009
Posts: 1047
Location: California
I just finished playing through this game for the first time and I've concluded that it NEEDS to be TASed. What are the first steps needed for this game to even be TASable?
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Sync stability. I tried TASing this game twice, it desynchs every time you activate (or skip) a cutscene. For some reason it must add an extra frame, or remove one every time a cutscene plays. for this reason, you have to play from the beginning up to every cutscene every time you get to one, and then save from there. As far as long term sync stability is concerned, I'm not really sure either. It doesn't appear to desynch, as long as you don't load a state. I reccomend the latest glide plugin for CBFD.
