Jump to content
IGNORED

Shamus fixed for XL/XEs with title music?


slx

Recommended Posts

Comparison testing shows that for different maps on the C64 there are different boundaries between the black, blue, green and red levels. Writing down the "boundary" numbers and searching for them shows them on page 1 and after a little more sleuthing (shamusing?) I also have the table where they're stored for different levels. Searching for the same numbers on the Atari reveals nothing but after decreasing them by one I find the list.

 

While this table is no more than 15 bytes long, I'll still patch the data into the "map data file" to leave the possibility of loading even more maps open.

 

Object (Keyhole, Key, etc.) colors need some more work as well. Atari Shamus uses a fixed luminance of 6 for all objects but that simply doesn't work when trying to recreate the C64's palette with its five shades of gray. As it would be quite shameful not to be able to recreate the C64 colors on a machine that prides itself on having 16 times as many, I need to store luminance information as well and patch the Atari code to use it. I have an idea how to do that but it remains to be seen whether that will break something else :twisted:

  • Like 3
Link to comment
Share on other sites

Action! drives me crazy by constantly crashing, probably some array index writing where it shouldn't and/or too little memory. Level boundary data is generated correctly but somehow gets stored in the wrong place or is lost on the way to WUDSN :mad: Should have done this in Python...

Going to bed now, it's 1:30 AM here :sleep:

  • Like 1
Link to comment
Share on other sites

Tried to go to bed twice but always had some idea when preparing to do so, went back to the computer and tried some more. Got the converter up and running again by reverting to a previous version and fixing a stupid bug. Took a printout with me to think about the assembly code while commuting but found that there was a reason for using fan-fold paper BITD. At least with the type sizes I now need to read comfortably you simply can't fit much assembly code on a single page and it's much easier not to lose track of where your are and connect stuff with lines on fan-fold ...

 

To think that I once used Atari ST software that would print about 4 pages on one sheet using graphical micro-fonts in order to save paper....

  • Like 1
Link to comment
Share on other sites

Found a missing # in what should have been LDA #$06 and another logical mistake (trying to use data that wasn't there yet). Feels quite finished now but I still want to do a room-by-room check. No reply by Cathryn Mataga yet.

  • Like 4
Link to comment
Share on other sites

Set up Altirra and x64 windows side by side, took a gampad in one hand and joystick in the other and "walked" all 128 rooms of the first maze ("Original") of the C64 game.

 

The good news is that except for one they all looked identical and I quickly found the error in the converter tool for the one that was wrong.

 

I was puzzled by a room that seemed "broken" as it was impassable with walls blocking the way between left and right. After a long comparison with another cracked version of C64 Shamus a quick look on a Shamus map showed me that it was just a clever maze layout that works.

 

I also found that the mystery bonus and potion "objects" do change color in higher levels, so I had to put that in the converter as well.

 

While re-coding the converter wasn't that hard it kept crashing, apparantly by zapping itself and when I inadvertently saved a version that was missing most of the code that wasn't on-screen at the time of saving, I had to go back to a previous version and re-do some of the last changes (more elegantly this time, I hope). The "original" converter had loaded all of the C64 map data in one array and then wrangled it into a second "Atari" array which it saved out. As I suspect the program of exceeding Action! memory capabilities I'll now change it so it will load one maze at a time, convert it and write it out to the Atari map file, then grab the next maze, etc.

 

Need to finish this, too much work around the house waiting for me...

 

 

 

 

  • Like 5
Link to comment
Share on other sites

Not looked at this thread for a while, epic work by Six, really excellent work there...

 

I saw you mention Cathryn, I presume William did the same as Dani Bunten?

 

A by product of game programming :)

 

Seriously, I have no issues with gender, what people do is up to them and I hope it brings happiness which every one deserves...

  • Like 1
Link to comment
Share on other sites

Not looked at this thread for a while, epic work by Six, really excellent work there...

 

I saw you mention Cathryn, I presume William did the same as Dani Bunten?

 

