Christopher Tumber

Actually, my idea is that the "bonus items" are the "oxygen". It's an archeaological dig, so you have a budget (or grant). Every relic you find, ups the budget slightly (likely a different amount for different relics) but mounting these expeditions is costly so the funds run down continuously like the oxygen meter in Mr. Driller... Run out of money and everyone goes home... I have a serious decision to make with Big Dig that I'm putting off by working on a horiz scrolling shooter. Currently the screen in Big Dig is 7 blocks wide. Using some of what I learned doing Space Instigators I could make the squares smaller and get 9 blocks (By using a RAM routine to do the drawing). But it would mean a complete rewrite pretty much from scratch. (Changing the display kernal and adding the RAM routine is no big deal, but, to make room in RAM would mean completely changing the data structure which holds the block colours and rewriting all the code that deals with removing blocks, dropping blocks, etc...) So I'm putting off deciding whether it's worth starting over at square one or not... Chris...

The scroll speed is completely arbitrary, it was slow for dev purposes (esp checking sprite overlay alignment) Attached is a version scrolling 1 pixel per frame. However, it still doesn't look quite right. I think I may be dropping/duplicating a frame (presumably during the transition from soft to hard scroll). Ah, well that's why it's called WIP, eh... Just for the record, my scroll looks the way it does because I'm doing calculations on the blank lines (basically just feeding a RAM routine which does the actual drawing) like with Space Instigators. It was only when someone mentioned Thrust in this (or the other) thread that I went "D'hoh! It looks like it could be Thrust II: Thrust Harder!" The big drawbacks to this engine are that the scroller uses both Player objects. There's no reason not to re-use the Players below/above the scrolling regions (ie: For enemies) but the player's ship pretty much has to be either a missile or ball in order to interact (crash into, dodge behind mountains) with the scroller. In addition, only every third line is drawn in the scroller so each pixel in the player's ship is 3 scanlines tall which make for a slightly chunky sprite. However, now that you mention interlacing. Hmmm.... It also eats a fair bit of RAM (smile). Chris... scroll.zip

A demo of shutter or Red/Blue? I'm not sure why you would need the interlaced mode for Red/Blue, it's not the vertical resolution that's any problem... But, yeah, absolutely. I'm sure you could do some kind of Red/Blue 3D cube or something (smile). But I think getting enough 3D objects onscreen at once to make for a game would be a real challenge. Chris...

Did you take a look at the Mortal Kurling WIP I posted to Stella while you were offline? It's still pretty preliminary, but, well, take a look... Chris... (Not really a curling game, just part of that joke. Though I am considering doing a curling game now. It's just too bizzarre...)

