Tile based Scrolling and expanding Engines

[Mr SQL]

Twin Engines for playfield bitstream expansion and scrolling:

 

I've had a number of 2600 games in mind I'd like to build that could use an expanding and scolling tile/virtual pixel engine and seeing the impressive scrolling engine in BoulderDash inspired me to build these; my scrolling and expanding engines are respectively a bit shifter and a bit expander. The 2600's unique architecture threw up a couple of obstacles along the way thus these twin engines complement each others functionality - the bit expander can function stand alone but the bit shifter requires it's assistance to work

 

Functionality:

 

This tile based scolling engine can take a very wide right-ways-up playfield bitmap and pan across the image while silmutaneously expanding the image in a 2:1 ratio so that 20 virtual pixels span the screen, it can scroll up and down too depending upon the height of the bitmap but I'm just side scrolling in the demo.

 

In the pic of the panoramic bitstream below, note the contiguity of the bit pattern with no gaps or flip-flops after the first four spacers left over from the initial expander which can run either as a stand alone engine (the expander can static screens) or as a component of the bit slider:

 

(panoramic WYSIWYG bitstream the bitshifter slides across)

 

World size specs:

 

Because the bitstream is expanded 2:1, a large virtual world up to 10 screens wide (200 pixels) can be easily stored in a single 256 byte table. Combinations are also possible such as a virtual world two screens high and five screens across.

 

Demo: BITShifter.bin

 

The demo pans across a virtual world 5 screens long; the bitmap shown above in a 120 byte table.

 

Here is the bin, it's a bit annoying in Stella because I halved the framerate for cycles but it looks OK on the real hardware (why can't Stella handle skipped frames as good as a Television? I thought it had phospher simulation).

 

Optimisations:

 

I am now optimising these engines to fit within the blanks by taking just a bit of the screen display for more of a DVD style view (still 20x10) with squarer pixels where I won't have to halve the framerate.

[RevEng]

Looks good!

 

To enable phosphor in stella, hit alt-p. That said, phosphor in stella is a lot more forgiving that actual phosphors in a CRT.

[Mr SQL]

Looks good!

 

To enable phosphor in stella, hit alt-p. That said, phosphor in stella is a lot more forgiving that actual phosphors in a CRT.

Thanks RevEng!

 

- wow the difference is night and day in Stella, thanks again! I'm almost tempted not to optimise it.

[Thomas Jentzsch]

Looking forward how far you will get with your approach. I suppose it will become very, very CPU intensive.

 

BTW: There seems to be a bug in the 5th column.

[Mr SQL]

Looking forward how far you will get with your approach. I suppose it will become very, very CPU intensive.

 

BTW: There seems to be a bug in the 5th column.

Thanks Tom, I've updated the bin. It looks much better with that column not breaking! The bug was in the expander

 

BITShifter.bin

 

My algorythms are very efficient but I need to optimse them further to avoid using a whole frame - one thing I can't workaround with the source table in ROM is modifying the scrolling large play area on the fly; a large play area the size of the demo can actually reside entirely in superchip RAM (the 100 pixel wide 10 row table is only 120 bytes) to keep it malleable but larger play areas double that size (the 256 byte tables) are limited to display only - good for mazes and scrolling backgrounds that can't be changed.

 

How do you get around these limitations modifying your large play area in BoulderDash - RAM beyond SARA like the SuperCharger?

Edited August 2, 2012 by Mr SQL

[Thomas Jentzsch]

You could post the source code, maybe others can give some help.

 

BTW: The latest demo has an instable scan line count, which causes major problems on real PAL hardware.

[Mr SQL]

You could post the source code, maybe others can give some help.

 

BTW: The latest demo has an instable scan line count, which causes major problems on real PAL hardware.

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

[Thomas Jentzsch]

Try using Stella's info mode (ALT+L).

[Mr SQL]

Try using Stella's info mode (ALT+L).

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?

[RevEng]

A 262 line display on a PAL TV is called PAL60, which produces a frame with NTSC resolution and pal colors.

An odd number of scanlines on a PAL set will give you a black and white display.

A varying number of scanlines from frame to frame will cause the screen to bounce for every region, depending on the TV and the line-count variance. For PAL, the colors may go in and out as the scanline count semi-randomly becomes even or odd.

[Mr SQL]

A 262 line display on a PAL TV is called PAL60, which produces a frame with NTSC resolution and pal colors.

An odd number of scanlines on a PAL set will give you a black and white display.

A varying number of scanlines from frame to frame will cause the screen to bounce for every region, depending on the TV and the line-count variance. For PAL, the colors may go in and out as the scanline count semi-randomly becomes even or odd.

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

[+SpiceWare]

I would expect the circuitry would have tolerance for a scan line or two off from the count.

 

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.

[Mr SQL]

I would expect the circuitry would have tolerance for a scan line or two off from the count.

 

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

[Thomas Jentzsch]

that's interesting, how far can you push the spec before the screen rolls?

That solely depends on the TV. E.g. most PAL TV can sync to NTSC, but most NTSC TV can not do vice versa.

 

Back in the 80ties, some games produced less than 250 scan lines and rolled on some TVs, but not all. Others produced 280 scan lines with the same results. I found that 10-16 scan lines seem to be pretty safe.

 

What PAL doesn't like at all, are odd scan line counts, since it completely looses colors then. That's because the color is averaged over two scan lines to avoid the inconstant colors of NTSC.

 

Also a lot of TV react pretty sensitive to changing scan line counts. PAL will most likely loose color, often screens will roll (all systems).

Edited August 6, 2012 by Thomas Jentzsch

[Mr SQL]

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?

[Thomas Jentzsch]

I would test on my PAL hardware, but scanlines are still not constant.

[+stephena]

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?

 

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.

[Mr SQL]

I would test on my PAL hardware, but scanlines are still not constant.

Tom,

fixed it! Please try this build

SCROLLOUT.BIN

[Mr SQL]

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?

 

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?

[+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?

 

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.

[Mr SQL]

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?

 

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.

[+stephena]

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.

 

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.

[Mr SQL]

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.

 

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!

[Thomas Jentzsch]

fixed it! Please try this build

SCROLLOUT.BIN

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.

[+Gemintronic]

Flickering is really annoying. I've done my own studies and found I can only tolerate a couple of blocks worth of flicker. The engine itself is awesome though! I keep getting fevered visions of a 4 way scrolling Dark Chambers