A by product of game programming :)

 

Seriously, I have no issues with gender, what people do is up to them and I hope it brings happiness which every one deserves...

 

This is epic the same way an ant's journey across the yard is epic ;) Most of the time I am fighting against my own programming weaknesses rather than epic obstructions. I am constantly reminded that with Assembler you just can't make some change that looks about right and wait for a failure message to warn you if it wasn't that right, you really have to think through every little bit you change. (When I found that missing # I was starkly reminded of a night spend coding at age 17 when it took me several hours poring over printouts to find a similar error.) Converting a whole C64 game would better fit "epic" maybe, that's on the bucket list as well but I don't really know if I want to learn enough C64 to do it, that RAM/ROM banking scheme alone is quite scary for someone who learned Atari programming before the XL era.

 

Cathryn Mataga was indeed William Mataga in 1982. I always found it striking that the programmers of my two favourite Atari games chose that way but as you say, it is entirely up to them. So far she hasn't replied to my request and I have asked someone in contact with her to try to reach out to her. As she last used the Shamus franchise commercially (for a tablet game) a couple of years ago, I'd really feel better releasing this with her blessing.

Edited by slx
  • Like 1
Link to comment
Share on other sites

Thanks for all the likes, hope to be able to meet expectations eventually...

 

Re-writing of the Action! converter utility unearthed a variable declaration bug that had masked the presence of corridor rooms on the C64 that do not fit into the Atari coding scheme (the C64 has a more flexible way to code corridors and can thus code vertical corridors with or without exits to the left/right as well as horizontal corridors with dead ends while the Atari is pretty much limited to the seven variations that can be seen in the game and a dead end open to the top of the screen that is not used in the original maze).

 

The horizontal corridor can be recreated gameplay-wise if not visually by "walling off" an otherwise empty "chamber" type room but the vertical rooms I will only be able to approximate using angled corridors (which will make that part of the maze a bit easier to navigate as the vertical corridors loop onto themselves and therefore make keeping track of one's position more difficult).

 

The Shadow does not yield his lairs easily....

  • Like 4
Link to comment
Share on other sites

I am happy to report that a room-by-room comparison of the "Original" maze from the C64 with the same maze converted to the Atari shows no real differences in maze layout, placement and color of objects. :) :) :)

 

As this is not going to be an emulator but an attempt to play C64 mazes on the Atari I will not further tweak colors trying to find an exact match for the C64 colors. They're reasonably alike and as the whole game looks quite different on the C64, different sprite/enemy bitmaps, etc. I don't see a point in tuning one single aspect of the visuals to perfection.

 

:arrow: I need to repeat this for the remaining 4 mazes but am confident that they won't throw any new tricks at me.

:arrow: I am still waiting for word from Cathryn Mataga.

:arrow: Before releasing anything, I want to clean up my "hacking notes" and include my observations on the differences between the C64 and the Atari versions of Shamus (of which there are many).

:arrow: I think that there is a bug in the original code of Shamus that causes massive slowdown when entering the blue level in "Expert" mode. I want to re-check this on actual hardware and have already identified a delay loop I believe to be the culprit.

 

While a level editor and/or map function (like on Shamus: Case II) would be nice, they're not that simple to implement as there is no requirement for the map to be consistent, i.e you can walk down from one room, move one room sideways and return back up to a room 10 rooms distant from the one you started from, even in the other direction. Maybe someone already versed in map editors will take up the baton once I publish the maze coding specs.

 

School holidays are over in Austria, so the alarm clock will sound earlier on weekdays and there will be less time for late-night coding. :sleep:

 

The commented Action! source code of the converter has over 10K now and compiles to around 4K, the patch without map data is just around three pages long, at least one half of that is display lists and text for the menu.

  • Like 8
Link to comment
Share on other sites

After writing about 10 pages describing the mapping on the Atari and the C64 I resumed testing the remaining mazes and found another type of room I had believed not to exist.

 

Holmes Room 50.bmp

 

