Kurt_Woloch

Here are my times for this week (June 18th through 24th) on modern systems: Sorry, I didn't play anything on modern systems this week, though I considered visiting the arcade again to play another round of "Dolphin Star", but in the end I refrained from doing it. There's still a discussion going on about the development of "Baby Pac-Man" on the Atari 7800. Right now the pinball part is in the works, and while I'm not the programmer, I made some quite extensive contributions to the thread explaining my ideas how to program things, such as dividing the pinball playfield in several areas having only 1 to 2 collision checks each. You can read all of my postings from this week if you start here: http://atariage.com/forums/topic/278165-baby-pac-man/page-15

Here are my times for this week (June 18th through 24th) on classic systems: Atari 2600: Midnight magic - 5 min. Hmmm... seems like I didn't play anything else than "Midnight Magic" on the Atari 2600, which is a pinball game that came out late in the system's life. There's still a discussion going on about the development of "Baby Pac-Man" on the Atari 7800. Right now the pinball part is in the works, and while I'm not the programmer, I made some quite extensive contributions to the thread explaining my ideas how to program things, such as dividing the pinball playfield in several areas having only 1 to 2 collision checks each. You can read all of my postings from this week if you start here: http://atariage.com/forums/topic/278165-baby-pac-man/page-15 To that end, I played a bit of "Midnight magic" to see how an already existing 8-bit pinball game works.

