Posts for RetroEdit


RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
ThunderAxe31 wrote:
RetroEdit wrote:
This is the screen that appears after completing the Stars level collection: The phrasing "You have solved every puzzle" suggests this is the end of the main game. It isn't credits, but it's pretty expressive. I disagree that completing all 64 unique Time Trial puzzles is required for publication because "all unique content" needs to be played. Instead, I think this screen is sufficient to show completing all 192 standard levels is an endpoint.
I agree that this is the completion point for fastest-completion, as it objectively counts as the ending of the game, but an author may still add the additional Time Trial puzzles and would be considered applicable for Vault as full-completion.
This presents an interesting conundrum for all movies thus far that I have just realized after some testing. You don't have to play the Easy levels at all to reach this screen. Only all the Kinoko levels to unlock the Star levels, and then all the Star levels to reach the screen. Under this metric, the current movies could be considered severely suboptimal in the pursuit of reaching the fastest completion goal. EDIT: Here's a movie that skips the Easy levels and goes straight through Kinoko levels and then Star levels to the completion screen: Picross-Scripting-SkipEasy.bk2 EDIT II: My original interpretation seems a bit wrong. The game delineates between "EASY PICROSS" and "PICROSS". That screen refers specifically to the PICROSS level set, which includes the Kinoko levels and the Star levels.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Basically, the way lag marking in BizHawk works is it indicates whether input is polled by the game. However, the game can still poll input but do nothing with the input, so it's not a perfect metric. And I'm having a look now, and you're right, it does seem to be 20 FPS (only every third frame is used), though there's sometimes a bit of extra lag. And the enemies and the player seem to move on separate frames, but each one moves periodically only every three.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Any reason you're using 2.3.1 instead of a newer version like 2.4.2? I might try and take a look.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Do you have TAStudio open? It might be a known bug: https://github.com/TASVideos/BizHawk/issues/2172 The easiest workaround I found is not using TAStudio when using the script.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
This is the screen that appears after completing the Stars level collection: The phrasing "You have solved every puzzle" suggests this is the end of the main game. It isn't credits, but it's pretty expressive. I disagree that completing all 64 unique Time Trial puzzles is required for publication because "all unique content" needs to be played. Instead, I think this screen is sufficient to show completing all 192 standard levels is an endpoint. My draft movie above also ends input early on the premise that reaching this screen is completion. However, there are screens afterwards explaining that Time Trial mode is now unlocked. I will note the screens go on to describe time trial as "the ultimate PICROSS challenge", but I will still maintain that it's fundamentally a side-mode that's not needed for completion. Side note: "How to play" isn't really content either, it's just an explanation of how to play and a brief demo, but it can be skipped after entering by pressing start. In my opinion, it should not count towards completion either.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Here's some movies I made: hard-reset movie / soft-reset movie (old) So I have finally finished one run of my bot, and netted a time save of around 02:02.51 02:02.61 02:09.29 (compared with Jigwally's latest version). However, the frames aren't really mainly because I used a bot but because I used a few better strategies. One main strategy is better menuing. During hint cancellation, the original movie uses B to cancel the hint. By instead pressing R followed by A, the movie saves 30 frames on each level. Over the whole run, this probably saves ~01:36.44. This movie also uses a soft-reset between Easy/Kinoko, which may or may not save time. The remaining ~00:26.07 are probably mainly due to different in-level lag. I know it was mentioned that a soft-reset between Easy and Kinoko seems to add a lot of lag at levels near the beginning, but maybe it cancels out with levels near the end? Or maybe faster hint canceling alters lag? Overall, I think there's still quite a bit of potential to analyze further and squeeze more frames out through a variety of methods. I'd also like to switch over to using non-equal length frames in my next posted movie, since I think ELF hinders the ability to productively work on the movie. Disabling ELF will add some "frames", but the cycle count will reflect the actual time. EDIT: 6 more frames saved by removing some extraneous inputs from Star 6B. EDIT 2: 399 more frames saved by hard-resetting between Easy/Kinoko. This is due to seemingly random level lag, and not anything intrinsic to hard-resetting. If level lag can be mitigated through other methods, soft-resetting should be the fastest method.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I would argue the time trial puzzle(s) doesn't count towards full competition at all. It's just a single record; it doesn't keep track of each individual puzzle out of the 64 possible puzzles that was done. This is in contrast to the clear way the other 192 puzzles are treated, each having an individual checkbox among other indicators showing each puzzle is complete.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Also a meh. Came here without having seen the previous run (or the animated show, for that matter). Of course, the technical value here seems good, especially in consideration of the previous run, and the levels being short prevented giving it an outright no. On the other hand, it also means the game is half cutscenes now. For me, it just doesn't have enough entertainment value to warrant a yes.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I just did some testing, and this run syncs cleanly on 2.4.2 without modification. In fact, because mGBA in 2.4.2 has less lag, you can delete the frames 277 and 788 that were lag frames in 1.12.2, and the run still syncs properly (obviously, that's not real timesave, just basic emulation differences).
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
To the best of my knowledge, this isn't currently possible. However, you can replicate the behavior through Lua scripts pretty easily.
Language: lua