Okay, thanks for the clarification. But it's still basically a moot point - How many of these types of games actually need to scroll horizontally (including on oher consoles where scrolling is common)? Generally these kinds of games are single screen games. Boulder Dash, Fortress, uh... And given the amount of scrolling, Boulder Dash could probably get away with a "page scroll" or even a hard scroll. Fortress pretty much needs a smooth scroll but that's like, one, mediocre game... (Yeh, there's probably others, particularly stuff that's unlikely to make it to the 2600 for other reasons (ie: RTS) but I hope I've made my point...)

Actually, I was working on something similar before I got hooked on doing Space Instigators. It's about half done, but I've been putting off deciding on whether or not to do a complete rewrite based on some of the stuff I learned writing Instigators. Speaking of puzzle/action games, I've always though Rampart could be done quite well on the 2600... Chris...

Many, many years ago I did some experimenting with Red/Blue 3D on the PC and it was possible to get pretty good animation results on 320x200 VGA. The 2600's resolution would be fine, however you can't really arbitrarily generate the required images. The real problem as I see it is that in order to do Red/Blue 3D you essentially need to generate two images for every object on screen (Three if the two views overlap, then you need Red, Blue and Purple portions). So in effect, you need double (tripple) the number of sprites and playfield objects onscreen. Or, you need to incorperate a colour change on the fly. Or something else. At any rate, given the 2600's video hardware limitations, you're looking at a really tough time composing an scene complex enough to be usefull. Shutter-type technology would be a better fit (on any console - The SMS 3D glasses work pretty well IMHO) but then you're looking at designing an interface. Any any non-trivial custom hardware project is an iffy proposition at best - Look how long it's taken for something really usefull, like a new "Cuttle Cart" to come out...

Okay, but that's essentially a meaningless statement. No game on the planet has a truly arbitrary playfield. And if you consider 2600 games in particular, the displays are almost always 50-75% empty space. If you want a smooth scroll, you do need to tailor the lay-out to the scroll. But that kind of tailoring is true of everything on the 2600.... Chris...

Uh, that's kind of the point of this thread. Go back and read the second post in the Scramble thread. Cost of production isn't really an issue anymore, the components in a 32k cartridge are a little more expensive then a 4k cart, but it's not like 20 years ago. Let me be clear, a full screen, high resolution, multi-coloured scrolling background is not likely. But other... interesting... things are very possible... Chris....

A jerky scroll like Super Cobra IS relatively easy. However, a smooth scroll looks a lot better. Doing a SMOOTH horizontal scroller anywhere near as complex as Super Cobra's IS really, really tough. So for games which needed to interact with the scroll, they instead tended to do either vertical scrollers or horizontal scrollers like Barnstorming (Consider using the Barnstorming game engine, but instead of only 2 different sprites on the ground (farms and windmills) you use a whole bunch of different sprites (Maybe a variety of different building in a cityscape, trees, mountains, etc) and instead of birds you make enemy ships. Could be a pretty good game (though not in 4k like Barnstorming) Consider also that these games would have been coming out around '83 or later (Super Cobra is '83). So they're going to be compared to the things like the Commodore 64 or very shortly the NES which both had all kinds of smooth scrollers. Why set yourself up for that, when you could just make a vertical scroll and make it smooth very easily? Super Cobra and Vanguard are both 8k. However, Super Cobra must dedicate more ROM space to the scroller data as opposed to Vanguard's repetitive scroller. But Vanguard also needs to be a vertical scroller too so that's presumably where the "extra" space goes. If Vanguard could've been a 16k or 32k game it could have had a much more varied scroll background (Or maybe they were just lazy/pressed for time and didn't bother with a more complex scroll...) Chris...

Noooo... I said that Super Cobra (and Vanguard and Defender) have a rough/hard scroll, which they do. Other people DID say it's a crap game, but I've offered no opinion. I haven't gone through all the games on ZylonBane's list yet, but, Super Cobra may well have the most functional scroller what do you want, a medal? Chris...

Sorry, was thinking of Fantastic Voyage (They're all starting to blur.....) Chris...

>Planet Patrol Vertical scroller (unless it goes horizontal scroller later in the game?) >Laser Gates, Fantastic Voyage, Gas Hog Thanks... I'm going to stop replying to every post, and just say thanks in advance to everyone who offers suggestions... Also Dragster and Stampede (When you stop to think about it, there's actually quite a few...) Chris...

Hey, screen 3 of Jungle Hunt even has parallax scrolling! Good call. Well, I'm not really putting together an "Ultimate list of 2600 scrollers" rather trying to look at what's been done before. So anything vaguely related is of interest to me because horizontal scrolling is generally considered such a bugaboo on the 2600.... But "functionality" versus simply a visual fx is definately a valid differentiation (if you don't have to worry about the scroller interacting with anything that certainly simplifies things...) [You can also crash into walls in Vanguard, btw] Chris...

Yeah, I'll take those - Chopper Command in particular has a nice looking smooth scrolling mountain at the top of the screen (still a simple design, but very effective) Chris...

Yeah, but whenever you do that kind of thing you risk run into big aspect ratio problems - ie: the screen to the side of the player is a lot wider than it should be and the space in front and behind is a lot shorter. Though that would actually work with Scramble since the arcade version is a horizontal scroller but the monitor is oriented vertically. So an accurate console port of Scramble actually SHOULD be a vertical scroller! (Though bombs "falling" to the right would seem odd...) (Similar to most arcade vertical scrollers which when ported remain vertical scrollers, except the arcade version usually has a vertical monitor so it really should be ported as a horizontal scroller [because tv's are all oriented horizontally]... Except everyone would say it's facing the wrong way...) Really? Thought it was damn near incomprehensible myself but after writing all that I couldn't bear to just delete it... Chris...

I'm putting together a list of horizontal scroller for "research purposes". Defender, Vanguard and Super Cobra all have the same kind of rough scroll. Defender II has a nice. smooth scroll but the background is really, really simple. Moon Patrol's mountains are a rough scroll, the stars and ground is a smooth scroll. Anything else noteworthy? Thanks, Chris... (There are plenty of games which scroll a whole screen at a time, like Pitfall or Xenophobe - Not those!)

Ayep, seems dese high faloot'n web forums is much too citified fer da likes a me... Chris...

Did someone mention something about needing to get out more? Chris...

>So a Supercharger games' screen could be done in a standard cart? Sorta. It's pretty safe to say that any -single frame- could be replicated on a standard cart but it might have to be hard-coded in ROM and you might not be able to DO anything with that screen, like move things around). To give a simple example - Let's say you have some game which for some reason has 300 objects moving around the screen. Your program would have to keep track of the X and Y position of all 300 objcts, plus maybe some other data (if it's alive or dead, if it's shooting, etc). The 2600 only has 128 bytes of RAM, keeping track of all those items would be really, really difficult if not impossible. But using the Supercharger RAM you'd presumably have no problem managing all that data. So you COULD draw said screen with a regular cart, but it would just be a static screen. A game running on a standard cart wouldn't be able to store so much information to actually make the game run. Basically, the bottom line is that there is only one "graphics mode" on the 2600. Designing a game for the 2600 often consists of tradeoffs (like in a car, say, performance vs economy) having more resources available as with Supercharger RAM gives more options but you're still not going to drive a Hyundai in the Indy 500... The extra RAM doesn't make the TIA work any differently. What it does is provide the programmer with more options, particularly when it could to dealing with a lot of data and/or designing dynamic, self-modifying code. Drawing an equivalently detailed a screen on a regular cart may require too much ROM space to make it practical. Particularly if objects can be moved around randomly but that's not really a limitation with the display hardware. >fuel pods. **Wouldn't you need the player object used to make the edge >of the screen used for that only? There are a variety of ways to approach any problem, that's not really my point. My point was that a blanket generalisation that a pixel scroll is not possible is extremely short-sighted. Particularly since Defender II does it (if your criteria is "full screen", there's no reason the mountains couldn't extend to the top of the screen ) >Otherwise, the screen would flash on the scanline of whatever object it >is serving double-duty for...right? The sprite object(s) would flicker. The rest of the screen is unaffected. >Then again, it might be easier just to make Scramble into a vertical >scroller Yeh, but then everyone'd piss and moan like with Zaxxon.... Chris... BTW - Moon Patrol is another scroller. The Mountains are a coarse scroll, while the stars and the ground are both smooth.

I probably shouldn't assume everyone knows what the mathematical symbol ! means. ! is factorial. 8!=8*7*6*5*4*3*2*1 6!=6*5*4*3*2*1 I won't turn this into a big math lesson, it's used in determining the number of permutations and combinations of items. Chris...

>Forgive my ignorance, but how the heck would you use a player on >every scanline without causing flicker on the entire screen? The players, missiles and balls are only one scanline high, unlike later sprite systems which had sprites of a certain height. So the height of any image is completely arbitrary, and the players, missiles and balls can be re-used every scanline. You could have sprites 200 scanlines tall if you wanted. Repositioning the player/missile/ball arbitrarily on a scanline is a chore, however, moving them a small offset (-7 to +8 pixels) is trivial, as is done with the mountains in Defender II. Basically, each scanline is completely independant from the scanline before it (except for the difficulties in repositioning sprites arbitrarily). >You would need 1 player for the player-controlled sprite (which is free to >roam the entire screen)... All the hardware objects (players, missiles, ball) are free to roam the entire screen. It's up to the coder to determine what is used for what. You definately don't need to use only the player for the player-controller sprite. >but wouldn't that cause the edge of the screen to flicker as well? Flicker is caused when an object (player, missile, ball) is only drawn every other frame in order to "share" that object between images. A flickering smooth scroll would completely miss the point (ie: If it's going to flicker, IMHO you might as well stick to a coarse scroll). >Aren't higher-resolution screens made with this than what is possible >with carts? No, all 2600 screens are of the same resolution. You get the chunky Playfield graphics and the high resolution Players, Missiles and Ball. That's it. The Supercharger just gives you a bunch of extra RAM, which can be incredibly usefull but doesn't change the consoles specs. One of the advantages of the extra RAM is to be able to dynamically create optimized routines in RAM. For example, Galaxian has a bunch (hundreds?) of routines in ROM specific for every possible layout of Galaxians (ie: Full row, First Galaxian missing but otherwise full, Second Galaxian missing but otherwise full, &etc). That uses up a lot of ROM and ultimately limits your flexibility because eventually you get to a situation where there are too many possible combinations to handle (ie: 8! is an awful lot biger than 6!) Space Instigators creates the routine it needs in RAM, but because the amount of RAM available is so limited all 5 rows share the same routine (instead of creating a unique routine for each row). So, that routine must be changed between rows. Fortunately, a couple blank lines between rows of Instigators are expcted, and that's where these changes are made. If a solid image was needed, it'd have to be a different approach. A Supercharger version could take advantage of the extra RAM, and create a unique routine for each row ahead of time and do away with the blank scanlines... But that has nothing to do with the actual resolution of the screen... Chris...

Tsk, tsk! So cranky! What're you, up past your bedtime or something?

>I was referring to the screen graphics... WTF? It seems pretty clear what you said - That Super Cobra and Defender II were both scrolling the same but that the jerkyness is just more noticeable on Super Cobra because the screen's more complicated. Which couldn't be further from the truth. There's not a lot of point to arguing what you did or didn't say since anyone can read it, so, would you like to actually mention any other scrolling games I can add to the comparison list? Really, if you've been paying attention to this thread, you'd know I have a specific interest in seeing what's been done before. >there's no way that you would be able to pixel-scroll an entire screen Heh, heh, heh, okay if you say so. >(i.e. the mountians) using P/M. You would need to reuse the players >and missiles for the game objects as well, and there's just not enough >time to do that many updates. "That many updates?" What are you talking about? You can update every object every scanline if you want to. What you can't do is re-use them on a scanline (sorta - that's not even a hard and fast rule) >Using the SuperCharger's extra Ram...now that might be an option (Erm, didn't you just say there was NO way?) Extra RAM has nothing to do with how many cycles a scanline takes to draw and the only way accessing RAM is faster than ROM is if it's zero page and the extra Supercharger RAM is not zero page. So unless, as I suspect, "Using the SuperCharger's RAM" is actually a euphamism for "I have no idea what I'm talking about, but I hear the Supercharger has magic powers so maybe I can bluff my way out of this" then maybe you could clarify? Chris... (Go ahead and argue with me. I obviously have no idea what I'm talking about here.)

Ah, no. Have you SEEN Defender II? Defender, Super Cobra and Vanguard all do a hard scroll using only playfield graphics for the backgrounds. Defender II does a smooth pixel-scroll, using the missile(s) and/or ball and/or player(s) for the mountains. It's a very noticeably different effect. Simplicity has nothing to do with anything (except that simplicity is a lot easier to program...) Chris...