Robert M

You really need to post the source code, or it nearly impossible to help.

Nice work! I noticed a couple things. 1. You need to reset the fish to the middle of the game area each time the game restarts. As it is now, if you swim to the edge of the field and day, then restart the game, you can escape the ring and get infinite points. 2. I didn't like that I died if my bubbles hit the walls. Maybe you could use the player's missile to make a bubble animation, and then it won't cause player death if it hits a wall. Cheers!

The aspect ratio on the Atari 2600 pixels is somewhere between 1.5 and 1.75 depending on the TV, so you need 6 or 7 scanlines to make a PF pixel look square. If you use 6 scanlines, you can get 32 such square vertically in 192 scanlines. If you use 7 scanlines, you get 27 squares.

A good place to start is from your compiled bBasic code. The bBasic compiler can output an asm file which lists your bBasic code as comments along with the assembly language equivalent. Now that you understand bBasic, it should give you insight into the assembly code. You can experiment with the asm file and compile it with dasm to see if your experiments are correct. If you mess up the asm file, you can regenerate it from the bBasic code. Cheers!

So is the following tiled game idea a different kind of thing from what I'm talking about: http://www.atariage.com/forums/index.php?showtopic=120849 Your mockup showed PF graphics with the resolution of sprites (160 pixels across the whole screen). The linked demo is making multi color tiles at PF resolution (40 pixels across). There is a lot of flicker and fast swapping of colors to make that demo. If you or someone else package that multi-color tile display kernel into a file so it can be linked into a bBasic program, then yes you could write a bBasic game using that kernel. The default kernels bBasic do not have that ability. Cheers!

That would be awesome, but the 2600 can not do that. You need to step up to the 5200 or 7800 to get graphics abilities like that. Cheers!

Thanks. I'll see what kind of mangled mess I can make with that. Might be useful for some type of game. You have another option if you don't care about the color of the ball as long as it is not the same as the PF. What you do is rotate using the M1, M0, and Ball objects each frame. Then the ball and missles become flashing color like the chalice in Adventure. I use this technique in my hero themed shooter demo posted in this forum somewhere. Each frame you nee to do something like this: rem * rotate objects to get flickery mixed colors. temp = ballx ballx = missile0x missile0x = missile1x missle1x = temp temp = bally bally = missile0y missile0y = missile1y missile1y = temp rem * rotatecount keeps track of which screen object is used to draw each game object. rem * rem * rotatecount = 0 means ball = P0 shot, M0 = P1 shot, M1 = treasure rem * rotatecount = 1 means ball = P1 shot, M0 = treasure, M1 = P0 shot rem * rotatecount = 2 means ball = treasure, M0 = P0 shot, M1 = P1 shot if rotatecount then rotatecount = rotatecount - 1 else rotatecount = 2 drawscreen rem * Jump to routine to map ball, m0 and m1 collisions to the objects they represent this frame. on rotatecount goto collisonmap1 collisionmap2 collisionmap3

There is one way to get a different color ball, but I don't think you will like it. If you set bit 1 in the CTRLPF register you enable score mode. In Score mode the left side PF is the color in COLUP0 and the right side PF in the color in COLUP1. The ball is still the color in COLUPF. Of course, now the PF is the same color(s) as the sprites. Cheers!

double post

