|
|
Post by Peer on Apr 29, 2023 8:02:07 GMT -5
Digital Archeology - Raiders of the Lost Code
After discovering the Easter Egg in Star Ship (programmer's name appearing on the screen, see here), it was a logical choice next to investigate one of other games written by Mark Indictor. I chose Spinball because, and please correct me if I am wrong, I did not find any cheats or Easter Eggs mentioned for that game anywhere on the web either:
As it turned out, Spinball also contains a hidden way to show the programmer's credentials 
Many Cheers, Peer |
|
|
|
Post by rayxamber on May 5, 2023 13:02:45 GMT -5
Peer, I have dumped the european version of the game (Flipper / Pinball) and send it to you. But the title screen is Spinball, so I think the code is exactly the same. But who knows? And here is a screenshot on emulator of the screen with Mark Indictor name. Not so easy to obtain exactly the good score! And I confirm it doesn't work if a previous score is higher.  |
|
|
|
Post by Peer on May 6, 2023 2:27:50 GMT -5
... Not so easy to obtain exactly the good score! ... There is an "easy" way to trigger this in an emulator: Just play Spinball in Vide. Once the last round of your game is about to end, pause emulation. Vide allows you to monitor the Vectrex RAM locations, and also to inject specific values into specific RAM cells. Just find out where the current game score is stored, then poke the desired values into those cells, and then unpause emulation  Hint: The score is stored as a Vectrex ascii string, consisting of 6 digits, and a 0x80 terminator byte. A bit dump of the Vectrex characters and their hex codes can be found here. The locations of player 0's and player 1's scores are not that difficult to spot...
{Spoiler!}
RAM_score_string_player_0: 0xC983 - 0xC989
RAM_score_string_player_1: 0xC98C - 0xC992
|
|
|
|
Post by Peer on Nov 18, 2023 5:27:43 GMT -5
Due to a discussion started during this year's Vector War, I continued analyzing and going through the code of Spinball. I will post the findings here in this thread, and I start by cross-posting some of the things I already wrote in the Vector War thread.
|
|
|
|
Post by Peer on Nov 18, 2023 5:28:16 GMT -5
[cross post from Vector War thread]
Have you noticed that Spinball does not display well in ParaJVE? The ball is off to the right. This is due to the fact that Spinball draws the ball as a string, using the Print_Str() BIOS function and the 0x65 character (filled circle). I have long since suspected that ParaJVE has some inaccuracy when emulating Print_Str(). Large texts are displayed being too much offset to the right. Spinball now confirms this. Another fun fact: Spinball also draws the spring of the plunger as a string by means of Print_Str(). Here it uses the 0x6F character (filled square), and the extending-spring effect when pulling the plunger is achieved by modifying the height of the displayed string, stretching the raster lines of the square in y direction. I think this is a pretty neat and clever idea the programmers had here. The plunger is, of course, also displayed too much to the right in ParaJVE, due to the same flaw. |
|
|
|
Post by Peer on Nov 18, 2023 5:29:50 GMT -5
[cross post from Vector War thread]
I have made some pretty good progress by now analyzing the Spinball code, but I have not yet fully understood the physics engine. I am beginning to understand parts of it (it uses 16-bit precision computations, of which 8 bits are for the fractional part), but I have not yet found the part which is responsible for the bounciness of the ball, and I doubt that something like an easy fix will be possible. I do have patched version which draws the ball as a regular vector lists and not by means of Print_Str(). This actually looks quite nice, and also allows the game to be properly (dis)played in ParaJVE. |
|
|
|
Post by Peer on Nov 20, 2023 14:33:04 GMT -5
[another cross-post from the Vector War thread] So Peer, would you say Flipper Pinball / Spinball was programmed in a rush or are the maze of data more due to the limitations of the vectrex environment itself? Hypotetically if you would unravel those lists pointing to lists of lists and reorder it in a more efficient data structure, would that help the framerate at all? Could it be that they put the collision data in between the vector data so they would always be "half there" when needing it so to speak, or is the mess more of a badly arranged workbench where you have to lift things to find what you need? No, on the contrary. I would say that Spinball is a very well written and very well designed piece of software. Deciphering that large 3K bulk of data-bytes felt like walking through a maze. From the inside, a maze is confusing. But when looked at from the top, the structure of the maze becomes clear. The "Spinball data maze" is well structured. Those lists pointing to lists etc. is not chaos, but the way the programmer organized the stuff which is needed to draw the playfield and to do the trajectory computation of the ball. So to speak it is a very sophisticated way to bundle the necessary data. And you are correct, vector data and collision-specific data is indeed mixed. The vector lists contain not only vectors, but also pointers (references) to the addresses of the corresponding collision-check information of each vector. This collision-check data then itself contains pointers to information about how the ball is to be reflected on collision. There is nothing bad about such a design. It is one way to do it. There are certainly other ways, but this is how they did it. The low framerate, in my opinion, is not primarily a consequence of this data design, but rather of the fact that there is some heavy math going on. There are lots of mathematical subroutines, which are used to compute the trajectory of the ball, and which are computationally expensive. Again, not because they are badly programmed, but simply because they tried to make their mathematical model as accurate as possible. Despite the "bounciness" of the ball, I think they did a really good job here. I hope this helps. More on the "bounciness" at some other time. Also more on "drawing the playfield" then.
|
|
