Kurt_Woloch

Oh, sorry then... I misremembered that part. I just thought when I heard about the massacres "hey, those two people must have been playing LIT". But if there's only a slingshot as a weapon, then my last posting is obsolete. Slingshot, ala Dennis the Menace. No guns in LIT. - Adam

Hate to say it, but in view of the recent school shootings in Germany and Alabama I would actually vote for retracting this game from sale... shooting with guns in a school setting just doesn't feel right to me.

I think in the early days, they tried to compete with all those "Pong" clones, which probably were advertised to have this-and-that number of games built-in, even if they were really minor variations of the same game. So more game variations meant more "value" to the gamer who (supposedly) bought games comparing how many variations they had. Later, when the Pong clones had phased out, they more mimicked arcade games which, of course, normally only have one game variation to play (though the operator mostly is able to set the difficulty, number of lives etc. by DIP switches, and later by an on-screen menu)

Actually, the Amiga 1000 was the first model. The Amiga 500 was its successor, so the Amiga 1000 is not "better" in any hardware-wise way other than it's a "desktop" with detached keyboard, instead of the integrated keyboard-disk-drive computer, and some minor differences: The Amiga 1000 (at least the first models) requires the "Kickstart" disk which loads the main OS, which already is in ROM on the Amiga 500 and thus doesn't have to be loaded anymore (this is because Kickstart still received revisions during the A1000's short lifetime). Also, the A500 has 512K standard (1 MB with the standard expansion, and expandable to up to 8,5 MB to my knowledge) while the A1000 only has 256K standard (expandable to 512K with the standard expansion). Now some tricky games (don't know if there are any, though) might take advantage of the A1000's Kickstart memory, which is replaced by ROM on the A500, by loading directly instead of the Kickstart disk. Such games of course will have problems with the A500, but I doubt there are many of them. Also, there are some games which run on a standard A500 with 512K memory, but NOT on an expanded one (not even with the standard 1M one). I think "Garrison" (a Gauntlet clone) was one of them, and some Defender clone (forgot its name right now). On the other hand, some games won't run correctly on an unexpanded A500, for instance "Marble Madness" lacks sound on some levels in that case. And some later games and apps (such as the "Theme Park" demo and "PageStream") even have problems with 1 MB installed and really only run smoothly with more memory. Then there are some apps (Aegis Animator comes to mind here, Amigabasic may be like that too) which refuse to reserve more memory than a standard amount for their data, even if more memory is available.

OK... I've looked at the code, and I'd say the bug lies in the setting of the variable o, which gets set to the current pfpixel column / row of the ball in order to check for a collision with the wall being drawn. The problem is here that you're basically checking the coordinate under the ball. At the moment the ball hits the playfield, it's basically still not on the pfpixel of the wall, but on the adjacent one to it. So the calculations you're doing: if !c{1} then o=(missile0x-17)/4 else o=(missile0y-1)/4 are flawed. To be correct, you should subtract another 8 pixels from missile0x before doing the calculation if the ball is flying left, but add them to missile0x if the ball is flying right. Likewise, 2 pixels should be subtracted / added to/from the missile0y variable depending on if the ball is flying left or right. By the way, I would only calculate this if the collision has occured, not every frame like you are doing it now. So I would replace the line above by roughly the following: if c{1} then goto check_collision_1 if n{0} !! n{1} then o = (missile0x-9)/4 else o = (missile0x-25) / 4 goto check_collision_2 check_collision_1 if n{0} !! n{3} then o = (missile0y+1)/4 else o = (missile0y-3) / 4 check_collision_2 Note: I haven't tested this, but I think it would work this way. Oh, and here's another version of your original source code... I added some comments to it. Actually, I would find it helpful if you would comment your code like that if you want other people to help you so they can see better what different parts of the code are supposed to do. jezzball.bas

Well... I always like to keep things as close to the original as possible, so I'd vote for the original music from the WII, of course adapted to the 2600... I think the baseline with the whistling on top, and then the breathing (which is essentially noise) could convert pretty well. By the way, I made a mistake in my previous post... actually, the WII screenshot does show a grid of 12x12. So the 2600 display could consist of 12 logical lines as well, but they would have to be less high than in the mock-up... let's say 12 scanlines each instead of 16. Actually, since with Jake being upright, a sort of pseudo-3D look would be displayed, it could fit the perspective pretty well if each cell was less high than wide. Oh, and the tables and lamps could actually be more detailed than simple squares if displayed by the other player.

OK, here are my times for the past week (again skewing the charts... probably... but the times are correct) Park Patrol (C-64, emulated in VICE) 389 minutes in 8 sessions 1942 (arcade version, emulated in MAME) 30 minutes (don't know if that one's old enough to count for the charts) Man goes down (2600, emulated in Stella) 12 minutes Robotron demo by Cybergoth (2600, emulated in Stella) 1 minute Another Robotron demo in batari basic by dgob123 (2600, emulated in Stella) 1 minute 3D Vectari (2600, emulated in Stella) 1 minute