use_from_movie = {'B', 'Left', 'Right', 'Up', 'Down'} while true do old_inputs = movie.getinput(emu.framecount()) filtered_inputs = {} for k, button in pairs(use_from_movie) do filtered_inputs[button] = old_inputs[button] end joypad.set(filtered_inputs) emu.frameadvance() end
use_from_movie is a table of inputs I want to be taken from the movie. In my example code, I choose for directional inputs and the 'B' button to be taken from the movie. That means the emulator will essentially ignore any of my inputs that are directional keys or the 'B' button, and always press those when the original movie had them pressed. You can save that script to a file with a .lua file extension and drag it into BizHawk. That first line of code can be modified to your specific situation. You can see a list of buttons for your current emulated system by entering joypad.get() into the Lua console.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
ais523 wrote:
In games from the era that TASvideos normally cares about, a search for the constant 0x41c64e6d (1103515245 in decimal) within the ROM is likely to find the RNG routine approximately half the time.
I've seen you mention this before, and I have to admit I'm a bit skeptical of its commonality. Maybe the games I've looked at (which are GBA games) are not the ones you're referring to. For reference, the two games I've analyzed had the following values (both using linear congruential generators): Game & Watch Gallery 4 -- multiplier: 0x5D588B65, increment: 1 Final Fantasy I & II: Dawn of Souls -- multiplier: 0x6C078965, increment: 7 I'd be curious to know what examples you have for using the multiplier you mention, or maybe there's a list somewhere already that can be linked to? ----
goldenband wrote:
Very interesting, thanks. What properties of these numbers make them so effective as RNG seeds? Is it something about how they respond to bitshifting operations and XORs, or something else?
Just to clarify: these values aren't actually seeds. They're Linear Congruential Generator (LCG) multipliers. The difference is that a seed is the initial state value for an RNG, while the multiplier determines how the RNG state advances each time it is called. Actually, an LCG is a pretty easily understood method of RNG, in my opinion. The basic idea is this: the RNG starts at some state (i.e. a number), and each time a random number is wanted, the LCG produces the next random number by multiplying the old state by the multiplier, and adding the increment-value (both values are generally hardcoded in advance). So for example, if you had a multipler of 10 and an increment of 7, the RNG state would advance as follows: 0, 7, 77, 777, 7777, 77777 (0 * 10 + 7 = 7, 7 * 10 + 7 = 77, etc.) There's one other wrinkle to this: the RNG state has a fixed size, usually either 2^32 (for 32 bit systems) or 2^64 (for 64 bit system). If the resulting RNG state would exceed that size after multiplying by the multiplier and adding the increment, only the remainder after dividing the original result by the size is kept (i.e. the modulus operation, but really in practice it's done implicitly because the result is truncated by the memory location's size anyway, or it can be done through a bit shift because of the nature of powers of 2). I can't claim to understand the full theory behind choosing good LCG parameters, but I can at least give a simple example of bad LCG parameters nabbed from the Wikipedia article: multiplier = 0 and increment = 1. This produces an LCG that produces the following numbers: 0, 1, 2, 3, 4, 5, 6, ... Clearly not random, and there are probably many similar parameters that would be easily detected by the player, so it's best to be a bit careful in ones choice.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
TiKevin83 wrote:
If you go through the donation links you'll see that the "Bundle for Racial Justice and Equality" redirects to an ActBlue campaign. The bundle is essentially cleverly disguised superPAC campaign funding for Democrats. This is wildly different from simply donating directly to bail funds or other human rights oriented charities.
Uh, no, I think I'll have to push back on that. Firstly, the bundle's proceeds are split between two funds: the NAACP Legal Defense Fund and the ActBlue's collection of legal bail funds. Saying that the bundle "redirects" to an ActBlue campaign completely fails to mention the other half of the proceeds, which is misleading in my opinion. Secondly, there's no indication that the funds going to the ActBlue bail funds page can be used for campaign funding. The page has a specific list of organizations the funds will be distributed to. The page also lists places to contact for the organization's financial reports at the bottom of the page, so it can be audited.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
MattyXB wrote:
Why the japanese version and not the englisch? Is the japanese faster?
Likely because text-scrolling is faster, as this tutorial video for the speedrun mentions near the beginning: https://www.youtube.com/watch?v=Ud5SYP88LO8 Not that the text-scroll differences matter for the purposes of timing comparison on this site, as they are excluded when doing timing comparison for TASes here. (related movie rule)
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Just to further build on Memory's reply, the speed of an AVI dumped video is not dependent on the speed the emulator runs at because it records the content at the emulated console's speed, not your computer's speed. So if such an AVI was played back, it should show the content in a speed similar to a real console. (the emulator has to run all the game logic that determines how gameplay works, while the video only has to play back a prerecorded set of images and sound)
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Uh, BizHawk 2.4.2 was released a week ago: GitHub, Release history Nevermind, it seems I misunderstood, as Colin pointed out.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I also had concerns about how optimal this movie is. I saw one of the character's spells miss at around the 4m50s mark in the YouTube encode (evidently, InfamousKnight independently noticed spells missing), and that made me concerned there may have been missed opportunities for optimization. I tweaked the movie file a bit and saved 3 frames through better menuing of Ron's character selection. There's probably potential for more time save through gameplay, for instance I noticed a point near the beginning where the character waited 10-20 extra frames before casting a Leviosa spell on an object, which was not noticeable in the encode. However, removing wait time from gameplay appears to affect RNG, specifically for enemy spawning, so changes did not sync forwards. Admittedly, the extra wait time potentially aids with RNG manipulation, but it's difficult to discern clearly, and there may be less expensive ways to achieve the same results. It might be good to update to latest BizHawk (2.4.2 at time of writing). If you can't go 64-bit, at least 1.13.2 might be a good option too. This game seems fairly sync-friendly in non-RNG components, so if you feel like it's worthwhile, it hopefully won't be too painful.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Futurama39 wrote:
Bobthefloater wrote:
I'm surprised no-one has mentioned BlueMaxima's Flashpoint. For context, the Flash engine is going to be discontinued this year and web browsers will stop supporting it over the coming years, so some people have formed a conservatory for Flash games. If there are issues with using it, you could ask the people involved with it. I don't have any technical knowledge over how it works, but I'm mentioning this because it seems relevant.
I've also tried to look on the project, but it seems to be windows only. And when there's wine involved you might just run the windows version of the flash projector thru it? (been trying myself, got it to work once, struggling since) Flash player is getting discontinued in all popular browsers, yes. We can still run the flash games using the flash projector, or other tools in their own states of usability
BlueMaxima's FlashPoint is largely just a frontend to the standard Flash Player. The one change I do know is that the most recent version has hacked the networking code to prevent it from actually connecting to the internet; previously it used a proxy to redirect all of Flash Player's network traffic locally (in both cases the goal is often to overcome site-locked games by pretending to be the original site the game was hosted on). Aside from that, I'm not sure it's really much different than the standard Flash Player for actually running games. When I asked in their Discord server about Flash technical details, they directed me to Ruffle, and I think if development continues to proceed smoothly, it will eventually become a viable option for Flash TASing.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I will note, I was aware that this solution would not work in cases where the frame loaded happens to be one frame greater than the current frame. However, in this particular example of practicing a particular section, I assume they would not go back in time and even if that was the case, the only negative effect is not re-seeding the RNG for that particular attempt. Regardless, I should have mentioned this drawback. I'm not certain I follow what you mean when you mention "what if you are executing a function in the middle of the frame"? How would a frame number-comparison method break down in that instance?
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
One potential way I can think off the top of my head: Each frame, compare the current frame number to the previous (and then store the current frame number as the previous). If the current frame isn't one greater than the previous, then you have loaded a savestate. There may be a better way, but there's currently no built in callbacks for savestate loading if I recall, and I don't see any obvious flaws with this method. Edit: My recollection was wrong, as Amaraticando points out, event.onloadstate exists and should be preferred as a more robust solution than the hacky solution of comparing to the previous frame. My apologies for being too lazy to even check the documentation (I am a bit averse to BizHawk's Lua docs, since I find them to be poorly formatted and difficult to use, but that is no excuse.) As for flaws with the previous method, I'm writing a reply currently, but I concede my method is not perfect for all cases. Code example with a callback:
Language: lua

