Mr SQL

SCROLLOUT.BIN Got caught up making a hotfix build for Breakanoid on less forgiving monitors, but here is the next build of Scrollout: I've added a camera to follow the ball after the initial horizontal and diagonal scrolling. Adding a paddle (on either side) and some randomization is next and the game is ready for play Do not try to watch this one on stella without openGL if you are using windows (hurts a bit).

sprybug, I'm guessing you have the openGL drivers? I only go with the default build because unfortunately that's what most have and alt-p helps a bit but mostly seems to just blur out the pixels as they break rank - can't wait for the next release from stephena with default double buffering (no extra drivers to install). Yes you definitely need a Harmony, highly recommend Excellent Mario demo btw! Tom, how come bd looks so good scrolling horizontally in the default stella build (without OpenGL)? I don't see the pixels break rank at all!

Nice effect and it's fast, interesting approach! Rogue on the Sega Genesis would be fantastic, I enjoyed that game on the CoCo, think it was one of the few OS-9 games I actually liked What do you use for Genesis dev, that Tiny BASIC compiler or C?

Very cool Loon! Is this the bit project you were working on?

Hi stardust4ever, excellent topic! BREAKANOID is stable on most displays but rolls on JVC televisions and on SR3000 composite monitors, you can download the demo here: http://www.atariage....0-order-thread/ I have a hotfix version available but there is a tad less performance without pushing the spec.

Hi Draugr, great post! you really cracked me up - I did a double take when I first read it :) Please pm me with your email address and I will send you an invoice: I am selling Breakanoid for $20 and it comes with four versions of the game each with many levels and a level editor (for windows) that will allow you to edit the colours and level designs to create your own Breakanoid games! I do not sell Breakanoid on cart but you also receive rights to create one stand alone cart through the Atari age store of whichever version you like best (the store charges $25 for this service). The Harmony multi-cart is recommended for maximum Breaknanoid fun as it lets you immediately test the new Breakanoid games you can build with the editor Note: Breakanoid was recently entered in Atari's Developer Pong challenge contest and now includes the official Atari instruction manual and setup guide from the contest as well!

You're welcome, invoice sent!

Hi mhodgeshvs, thank you for your interest in Breakanoid! Please pm me with your email address and I will send you an invoice: I am selling Breakanoid for $20 and it comes with four versions of the game each with many levels and a level editor (for windows) that will allow you to edit the colours and level designs to create your own Breakanoid games! I do not sell Breakanoid on cart but you also receive rights to create one stand alone cart through the Atari age store of whichever version you like best (the store charges $25 for this service). The Harmony multi-cart is recommended for maximum Breaknanoid fun as it lets you immediately test the new Breakanoid games you can build with the editor Note: Breakanoid was recently entered in Atari's Developer Pong challenge contest and now includes the official Atari instruction manual and setup guide from the contest as well!

Yes, quite a lot of RAM. Our approach is much different to yours. The whole "board" is stored and manipulated in RAM. Plus we have a display buffer, which holds a window of the board, with the board characters (tiles) converted into display graphics. From there we feed the kernel. Tom, yes I was thinking you would have to do another pass over your tiles to build the characters; this pass looks like quite a bit of overhead, are you using precalcuations to optimise this too with lookup tables and such? Can you explain in more detail how you perform these passes to manipulate the data in RAM and render the virtual world to the display buffer? Just concept details of how your engines interact

Thanks loon, I've had a lot of fun building these engines! There are similar routines in them to the ones in the project you are working on! Four way scrolling Dark Chambers would be awesome

That one works without flaws. But I am a person which is pretty sensitive to flicker. Therefore I don't think I could play a game based on this technology very long. Tom, I wonder if perhaps the flicker is worse with PAL's 262 scanline mode than on an NTSC television? On my set the shimmer seems to be a pleasing effect, somewhat mesmerising with the large virtual pixels I wouldn't want to play a game with the retro pixels breaking like was happening in the emulator; I wonder if the shimmer effect may be more pronounced when you view it on PAL - does an NTSC signal look different in general on PAL 262 than on an NTSC set?

