Kurt_Woloch

Well, I did think a bit more about the gravity... the correct amount of general acceleration would be proportional to the sinus of the angle at which the ball is going down. But that includes the left/right acceleration. The correct amount of down force would then be the (sinus of that angle) squared... which is equal to the sinus of (double the angle minus 90 degrees) + 0.5 (so always between 0 and 100% of gravity). The correct amount of left/right acceleration then would be the sinus of double the angle, with the maximum being 50% of total gravity at 45 degrees. Also I was going to take down the gravity by two "ticks" (2 sub-pixels per frame) if the ball is going down vs. if it's going up. The ball serve: I did do that purposely, I just don't know if it's really correct or if the ball does sometimes serve to the right as well. That's why I asked. But that's exactly why I chose the LEFT bumper first, not the right one. I just think the serve on the original machine doesn't ever go as high as in my version. I did that so that the ball is sometimes able to reach the upper portion of the bumper (in order to better test the line detection). Horizontal momentum: Well, actually half would actually look right to me, I just think it should lose half of the vertical momentum as well. Also, it might actually differ depending on the material... maybe if it hits something which in the original game is only made of rubber, it should only lose a quarter of its momentum (pretty easy... shift right twice and subtract that from the original value). But those are not the vertical streaks. Yes, I believe the curves at the top are circular on the actual game as well. This will probably be some trial and error to me... whatever looks good.

OK, uh... some answers to what has been written here: As for gravity, I was considering doing different gravity schemes, depending on if the ball is rolling on the table or against a lane, in which case the gravity would be weaker, but slanted according to the slant of the lane. Which would maybe solve the problem of the transition between bouncing off from an obstacle and rolling against the side of it. The ball serve, as I implemented it, wasn't the final planned version, instead it was coded in a way that the ball was at least sometimes hitting the only coded obstacle (the right side of the left bumper) at different points. Actually, @Imstarryeyed, since you own the real game, I'd like to have an input from you here on which way the ball actually gets served on the real machine... does it prefer one direction or is there a range of directions it might come out in? Does it always have the same power, or does that vary as well? I think the left and right edge boundary checks are slightly wrong... if the ball loses half of its horizontal momentum, it should lose half of its vertical momentum as well, otherwise it would come out at a different angle than it goes in. In Pool Billards this doesn't happen... the balls always come out at the same angle they go in, so why should this be different at Pinball? And that direction change routine for the boundary checks could be reused for other vertical obstacles, i.e. the inner boundaries of the outer lanes and the lanes leading to the curves (NOT the lanes to the back of the bumpers, because they are just 7 pixels wide so that the ball just fits in... no room for left and right movements there!) I'm still considering how to do the curves at the top, actually. The problem there is that they are not circles, but rather ovals. And the left and right curves even have different radii. Therefore I was thinking of maybe breaking them up into sections. But we'll see... I have to apologize for not advancing quicker on this. It's still summer, and I went swimming with my father (who just lost his wife about 6 months ago) nearly every day for the last week. I put about 6 hours into this project last week, but that already caused me to fall behind with my other projects, so I'm trying to catch up since then. Looking forward to your next binary!

This is not a question about how many bytes the coordinates have... there are already pixel and sub-pixel coordinates as well as pixel/frame and subpixel/frame speeds, and I'm going to stick with that. The pixel coordinates will also always have only one byte because the playfield in 160 mode is 128 bytes wide, so if I double that it would still fit in a byte. It helps that the ball never wraps around. Memory or processing time? Hmmm... the 7800 has 2K of RAM as far as I know, and I don't know how much of that already gets used for the tile map and display list. As for now. I'm trying to stick with the temp variables and the pinball variables reserved by Bob. The pinball variables are 32 bytes for game objects + 32 bytes for balls (out of which 5 are still free), and the temporary ones 16 bytes. I'm trying to keep within this frame, though it might get tricky during some of the calculations that need to be done. As for speed, the 6502 in the 7800 is running at 1.79 MHz, but much of that is being taken away during screen display by the Maria DMA. Bob was always afraid of something not fitting into one frame, so I'm cautious how many cycles I use for one collision. Oh, and currently there's about 1379 bytes free for code in the block I'm using. So far I seem to have used up about 308 bytes, so I might scratch that limit sooner or later. As for Bob claiming to be an idiot... I don't think so at all. Each man has got its strengths and weaknesses. For instance, I'm generally weak socially, and I'm having a hard time starting conversations, always afraid I might annoy someone. And at work, even though I do work as a programmer, I must admit I often have a hard time grasping everything I need because there's a lot of domain knowledge we're supposed to keep in our heads, which is where I often fail, unfortunately. To compensate for this, I'm good at math and trigonometry. But I do admit that it actually seems to me that I have a talent for making other people look like an idiot without even trying to do so, and it's actually depressing for me if I see that again I seem to have discouraged someone to the point that he/she gives up what he/she was doing. This I actually consider a weak or mean side of me.

