Could bit-mapped bullet-hell maniac shmup be done on 2600?

[PC Engine Fan X!]

My question is this: Could a bit-mapped bullet-hell maniac shmup game be created for the Atari 2600 VCS console?

It might be wishful thinking but it would be interesting to see if anyone could pull this bullet-hell maniac shmup title off on the 2600 platform... ^_~

The homebrew 2600 game of Oystron looks quite dazzling with it's classic Sinistar/Defender/Rip-Off-inspired gameplay...

PC Engine Fan X! ^_~

[ptoing]

what do you mean with bit-mapped? I would guess that the gfx on the atari are bitmaps, tho that does not make much difference.

It's not a very fast machine (bit more than 1mhz), and is graphically impaired a lot, also no hardware sprites I think, which does not help at all.

Best shot would prolly be to go with something with as little colours as possible and really simple sprites, and i mean really simple, like blocks.

But in any case, I doubt that it would be possible to get a decent amount of bullets/nice bulletspreads on screen without it being really slow.

[FIL]

Sprite limit would be a problem wouldn't it?

[PC Engine Fan X!]

Yeah, I see now...

Sprite limitations + the factor of framerate issue = things could slow down to a crawl.....

The CPU that runs the 1983 Williams Blaster arcade game PCB runs at a whopping 1 mhz! (Of course, that's specialized & dedicated arcade hardware to begin with...)

PC Engine Fan X! ^_~

[ptoing]

the processor in the 2600 is the same as in the NES. On the NES we have Recca, but the NES has hardware sprites and is about 3 times faster.

I think if the 2600 would have hardware sprites, which I doubt, then perhaps something could be done, but afaik you have to do everything yourself on this thing.

[JoshF]

Now I see why you're Rob's favorite poster.

[320x240]

Hardware sprites is cheating. And whats with that "assembler" stuff? Pen and paper not good enough?

[BrianC]

Sprite limitations + the factor of framerate issue = things could slow down to a crawl.....

Not really. More like things could be a mess of disappearing sprites and flicker or not even work at all. Sprite limitations are the main issue, but framerate isn't much of a problem. Flicker is more of a problem for the system than slowdown. The problem is that games have to be programmed a certain way. If they aren't, graphic elements may disappear or the games won't even work.

Developers pulled off some amazing things with the system. Stargate/Defender II, Millipede, Activision games, and Solaris are good examples of this. Defender II, Millipede, and some Activision games showed that developers could pull off speedy, fast paced games despite the hardware issues. Solaris is a fairly complex game for the system that also does pseudo 3D very well.

[Ceph]

the processor in the 2600 is the same as in the NES. On the NES we have Recca, but the NES has hardware sprites and is about 3 times faster.

I think if the 2600 would have hardware sprites, which I doubt, then perhaps something could be done, but afaik you have to do everything yourself on this thing.

Hahahahahaha!

This is the most uniformed nonsense that I have read here in a long time.

[Ex-Cyber]

RAM would be tight at best (128 bytes). It might be possible to code geometric bullet spreads purely as a function of time, but that would also burn CPU cycles, which aren't exactly abundant either..

[ptoing]

the processor in the 2600 is the same as in the NES. On the NES we have Recca, but the NES has hardware sprites and is about 3 times faster.

I think if the 2600 would have hardware sprites, which I doubt, then perhaps something could be done, but afaik you have to do everything yourself on this thing.

Hahahahahaha!

This is the most uniformed nonsense that I have read here in a long time.

Gah, you got me, I did not doublecheck :/ they both have a MOS 65XX series chip, with the 2600 having a crapper version, and for some reasons I thought the NES had 3.something Mhz instead of 1.7ish.

Tho I am still pretty sure the 2600 has no hardware sprites, which the NES has. And hardware sprites are a big anvantage in any case. You can have 64 native at one time on the nes, 8 per scanline, but you can have WAY more if you multiplex, same thing people did a lot on the C64 (and still do in demos) to get shitloads more sprites on screen than intended by the manufacturer (C64 has only 8 sprites total, not sure where the current record is, but it is deffo close or over 100)

[Ex-Cyber]

2600 does have 5 hardware sprites, but they're extremely limited: they're single-color (also, two pairs each share a color, and the odd one out shares the playfield color), and have no pattern data (just a width setting).

[ptoing]

Ah, did not know that. Sounds like very weird restrictions. There is also stuff about how many colours in a line for the background, no?

[Ex-Cyber]

Ah, did not know that. Sounds like very weird restrictions. There is also stuff about how many colours in a line for the background, no?

First of all, I screwed up: the "player" sprites (2 of the 5) are bitmapped (8 pixels wide with some kind of primitive scaling ability). The length setting is for the "missile" sprites.

The restrictions are weird because 2600 is optimized to run simple two-player games like Pong and Spacewar. The sprites break down like this:

2 "player" sprites
2 "missile" sprites, each of which is the same color as a "player" sprite
1 "ball" sprite

I'm not sure how often the playfield (background) color can be changed, but I'm sure it's not a lot because the TIA runs at 3 pixels per CPU clock, and 65xx can't get anything done in a single clock; even a NOP takes two clocks...

[ptoing]

I think colour on background can be changed every 8 pixels per line and only 2 colours per line total unless you trick around. not 100% sure tho.

[Ex-Cyber]

I think colour on background can be changed every 8 pixels per line and only 2 colours per line total unless you trick around. not 100% sure tho.

Every 8 pixels would be impossible if each CPU clock is 3 pixels. According to a random source I found, the TIA clocks 228 pixels per line, of which only 160 are actually visible. Loading arbitrary colors would mean at least one load and one store, which would be 5 cycles = 15 pixels, so I think it is possible to have at least 11 differently-colored regions. It might be possible to add a few more by pre-loading other values to the index registers during blanking and perhaps reusing colors. But if you pushed this anywhere close to the limit you'd have virtually no time left to do anything else (e.g. updating the sprite hardware).

[mrkotfw]

Don't forget that the 2600 has no video memory.

Uhm, you're better off on the NES.

[ED-057]

The small RAM pretty much rules out bitmapped gfx or large numbers of objects. I believe that the 2600 cartridge port doesn't contain the R/W signal (ie. it's read only) so you can't even use additional RAM in a cartridge.