OK, since this is a WII only game, there seems to be no way to play the original version on a PC, so I have to judge that by the screenshots shown only. Now... how could that reasonably be done? Basically, the playfield only consists of one high-res figure (the player) and several blocks which more or less are static, i.e. get displayed or not, but never move. I would do this as follows: - Reduce the player to monochrome (red only, no second color), that way only one player gets used for it. The slingshot pellet should be red instead of green, that way the player's missile could be used for it. The entrance and exit could also be displayed by the player's missile, since nothing else exists on those scanlines. - The yellow light stripes and areas are probably the best use for the 2600's playfield graphics. The playfield may be asymmetrical, however, which may pose some problems creating the display, but those are not unsolvable. The worst thing that might be required would be to have some black scanlines between each logical "line" on screen. - This leaves the lamps, the windows and the tables to be displayed. On your mock-up, the lamps and the windows never occur on the same scanline. But they may occur on the same scanline with tables, which are a different color. In this case I'd say that if two of those objects appear on the same scanline, they either may have to flicker, or they would be displayed in a "striped" way, that is, on alternating scanlines. However, some optimizations are thinkable: - On lines where the "main" player isn't visible, both players could be used to display the other objects. - If there is no light on a line, or the line is fully lit because an open window is on it, the background color may be set to either black or yellow, and the playfield / ball graphics are free to be used to display other objects. So, let's give a quick rundown of how the different screens could be displayed: 1 and 2: Jake is player 1, the entrance and the exits are Missile 1. The windows on the dark lines are the ball (should be by default). The yellow square on the bottom is the playfield (it would be too complex to do it otherwise). Changes to the screenshot: Jake should be monochrome. 3 and 4: The table is player 2 (because nothing else occupies player 2). The playfield pellet is Missile 1. 5: The background color of the line where the window is on gets changed to yellow (should extend a bit more to the left, actually). Actually, the window itself could be removed now since it can't be closed anymore, so it's not relevant which side the light comes from. 6: The table is still player 2, the electrical object gets displayed by the ball (since no light is on the same line). 7 through 10: Here it gets complex. The lit lamp and the the table now have to share player 2 and thus flicker. But the lamp could switch to be player 1 from screenshot 8 on where Jake is on another line. 11 through 13: The vertical stripe of light is playfield graphics. The windows on the left and right now switch to be player 2. The table on top is also player 2, with the pellet laying on it as player 1. 14: The background color on the new horizontal stripe of light gets turned to yellow. The table on that line is player 2, and the window again could be removed to leave just a horizontal stripe, Jack (player 1) and the table (player 2) on that line. 15: The lamp, this time would switch to be player 2 since there's light on that line. 16: The turned-on lamp would be player 2 this time (since there's light on that line). On the line below, the table would be player 2, and the pellet on it would be missile 1 since Jake isn't on the same line. The window to the right could switch to be yellow instead of white, thus being displayed by the ball. 17: When both Jake and the pellet are visible on the same line, it's not a problem because both are red. 18: The background color again gets turned to yellow for the new horizontal path. The table blocking the path would be player 2. Oh, and I would make the window disappear again. The newly revealed table, again, is player 2, and the pellet on it is player 1. 20: The new vertical beam gets added to the playfield graphics. 21: The lamp revealed gets displayed by player 2 (or missile 2?) 22: The lit lamp also gets displayed by player 2 since no other object (except for Jake) is on that line. As you can see, most of the time there's no need for flicker to create a reasonable display with just some more restrictions (make the pellet red, Jake monochrome and the windows disappear once shot). Also, the objects all have some default representation (Player 1 for Jake, missile 1 for the pellet and exits, player 2 for tables and lamps, background graphics for light, background color for horizontal light stripes, and the ball for vertical windows), but may switch to another object if their default object isn't free (which, however, requires some complex kernal). I think the following mock-up (modified from screenshot #18) might be closer to what the 2600 actually may be able to display: Oh, and why have you chosen to work with a bigger matrix for the 2600 version? The WII version only works with a 9x12 matrix, as far as I can see. Since the 2600 would have to store some kind of playfield in RAM, and only has got 128 bytes of RAM, it might be good to stick with the smaller matrix instead of blowing it up to 12x20 (presumably), as you have done. At least the 9 horizontal lines should be kept, otherwise you might be doing more scanlines than a normal NTSC TV is able to display. Seems like you're doing 240 scanlines in that mockup. The reduction to 9 lines would reduce that to the standard 192 scanlines.

OK, here's my best so far... 0156. I think this game has gorgeous graphics and music...

I think it's possible to somehow cram all four screens of DK into 16K. Atarisoft did this on their TI-99 version (and other home versions too, but the TI-99 has got the same video and sound chip as the Colecovision), which even looks a bit better too.

Sorry, but that is incorrect. There is enough space in VRAM to store 256 8x8 patterns, which is just enough for 32 16x16 sprite patterns. The smaller sprite attribute table in VRAM is capable of containing 32 sprites (x,y,color and pattern number), so one can therefore display up to 32 16x16 sprites on the screen. Sorry, but that is incorrect too. The VDP allows for 256 different patterns in 8x8 mode, or 64 different patterns in 16x16 mode. Since a 16x16 pattern takes up four times the memory of an 8x8 pattern (32 bytes instead of 8 ), 256 8x8 patterns take up the same memory as 64 16x16 ones do, not 32 16x16 ones. Oh, and I can confirm that the video chip IS able to display 32 sprites on screen. There's only a limit of four sprites per scanline, so if you try to put more than 4 sprites on the same scanline, only four of them will be displayed (I think those which come first in the sprite attribute table). Maybe this is how the 9th sprite of youki disappeared...

I think the first easter egg I discovered was in Coleco's Carnival, when rolling the score (which wasn't too hard since the difficulty topped off at round 4), on the next two score increases the score display said "Program by" and "S. Kitchen". Later I learned that you could also access this display by doing a different trick on power up, but this is how I saw it first.