You must include the pfcolors kernel option with the background kernel option. Then you must use the pfcolors: construct to make a table of 11 colors (assuming you are using the standard 11 high resolution. Like this: pfcolors: $f5 $f5 $f5 $43 $f5 $f5 $f5 $f5 $f5 $f5 $f5 end Normally with the pfcolors kernel option set, the table of pfcolors would be applied to the COLUPF register on each row change. With the additional background option set, however, the kernel writes to the COLUBK register instead of COLUPF. So with pfcolors you can have a new PF pixel color each row with a solid background. If you throw in the background option, then you get rows of color in the background PF, and the PF pixels are all the same color. Cheers!

BTW, I like the demo.

Ah, thanks. I think I get it. So basically, if my scanlines leap while the display is cleared (sprites and playfield not visible), then the roll will probably not be noticeable? No that is not correct. Each frame of the television image is expected to 262 scanlines tall. Each frame is divided in to 4 sections: vertical sync (3 lines), vertical blank (37 lines), the visible portion (192 lines), and overscan (30 lines). 3 + 37 + 192 + 30 = 262 scanlines per frame. There are 60 TV frames per seconds for NTSC and PAL60 televisions. NOTE: The number of lines per frame, and frames per second is different for PAL televisions. If your code does not produce exactly the same number of scanlines for each of those four sections on every single TV frame, then there is a chance the TV image will jump or lose vertical hold. The more your code deviates the more likely it is a jump will occur. Stability with uneven line counts will depend on the intelligence of the television to clean up the bad frames. As an Atari VCS programmer it is ideal to never vary your scanline counts for any of the 4 TV frame sections. If you are writing pure bBasic code, then your code will run during the overscan section of each TV frame. When you are done with all your code tasks for a single frame, your code must call DrawScreen, and bBasic draws the rest of the TV frame. IF your code takes more time than the 30 scanlines of overscan then the screen will jump or roll. AS a bBasic programmer you must work out the minimal list of tasks to be done each frame to keep under the time limit. Cheers! P.S. There is a way to get some more time to run your bBasic code each frame during the vertical blank period. Check the online docs.

If the number of scanlines is not a constant 262 (or so), then the TV may lose vertical sync for a frame or two and the image on the screen will jump or roll. Its not a great thing to do, but I have seen many commercial releases that jump/roll at the start of each level. Cheers!

I went to the show. It was good. Not as good as a year ago, but it was still good. I found a lot of 5200 carts for reasonable prices, and some other stuff too. The show wasn't as busy this time, and as others said going to 8pm on a Sunday meant I had to leave before the show ended. But, I do plan to go again next year. Cheers!

That's the approach I am using in the Littleman kernel. It cuts the masking table size in half, but it also splits your sprite data into two tables which is painful to generate and maintain without some sort of editor tool. Cheers!

Why not eliminate the side scrolling and use static screens instead?

Hi, The attached file is a base I use when starting a new project. If you look at the code starting at the label Mainloop; you can see code for implementing a timer during overscan. In fact I use a subroutine to set the timer for each section of a TV frame. base.asm.zip

bump... Lowered asking price.

bump... Lowered asking price.

When I look at that demo I think it would be interesting to invert the animation so the checkerboard is in the sky as "clouds", to provide a movement reference for a two player battlezone style game. Putting the cloud animation above would free up all the system objects to draw targets/obstacles on the "ground". Edit: My original post is not really clear. What I mwan is that if the game objects are in the portion of the screen opposite where the PF graphics are used to make the grid/clouds; then there will be more cycles to allow single line res multi-color objects for shots and enemies and such.

Hello, I am offering a lot for sale where the buyer will choose 14 regular cartridges from a pile of 70, and then choose one of 2 Xonox double ender carts. Also included is a holder for the 15 chosen carts. The Xonox cart fits in the slot originally used to hold the manuals. See the pictures for details. Sorry the pictures are kind of dark. It was the only way I could get no glare on the labels with my lousy camera. I will ship the whole lot to the buyer for $37 $32. Cheers! Rob

I am offering a lot with 4 jitter free paddles and 14 paddle games for sale. I am asking $25 $18 for the whole lot. That price includes the shipping to anywhere in the U.S. See the picture for the game titles. First come first served. Cheers! Rob

I have found an example of a real game design document in a link in a another thread in this forum. It was decompiled from a copy of the game M.U.L.E. This document is an excellent example of a clear and precise video game design. Any programmer could take this wonderful design and write the game M.U.L.E. from it. If a would be designer could come up with a detailed description of their game idea using a format and mathematical techniques as they are used in this example, then I believe it would not difficult to find a programmer. (Assuming the game looks fun of course ) Incredible Game Design Document Example! Read and learn! Cheers!

I was not going to vote between 7800 Centipede and Mike Tyson's Punchout because I never played either game. But the system required a vote so I went for the Atari title.

For me it was Entombed. I was really expecting a dungeon crawl/explore the maze kind of game. I was not expecting an obstacle course racing game.