[ptoing]

Every 8 pixels would be impossible if each CPU clock is 3 pixels....

I did not mean change the colour to whatever every 8 pixels in the background, but change between 2 colours which you have on any given scanline.



In this screenshot there are 3 colours on some of the background lines, black, grey and green, and they are in 8 pixel steps (which are probably actually only 4 pixels as the sprites are widepixels as well).

[antron]

the "player" sprites (2 of the 5) are bitmapped (8 pixels wide with some kind of primitive scaling ability). The length setting is for the "missile" sprites.

The restrictions are weird because 2600 is optimized to run simple two-player games like Pong and Spacewar. The sprites break down like this:

2 "player" sprites
2 "missile" sprites, each of which is the same color as a "player" sprite
1 "ball" sprite

I'm not sure how often the playfield (background) color can be changed, but I'm sure it's not a lot because the TIA runs at 3 pixels per CPU clock, and 65xx can't get anything done in a single clock; even a NOP takes two clocks...

correct, but the Playfield does have graphics registers (in 4 pixel blocks) that are seperate form the Background. But the left and the right side of the screen share the Playfield registers, so it is either mirrored or you must change it on the fly (and there is not much time if you want to do other things). also the ball is the same color as the Playfield. building a 2600 scanline kernel is quite a challange.

you can always alternate using the Player registers for different sprites. This causes flicker, like in Asteroids.

[Ex-Cyber]

I did not mean change the colour to whatever every 8 pixels in the background, but change between 2 colours which you have on any given scanline.

Ah, I thought you were talking about palette changes. As antron says, there are 40 "playfield pixels" in a scanline (i.e. 4 pixel clocks each), but only bits for 20 - on the right half of the screen they are repeated either in the same order or reversed. With careful timing, it is possible to update the registers in the middle of the scanline and get a unique pattern for the second half of the line.

I believe that the 2600 cartridge port doesn't contain the R/W signal (ie. it's read only) so you can't even use additional RAM in a cartridge.

You can, it's just a little tricky. For example, you can use an address line as the read/write line (thereby mirroring the RAM into a "read area" and a "write area"). This could also be folded into a bankswitching scheme.

[D]

petition for Dodonpachi Daifukkatsu on 2600
OMG

Seriously, this talk fascinates me. I am very curious about system limits. And I wonder if with today knowledge more system limit pushing stuff can be done. Could a processing chip in the cartridge (Super FX chip) be used for the 2600?
There is always a more clever way to code things, right?
I remember the new games 2600 a while ago. I was fascinated to see that. And even though it makes no sense it is still very exciting to see old system push around new code and make an old system smoke/push it to it's limits. I wonder which other systems could have been upgraded like the saturn and N64 4mb memory through certain slots.

[antron]

petition for Dodonpachi Daifukkatsu on 2600
OMG

