Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Kurt_Woloch

Members
 View Profile  See their activity

  • Content Count

    1,781

  • Joined

  • Last visited

Posts posted by Kurt_Woloch

  1. Posted

    I think you're wrong here. If you go back to page 14, post #339, there are all mazes as they appear in the arcade version. What you say is true for Ms. Pac-Man or Jr. Pac-Man, but not for Baby Pac-Man in which each wall has got only one color.

     

    @Pacman Plus: I do not know how many colors you have left to work with in the palette, however maze walls are typically one color for the border and another color for the filled in parts. The mazes that render portions of the walls invisible or alternate colors would assign the third unused color to this effect (assuming the available sprite colors are transparent plus three additional colors like NES). The alternate colored maze parts would need a unique tile set but they could share the color palette of the standard tiles. Either the borders would remain the same and the interiors change color, or the interiors remain the same and the borders change color.

    • Like 1

  3. Posted · Edited by Kurt_Woloch

    Well, it doesn't seem to be quite as simple as I wrote above. I just tried to implement it like this in my version of the code, and some characters don't properly change color...

     

    here's what the first maze looks like if I let my routine transform Maze 03 into Maze 00:

     

    post-8393-0-51272000-1546011592.png

     

    And here's what it should look like:

     

    post-8393-0-76665700-1546011607.png

    So it seems like in this case, in addition to what I'm doing now, character $BE should be transformed to $AE if in the inner maze, but should not be transformed if part of the maze border. Also, characters $E0 to $FE should NOT be transformed if part of the outer border.

     

    But I have an idea how to get around this...

     

    Since apparently all maze characters have their lowest bit set, this could be used as a flag if this character is part of the outer border or monster pen. If that bit is set a different transformation takes place than for characters where it is cleared.

     

    This, however, makes the transfomation more complicated than I thought it would be. For what I wrote above, I was only looking at the characters used for the upper border and the uppermost maze parts, for which my transformation is correct.

     

    However, it seems like the other transformation not implemented yet (for the outer border) is even simpler because the outer border and monster pen ALWAYS uses the same characters, so those don't need to be transformed... not even for the monster pen because it also always uses the same characters.

     

    So I think it would be best to increase the values of the characters that may be transformed by 1 in the standard map while leaving them the way they are for the outer border and the monster pen, and then subtracting 1 if they don't need to be transformed, or $21 in places where I wrote $20 should be subtracted.

    For example, the 3rd line of MAP05 would now look like this:

    .BYTE $BA,$00,$E5,$ED,$ED,$E1,$00,$C5,$CD,$CD,$CD,$C1,$00,$EB

    The characters BE and AE (or BF and AF if transformable) is a special case apparently because it slightly breaks the rules for the other characters. BE seems to be part of the Ex set and AE is part of the Cx set, so the following rules would apply here:

    - Character BE always stays BE (as part of the outer border).

    - Character BF gets transformed into BE if E0-FE should not be transformed, into A8 if they should be turned invisible, and into AE if $20 would be subtracted from the E0-FE set.

    - Character AF gets transformed into AE if C0-DE should not be transformed and into A8 if they should be turned invisible.

     

    And yes, I meant MAP03 through MAP05, not MAP03 through MAP04. And no, you're still not an idiot.

    • Like 3

  4. Posted · Edited by Kurt_Woloch

    I wondered if there would be a way to somehow compress the maps. Right now each map seems to take up 448 bytes. However, the first and last line of code seems to be the same for most of the mazes, so maybe it would save some space to put up a table of different lines, and then the actual maze definitions would be just a sequence of those lines.

     

    Then there's many places in the mazes where the same character is put up several successive times. This could be solved by run-length compression if codes that are now unused get used to signify a number of repetitions for the next character that follows.

     

    And then there are actually only 3 different mazes, the remaining mazes only differ in color to them. So I don't think each of those variations has to be stored independently.

    I would define each maze only once in the code, and then put the characters through different transformation tables depending on the maze number which is on.

     

    You already have such a transformation table at the label MAPFLIPD which currently turns the possible maze characters into their mirrored equivalents. What if there was also such a table for the left side, and more tables for the different maze variations? Actually those tables only would need to be there for one side per maze, they just would work roughly the same way.

     

    Actually, if the character table is still laid out the way it was in the code you posted back in September, it's even simpler than that because it's not even a transformation table but only some kind of algorithm...

     

    Let's assume you have the maps MAP03 through MAP04 as a base for displaying all copies of the first maze with the transformation algorithm running roughly as follows:

     

    Transformation from Maze 03 through 05 to Maze 00 through 02:

    - If the character is between $E0 and $FF, subtract $20 so that it becomes $C0 to $DF.

    Transformation for mazes 03 through 05: none.

    Transformation from Maze 03 to Maze 06 and Maze 04 to Maze 07:

    - If the character is between $C0 and $DF, turn it into $A8.

    - If the character is between $E0 and $FF, subtract $20 so that it becomes $C0 to $DF.

    Transformation from Maze 05 to Maze 08:

    - If the character is between $E0 and $FF, turn it into $A8.

    Transformation from Maze 03-05 to Maze 09-11:

    - If the character is between $C0 and $FF, turn it into $A8.

     

    See the principle? Seems pretty simple to code, and then you only need three actual maze maps. Actually, there are only two possible transformations - subtract $20 or turn into $A8. So for each maze you just have to define which of the two (if any) gets done for codes $C0 to $DF and for codes $E0 to $FF. Or something similar to that...

     

    On, and for the phrase "You earned an extra baby"... would it be possible to write this in the other text color which has the complete alphabet (if the character table still is like that)?

    • Like 1

  5. Posted

    Some comments of mine:

    - Extra Ball or Extra Baby? I think it's an extra baby which means that the usual cycle takes place once more... starting in the maze, then (if you don't lose your baby before that) going down to the pinball maze and on losing the ball there another trip to the maze, supplemented by additional trips back and forth if you earn power pellets and hit the hole or complete mazes. How would an extra "ball" only work in this game anyway?

    What I'm questioning myself is what happens if you earned an extra baby and then manage to earn another before you lose the current baby. In this case the "extra baby" light in the pinball mode would still be lit so I suppose you don't earn another extra, or do you? However, in the maze part the extra baby is visible on the bottom as part of the extra babies as if it would have always been there. But you can't earn an extra baby in the maze part, except by clearing the 3rd maze, and in that case I suppose it doesn't depend if you're currently having an "extra" in storage on the pinball part or not... or does it?

     

    When testing the last binary, I also ran through a non-blue ghost once or twice. But I think this is also able to happen on the original Pac-Man machines... don't know if it's possible on Baby Pac-Man though.

  6. Posted

    OK, I tried this one at well, and here's some things I noticed...

    - The red monster now seems to have become faster, it catches up on you much sooner, at least with the "Classic" AI which I tried.

    - At one point in the game, I earned power pellet #3 by spelling "Pac-Man", but the arrow of the right hole didn't start flashing so I couldn't enter the maze part to use the pellet. I was under the impression that the arrow should start flashing in this case, but maybe I'm wrong.

    - Where are the "random colors" of the Pacscalator? As far as I can see, it still has got only one color... or did you mean it's always got only one color (or two) and not sort-of "rainbow colors" like the one in the arcade has?

  8. Posted

    Here are my times for this past week (December 16th through 23rd)...

     

    Atari 7800:

    Baby Pac-Man - 54 min. in 2 sessions

     

    The only game I played this week was Baby Pac-Man on the Atari 7800. Bob posted another update where the drop targets work properly, which prompted me to send him an update to my code which should prevent the ball from "hanging" in the target area taking out multiple targets at once. Other than that, I concentrated on getting on with my goals and chores, so no further gaming than that.

    • Like 5

  9. Posted

    Well... I do see a difference between the ghosts behavior between arcade and classic, the main difference being that in the arcade setting, the ghosts often turn around and go back and forth while on the classic setting they usually don't turn around and move somewhat more goal oriented.

     

    As for the hole trick, in principle this is an intended behavior... sort of. At first I had it so that the ball just hits the hole, but people complained that it was too easy to hit the hole, so I amended the hole handler a bit. As of now, the ball only really is captured by the hole if it hits it pretty much spot on, but as soon as it's over the edge of the hole, it gets drawn into the hole. However, if it's on the edge of the hole, that draw is not enough to really capture it, so its trajectory is only a bit amended. But that "amendment" turned out as the very fast circling of the hole you observed, still I left it in because it definitely does make it harder to hit the hole, and I think it's kinda cool too.

     

    As for the speed and slowdown issues... would it be possible for you to shoot a video that compares the behavior on the old and new 7800 so we can see how exactly this looks like?

     

    I can't really tell a difference in the Ghosts behavior between arcade and classic? Has that been fully implemented yet?

     

    Pinball section -

     

    So I might just suck at this part but I'm usually pretty decent with pinball games in general. But I seem to lose the ball almost immediately upon launch about 1 in 3 times. Basically it will launch and hit that left bumper as just the right angle to immediately drain straight down the center. I also had the ball do something really strange once when it hit the upper left pit target. Normally when the ball get anywhere near those, it will just drop in, rack up some points and pop right out. But once last night the ball literally rounded the pit crazy fast and sling shot off to the right straight across the screen! It was actually really cool to see because I suppose that could happen in actual physics on a real table, but I've never seen that replicated on a simulated pinball game. I'm not sure it was supposed to do that anyway but thought I would mention it.

     

    Now...here is something VERY odd I discovered while using two different 7800s with this last night. I have an original '84 made unit, an '86 made unit and I have a later '87 made unit currently being modded on the bench. Well the original '84 and '86 versions both play the game very smoothly. But the later made '87 model would exhibit slight but noticeable slow down in the maze at various times? Also seems like the pinball portion didn't play as smooth on this later made '87 unit. The '87 made unit does have the extra components in place for the timing circuit fix. So I'm not sure if that has something to do with it? I did try it both with C64 removed from circuit and in circuit and didn't see much difference. But there was a difference between those revisions in how the game played.

  10. Posted · Edited by Kurt_Woloch

    OK, I'll think about how I could improve the target handler then... however, for this it would actually be useful to be able to work on the current version of Bob's code instead of the outdated one I still have.

     

    About the ball serve, actually it's always a bit surprising to me if the ball gets launched from a hole instead of the bottom since it launches pretty quickly and, the pinball section being invisible until you re-enter it, you sometimes don't realize where the ball will come from until it starts moving. I think it would be better to lengthen the delay a bit here and maybe let the arrow below the respective hole flash in a different color if possible to draw the attention of the player to the location on the board where the ball will come out. This is especially true if the Pacscalator doesn't appear before that, which may happen if you've lost your Baby Pac-Man in the maze which actually would have had a chance to return to the pinball table, and then on escaping with your next baby, the ball is still there in the hole.

     

    Update: I've done a little correction to the source code which I've just sent to Bob to include. This should make it harder to take out a sweep of multiple targets, but doesn't change the trajectory of the ball by much, as Imstarryeyed described. This fix should prevent the ball from "hanging" in the target area taking out multiple targets at once as it often happens in Bob's last update.

    • Like 2

  11. Posted

    Sadly, I've noticed a flaw in my target logic... the collision detection and deflection actually only works correctly if the ball hits a target from below, but it works incorrectly if one target's already down and the ball hits another from the side coming from the space where the target's down. This happens much more often than I thought it would now that the target logic is correctly implemented, partly due to the fact that the target below the upper ball is always down. Thus if you have a ball deflected from the right and it sweeps across the target area from there, it's very well possible to take out multiple targets at once. I don't think this is very realistic, but I know that David's Midnight Magic has the same kind of simplified target logic where you can also take out the whole row of targets at once if hitting them the right way.

     

    There would be multiple ways to remedy this, from the simplest to the most complex one this would be:

    - Only turning the ball speed positive on hitting a target if it's going up, but not down... this would reduce the probability of taking out another target, but not rule it out.

    - In addition to that, setting the ball below the target area on the first hit of a target... this would eliminate the possibility of taking out multiple targets at once, but the collision detection and deflection would still be incorrect.

    - On hitting one target, if the ball is not in the bottom row of the targets, the horizontal speed could be set to 0. This would also eliminate the possibility of hitting two targets at once and the deflection would be somewhat more accurate, but the collision detection would still be incorrect

    - Rewriting the handler so that if the ball goes farther than the bottom line of the targets, sometimes two targets get checked if up or down (because in this case the ball actually occupies an area where two targets could be). If both are down, the ball continues rolling, but if one is up, it should be taken down and deflect the ball accordingly. This would be the physically correct thing to do, with roughly correct collision detection and deflection. In this case there would be another deflection table similar to the one for the lower end of the divider.

     

    The thing is, I don't actually know what happens if the ball hits a target from the side. Does the target still get taken down? And in this case, how sharply does the ball come down?

  12. Posted

    Thank you for the update! I tried it for a bit, and it's definitely easier to rack up the points and extra babies now! The behavior of the drop targets takes a bit to get used to though... is the middle blue target really supposed to retract by itself (without you hitting it) from time to time? Other than that, it must be the rules... I first thought there were some errors in the drop targets, but it all seems logical after a while, even though I have the feeling that the blue target doesn't always advance the arrows, but I may be wrong here.

     

    One thing I noticed about the overlays with the monster scores is that sometimes it seems that they are non-transparent, that is, they cover everything while sometimes they're transparent. I think I've seen the 1,6K one lets the dot shine through while the 200, 400 or 800 one does not.

     

    Also concerning extra babies, I think I've seen the original arcade machine award another extra baby at 100,000 points, or even every 100,000 points (at least until you've completed the third maze). But that may be a DIP switch setting as well...

    • Like 1

  14. Posted

    Here are my times for this past week (December 10th through 16th)...

     

    Atari 7800:

    Baby Pac-Man (WIP) - 216 min. in 4 sessions

    Clobberman - 21 min.

    Karateka - 3 min.

     

    MS-DOS:

    Karateka - 2 min.

     

    Most of this week's time was played on the Atari 7800, and most of that on the WIP of Baby Pac-Man of which there was another update this week. I found some issues there as well such as your baby dying going through the tunnels eating blue ghosts with tunnel speed 4.

    Other than that, I played another Pac-Man variant called Clobberman and two versions of Karateka, in both of which I didn't manage to score a single hit before being killed by the first enemy. I can remember that I made it much farther back in the day on the C-64 though...

    • Like 7

  15. Posted

    Now I noticed something else... something strange is going on in the tunnel. I reached a tunnel speed of 4 and was chasing two blue monsters that went through the tunnel. However, one of the monsters suddenly was lethal... I lost my Baby Pac-Man on eating it. At the same time, I could see its eyes going towards the pen, but much slower than usual, while the dying animation took place. Or was it actually the collision with the eyes of the other ghost I'd already eaten that was lethal? I don't know exactly...

     

    On another occasion, also at this high tunnel speed I passed a non-blue ghost that was going through the tunnel in the opposite direction. I don't know if that's supposed to happen either...

    • Like 1

  16. Posted

    I've tried your newest version as well. I think I've spotted one error in your pinball logic which hasn't been adressed yet...

    As far as I know, the arrows of the holes should only light up if there's at least one power pellet on that side of the maze. If you use up all the power pellets on that side and go back to the maze, the arrow below the respective hole should cease to flash.

     

    In your version, however, once a power pellet has been earned on one side, the respective arrow continues to light even if all the power pellets on that side have been used up. Thus a hole can return you to a maze which has no power pellets in it. I never had that happen in the arcade version... the holes only sent me to the maze if there was a power pellet on that side.

     

    Also, I actually question why the ball is being launched by pushing up in your version when it's the right flipper button which launches the ball in the arcade version.

    • Like 1

  17. Posted

    I even made some mockup screen shots on the 7800 look

    That's a great mock-up, but the score on the right doesn't quite work out on the Atari 7800 because you've got multicolor (160 pixel per line) graphics on the left, and you can only have either 160 or 320 pixels per line for each scanline, but not both. Right now you're showing the score in hi-res and the enemy fleet in multicolor.

     

    In contrast to that, on the title screen you're showing, the Galaxian logo could be in hi-res instead of low-res because it doesn't really contain multicolor, it's just made up of two monochrome stripes, and the Atari 7800 can do this nicely in hi-res mode. I thnk in this mode you could actually have up to 8 different foreground colors over one background color, but you can't mix them up too heavily because each object drawn, in this case, is only allowed to have one foreground color (and maybe one background color as well, but I'm not sure if they can be different or not).

     

    How, then, are the games made who utilize hi-res with multicolor? Well, that's a different mode, but it's limited to 2 pallettes of 3 colors each in addition to the background color (as far as I know).

  18. Posted

    Maybe it has to do with my pinball code... I reused some variables of the maze portion for the pinball portion which I supposed would be overwritten on re-entering the maze anyway... but I don't think any of those have got to do with the monsters. I've re-used PSLOW (which is the flag if the player is in the tunnel) for the number of remaining physics iterations and POINTPAUSE (which is the delay counter counting the frames while displaying the score for an eaten monster) as the delay variable for the holes. But I'm pretty sure those variables don't have to do anything with the monsters and get rewritten before their use in the maze part anyway. They also don't need to be retained after leaving the pinball part since POINTPAUSE gets re-initialized on serving the ball and PSLOW is only used throughout one frame to count the physics iterations left.

     

    But actually the issue I had (which you solved by amending the table) also only crept up recently... I don't think it's in the code you publicly posted which I based my version on. And I think I only got it after scoring a higher tunnel speed and tunneling with that at least once (whatever that may mean).

    • Like 3

  20. Posted

    Here are my times for the past week (December 3rd through 9th)...

     

    Atari 7800:

    Baby Pac-Man (WIP) - 212 min. in 7 sessions

    Galaxians (WIP) - 3 min.

     

    Commodore 64:

    Dino Eggs - 32 min.

     

    This week, thanks to the extended Internet outage at home, I managed to complete my part of the work on Baby Pac-Man. Since Bob has already posted a binary where there's a way to go back from the pinball part to the maze (after you've lost the ball), I now consider the "full" play mode playable, so I did quite a bit of playing there.

     

    I also tried Baby Blue Azure's Galaxians, which actually is one subgame out of Gorf, but something got mixed up there... the enemies look like those in Galaxian, but behave like those in Space Invaders. Also enemy fire won't kill you, so I consider this game incomplete and didn't spend much time on it.

     

    Finally, I played a bit of Dino Eggs on the C-64 because your task of collecting the eggs and bringing them to a portal there is similar to the task which scooter chargers have... collecting scooters, charging them and putting them back to some specified location. Those 32 minutes were one game in which I made it to the last level, but couldn't complete it.

    • Like 6

  21. Posted

    OK... in the last version you posted, it's not yet possible to light the right blue arrow and leave the pinball part by placing the ball in the saucer, it's only possible to leave it by draining the ball, so I wasn't assuming there could be an error while doing that. But I still think it might be the additional routines that get executed after the transition takes place (if you put that transition into the handler I wrote, which gets called pretty much at the start of the pinball routines).

     

    I see three possibilities to avoid this:

    1. In the pinball part, only set a marker in the handler and then do the transition after everything else has been done. For instance, you could check if the ball is captured in a hole and the respective arrow is flashing or if it has drained in an extra routine which runs last.

    2. Leave the transition in the handler, but upon returning from the handler, skip all remaining routines if the game state is not Pinball anymore.

    3. Run the pinball collision and handler last (but this could break other things)

     

    No, I didn't mean the dot eating by unsteadiness, you sometimes see it if a ghost is following you... it falls back by a pixel and then catches up again. I think what actually happens is this:

    I built some test code in my version to check how long the routines are really running. The pinball part is normally finished before the visible part of the screen begins, only if the ball touches something and gets deflected, the routines take until the beam reaches about the upper third of the screen. In the maze part, the routines sometimes run up to a bit below the middle of the screen. And they never start before the visible part ends (including the border). I guess what really happens is this:

     

    I guess you rewrite the monster parts of the display list after all processing has been finished, which may be before or after the monsters get displayed, or even in the middle of a monster being displayed. If there's one frame where the routines take long, the display part may get executedl after the displaying of a monster which in most cases gets displayed after the routines finish. This causes the monster to lag for a frame on such long frames and then catch up on short frames, which looks as if the monster is a bit unsteady. And it may lead to sprite corruption if the monster is being drawn while the display list gets changed, so there's some inconsistency in what's being displayed. I think I was such a corruption once as well for a frame, but only on one of the monsters, not at all of them at once. I think it was the blue monster, and it was at a line which roughly corresponds to the end of processing on those long frames.

  22. Posted

    Thank you for the fix! You're right, it plays more like Space Invaders. The one on the original Gorf arcade game, as much as I can remember, did play more like Galaxian (Space Invaders having its own stage in Gorf). Actually, this version even manages to copy the inconsistent speed the arcade game runs at. ;-) And you can't die, which would make the game a bit more challenging.

     

    Maybe it would have been better to hack Galaga into this game, which we already have since it was one of the 7800's launch titles. The next step up would probably be Gyruss which I actually think the 7800 would be good at doing with its capability to draw many sprites, especially in lines where there aren't any character graphics called for.

  24. Posted

    About the sprite corruption issue: I did a bit of playtesting of your version over the last days, and I noticed a bit of unsteadiness in the movement of both player and enemies in the maze part. Therefore I suppose that there are times where not all that has to be done fits in a frame, and then the sprite info or display list get written just at the time they are supposed to be displayed, hence the corruption. I especially noticed this unsteadiness if Baby and the monsters are all in the lower half of the screen, and I was playing with the monster AI switched to Classic. Don't know if I'm on the right track here...

    • Like 1

  25. Posted

    Hmm... this error sounds similar to what we had the other way round, when changing from maze to pinball. Could it be that after changing to the maze, there are still some pinball routines being called which change some bytes (for instance, spin the spinners, which by that time have become maze dots)?

     

    To make sure that at least no further physics iterations get called after the ball drains, you could add the following to the transition code:

     

    LDA #$01
    STA PB_NUMBERITERATIONS ;skip the remaining physics iterations

    as it's done when the ball enters a hole. That way the loop that does the physics iterations (part of which probably is the "exit to maze" code) terminates after this run.

     

    However, after doing the physics iterations quite a few more things are done... gravity is applied, the ball is being displayed on screen, the upper ball is moved, then after the return from "Handlepinball", the arrows are flashed (don't know why this actually is outside of the Handlepinball routine while the other flashes are inside of it...). At least that's how it is in the code version I have...

     

    - Similarly, while I was playtesting, ONE time while moving from pinball mode to maze mode after losing the ball, five or six maze/dot tiles on the top left side of the screen got corrupt. The maze could not be finished after that. That's going to be a bear to find.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...