I had incorrectly assumed that all "pod" rooms were otherwise empty and even convinced myself that this would occur automatically on the C64 regardless of other coding. Turns out I must have been sloppy trying it out and/or jumping to conclusions.

 

Fortunately it seems that this can be re-created on the Atari, so it will require only a little change to the converter utility (and a re-write of the specification). On the Atari, the pod room moving barriers will obstruct the vertical walls of the maze, however. As this should not impair gameplay, I am rather inclined not to change that in the game engine.

 

 

  • Like 3
Link to comment
Share on other sites

I am still not sure that I fully understand the issue but it seems that different cracked versions of Shamus for the C64 handle this pod room issue differently. At least they showed different results on identical map data, with the version I had used all along making pod rooms empty regardless of other coding. I tried a couple others and they all behaved the same, so I'll assume that's correct.

 

Changing the converter was easy, I'm now back to room by room testing.

 

Second Maze (Holmes) tested fine. Three more to go.

Edited by slx
Link to comment
Share on other sites

All mazes checked! And working! Found that I need to disable the routine that randomly swaps bonuses, extra lives and keys around as it places them in corridors on some C64 mazes. It would have been possible to change the routine to only use corridor rooms but as that would have required mapping all the mazes in order not to let it move keys behind keyholes requiring them and as the C64 does not swap items (at least so I think after some trials) and as I want to play the game without knowing the map I decided to just bypass the swapping when using any other than the Atari maze.

 

Still no word from Cathryn Mataga.

 

 

Gesendet von iPhone mit Tapatalk

  • Like 5
Link to comment
Share on other sites

Mostly finished, actually my code seems to work without any flaws. I came across what I think is a bug in the original game, however. The Atari version of Shamus increases the speed of the game (by decreasing $0206 which controls how often code starting at $2F98 runs a simple loop of the Y register from FF to 00 ) with higher difficulty settings as well as higher levels. The value in $0206 is decreased by 2 for every difficulty level and by 1 for every level in the maze. (NOVICE will have $07 at $0206, when making it to blue level it will drop to $06, etc.)

 

The problem with this is, that any decrease below 0 will slow down the game so much as to make it unplayable (this causes the inner Y loop to run 255 times for a total of 65535 loops).

 

In order to notice that you have to either start at "ADVANCED" and make it to the red level or start at "EXPERT" and make it to the blue level. I don't think I ever played the game beyond "NOVICE" level even though I considered myself quite adept at it. I wonder if anyone ever ran into that bug BITD or if anyone could confirm it to exist on a real machine?

 

While the code that needs fixing is not time-critical as it is executed during level changes only, fixing it seems to be a bit more complicated than I first thought. My first idea was to simply prevent the value in $0206 from dropping below 01 (and maybe allowing for a gentle increase in game speed by reducing the FF in the inner loop.)

As you can return to lower levels within the game, that value can increase as well and so I would need a major re-write to change the whole "speed setting" code to keep it from increasing that value (but maybe change back the inner loop to FF) when returning to a lower level.

 

Would appreciate any input on whether that error exists on the real machine (top notch players required here) and if so on whether I should actually attempt to fix a bug that maybe does not affect anyone as hardly anyone has the skills to run into it.

 

( I found this bug in all file versions of Shamus as well as the ROM version (where the speed setting is in $1009) but only checked it in Altirra.)

Edited by slx
Link to comment
Share on other sites

In the modern day recreating it should be easy - with collision detection disabled you could probably do a run through all levels in a matter of a few minutes.

 

That's how I test it in Altirra, I can even have level blue start from room 2, level green from room 3, etc. but I don't have any "cheating gear" for real hardware (at least not installed, that is ;-)).

 

With the fidelity of Altirra I highly doubt that real machines would behave differently but then it's hard to believe that Shamus should have been faulty for the last 35 years without anyone noticing...

 

 

P.S. to have the levels start earlier you need to set $24F8 to $24FA to 01 02 03. I have not looked for the collision detection code yet as I can simply turn it off in Altirra.