event.onloadstate(randomize_rng)
<h2>My original, less robust method</h2> Code-wise, it would be something like:
Language: lua

local prev_frame = emu.framecount() - 1 while true do local curr_frame = emu.framecount() if curr_frame ~= prev_frame + 1 then randomize_rng() end prev_frame = curr_frame emu.frameadvance() end
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
In regards to mGBA, it's already fairly mature and has ironed out a lot of subtle bugs over time. There is potentially space for another GBA core that's cycle-accurate (mGBA is cycle-count accurate). Higan is the modern existing cycle-accurate emulator that I'm aware of. However, cycle-accurate may not offer any benefits; it's possible it would lead to more accuracy, but mGBA may be accurate enough to resolve identically in all practical cases. As far as new features go, it's mostly a matter of getting the features into BizHawk, as mGBA already has most of the features you mention. The one feature I'm also hoping to be able to TAS GBA with link-cable. This currently presents multiple issues; mGBA's implementation is not entirely feature-complete (it doesn't support Single-Pak currently), and it may not yet be deterministic to the degree required for TASing. I'm hopeful that these issues will eventually be resolved in mGBA. As far as sub-frame inputs go, it's probably not relevant for most GBA games, since most games only poll once per frame anyway. Sub-frame resets could potentially be useful for SaveRAM manipulation, but probably would only work in very specific games. endrift said mGBA already supports sub-frame inputs, so it's really just a matter of connecting it to BizHawk and then having BizHawk present it a usable way. Sub-frame in itself an ongoing project complete mess that BizHawk is not yet designed to support for BizHawk in general, from some recent discussion I've seen in IRC. AFAICT, for mGBA, it's really a matter of having someone familiar with the internal working to be able to interface with BizHawk. I'm hoping to become more familiar; my immediate motivation is a longstanding and overlooked bug related to SaveRAM not loading when loading savestates.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I got in the mood to mess around with FF1 a bit, and I made a short movie showing how it's most likely going to be possible to skip any (non-required) encounter if you want to: User movie #62833919042274607 Edit 1: Silly me, babbling about basic RNG that was already known for more than a decade. But knowing encounters are avoidable is just the tip of the iceberg; knowing the detailed mechanics behind encounters will be important in shaping required encounter outcomes to my favor, so that will be the next step. Edit 2: I've had a chance now to look at arandomgameTASer's movies (1, 2). Unfortunately, they both have a desync shortly after crossing the bridge North of Cornelia at around frame 19200. Since this is relatively early into the movie, the vast majority of the movie is unfortunately likely lost to this desync. However, this was a BizHawk 2.0.0 movie anyway, and I'm not planning to continue on such an old mGBA core version, so I'll probably wait until 2.5 comes out (or later) to really begin movie-making in earnest. (2.4 has a bug with Final Fantasy: Menu bug description) Edit 3: The desync was just my own foolishness. From context, I should have realized I was doing something wrong, since other people were able to watch the movie at the time. Turns out I misread the file and was using the wrong emulator version! Anyway, I will probably avoid editing this post again and instead make a new post if I make any progress.
Post subject: Re: Stone Protectors
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I think while you are in the process of creating a TAS is the perfect time to create a new discussion thread in the SNES forum. For instance, observe how Alyosha, an experienced and well-respected member of our community, recently created the Donkey Kong Land 2 topic, and has over time posted several WIPs. This example is especially illustrative because despite how experienced Alyosha is, the initial WIP of world 1 was shown to be very improvable. This is one example of many; many TASers segment their progress into discrete WIPs to receive feedback and be made aware of improvements earlier in the process, rather than at the very end. It's perfectly fine to continue an otherwise nonexistent or dead game thread to post progress updates on how a current TAS project is going. By doing so throughout the process, you can ideally get feedback on each level as you work, instead of having so many improvements at submission-time that they pile up and make full optimization infeasible in a short time-span. In the future, I would recommend posting in the game's thread to get feedback on segments of a TAS as you make them. I also think you probably need to put more time/attention into each segment, and experiment with different strategies a bit more. After all, creativity in your problem-solving is a huge component in creating great TASes.
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Alyosha wrote:
I took some time today to redo the vectrex display algorithm. It now looks MUCH better. It's a bit slower now, but I think it's worth the great increase in display quality.
Is there any chance that Vectrex could ever have a scalable display algorithm like an SVG? Or is that difficult to do with the current codebase?
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
Blazephlozard wrote:
I'm quite interested in this kind of "game inside a game" runs and wonder how acceptable they are.
Movie Rules wrote:
<h3>Games with additional level sets or games</h3>Games which consist of multiple full games available immediately in a menu, such as separate level sets, often referred to as episodes in DOS games, or the individual games in Super Mario All-Stars, they may be played and submitted individually. Playing a single episode or individual game to completion, or all episodes or games, is considered game completion. Playing multiple, but not all, episodes or games is not considered completion. Multi-games should be avoided if all the games they contain exist separately on the platform, play the individual ones instead.
Not sure if this technically counts as a "full game" within a game. One could also argue it breaks the "exists separately on the platform" portion of this rule, although I'm not sure if Galaga in single-game form was ever released for PSX. It certainly breaks the spirit of the rule when taking into account the Use the correct version rule. However, as a counterpoint to this argument, this TAS presents a unique opportunity to see double-ship action, since my understanding is that a full "All Challenging Stages" TAS of standard Galaga would likely skip getting double-ship because the time loss to obtain them is too significant. But by the same token, a double-ship TAS variant could be created for a full game Galaga submission, which would be more "complete" than this movie (though it may still be ineligible for publication, given that it would likely have to mean Moons criteria, since double-ship seems too arbitrary to be Vault eligible).
RetroEdit
Any
Editor, Experienced Forum User, Reviewer, Player (166)
Joined: 8/8/2019
Posts: 131
I will echo what others have said and say this is surprisingly fun to watch. Keep up the good work! I'll definitely be interested to see the final product, and hopefully the desync issues will be worked out soon.