Seriously, this talk fascinates me. I am very curious about system limits. And I wonder if with today knowledge more system limit pushing stuff can be done. Could a processing chip in the cartridge (Super FX chip) be used for the 2600?

Pitfall 2 did contain extra hardware to handle the music.

[ubersaurus]

Atari 2600 homebrewers are capable of a lot of things on the system. but moving enough bullets independently for a manic shooter is really, really unlikely.

I could see it on the 7800, however. That machine was practically built to move around large amounts of objects. It can also use on-cart RAM expansions.

[PC Engine Fan X!]

Atari 2600 homebrewers are capable of a lot of things on the system. but moving enough bullets independently for a manic shooter is really, really unlikely.

I could see it on the 7800, however. That machine was practically built to move around large amounts of objects. It can also use on-cart RAM expansions.

For ubersaurus,

I do recall seeing the Atari 7800 for sale at Sears back in 1984 except that it came with a cool Sears branded game controller that was a combination of joystick/paddle -- slide the switch in one direction and it would lock up the paddle portion and allow for 8-way digitial joystick direction...slide in the opposite direction and lock up the joystick and use the joystick to spin either to the left or right as a paddle. I've never seen that Sears branded 7800 console since then...it was named the Sears Telegames III console. (The Sears Telegames and Telegames II consoles were the Atari VCS/2600 console with Sears Telegames label placed on it instead of Atari's.) Interesting stuff back in those early 1980's era of Atari before it crashed and burned "big time" in during the "Great Video Game Crash of '83-'84"... ^_~

In the 7800 version of Desert Falcon isometric-based shmup game, when the Sphinx boss is finally destroyed at the end of a given stage, the stage flashes a myriad of colors...very cool and coloful effects on the 7800 console. So a bullet-hell shmup could work on the 7800 platform then?

PC Engine Fan X! ^_~

[Ex-Cyber]

Could a processing chip in the cartridge (Super FX chip) be used for the 2600?

A SuperFX style chip wouldn't buy you much, because the bottleneck is the relative frequency with which the CPU can write to the graphics registers. If you were to do an on-cart processor for 2600, I think it would actually make more sense to offload the game logic/state to it rather than the graphics.

There is always a more clever way to code things, right?

Not necessarily. Given the constraints of the 2600 hardware, you can pretty quickly run up against theoretical limits. At that point, the cleverness is in designing the entire game, not just the code, around those limits.

[ubersaurus]

I don't see why it couldn't. The background would have to be pretty much nonexistent, and slowdown is entirely a possibility...but the thing can run a full speed version of Robotron, which has plenty of shit moving around at the same time. So this couldn't be too much worse with more RAM and a decent cart size.

[antron]

I don't see why it couldn't. The background would have to be pretty much nonexistent, and slowdown is entirely a possibility...but the thing can run a full speed version of Robotron, which has plenty of shit moving around at the same time. So this couldn't be too much worse with more RAM and a decent cart size.

do you mean Robotron for the 2600?
becuse that does not exist and would flicker like hell if it did

There is always a more clever way to code things, right?

Not necessarily. Given the constraints of the 2600 hardware, you can pretty quickly run up against theoretical limits. At that point, the cleverness is in designing the entire game, not just the code, around those limits.

there have been some accomplishments
Play Thrust+ by Thomas Jentzsch. When too many objects get on the same horizontal line the game has a neat way of minimizing the flicker.

I think there is a modern Space Invaders that manages to get all the monsters on the screen without any flicker.

[Ex-Cyber]

There is always a more clever way to code things, right?

Not necessarily. Given the constraints of the 2600 hardware, you can pretty quickly run up against theoretical limits. At that point, the cleverness is in designing the entire game, not just the code, around those limits.

there have been some accomplishments
Play Thrust+ by Thomas Jentzsch. When too many objects get on the same horizontal line the game has a neat way of minimizing the flicker.

I think there is a modern Space Invaders that manages to get all the monsters on the screen without any flicker.

Yeah, my point was that there is not always a more clever way to code, and that this is particularly true on the 2600, where you have to be fairly clever to do anything appreciably complex in the first place. There are limits, even if they're somewhat obscured by the fact that most people stop when the hardware stops making life easy.

[antron]

I think there is a modern Space Invaders that manages to get all the monsters on the screen without any flicker.

it's Space Invaders Arcade by Rob Kudla


also, there is now a BASIC compiler for 2600 called batari BASIC.
it uses limited custom scan-line kernels written in assembly. alot of games are coming out now becuse of it. one is a shmup called N.E.R.D.S., but I understand that it is not very good.