Stella 4.0 will be using SDL 2.0 (currently, it's using SDL 1.2, as 2.0 is still in beta). When that happens, it will automatically take advantage of the best hardware acceleration available on a platform. That means Direct3D for Windows, straight OpenGL for OSX and Linux, OpenGLES for Android, etc. SDL 2.0 is currently being prepared for release, perhaps by the end of this year. So I will wait for that, since writing DirectX, WIndows-specific code now, only to throw it away again in 6 months is a waste of my (very limited) time. But I agree that OpenGL isn't a first-class citizen on Windows, and Stella is (somewhat) suffering for it. SDL 2.0 will fix that. Excellent!

Installing OpenGL isn't something I want to have to support from the Stella installer itself. In fact that's why I haven't made it the default; Windows insists on making it as difficult as possible to have working OpenGL out of the box. You can go to your video card manufacturer website and download the drivers yourself, but WIndows doesn't do it automatically, strictly because they want people to use DirectX instead. As for the hardware requirements, it won't be extreme. In fact, onboard Intel graphics cards from 5 years ago work perfectly well. Stella really doesn't stress the video card that much. I won't be doing double-buffering in software, since I feel in 2012 it's ridiculous to still be using software rendering mode, when even your lowest/crappiest smartphone has good to excellent 3D acceleration. And besides that, those 'crappy' 3D cards from 5 years ago are still much faster than single-buffered software mode on a 3GHz system. Anyway, I suggest to go to your video card manufacturers website and install the correct drivers. Stella will work much better with them. And if everything works fine, then you know what 4.0 will require, since I won't be adding anything more demanding. To get technical, Stella requires OpenGL 1.5/OpenGLES 1.0, and likely will remain so in the future. stephena, all excellent points but considering that DirectX is pushed pretty hard as the standard on windows I think it is a good idea to add support for it as many users won't add OpenGL on their own and thus lose all the enhancements that don't run out of the box.

Not saying that there isn't a problem in Stella, but you should always use OpenGL rendering (with v'sync) if it's supported on your system. It not only fixes this type of scrolling issue, but also allows you to use TV effects (which aren't available in OpenGL mode). The next major release of Stella (4.0) will require hardware acceleration. Currently this means OpenGL, but I may get it working for Direct3D too. BTW, you're right in that it's a buffering issue. Software rendering is single-buffered, so you see 'tearing'. OpenGL mode is double-buffered, and if you also enable v'sync, the buffering is tear-free. stephena, that's interesting; I've only got the stock directX libraries - why not detect and install OpenGL in the 4.0 release? Double buffering in software is also an option. Curious what kind of system spec 4.0 will require?

Tom, fixed it! Please try this build SCROLLOUT.BIN

SCROLLOUT Demo SCROLLOUT.BIN I've built a new Demo to show some unique features of these engines and will be turning it into a game shortly The demo does a bunch of left right and diagonal panning across a large virtual world two screens tall by 5 screens wide and then starts to breakout but the camera doesn't follow the ball (it will in the game of course). Instead, you can get a glimpse of it when it pans by and otherwise hear it; the events you hear in the virtual world are real and actually taking place in real time which is a somewhat unique feature that I intend to use in some other games I have in mind for these engines - one is Tron light cycles where you can hold the button down and turbo offscreen into uncharted regions of the virtual world. SCROLLOUT design details: Here are some details on my approach to building the demo SCROLLOUT, and my plans for implementing the game functionality with these engines. In the demo, all these calculations take place in an alternate frame where the engines reside; obviously there are plenty of cycles, but this also means that the display frame is completely free for additional game logic and sprite positioning since it has no load beyond building a preassembled asymetric playfield: 1. The bit slider engine slides around to grab a 20x10 pixel block from anywhere within a panoramic 96x20 pixel bitmap (a 240 byte WYSIWYG bitmap table), taking simple x and y coordinates as inputs. I store the bitmap panorama in CBS RAM to render the virtual world malleable in SCROLLOUT The 20x10 pixel block is stored in 30 bytes of the 2600's internal RAM, or 1/2 of the screen buffer I've allocated (60 bytes). 2. The bit expander engine takes no arguments and just upsizes the 30 bytes to 60 bytes to build the large virtual pixels, flipping them to and fro along the way so they are rightways up Either before or after calling these engines, game or demo logic ensues and can leverage a 3rd bit engine to get and set bits or find their status anywhere on the large virtual world, also taking simple x and y coordinates as inputs and an argument to determine wheather to get, set and/or check the bit specified with x,y. The Scrollout game will use a paddle also made of bits and the camera will follow the ball (although another may bounce around in and out of view); like the demo this game will use the playfield elements only but in SCROLLANOID I'll add sprites and missles The scrolling doesn't seem to work properly in Stella: SCROLLOUT looks a lot better on the real hardware - I think there is a latency issue with Stella emulation and side scrolling and diagonal scrolling; when the large text in the demo scrolls back to the left it is most apparent and you can see the many tiny bits that are marshalled to comprise the large retro pixels breaking rank. Perhaps there is some rendering in Stella that needs to be buffered?

I don't understand what you mean. The Apple II was the development machine for the SC's commercial games (Phaser Patrol, Frogger, etc). They used that to assemble code (i.e. cross-platform), and then stored the binary to cassette using the Apple's cassette jack. The SC was then used to load the binary to the Atari 2600. Pretty slick operation for a 3rd-party dev (and they didn't need a powerful mainframe system). Nukey, very cool! I thought the company that created some of the supercharger games was a 3rd party dev different from the supercharger company. Did any other 3rd party dev's utilize the supercharger device and a 6502 based home computer as a development medium for the 2600? Because it seems like it was a tremendous opportunity for many small software houses to tool up shop for both 2600 development and production without an investment in expensive hardware; tapes were the balm for small sofware houses. Great work making so many of the original release titles work in the SC btw!