OK... I think I got a clear answer to my question. There were basically two votes for the 1:2 aspect ratio (the green arrow) and none for any other possibility, so 1:2 it will be. Just considering how to do this. The first possibility would be to actually keep the ball coordinates in 320P (which would be possible because the screen is actually only 128 pixels wide) and then converting them down for display. The other one would be to keep the coordinates in 160P as they are now, convert the speeds to 320P before each direction change involving angles and then converting them back. Another question is: Do you think I should post some intermediate binaries even if they still aren't playable yet? (The maze part is playable however... Bob even made some minor improvements before posting his source code which I picked up)

Well, it could... if the power bumper is actually powered. However, I've looked at videos from a real Baby Pac Man machine, and it seems like on this table, the power in the power bumpers is not actually very strong, so it might be a reasonably approximation to simply deflect the ball from the bumper surface without losing any momentum. Your proposal, in fact, does come true since the ball's trajectory is of course no straight line, and the lower the ball speed is, the less it will travel to the right for the same distance down created by gravity. However, I purposely ignored this and only tried to give the starting angle of the deflected ball on my arrows. And without power, I don't think that shouldn't be affected by the incoming speed of the ball. Look at billards... there you actually count on the deflected ball going away from the wall at the same angle it hits it... no matter what its speed is. OK, the pool table is of course not sloped.

Hmmm... OK, I watched all three of those videos. In all three of them, however, they kept the usual aspect ratio of pinball tables, i.e. they are clearly higher than wide, or at least square. Also the ball doesn't look as squashed, but really round so in those games I'd assume that the correct deflection would involve angles that look right when shown on screen. If this is what you mean by those examples, then the best solution probably would be to assume that for deflection angles, a pixel is actually twice as wide as high (as it actually is in PAL).

