Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
feos wrote:
You should be the first and the main person to judge your runs as you make them, and be hungry for anything that looks suboptimal. It's not a basic skill, but if enough effort is invested, it's always better than less effort :D
Effort isn't the problem; experience is. I have no problem putting in the time. I'm just nowhere near as good at recognizing sub-optimal situations as you more experienced players.
Sure, it's a bit frustrating when you work hard on something and think you've made it the best it can be, only to have someone else point out something that can be improved.
But what is even more discouraging is the self-realization that a much more experienced eye can see improvement possibilities that to them are obvious, while I would never see or even contemplate trying it.
feos wrote:
Improvements like this one...stand out as obvious to try.
This is an example...I would never have considered trying that method. I understand that it's due to my inexperience. But while it may have been obvious to you, it wasn't to me.
feos wrote:
Are you planning to redo this run again?
I don't know. I'm not really excited about it at the moment, but that doesn't mean I won't look at it again in the future.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Unfortunately the one human skill a TAS can't compensate for is planning and observation.
So now i'm frustrated with myself for missing something that seems like it should have been obvious.
The longer I think about it...the delay in Shaft 12 may in fact not be the most optimal method. The yellow cart could delay the turn into the transporter instead of doing a double direction change. This may allow for arrival of the yellow cart at the processing center just as the door closes after the blue cart leaves. It would shave a few frames off the overall time.
I hate finding stuff like this so long after a submission. It frustrates me that it takes someone else pointing out the possible optimization instead of me realizing it on my own in the first place.
That said...I will be revisiting this game using NTSC settings. Even though changing the yellow cart's movement is a seemingly small fix, doing so would force re-doing the timing of everything thereafter. I personally don't see a reason to spend time fixing this small flaw in the PAL run when an NTSC run will likely be faster anyway. I'll spend my time there.
If you need to reject the submission for this flaw, go ahead. If you're ok accepting it knowing it will likely be obsoleted by and NTSC run in the future, I'm ok with that too.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
feos wrote:
Can you also describe vertical positioning?
Vertical position was usually adjusted to minimize the necessary vertical movement of enemies as they enter the screen (as you suggested a while back with the abobo fight). It was also adjusted if necessary to position Billy to knock enemies off a ledge.
There are a couple other instances where vertical position somehow affected screen scroll. Most notably at the end of Mission 2. Any closer to the bottom of the screen and it won't scroll correctly for Billy to climb down the ladder to mission 3.
feos wrote:
...but sometimes how much you walk diagonally affects how far you can walk horizontally. Did you notice that?
I'm not even sure what you mean with this. I didn't notice anything odd with diagonal movement. I may have just missed it.
If there's an example in the submission, give me a time/frame # and I'll try to see what you are referring to.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
feos wrote:
SmashManiac wrote:
...on shaft 12 that the yellow miner goes back and forth immediately before entering the processing center for seemingly no reason. ...
The wiggle from the yellow miner happens for two reasons:
1) Only one player can be in the processing center at any time. As one player is leaving, the other cannot enter until the first has left completely (with all its diamonds) and the door shuts. Then the second can enter to process his diamonds.
The timing of the blue cart leaving forces the delayed arrival of the yellow cart. The wiggle could have been done at any point. I just arbitrarily chose that spot.
2) Direction changes can only happen at the center of grid points on the map. So a full block wiggle is necessary to reverse direction twice to delay the arrival of the yellow cart at the processing point.
Simplifying the branch to "All Diamonds" makes sense to me. And I'd expect a 1P "all diamond" run to be at least 45 minutes long if not an hour or more.
As far as RNG, the only thing I can see to try and manipulate is the enemy movements. However, they are typically easily dealt with without messing around with manipulating RNG.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
feos wrote:
Please tell how do you choose what attack type to use.
From what I could figure out, the back-elbow was typically the fastest method when I first started playing the game. After finding it most useful across the first few battles of Mission 1, I essentially made it my default attack.
I couldn't easily find the ram values for enemy life to see if there was a faster way to decrease damage than the elbow. I couldn't even figure out if enemy deaths were based on total damage or number of knockdowns to determine when an enemy died.
On the assumption that enemy death was knockdown based (each enemy's costume color variation seemed to take the same number of hits), I tested and found the elbows seemed to be able to hit faster than headbutts or other 1-hit knockdown attacks. Especially when moving back and forth between two enemies while attacking both.
I only did this basic testing for attack options on the first few enemies to see which attacks knocked them down fastest. I'll freely admit that I didn't try every possible attack combination on every individual enemy...because that would have taken years!
Exceptions to using the back-elbow:
-When enemies would otherwise duck/jump to doge the elbow attack. In these situations, I used a different attack; usually jump kick because the enemy would often also dodge other ground based attacks.
-Landing an elbow during Abobo battles was much more difficult to get the timing and tended to take longer than using the headbutt attack instead. The glitch to control Abobo's flight helped too.
-In general jump kicks were only used as substitutions for elbow/headbutt. If I remember correctly without re-watching the whole video, there is an instance or two where jump kicks are also used to improve position for screen scrolling.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Mothrayas wrote:
Regarding PAL runs currently on the queue (assuming NTSC is valid), it's up to the author if they want to cancel the submission and redo on NTSC, or let the PAL run be accepted for now and obsoleted with NTSC later.
PAL/NTSC info for the current queued C64 runs:
C64 Jungle Hunt in 02:28 -- faster NTSC run similar to current published PAL run
C64 Diamond Mine "2 player, 100%" in 17:51 -- This is PAL. Accept/reject as is for now, I'll look at obsoleting via NTSC later.
C64 Double Dragon "OCEAN Port" in 12:53 -- This is a PAL release of the game (graphical glitches in NTSC) accept/reject as is.
C64 Congo Bongo in 00:29 -- faster NTSC run similar to current published PAL run
C64 Frogger "Parker Brothers Port" in 04:12 -- I canceled the original submission that was made in PAL mode. I then tweaked the run in NTSC and uncanceled requesting in the author's comments that the submission .bk2 be updated to the faster NTSC version i uploaded to WIPs (link in comments).
Thanks to all of you for the discussion...it will help with TASing C64 in the future.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Not sure if there's someone specific I should suggest this to, but I assume if there is, someone here will tell me.
I have a thought/suggestion for future BizHawk versions regarding utilizing fastloaders.
I have extremely little coding experience/understanding, so I have no idea how difficult the following suggestion would be (if it's even possible). But here goes...
Could a section be added in the C64 firmware settings for a fastloader cartridge rom?
If it is loaded in as part of the firmware, couldn't other games/disk images then be opened just as they are now, while still benefiting from the faster loading times resulting from of the fastloader cartridge?
Again, I have no idea if this is even possible in an emulated environment.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Mothrayas wrote:
Of course, then it might be complicated what to do with obscure media that release info can't be tracked down for. Maybe allow NTSC anyway in such cases? I don't think there's any better option there.
If it is impossible to determine the release information for a particular rom, and there are no noticeable differences in gameplay (other than music/sound pitches and speed); wouldn't it be acceptable to consider either setting option as valid and select whichever results in a faster play-through for that particular rom?
The other option that needs to be considered by the site managers, would be to not allow any runs for publication unless the release region information can be confirmed for a particular rom file....And yes, I realize if this decision was made, it would negate most of the submissions and the few publications I have in the C64 section of the site.
Enacting this policy, however, may also deter people from TASing for the C64 in the future.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
c-square wrote:
Looks well optimized, voted meh for entertainment. Using the glitch to get multiple boulder scores would definitely help on the entertainment front.
I considered doing more glitches, but I didn't think more uses of the glitch would add enough entertainment value to bump this video up a tier to moons (assuming it obsoletes the current run). Perhaps I'm wrong on that. Oh well.
There are actually a couple other movement glitches that I could find no benefit for (at least not yet):
In the boulder section another one makes it appear as though you are in the canopy for a very brief moment, it may help land jumps faster, but i'd have to investigate this more. Even if it does, it's just a visual thing...it doesn't speed up the game.
In the last stage (Saving the girl), there are two similar momentary canopy glitches. One always seems results in instant death. The other usually does, but if performed in the right spot, you can survive and move slightly to the right. Neither is beneficial for this very short stage. As far as I can tell, doing either of these for entertainment/demonstration reasons, would only add to the length of the run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
mklip2001 wrote:
Using a bot would be an interesting thing to try in the future, but it's certainly not a requirement at the moment.
I'm sure I'd appreciate the ability to use bots to figure things like this out, but I don't know anything about programming bots ...or even where to begin learning to doing so. I don't have very much programming knowledge; just enough to recognize some basic things.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
For anyone who cares, this version of the game is PAL format. Switching to NTSC settings in BizHawk results in graphical glitches.
That's one less game to completely redo...at least until feos finds something else I can majorly improve in the run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Un-Cancelling. Changing settings from PAL to NTSC resulted in a significantly faster video with minimal input changes to re-sync. See updated submission notes for more details.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Alyosha wrote:
C64 core in BizHawk defaults to PAL video mode. Also, I believe many of the readily available ROMs are also PAL.
@DrD2k9: I would strongly recommend that you research the ROM you are using before trying to change the emulation settings. C64 appears to be quite a bit messier in terms of ROM cataloging then other systems. Also, check other sources to see if the game sounds correct and seems to be playing at the correct speed, as these are often obvious signs of using the wrong region.
Using PAL isn't necessarily wrong, and NTSC is not necessarily faster.
Thank you for the info.
As it stands, I've become rather discouraged regarding the C64 and TASing. As much nostalgia as this system holds for me, and as much as I feel it deserves its place on the site for history's sake (even if that means just in the vault), I am struggling to find enjoyment in doing the C64 TASes compared to other systems.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
SmashManiac wrote:
Isn't it possible to avoid waiting for the last barrel through RNG manipulation here?
I cannot deduce the RNG well enough to manipulate it.
I can't figure out anything regarding the barrels or conveyors.
I believe the spawn point and movement of fireball enemies is impacted to some degree by your position on the screen, but subtle movements don't seem to have much impact.
I can't get breakpoints to work in the debugger. So attempting to reverse engineer the RNG is currently not an option. This leaves trial & error as the only option (at least for me--someone else may have other ideas/skills that I'm not aware of).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
adelikat wrote:
DrD2k9 wrote:
Cancelling--I need to check PAL/NTSC settings.
There are no PAL/NTSC settings...
Please don't cancel for that.
Under the C64>Settings menu there is a tab for Sync settings where PAL/NTSC can be changed. PAL was set as default on my BizHawk.
Unfortunately I can't just switch it on the .tasproj files i've already made, but will have to manually redo one of my C64 games in the other setting to see if it makes a difference.
This submission being short, I can at least check to see if there's much difference using it for comparison.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
SmashManiac wrote:
Voting No for bad port and lots of waiting.
Also, I'm concerned that you're not sure about the fill order. A bot should be able to easily test all 120 combinations per round.
Forgive my ignorance, but I don't have the knowledge/skills to use bots to TAS my games for me.
Spikestuff wrote:
Comparison to the Sierra Version which is more of an interesting and upbeat version.
I know the Sierra version is better (it's the version I had as a kid). I was planning on doing both versions at some point.
I don't expect many C64 games to have Moon-level entertainment value, but I do feel that they should have their place in the vault for history's sake.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Due to the concerns of this run being incomplete due to not finishing the level loop, I'm going to cancel this submission. I will likely revisit this game in the future (even if it isn't the most entertaining watch).
Unfortunately many C64 games aren't very exciting to watch, but I feel that the system still deserves some TAS runs even if they are only vault worthy. The C64 is part of video gaming history and deserves it's space on this site if only for history's sake.
As far as the PAL vs. NTSC situation. I didn't realize my BizHawk settings were for PAL instead of NTSC.
That being the case, I'm going to have to revisit all of my Commodore 64 submissions as they've all been done with default settings...which means that they are all likely in PAL and may be faster if converted to NTSC.
Ugh. Now I have a ton of unexpected work to do.