I don't know if you are able to write a game, but the necessary C64 to SC audio player can be found here. Hey that's cool! Great link, it's just like theloon was saying Makes sense you could use a 6502 Assembler and save a 2600 .bin to tape for play in the supercharger. Nukey, it looks like the c64 package didn't emerge until '97; how long was the supercharger on the market before they started developing for it on the Apple?

It does have tolerance, in Stella's Stocking we used 264 scan lines because the music driver needed the scan line count to be divisible by 4. The jitter problem occurs when the scan line count is not consistent. Spice, that's interesting, how far can you push the spec before the screen rolls? I found out inadvertantly that the jitter problem from an inconsistant scan line count is also inconsistant with tolerance - I tuned a game that was spiking a frame and jittering so that it was solid on my SONY tube TV and my Plasma flatscreen; turns out JVC tube TV's (tested two different size models) have less tolerance and still Jitter when spiking a single frame up 5 scanlines to 267. I now use a JVC Television to test my Atari builds, picked up a 13" that doubles as a great composite monitor for my c64 and reminds me of the 1701

RevEng, that's interesting; I would expect the circuitry would have tolerance for a scan line or two off from the count. I've tuned it to exactly 262 scanlines here in this build, does it display on PAL correctly now? I think the NTSC Television output seems more stable than it was. BITShifter.bin

Thanks Tom, I see it's alternating between 259 and 261 scanlines - odd perhaps I have an extra or missing WSYNC call before or after an INTIM poll but isn't that still within spec or do I have to go hunting for it? Would the difference be that if I get it spot on for NTSC it will still display (in BW) on PAL but right now it's not possible to view it on a PAL Television at all?

Excellent progress Loon! I see you've calculated the row offset to get your Y value and then add in your x byte off set: cellx = (mapx/8) But you need the remainder to check the bit; in this case 5/8 is zero remainder 5, or the 5th bit (reading left to right, 4th bit really) of the 1st byte in the row. One way to get the byte offset and the bit offset is with a subtract loop: xbyteoffset=0 subloop if mapx<= 8 then jumparound mapx = mapx-8 xbyteoffset=xbyteoffset+1 goto subloop jumparound cell = (xbyteoffset + celly) rem mapx now holds the remainder or target bit in the cell (0-7) rem you could use 8 handlers like these to check the status of the target bit: rem if mapx = 0 then result = cell and %1000000 rem this will check the 1st bit reading left to right if mapx = 1 then result = cell and %01000000 ... I'm not sure if that's the correct syntax for using AND but I know it's supported, check RT's command reference on AND'ing if it throws an error

Tom, I used the scanline count for NTSC - 192 visible scanlines; perhaps I have another bug, I am polling INTIM so I think it should be stable otherwise. I am planning to share the source but want to clean it up a bit and add some comments

LOL! I like your SQL humour Loon! Aha you want x and y, not just the nth element of the binary array. You're right about the data being a 1D array but we can change that conceptually by picking a row length. Say we want to turn this 1D array into a table (2D array) of 16x3 (X and Y) elements: .byte 01010101, 01010101, 0001111, 1110111, 0000011,1111101 becomes: byte. 10101010, 01010101 byte. 01101010, 01010101 byte. 00000011, 11111110 Now we can calculate X and Y coordinates with ease from our table construct. Say you want to find the bit at the X and Y coordinates 12,2 (where 0,0 is in the upper left): Multiply your row size (in bytes, not bits) by your Y value: 2x2 bytes=4 This is your offset that turns that 1D array into a 2D table You can see that it brings us down to the start of the 3rd line; now just add the math we talked about previously to walk to the target bit - 8 goes into 12 once with 4 left over so the target bit is the 4th bit of the next byte (2nd byte in the row). Technically it is the 5th bit of that byte but we are using 0,0 offset coordinates and reading all the bits in the row from left to right Now do an AND against that byte with a bit mask like we talked about above, masking all of the bits in the comparison except the target bit you want to check is on or off.

Loon, yes you could turn your 107th bit offset into a byte offset plus a bit offset: Divide by 8 and grab the remainder - the 107th binary element is the 3rd bit in the 14th byte; you can check to see if the 3rd bit is on by ANDing just the third bit (%00000100). If the result is >0 the bit is set And only keeps the bits turned on that are both turned on; since you're masking every other bit as off you will only get a zero result if the target bit you are checking for is off - if your byte was %10101010 and you AND %000000100 the results would be zero, showing the third bit was off.