Edited by slx
Link to comment
Share on other sites

Fiddled a little more and found that speed also changes every time a maze is finished by killing the Shadow in his lair (i.e. the last room in the maze).

 

The number of finished mazes is subtracted from three, doubled and increased by 2.

 

So for NOVICE mode you start on speed 7, decrease 6 (blue), 5 (green), 4 (red). On finishing the speed slows to

 

(3-1)x2+2=6

 

After finishing again, this time with speed 3 on the red level, it changes to

 

(3-2)x2+2=4

 

and for the fourth attempt it slows to 2 (which will cause slowdown when reaching the green level).

 

(The best I ever managed was finishing twice and then the blue level, so I was still far away from slowdown.)

 

I think it would start out with 8 for a fifth attempt as everything but the lowest two bits of the completed mazes are ANDed away, thus zero would be subtracted for four completed mazes.

 

The game is really twitchy at speed 1 so I maybe no one was ever supposed to make it that far.

 

Not really closer to fixing the speed bug, but keeps me thinking about a "tournament" mode where you don't loop back to room 0 of the same maze but rather continue with the next maze....

 

 

Link to comment
Share on other sites

Started on tournament, then thought it would be nice to have the current maze shown on the status line, just like the C64 has, so you'd know where you are (plus it would make troubleshooting easier).

 

Remembered the ANTIC jump instruction and used it to simplify the code patches to the menu by just jumping to a new end for the display list rather than replicating all of it and patching all code referring to it (which cut at least 30 lines from my assembly code).

 

Still messing around with that extra line on the main game screen.

 

Fixing the speed issue is still in the 'vague idea' phase with nothing coded yet.

 

Should have done this for retrochallenge...enough written for a honorable mention in the wordy blog category, even if there's no program to show yet ;)

 

 

Gesendet von iPhone mit Tapatalk

  • Like 1
Link to comment
Share on other sites

Tournament also requires a decision on how to handle speed on entering a new maze. If it works like the game - even when eventually fixed hopefully - it'll get super-twitchy by the time you reach the third maze, so it should probably reset to almost initial speed on maze advance.

 

 

Gesendet von iPhone mit Tapatalk

Link to comment
Share on other sites

I'd put a cap on the speed, there was probably little though at the time that people would just loop through continuously.

I tend to think that it was made so fast before the bug so that no one was ever expected to hit it. I once managed to play it 2 full mazes plus halfway into blue but thereafter there was no real further goal other than an even higher score, so I lost interest (plus it required an hour of increasingly fast play). If I leave the bug in it probably won't bother anyone soon, it's more a matter of perfection ;)

 

 

Maybe instead of repeating the same maze set when you finished them all it could play through the next set.

That's what I call Tournament mode for lack of a better name. It's already on the game menu and loads up the Atari maze first but the real work of patching the maze-end code to advance to the next maze is still ahead (at least I think I know where to find it as I stumbled over it while trying to fix the slowdown bug).

 

I plan to leave out the C64 'original' maze for tournament mode as it is almost identical to the Atari maze.

 

 

Gesendet von iPhone mit Tapatalk

Link to comment
Share on other sites

Tournament working with a slight speed increase (like after completing a maze) and a path in sight for the speed/slowdown bug.

 

Pondering Pause and Map, although the latter is much harder. Will see if I can pause the game and restart it but rather release a 0.x version before entering Atari vaporware league.

 

That probably requires enabling the keyboard, setting up a key interrupt and stopping any other interrupts from advancing the game.

 

While still coding slowly, I just love how machine language allows you to do stuff in multiple ways. (And hate when leaving out a hash leads to half an hour of debugging.)

 

Current map display on the bottom of the screen works as well, half an hour lost to sloppy thinking there when I had names truncated first and then spelled backwards because of a loop index counting down ISO up ;) still want to improve the code for that code to save space.

 

 

Gesendet von iPhone mit Tapatalk

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...