I don't think the 2600 version of Ms. Pac-Man has the intermissions... it goes from one labyrinth to the next without any special scene (other than the labyrinth flashing).

OK, here are my times for this week... Park Patrol (C-64, emulated in VICE) 318 minutes (in 7 sessions) Park Patrol (ZX-Spectrum, emulated in MESS) 40 minutes Joust (2600) 32 minutes Crazy Climber (Arcade version, emulated in MAME) 20 minutes Alien's Return (2600) 17 minutes Shower Scene (2600) 13 minutes (in 2 sessions) Ballblazer Demo (2600) 3 minutes (in 2 sessions) All 2600 games were emulated in Stella.

Ummm... somehow that acceleration thing doesn't always seem to work properly, especially when the woman is on her knees.

Yes, the rotofoils look good... only their logic is a bit illogical. But I'm confident things are going to improve even further...

Yes, I think the original allows you to make corners faster. If you take a turn, you can take the turn a few pixels (I think 3-4 pixels) before you reach the actual intersection, while the ghosts don't do that.

I'd actually vote for the Commodore 64 as a starting platform. It's very well documented (even the manual that came with it shows some kind of memory map and documents all memory locations of the video and sound chips), and you don't have to do too much to make anything appear on screen, since everything is memory mapped. Also, you can start programming in BASIC and only write short assembler routines which you call from BASIC.

Well, nice game, but there is no sound yet, and also there doesn't seem to be an ending if you've made it to completely clean yourself.

OK,here's my best so far... 25950.

OK... this is the first repetition of a game since I'm on board (we played this last in April 2008). Thus I didn't invest too much time into this one... my highest score this time is 11000 .

Well... I just played that Alien's Return game, and while it's true that there are many similarities to Turtles, there are also differences (to the arcade version of Turtles): - There are no enemies on screen as you start a round. In Turtles, you start out with 3 enemies already on screen (more in later rounds) - There are no question marks displayed, thus you don't see which rooms you've already visited - Not every collected piece gets accepted... it's possible that pieces aren't accepted (if it's the wrong one) and you have to bring them back to where you picked them up - In Turtles, the enemies are just as fast as you - In Turtles, not all the enemies instantly home in at you... they only get smarter after a time, but get dumb again if trapped by a bomb. - In Turtles, the enemies can't overlap... before they bump into each other, they reverse direction And the most important difference is... there's background music in the arcade version of Turtles! And have you seen the horrible flicker on Alien's Return? I suppose it's just as horrible as in Pac-Man (no reposition logic at all).

OK, here are my times for this week: Park Patrol (C-64) 468 minutes (in 6 sessions) Subterranea (2600) 37 minutes Ooze 0.85 (2600) 4 minutes Pig Perambulator (2600) 3 minutes NOBeta1b (MausGames Attempt at Ooze) (2600) 2 minutes Jack and the beanstalk (2600) 1 minute Ballblazer demo (2600) 1 minute Maybe I should explain why I'm still playing Park Patrol that much... I'm desperately trying to roll it, but didn't succeed yet. I got close, though, at a max of 900000 points. Unfortunately, reaching 999990 points takes nearly 2 hours, hence the long playing times. However, the difficulty level tops off at Level 6, it doesn't get any harder after that. But there's still a chance to screw up a game even if you've got plenty of extra lives because you've also got to watch the supply, which from level 3 on gets stolen by the ants. You start off each level with 9000 units of supply, but 1000 of those get stolen about every 20 seconds. The supply also gets decreased by 1000 if you lose a life or go into the house to fill up your own supply. If the supply reaches 0, it will be game over on the next life you lose, even if you've still got spare lives left. This is usually how games end for me... As always, the C-64 was emulated in VICE, and the 2600 was emulated in Stella.

Hmmm... the graphics on this look rather simple. Reminds me a bit of this game... Here's an idea... don't know if it's possible in Batari Basic, though... since the player on bottom and the pig on top never overlap, it should be possible to use both players for each of the characters (thus providing better graphics), and reposition them somewhere in between the top and the bottom.

Ummm... in case you didn't notice, the Atarimania page linked to above contains a ROM download for this... so you can check it out for yourself.