OK, this one didn't leave me alone, so here's some formulas to play with... I'm trying to correctly calculate a new set of x/y velocities from an old set of x/y velocities if the ball is reflected by a slanted line. Let's assume the line at the lower left (to the left of the left flipper) which goes down one step for each 4 steps to the right. We now have to convert the ball motion into a vector relative to the slant of the line (forgive me if you don't understand this, I know it's hard)... to do this we apply a turning matrix to the original x/y vectors to arrive at the x/y vectors relative to the slant of the line. The turning matrix formula looks like this: x' = x * cos a - y * sin a y' = x * sin a + y * cos a with x and y being the original x and y velocities, a being the angle of the slant and x' and y' being the resulting vectors relative to the slant of the line. Now, Sin and Cos? Well, yeah, but you don't need to calculate that... since the line is fixed, you can pre-store them. For this line, the "sin a" part would be roughly 0.96, and the "cos a" part would be roughly 0.24... not really exactly, it's only there for illustration. Basically we have to arrive at sin and cos values such that sin a / cos a is the slant of the line (4/1) and (sin a) squared + (cos a) squared = 1. (You'd best express this in a "fraction" byte so that the sin and cos values are all multiplied by 256, so the actual values would be 61 and 246 here. Actually, the ideal values in this case would be 62 and 249. But for clarity, let's stick to our original float values... Let's assume that the original speed vector of the ball is X = 3 and Y = -1, which means it goes down 3 pixels per frame and left 1 pixel per frame, so it's hitting the line pretty much straight on, but not exactly. We now compute the vector relative to the slant of the line by multiplying the original vectors with the turning matrix, so that: x' = x * 0.96 - y * 0.24 = 3 * 0.96 - (-1 * 0.24) = 2.88 + 0.24 = 3.12 y' = x * 0.24 + y * 0.96 = 3 * 0.24 + (-1 * 0.96) = 0.74 - 0.96 = -0.22 Now x' is the speed at which the ball is vertically hitting the line, and y' is the speed at which it travels along the line in its direction. Now to make it bump off, we negate x' so that x' is now -3.12. Then we reverse the turning matrix to turn this vector back to the original components. The reverse of the turning matrix is basically the turning matrix for the negative angle, which is: sin a = -0.96 and cos a = 0.24, so we just reversed the "sin a" part here. Now we repeat the same calculation as before with the new values (x' now becomes x and y' now becomes y): x' = x * 0.96 - y * -0.24 = -3.12 * 0.96 - (-0.24 * -0.24) = -3 + -0.0576 = -3.06 y' = x * -0.24 + y * 0.96 = -3.12 * -0.24 + (-0.24 * 0.96) = 0.75 + (-0.23) = 0.52 We now have the new speed vector of the ball after bumping off, which is -3.06 (3 pixels up per frame) / 0.52 (0.5 pixels to the right per frame) I know that's a lot of calculation, but at least it only uses multiplications, no divisions. I think it would be best to do a multiplication routine multiplying a 16-bit value with an 8-bit value (representing the sin and cos values) giving a new 16-bit value where the lower 8 bits of the actual 24-bit result are truncated. I think this shouldn't be too computationally expensive. For special cases such as the aforementioned circles or the moving flippers, I can also think of a routine calculating the sin and cos values on the fly without too much overhead. Just ask me... I've drawn up another picture to illustrate this: The red arrows show the direction at which the ball is initially travelling before hitting the ramp with the green lines giving the X and Y components of the speed (enlarged so you can read the numbers). The blue lines and numbers show the converted vector so you can see which directions they now represent. After negating the X component (3.1 to -3.1) the vector is "turned back" to its original orientation so that the X and Y values represent the actual screen axis again. I hope this wasn't too complicated... I tried to make it as easy as possible without using special mathematical symbols.

Unfortunately this approach sacrifices a realistic ballistic curve while the ball doesn't collide with anything... it would be more like a circle then. I'm just wondering what would be the best of both worlds... while unobstructed, the ball's movement would be expressed in X and Y velocity, then on a collision that would be converted into the vector * speed format and after the bumping action it would be converted back into x/y.

Well, as for the trapped ball... if there's a table for that, then there's the question if that table could also be used for the two curves on the upper left and right... as soon as the player's ball enters one of these areas, it could simply move as if it was the trapped ball and then get out at the other end of the curve at about the same speed it entered, but in a straight line down. This could save us from having to calculate the "proper" reactions of the ball to those two sharp curves... What I was suggesting above was essentially replacing the tile-based collision detection... it doesn't save you from the "act accordingly" part though.

Yes, I know... that's why thought to myself that checking against a slanted wall might actually be computationally more expensive than against a circle (using lookup tables). Whereas as long as the flippers aren't activated, the slants are pretty eay... the lines should be something like 4*x+y+c, and 4*x can easily be computed by left-shifting twice. However, the flippers are also slanted lines and move to different positions, and that's where things really get complicated. At the same time, the flippers are what the player actually controls and thus the ball's interaction with the flippers is probably the most critical thing on the whole playfield to get right because the player expects the ball to act in a certain way according to the "real thing" when the flippers get operated while the rest of the playfield more or less always sits in the same position. That being said, what happens if a collision is detected is probably in every case more complicated to calculate than detecting the collision in first place.

OK... I would definitely use subpixel math here. The way I'd normally do it is that both for the velocity and position of the ball (for each coordinate of it, of course) there would be one pixel byte and one subpixel byte. In each frame, there would be a 16-bit addition of the velocity to the pixel values. This way it doesn't actually matter much which direction the ball goes, the addition is always the same. In addition to that, a constant value is added to one of the velocity subpixel values in order to simulate gravity in each frame, increasing the pixel velocity value on overflow. As for checking for collision, you probably assume that a collision is only given if the ball is at an exact row or column value. But there are ways to go around this. The way I'd do it is to define a number of areas in which the playfield is subdivided. First there's a check which of the areas the ball currently is in. You can either do this freshly every frame or check if the ball is still in the same area as in the last frame and then first check if it's gone to the adjacent ones, and only if that fails, check for all others. For each area, only one or two different collision checks are performed. There are basically three types of collision checks: 1. Collision with a straight wall (can be horizontal or vertical) 2. Collision with a slanted wall or 3. Collision with the inside or outside of a circle. For a straight wall, you can simply check if the ball has gone beyond the boundary to check for, such as if the x or y coordinate has become higher or lower than the value to check for. Slanted walls usually have an equation defining them, such that x*a + y*b = c, or x*a + y*b + c = 0, where x and y are the ball coordinates, a and b are values unique for that slant and c is a value unique to that line. Now if x*a + y*b + c is positive, the ball is on one side of the line, and if it's negative, it's on the other side. The "wrong" side in terms of the check would mean it has collided with the obstacle. Finally, circles are actually easy to check for as well. You first subtract the ball position from the center of the circle. For both x and y differences, you take the absolute value and then the square of that absolute value, then add both squares together, so that result is (dx*dx + dy*dy) with dx and dy being the differences in x and y coordinates. The result is then checked against the square of the circle radius. If it's greater than that, the ball is outside the circle, if it's smaller, it's inside. For the square values, you can use a lookup table with an appropriate number of entries. The fact that the ball itself has got a size is accounted for by positioning the lines and circles so that they actually fall on the center of the ball when it's just hitting the obstacle. Here's another picture to illustrate this area principle and also the placement of the check boundaries and the different types of checks. I've colored the checking boundaries red and the area boundaries pink. As you can see, the areas can be checked pretty easily because they are always divided by horizontal or vertical lines, and by cleverly cascading the checks, there are only at most 6 checks to be performed until you have the exact area the ball is currently in. Note that the circles are always whole here, but they are actually only checked in the areas where they actually go along an obstacle. In the other areas, they are not being compared by simply not having that check performed in that area. Note that this picture is only there to illustrate the principle... the lines and circles are not all exactly where they should be. I've also only drawn the full set of lines and circles for the left half of the playfield, but they should of course be there in both halves.

Wait, something went wrong here... how can the PC be at #2 when it has only been played for 8 minutes? Either the placement or the time must be wrong.

Well, I considered how to go on with this. From Carlsson's comment about the framerate, it's clear that the framerate it currently runs at is a bit slow for a racing game, so I considered what to do with it, or if it really makes sense to go on with it. One solution might be to revert back to the version that only has a flat road, guaranteeing that the road doesn't stretch into the upper half of the screen, slowing down the drawing of the street even more. Then there was even more to come, like enemy cars on the road and scrolling mountains in the background... for which I was considering how to do them and how to encode them in ROM. I took a look at how the original track in the configuration I used looks like... basically, the closest thing I could find is this: The road curving and rising/lowering data is already taken from there, so that the road goes left, right, up and down at roughly the same points, but the amount by which it does so isn't consistent with the original track, especially the up/down movement looks greatly exxagerated. And then there's the question what to do with the mountain background... the way it presents itself in the video, it could go up very high at times.`And, as I said, the question is how to encode this in a meaningful way while still getting a good framerate. I compared this with what Namco did when they designed the arcade game "Pole Position"... it's also based on this track configuration, but they clearly made some compromises, for instance the first right curve is not nearly as sharp as the hairpin curve later on, while it seems to be as sharp on the original track. Also, of course, they didn't do any up/down movement. And there are no visible trees at all. Also, the scrolling background doesn't actually look too much like the original... it doesn't even properly wrap around so if you've completed a round, you're looking at a different point in the background than when you started! Finally I decided that in order to achieve a decent framerate, the code would have to be redesigned so that not all of the road has to be redrawn in each frame, but that would make it much more complicated, and it's the question if this is doable with only 64 bytes of RAM (the F8's registers). Anyway, the last posting was done on May 1th, and after that I decided that if it's that difficult to achieve a better framerate, there are probably more important projects to follow that I had. The weather also got warmer, so I can do more things outside now, like going swimming with my father, who is now alone after he lost his wife. Keep in mind that between each iteration I posted here, there were still 2 to 4 hours of coding going on on my part. And I did this basically as a bit of relief after all the work was done concerning the death of my mother on March 10th... but, alas, I couldn't sustain it. Sorry...

Well, I surely can remember playing its games before since I tried to play every version of Turtles in existence (other than the Casio PV-1000 version which I couldn't quite get a hold of)... I can remember that the VG-5000 version is pretty frustrating because unlike the arcade original and the Odyssey version, it has some open spaces and dead ends (OK, the Odyssey version does have those as well), and the enemies can turn on a dime if they feel like it, so they are pretty dangerous even though your turtle is much faster than them. Now it makes me wonder if there's ever been homebrew games for the VG-5000... the fact that it's been a computer with tape storage would favor it, and I think it had a Z-80 as the CPU, but was there ever a Z-80 assembler for it, or would you have to cross-assemble? I already wrapped my head around the datasheet of its video chip which seems to be an improved version of the Teletext chip used in the G7400 / Odyssey^3 (but without the low-res sprites overlaying there by the Odyssey^2 chip!), and I think that the VG-5000's full potential was never reached. Oh, wait... there's Tetris in the list of games played which does seem to be a homebrew from 2013. It definitely wasn't in the original list of released games.

I've now drawn up two example pictures... the first one shows what might happen to the ball coming down the "Tunnel" ramp if the rail after it isn't perfectly round... it bounces off at an angle and that angle increases until it hits the flipper, as shown by the red arrows. It should rather take the curve smoothly. In the second picture I've drawn the approximate circles (in red) which the guard rails should adhere to if they are round. In some places what's actually shown deviates noticeably from the circular shape... oh, and the flippers, as shown by the pink lines I drew, seem to stand out from the path the ball takes by one or two pixels, causing the ball to bounce off the upper part of the flippers if physically correct. The flippers thus should be lowered by that one or two pixels in order for the ball not to bounce off.

OK, here are some comments as for the ball physics... I just looked at a gameplay video of the original arcade game in order to better understand it. Basically, the ball physics of the unobstructed rolling ball should work such that the ball follows a ballistic curve, that is, the vertical speed stays the same while the horizontal speed (measured in scanlines per second counted from the top) increases by a fixed amount at regular intervals (which means that if it's negative, the ball goes up, and that negative value slowly decreases). This would be the movement of the unobstructed ball. If it hits something, it might bump off depending on the angle it hits the obstruction in. In this case, basically the movement gets divided in two components relative to the angle of the obstruction... one component that's parallel to the obstruction surface which is kept or slightly decreased, and another that's "normal" to the obstruction surface which basically gets negated (and possible decreased in intensity as well, or increased if it's a power bumper or such). Quite ofteh at least in this game, however, the ball will be "guarded" by a path it is going through... either the curved ones at the top or a straight one where "Tunnel" or "Fruit" lights up. For the curved ones, it should be made sure that the ball is going smoothly through them and doesn't ever fall off or be brought off-track by something that seems like a "cliff" in the curve. To achieve this, while on screen the ramps are pixellated, for the sake of calculation, they should be in angles and also be treated as such. This probably requires a bit of complex mathematics unless the ball is unobstructed. I still think this is important to get right because the ball is in such "guide rails" quite often. That being said, the way the 7800 version of the pinball playfield looks now I've got the feeling that some paths are not as smoothly curved as they should be... for instance, when the ball goes down through the "tunnel" section, the path changes into the angle at which the flippers are placed with only 2 or at most 3 intermediate steps, which if treated physically correct, might cause the ball to bump off one of the steps and get slightly off the guarded track, which is not what happens in the original version because that one is more "round".

Just out of curiosity, because the 7800 version seemed to be a bit too "clean" for me, I put the Baby Pac-Man table through the 64yourself online app, but the result looks rather chaotic and bad... you can hardly tell what's what, so now I'm appreciating the 7800 adaption much more than I did before.

Here are my times for this week (June 11th through 17th) on modern systems: Browser Based (Kongregate): Three Goblets - 34 min. VIsual PinMAME (PC): Baby Pac-Man - 87 min. I replayed the "original" version of Baby Pac-Man in order to compare it to the Atari 7800 version currently in development. Actually, this one is hard to categorize since it's a combination of emulation and simulation... Visual PinMAME runs the original ROM of Baby Pac-Man, so it's arcade perfect while you play the video part, but the pinball table has been re-built in Visual Pinball, which itself is a PC application, and it's noticeably different from the original version in that the original table is actually smaller than the "ported" one, at least in comparison to the ball. Then I tried a new game on Kongregate which I've never played before, Three Goblets. In it, you enter various dungeons battling monsters which get more and more powerful, so you have to upgrade your player in order to beat more and more of the enemies. You don't actually see the dungeons, however, only the battles with the monsters which appear as static monochrome images with sound and music only consisting of square waves.

Here are my times for this week (June 11th through 17th) on classic systems: Arcade: Donkey Kong Jr. - 23 min. Atari 7800: Baby Pac-Man (WIP) - 131 min. in 4 sessions B*nQ - 30 min. This week I followed the development of Baby Pac-Man for the Atari 7800, trying multiple versions both with arcade and "classic" ghost AI. It's coming along nicely, but the pinball portion is still missing. While at it, I also replayed B*nQ, a Q*bert clone for the Atari 7800 which is reasonably accurate to the original version (except for the sounds which remind me a bit of the NES version of Q*bert). I also replayed the original arcade version of Donkey Kong Jr. for a few rounds, but never made it past the 5th screen.

OK, here's some things I noticed. I tried the "arcade" monster AI this time (are they now monsters or ghosts? Anyway...). One thing that would make it closer to the "other" arcade versions would be if the monsters turned around when you eat a power pellet, which they do in Pac-Man and Mrs. Pac-Man, but not here, even in Arcade mode. Also, the blue ghosts should have a different tunnel speed. Right now, they don't slow down in the tunnel at all which makes them faster than non-blue ghosts going through the tunnel. The next thing I noticed is that from the 4th maze on (which is actually a repetition of the 1st), the speed picks up, but it seems slightly inconsistent... once it's a bit slower and once it's a bit faster, and it changes between that about once or twice a second. Oh, and in the original Baby Pac-Man the mazes do repeat, but they have different colors the next time around. Don't know if this is possible to replicate though... but here are screenshots of the first two mazes with their alternate colors (Levels 4 and 5)... I just played this in Visual PinMAME. Wile doing this, I noticed some more differences... in the original version, the ghosts like to turn around quite often even if they are somewhat on your track (but not if they are directly behind you!), so they are generally easier to outsmart than in your version. Also the whole gameplay seems to be somewhat slower, and it also doesn't speed up that greatly by Level 4 (only the ghosts get faster than you!). But to make up for this, the energizer time is quite a bit shorter, which reduces the advantage you have with each energizer earned.

I'd have a suggestion concerning the steering of the vid part... regarding diagonals. I know the player can't really go diagonally, but you could make it so that a diagonal means that both directions should be considered, such as... if you steer up and right, and Baby faces right, it will continue to go right as long as the path is free, but if the path is blocked it will turn upward.

Here are my times for this past week (June 4th through 10th) on modern systems... Browser-Based: Building Rush - 226 min. in 3 sessions I finally managed to complete Building Rush by going back to the first rounds and finishing them with a better score, taking advantage of the upgrades I already had and earning more upgrades in the process until I was finally able to beat the last level.

Here are my times for this past week (June 4th through 10th) on classic games... VIC-20: Q*bert - 41 min. ZX-Spectrum: Q*bert (Prototype) - 21 min. This week I tried both the VIC-20 and Spectrum versions of Q*bert. The VIC-20 version has a pretty bad display (the game characters all appear in black blocks on the cube tops), and the difficulty progression is a bit different to the original as well in that towards the end of a level, the speed picks up greatly (thus the end of Level 3 gets pretty chaotic so you can't always tell which creature's which). Also the bad guys jumping against the cube have got a different logic... in the rounds where they appear, you should only jump on the leftmost and rightmost cube on the bottom line if they are already on screen somewhere, otherwise they may strike at any time (same problem as with the Videopac version). The Spectrum version, working with somewhat similar display qualities, has got a much nicer display, but a different problem in that the speed is highly inconsistent, it even seems to be inconsistent regarding the relative speed of the characters to each other. Also the sounds and music are highly off.

Here are my times for this past week (May 28th through June 3rd)... Sorry, I didn't play any modern games this week. The weather's got pretty nice here, and I went swimming with my father multiple times which we didn't do last year when my mother was still alive, but now he's feeling somewhat lonely. This had gobbled up much of my time even though I had two days off work. And I'm actually getting used to this new life rhythm which is similar to the one I had in summer of 2015 (if anyone remembers)... big chunks of time get filled with "work", and more chunks get filled with "papa". My free time is what remains, and I often don't know which time slots will be free until the same day. In that time, however, I should primarily do tasks that have to be done, which at the moment are primarily household chores, although yesterday I caught my leg between two sofas while cleaning my living room, and now my father says I should rather not do anything like this, and we'd better have it done. We'll see how it turns out. I'd actually favor this approach because it leaves more time for gaming. (In case anyone wonders, no, I'm not an underage child, I'm actually 46 years old, but this is the way my father treats me since my mother died. It's actually a much longer story starting in my childhood with me suffering from high functioning autism). Here's my take on this... primarily, I'm with you on the first sentence concerning "browser based" games, which is what I call "online" in my write-ups. Typically, these games run in a window in the browser. It might be the case that they're visibly emulators or something to the effect of it, so sometimes I'll instead name the system which is being emulated there. If a game runs on the PC, but accesses the Internet for contents and interaction, I'd still call it PC, not online. The "Twitch" category was actually named by me because the game I used it for, Stockstream, is a bit different than a normal browser game having its own app or only one window. In this case the game was played through the Twitch chat with some extensions... if you gave it the command "!score", you got a link to a page displaying your score which you were supposed to open in a separate tab, which normally doesn't happen in normal browser-based games (except for maybe static help pages). Therefore I didn't use "online" as the classification for this game, but "Twitch". Regarding Flash and Kongregate games... these are not separate categories for me. With online games, you often don't know if they are actually written in HTML5, Flash, Java, Javascript or anything else supported by most browsers. Also, Kongregate games often appear on other sites as well, so I think of Kongregate as one aggregator of games out of many, not as a "system" of its own. I only gave Twitch as a separate category because that game used Twitch mechanics, such as the chat and the video which all players see at once, rather than a browser window which is different for each player, or at least you can't know if another player gets the same window or not (regularly he/she doesn't.) With Facebook, I don't know. I did list Facebook games under Facebook rather than Online or Browser-Based, because in order to use them you usually have to be signed in to Facebook, although the games probably use some of the same technology (Flash, HTML5, WebGL, Unity etc.) as other games not relying on Facebook. But Facebook games also may appear on other pages, or vice-versa. And Steam for me is a store for games, and maybe a platform as well, but also doesn't use other technologies than other platforms. I don't know, however, if it maybe blurs the line between PC and online games. I can't tell because I never used Steam so far. As for Windows, I'm unsure where lines should be drawn because the OS's are designed to be upwards compatible. Linux for sure is a separate category however. With Windows you could divide between the main lines, which would be Windows 3.x (though at that time games were usually written for DOS), WIndows 9x/ME, Windows NT / XP, and Windows Vista/7/8/10 (though I don't know if 10 is different enough from 7 and 8 to call it a new line).

Here are my times for this past week (May 28th through June 3rd)... Atari 800: Pitfall II - 83 min. This week I decided to try the Atari 8-bit version of Pitfall II which is the only version having an additional level. And that level is much harder than the first one. First, the maze is more irregular, thus harder to remember. Then it has several cross-sections which you may cross vertically by climbing the ladder or horizontally by jumping over it, but you can't change from the vertical path to the horizontal one or vice-versa because you can't get on or off the ladder there. Also there are some harder animals... frogs which jump towards you instead of staying in the middle, fish swimming at a high pace, rats, bats with a much higher movement span... I played around with that level for a while and then gave up. And that's it for gaming this week. The weather's got pretty nice here, and I went swimming with my father multiple times which we didn't do last year when my mother was still alive, but now he's feeling somewhat lonely. This had gobbled up much of my time even though I had two days off from work. And I'm actually getting used to this new life rhythm which is similar to the one I had in summer of 2015 (if anyone remembers)... big chunks of time get filled with "work", and more chunks get filled with "papa". My free time is what remains, and in that I should primarily do tasks that have to be done, which at the moment are primarily household chores, although yesterday I caught my leg between two sofas while cleaning my living room, and now my father says I should rather not do anything like this, and we'd better have it done. We'll see how it turns out. I'd actually favor this approach because it leaves more time for gaming. (In case anyone wonders, no, I'm not an underage child, I'm actually 46 years old, but this is the way my father treats me. It's actually a much longer story starting in my childhood with me suffering from high functioning autism).

Here are my times for this past week (May 21st through 27th) on classic systems: Online: Building Rush - 31 min. Building Rush 2 - 206 min. This week I played two online games on Kongregate, Building Rush 2 and Building Rush (in that order). In both of them you have the overhead view of a city with building lots which you have to supply with building materials from your delivery centers using trucks and (in later rounds) helicopters. Each round has a different map, and you have to reach a certain sales target in the predetermined time. Strategy comes in by having a starting money which you have to use to buy tracks and pay for deliveries upfront. Each sale will make you a profit and over time enable you to buy more trucks, helicopters and centers and upgrade them, but you have to be careful to leave over enough money to finance the next deliveries so that all trucks and helicopters are getting used.

Here are my times for this past week (May 21st through 27th) on classic systems: Atari 7800: Baby Pac-Man (WIP) - 18 min. TI-99/4A: Slymoids - 34 min. VIC-20: Donkey Kong - 68 min. in 3 sessions I tried the WIP of "Baby Pac-Man" on the Atari 7800 which was posted on an Atariage thread. It still misses the pinball part, but it's off to a good start. On the TI-99, I continued to play "Slymoids", but I started at Level 3 this time and didn't manage to finish it. Then I tried the VIC-20 version of Donkey Kong since I remember I tried to code something similar to that in BASIC (after having done the same on the TI-99), but it didn't nearly as good as the commercial version, which is fast and furious (way faster than the arcade original actually) although the framerate is not that great. You have to careful when jumping because unlike most other versions you can still steer left and right while in the air!

Here are my times for this past week (May 14th through 20th) on modern systems: Android: Crazy Taxi: City Rush - 72 min. in 5 sessions Toy Blast - 46 min. in 2 sessions Arcade: Dolphin Star - 3 min. World's largest Pac-Man - 4 min. Online: World's biggest Pac-Man - 9 min. I continued playing Crazy Taxi: City Rush, but now I completed all Downtown medal missions, and on the next level (Beach) I've already maxed out the car by upgrading it and still can't complete some of the medal missions, so the game gets rather boring at this point, and I basically gave up on it. Then I downloaded and installed "Toy Blast" which is actually very similar in gameplay to "Toon Blast" except for different graphics, sound and level designs. I've also been to the arcade again where I played one more round of World's largest Pac-Man and Dolphin Star, respectively. There have been quite a few players on World's largest Pac-Man because my 4th place in the hi-score list moved down to 9th by now, and I didn't manage entering the high score table again. On Dolphin Star, I played with my bag on and my knees resting on the foot rests, and it doesn't quite work out, the game stops moving repeatedly with my body in this position. Maybe my center of mass is too far in the front so that the machine can't lift my weight at some point, or maybe the belt just slips for some reason. In that respect it seems weaker than several "normal" kiddie rides without built-in video games. Similar to "World's largest Pac-Man" is "World's biggest Pac-Man" which refers not to the screen size, but to the total playfield because it consists of many user-made mazes, and after completing a maze you exit through one of the tunnels and enter the next one adjacent to it.

Here are my times for this past week (May 14th through 20th) on classic systems: Commodore 64: Crazy Kong (Interceptor) - 9 min. Crazy Kong (Supersoft) - 11 min. Intellivision: Auto Racing - 32 min. in 4 sessions TI-99/4A: Slymoids - 71 min. in 2 sessions This week I continued to play Auto Racing on the Intellivision in order to map it and slowly fill the off-track gaps. Then I tried two Donkey Kong clones, one by Interceptor Software (Ian Gray) and one by Supersoft (similar to one clone of Burger Time). Actually I looked for another clone made by Kingsoft back in the day, but couldn't find it. Out of the two I played, the one by Supersoft is better... it has the slanted lines and the screens look more "correct" than on Interceptor's version. Finally, I replayed Slymoids for the TI-99 in two sessions, but the games are getting pretty long... each session sonsisted only of a single game.