I was thinking of this the other day, as far as I know, there is no emulator yet that supports re-recording. (Well, yes, there's BizHawk, but its TI-83 emulation is very preliminary.) By re-recording, I mean, mainly being able to record input in a file to be replayed later and other tools useful for making TASes. Recording input would definitely be useful as you might even build a device that emulates a TI Keyboard and send the movie file to the calc. Wouldn't that be great?
Well, that's my thoughts, take note emu developers, I want to see this happen.
From what I remember:
-WabbitEmu, CEmu and TilEm both has speed settings allowing slowdowns, but no frame by frame advance (except maybe via breakpoints?).
-TilEm allegedly supports programming key input sequences in advances, but I never got it to work.
-BizHawk doesn't work (at least, not with any 83 ROM I tried, and it's not 83+/84+ compatible)
-Other emulators lacks speed settings altogether
-No TI emulator supports re-recording. Savestates are not a viable alternative, because they require pressing keys or mouse buttons to open the save/load menus, and save/loading interrupts GIF capture AFAIK.
So yeah, we're kinda limited in TAS'ing for calculators. Granted, we can do partial TAS by slowing down emulation or by adding a savestate feature to specific games, but we're not getting the most out of TAS'ing that way. With real tool-assisted speedrun tools, that Calcuzap speedrun would last much shorter and feature nearly perfect gameplay.
Just why ?
Almost the TI games outhere are not even worthy for speedrunning due to how uncomplex and unremarkable the games are.
But maybe you can prove me wrong.
@gameblabla I think you should remove your TI-Nspire CX and Call of Duty blindfolds and look at Ticalc.org POTY section. By your logic, 90% of the NES, Game Boy, Colecovision and Atari games that got speedrunned are not even worthy for speedrunning. Granted, most calc games don't feature wall-jumping/zipper glitches or stuff like that, but many speedruns are entertaining even when no glitch is abused.
There is indeed a few games that could prove you wrong.
I think he either only looked at the BASIC games section or he thinks that anything monochrome is worthless. In any case, such remark isn't really welcome on CodeWalrus considering the hard work some people spent on some calculator games.
Quote from: DJ Omnimaga on August 09, 2016, 03:33:18 AM
I think he either only looked at the BASIC games section or he thinks that anything monochrome is worthless. In any case, such remark isn't really welcome on CodeWalrus considering the hard work some people spent on some calculator games.
It doesn't have anything to do with monochrome games, after all a lot of people are doing speedruns of gameboy games.
I was just saying that the most ti games (including good ones) were so easy and primitive that speedruns would not add much to them, hence
why no speedruns tools and options were developed for TI emulators.
Of course, some games could make use of TAS but i'm not sure who will even have the effort to do such thing.
We'll see
We have a sceptic over here. Well, the only way to know is to try it. Also, it might probably be useful for teachers as a demo mode.
I don't think it's the reason why no TI speedrun tools exist. It's more because there are so few TI programmers out there and TI programmers who work on emulators are more interested in providing development tools such as debuggers rather than speedrunning tools.
The way your previous remark was written implied that almost every TI game out there weren't good, hence my rebuttal. Also, while most calc games look more primitive than console games, you can't judge games 100% based on graphics, and while many calc games have no ending and are all about racking up your highscores like in Atari games, this is why there are multiple categories of speedruns for games that cannot be beaten or that has secret areas (eg 10000 points in X minutes, Any%, 100%, all items, no death, no damage, reverse boss order, etc)
Also if such emulator existed, then calc speedruns could be included on TASVideos or on other speedrunning sites.
Quote from: DJ Omnimaga on August 09, 2016, 03:31:02 AM
@gameblabla I think you should remove your TI-Nspire CX and Call of Duty blindfolds and look at Ticalc.org POTY
/me gives DJ some COD MLG shades:
(http://images.ttcdn.co/media/i/product/71303-7b367dc248024aea8083ec5002ebe219.jpeg)
@Juju: if you realy need something like this you could always just use any regular screen capture program.
Quote from: c4ooo on August 09, 2016, 07:42:22 AM
Quote from: DJ Omnimaga on August 09, 2016, 03:31:02 AM
@gameblabla I think you should remove your TI-Nspire CX and Call of Duty blindfolds and look at Ticalc.org POTY
/me gives DJ some COD MLG shades:
(http://images.ttcdn.co/media/i/product/71303-7b367dc248024aea8083ec5002ebe219.jpeg)
@Juju: if you realy need something like this you could always just use any regular screen capture program.
I think according to what you added on WalrusIRC you missed the point of my earlier post
@c4ooo , but anyway we should get back on topic.
A regular capture program is innefective for a TAS because what if you need to rewind during recording? A TAS recording tool needs to record all your key inputs frame by frame during a specific game rather than the image. On the NES they sell special devices on which you can even store TAS recordings and when you boot a real game cartridge the device will automatically processes all key inputs from the recording, resulting into the game being TAS'ed on real hardware.
Well my autotester "plugin"/feature in CEmu allows for scripten inputs, but I doubt it would be extremely accurate from a computer to another... Though it would be nice to try how much it varies from one to another. I don't think there would be big/noticeable differences, but who knows... for games, adding milliseconds delays here and there can do something very different eventually.
Maybe a very sensitive keylogger could work? If it could log stuff like the exact amount of time a key is held down then it would be elementary to write a java program to then read the log and then replay keystrokes; but ime not sure this is what your going after.
Yeah I think key input and when they get processed by the OS should be recorded at the exact frame where they happen. I guess it could still be a problem on calculators where the battery level, VAT content or saturated flash has a direct impact on speed, though.
That said, I would be fine if an emulator allowed us to advance frame by frame and manually press keys on that frame (we could look at the source code in the debugger to see when the key input commands kick in) and still saved the previous frames in a GIF file (and continued saving after reloading saved state), so that for example in Calcuzap we could shoot bullets as fast as the game code physically allows). If you notice, in my speedrun I sometimes stop shooting, and it's because key input sometimes stops working (although I think GIF capture causes keys to sometimes not register).
By frame by frame advancement do you mean pausing every time the screen finishes updating? (The screen automatically updates around 60 times per second). Othetwise, it would be next to impossible to actually when a new "frame" has begun inside the game engine.
Yes. It could also be instruction by instructions or at least every loop iteration for extra precision.
I'd be happy to implement all of these ideas into CEmu once I get back in a week and a half. Please post in the CEmu thread somewhere about any specific feature requests, including the ones mentioned here so they don't get lost :)
Quote from: DJ Omnimaga on August 09, 2016, 08:32:25 PM
Yes. It could also be instruction by instructions or at least every loop iteration for extra precision.
Wekk the problem is that it would be next to impossible to know when a new loop has begun. Also the screen is most likely gona update faster then the game loop.
Can't this be detected via a debugger? Maybe for those who don't know ASM the debugger could have a mode that tells the user when a loop or block has started or ended.
Easy to say, but very unpractical. How would it tell say a loop that renders all the enemies from the game loop? And what about basic games (and some asm games) were there is no clear "loop"?
I'm not a TAS expert, but my understanding is that the vast majority of console games had all of their code and operations synchronized to the frame rate, so practically everything was handled in nice, clean frame increments (image updated once per frame, inputs read once per frame, etc.). And, because the consoles were designed to run on TVs, the frame rate was always constant because the old standard-definition CRT TVs were designed to run only at a specific scanning frequency dictated by the region's broadcasting standards (NTSC/PAL/whatever). This makes console TASs fairly straightforward (in theory, at least) to work with.
Calculators are a bit weird, though, because games aren't necessarily synchronized with the display refresh. They often just run loops at some arbitrary speed. Some games might use interrupt timers to regulate their speed (and some might have the timers set to different frequencies than others), others might have do-nothing delay loops or nothing at all, leaving their running speed entirely dependent on CPU speed. And the actual key reads could happen who-knows-where in the code at who-knows-what frequency. So TASing tools for calculators would be a lot trickier to implement, I think.
Since the precise timing and content of the inputs are the primary things that makes a TAS reproducible, if I understand correctly, and not necessarily when frames are drawn, it would be important to have the timing resolution be determined by the reading of inputs. Since calc programs can read keys or the link port or whatever at literally any time, one would either need to know the code to set breakpoints in the appropriate places, or the emulator might need to detect when they're being read and pause there so the user could define the next input. The "frame rate" of a game would thus vary depending on how often the game reads the inputs, which might not actually be at a steady, predictable rate depending on how it was coded.
Quote from: c4ooo on August 10, 2016, 05:22:05 PM
Easy to say, but very unpractical. How would it tell say a loop that renders all the enemies from the game loop? And what about basic games (and some asm games) were there is no clear "loop"?
I think if the TAS tool can at least detect if you just went in a loop, you just have to count them. As for more complicated loop nesting and branching then the TAS doesn't have to be perfect anyway. (although it's better if it is)
But yeah Travis brings up good points too. A TAS emulator for calcs would be much harder because of that. I still think some limited tools could be done, though, such as at least frame by frame advance where the TAS'er can assign keypresses to specific frames. An optimal TAS would probably require that the emulator runs a specific OS and that the user clears the entire RAM and archive, only leaving the game and dependencies in. That would ensure optimal speed, especially for BASIC games that tend to slow down when the calculator has more sub-programs and less RAM. But such limited tools would still be much better than just being able to slow down emulation to 1% speed.
Another nice tool would be if the emulator showed when keys are being released based on emulation rather than computer keyboard input. For example, if you set CEmu to run at 10% speed and decide to mash the shoot button at incredible speeds in Calcuzap, then the emulator registers it as holding down the shoot button most of the time. Knowing when the key is recognized as released on an hardware or game level (unless it's all dependent on loops?) would help figure out when we can press the key again.
Assuming that a TI emulator supporting TASs existed, what games would be speedrun? Have any games for calculators even been the subject of unassisted speed runs?
Not yet, although some TAS'es exist (not entire games sometimes, but rather parts). Illusiat 3, Galaxian, Super Mario 1.2 default level pack, Calcuzap, Drug Cartel and Portal Prelude
Such as this?
https://www.youtube.com/watch?v=zHYaRVu0ydQ&fmt=18
Yes
@calcplays , although this one would probably be even faster with real tools and a proper screenshot (in this case I just used WabbitEmu GIF capture and when I converted the GIF to avi it resulted into a glitch fest.
Also lol that game is very rare and hard to find.
JWinslow23 shared this on WalrusIRC and I lol'ed (although the Snake game seems to lag near the end and isn't fast to begin with.)
https://www.youtube.com/watch?v=YyRsdbskdwE
I like how the game is programmed as part of the TAS.
Oooh, wasn't aware someone at TASVideos attempted a TAS, but really nice try. If BizHawk had a way to load 8xp files and such, you would skip the speedcoding part (which would be uninteresting to TASVideos) and make pretty good TASes of things like Reuben Quest (Axe version, otherwise it would be too slow) and stuff like that.
Yeah I was shocked when I saw a calc TAS there. Shame that BizHawk author doesn't want to improve TI support, though. I guess this further exacerbates the need for a TI rerecording emu as alternative. That said, I loved the speedcoding part of the TAS and it was kinda ironic that it lasted much shorter than the gameplay footage itself XD.
As for tases of RPGs and the like I think the interesting part would be if some key combos that are hard to do in real-time could be achieved in TAS form to abuse glitches or if luck manipulation was used, such as critical hits. For BASIC games it would depend which one it is. I wonder if setting the Rand seed before starting the video and the game would be considered cheating?
BizHawk is modular, so if someone here wants to integrate one of the existing emulators (TilEm, z80e or WabbitEmu) into it, write the appropriate glue code and send a pull request, guess it's doable. The only concern would probably be what
@Travis said earlier in this thread, but again, we already have a proof of concept working written from scratch (http://tasvideos.org/Bizhawk/TI83.html) that proves it works.
If it's modular then I am surprised no one integrated other emulators yet. But I guess it doesn't necessarily mean the pull request will be accepted.