Here's a little update... I've worked on this for a few hours now, and so far I've implemented the check for a slanted line (or should I simply say a diagonal?), so that now the game correctly detects when the ball has hit the right surface of the left bumper. That's not much, but it's a start... however, I'm now unsure how to handle the aspect ratio correctly. To explain what I mean, the actual table of Baby Pac-Man has about a depth to width ratio of 7 to 6, while the table on the 7800 version is 216 x 128 pixels, which is a ratio of 27 to 16. While this would suggest that the table is higher than usual, this is actually more than compensated by the pixel aspect ratio of the 160 modes of the 7800. I guess that in PAL one pixel in that mode is twice as wide as it's high, so that would stretch the visible aspect ratio to 27 to 32, so it's a bit more wide than high. On NTSC, the pixels are about 20% higher, so there the aspect ratio would be 32.4 to 32, or 81 to 80. Now, the question is if this should represent a playfield which is actually 27 to 32, or 81 to 80 in size, or if it should represent one with a ratio of 27 to 16 with the pixels simply being squashed.Moreover, the ball is 7 pixels wide and 11 pixels high, which in PAL would look like 11 high and 14 wide, and in NTSC it looks like 13.2 high and 14 wide. Measured in percent of the playfield, this is 5.09% of the total height and 5.47% of the total width. On the original playfield, if the ball is round (which it should be), it occupies roughly 5.17% of the width and 4.4% of the height of the playfield (but that's not super exact). Where this comes into play is when the ball is deflected from a surface that's not purely horizontal or vertical, because in that case, the angles, if stretched, might not look correct. The question is what to do here... should the playfield be assumed to be "squashed"? Or should the aspect ratio look right if watched on NTSC? Or on PAL? Just to illustrate this, depending on what the aspect ratio is, an incoming ball might be deflected at a different angle. To illustrate this, the picture shows the left bumper and an incoming ball. The question is, which deflection angle (assuming no additional power from the bumper) would be the right one? Let's assume the ball coming in at the angle shown with the red arrow. With pixel aspect ratio 1:2, this would be a 45° diagonal. The bumper's surface, as I have measured and calculated, has a slant of 5/23, so with the aspect ratio this is stretched to 10/23, which is about 113°. Thus in this case the ball would be deflected so that it comes back at an angle of 1°, which is a bit over a horizontal line to the right. I'm showing this as the green arrow. However, if I assume the ratio to be squashed differently (like the ball is), the slant would change to 7.86/23, which is about 109°. At the same time, the ball incoming at the same angle would actually have a speed (relative to it) of 1/14 "ball units" to the left and 1/11 "ball units" up, changing the incoming angle to 52°. This would cause the ball to come back at an angle of -14°, which is quite a bit under a horizontal line (1 down, 4 right), but measured in ball sizes, so it's actually 1 down, 5.09 right. I'm showing that direction as a blue arrow. Finally, if I assume the actual pixel ratio to be correct, the slant changes to only 5/23, which is about 102°, and the ball now does 1/2 pixel to the left for each one down, changing the incoming angle to 63°. This would cause the ball to come back at an angle of -39°, which is nearly a diagonal, but shown at the pixel aspect ratio, so on screen it would be 1 down, 2 right. I'm showing this as a yellow arrow. Now the question to you all is: Which angle do you think would be the right one?

Here are my times for this past week (September 3rd through 9th) on modern games... Browser-based: Free Asteroids - 6 min. I only played one modern game which is a remake of the classic game Asteroids. I played it after I learned that Tesla (the maker of electric cars) will put some Atari games into their software to play in the car, and Asteroids was shown on screenshots of that new version. I was actually curious how many asteroids can be on screen at once, but I didn't manage to find an answer to that.

Here are my times for this past week (September 3rd through 9th)... Atari 7800: Baby Pac-Man (WIP) - 27 min. in 2 sessions I played two more sessions of Baby Pac-Man this week... one after Bob (Pacmanplus) abandoned the game and posted its source code. In the 2nd session I played a newer version of it which is contained in the ZIP file with the source code. After that, I started making changes to it myself and contacted Bob about it after they were successful, and now he's relying to me to implement some things he can't wrap his head around.

Well, thanks Bob for this phenomenal work you did. As "promised", I took a deep look into the source code you posted. The first thing I found embedded in the ZIP files were the latest binaries where even the maze part seems to be a bit refined compared to the binaries that were last posted here. As for the code itself, I think I'd know where and how to continue, although I can't promise having the stamina to really complete the pinball part on my own (for me it's mainly about the time needed). Moreover, I never programmed for the 7800 before, though I did a lot of 6502 code for other systems. At the moment my free time is sparse though, but that might improve over the next weeks. I won't tell much more here right now because I don't know if anyone is supposed to build on that code or even publicly comment on what's been done and what's not, or if this topic should just be closed and the game be left as unfinished as it is now.

Here are my times for this past week (August 27th through September 2nd)... sorry, I didn't play any modern games this week.

Here are my times for this past week (August 27th through September 2nd)... Colecovision: Steamroller - 294 min. in 9 sessions This week, I only played a single game, but I played it for about 5 hours and 9 sessions in total - Steamroller on the Colecovisoin. I haven't reached my goal of beating the typical Activision patch score of 35,000 points (has there been a patch for this game at all?), but I'm working on it. Several of the sessions only comprise a single game which typically lasts over 20 minutes.

Here are my times for this past week (August 20th through 26th) on modern systems: Browser Based: 20 Euros - 40 minutes I played a few rounds of 20 Euros this week (which is a variant of 2048), but didn't manage to finish the game. The 40 minutes is a rough estimate.

Here are my times for this past week (August 20th through 26th) on classic games: Atari 7800: Baby Pac-Man - 33 min. Bentley Bear's Crystal Quest - 94 min. Serpentine - 81 min. in 2 sessions This week I played 3 Atari 7800 games. I replayed Baby Pac-Man because its author is currently stuck, so the pinball portion will probably take another while to complete. Then I played another game by the same author, Bentley Bear's Crystal Quest (AKA Bently Bear, AKA Crystal Quest), using continues until the end of the 8th round where the first boss appears. Finally I also replayed Serpentine where I managed to beat the 20th and last level (which in this version is identical to one of the previous levels).

OK... obviously I was only talking about Pac-Man like games being based on Ms. Pac-Man... you can't base Scramble, Circus Atariage or Berzerk on what was originally a Pac-Man game. There's one more game I see some similarities with... Bentley Bear's jumping physics are also affected by gravity, as is the ball in Baby Pac-Man. However, it's obvious to me that the physics in Bentley Bear is somewhat "tweaked" since he comes down much faster than he goes up, which wouldn't happen this way in real life. Feel free to use any of the routines or ideas I posted earlier if you (or your fellow programmer) can understand any of them and find a place for them! I can also try to find the "connection" of my routines to your existing source code if this would help.

Oh dear... maybe I went too far with my explanations, but unfortunately the proper formula for deflecting balls at an arbitrary angle does contain Sin and Cos, and while there are ways to get around this in calculation, it's rather trickery to do so. I don't think collision detection would take more than one frame (at least the way I proposed to do it), but on a collision it may take longer to properly calculate the new ball speed. On the other hand, it may not... It's understandable for me if you can't wrap your head around that trigonometry stuff. I guess the maze portion was relatively easy to do since you already did multiple other games like this and they are probably all based on the 7800 version of Ms. Pac-Man, while there's no prerequisite for a pinball game. So what do we do with this now? Bob, you said you had you had another version you didn't post where some glitches were fixed. Then there's the question if you would be willing to share the source code of the game so far so somebody else could try to continue work on it. Or do you not want to share it and just call the project dead?

Hmmm... I doubt if this approach will lead to realistic ball behavior... at least as long as it's free rolling. Also, I'm a little confused... you talk about three variables, but there's something amiss here... if you express the ball movement as a combination of angle (direction) and speed, this would be two variables (i.e. angle from 0 to 31 and speed from 0 to 7) from which the x and y direction values (two more values) would be derived (via the sin/cos table). Now if you say it's difficult to find out what the ball does when colliding with the table, I thought you had chosen this expression of speed BECAUSE it makes it easier to calculate the ball behavior when bumping into something. At least the new speed would be easier to calculate than with the scheme I gave before... you have the angle normal to the thing the ball is colliding with (if you have it) and the angle the ball is coming in at... and the new angle would be (normal angle) + (normal angle - previous ball angle). Of course, it gets much more complicated if the ball isn't supposed to bounce back with full force, but with a lighter one.

Here are my times for this past week (August 13th through 19th) on modern games... sorry, I didn't play any modern games this week. I still go swimming with my father very often, and we have another heatwave right now which will probably last until Thursday or Friday, so still very little time for gaming here.

Red Sea Crossing??? Is that game widely available now? I thought there were only very few copies of it and no ROM available... Anyway, here are my times for this past week (August 13th through 19th) on classic games... Atari 7800: Serpentine - 63 min. in 2 sessions This week there was only time for two sessions of Serpentine spread over one day where I didn't go swimming because it was a bit cloudy. We have another heatwave right now, and it will probably last until Thursday or Friday, so still very little time for gaming here. In the game itself, I did get past the dreaded Level 11 where I usually fail, I think I made it up to Level 16 or 18, but by then your speed advantage over the enemy snakes gets very thin.

Here are my times for this past week (August 6th through 12th)... sorry, again I didn't play any games this week. Summer's still there, and I've been going swimming with my father nearly every day. The mornings were taken up with organizing the inheritance of my mother's estate, so there was no time left for gaming. In fact I plan to continue this trend over the next weeks. I've been off work for this week and the two before it, but from next week on I've got to work again, and summer's still there, and I still haven't completed the inheritance. Moreover, I actually had other plans for this summer holiday which didn't play out at all due to the extended swimming sessions... I planned to sort my papers and to backup my data, and also to release the next version of my CD+G authoring tool ClearSwipe which is in fact ready for beta testing but still needs an overhaul of the manual before I can send it to beta testers. In fact, these points have already been planned for my Easter holiday, but that has been completely gobbled up by the death of my mother and organizing her funeral and death mass. So I guess I'll have to squeeze these project into normal work weeks now...

Here are my times for this past week (August 6th through 12th)... sorry, again I didn't play any games this week. Summer's still there, and I've been going swimming with my father nearly every day. The mornings were taken up with organizing the inheritance of my mother's estate, so there was no time left for gaming. In fact I plan to continue this trend over the next weeks. I've been off work for this week and the two before it, but from next week on I've got to work again, and summer's still there, and I still haven't completed the inheritance. Moreover, I actually had other plans for this summer holiday which didn't play out at all due to the extended swimming sessions... I planned to sort my papers and to backup my data, and also to release the next version of my CD+G authoring tool ClearSwipe which is in fact ready for beta testing but still needs an overhaul of the manual before I can send it to beta testers. In fact, these points have already been planned for my Easter holiday, but that has been completely gobbled up by the death of my mother and organizing her funeral and death mass. So I guess I'll have to squeeze these project into normal work weeks now...

Here are my times for this past week (July 30th through August 5th)... sorry, I didn't play any games this week. Summer's in full swing, and I'm going swimming with my father nearly every day. Moreover, on Friday I got the note from the court that I'm now eligible to inherit my mother's estate, so there's some more things to do to organize this.

Here are my times for this past week (July 30th through August 5th)... sorry, I didn't play any games this week. Summer's in full swing, and I'm going swimming with my father nearly every day. Moreover, on Friday I got the note from the court that I'm now eligible to inherit my mother's estate, so there's some more things to do to organize this.

Here are my times for this past week (July 23th through 29th) on classic games... sorry, I didn't play any classic games this week. We've got a heatwave here in Vienna, and I'm going swimming with my father every day, which doesn't leave much time for gaming.

Here are my times for this past week (July 23th through 29th) on classic games... Atari 2600: White Water Madness - 5 min. Atari 7800: Serpentine - 97 min. in 5 sessions I didn't get to play too much this week because we've got a heatwave in Vienna, and I'm going swimming every day with my father now. I played a few more rounds of Serpentine on the Atari 7800... nothing new there. Then I tried a new game by Atariland2600, White Water Madness. It's nothing fancy actually, think horizontal Monaco GP with only one enemy at a time. But through graphical trickery, the player figure is 3-colors and consists of one player (man), the ball (boat) and a missile (the row).