Okay so... The missiles cannot intrude on another player copy's personal space just as another player object cannot?

No all 5 movable objects including Player0, Missile0, Player1, Missile1, and the Ball can all overlap with each other but when you render a copy of any of these objects(excluding the Ball which has no default copy ability.) it requires a mandatory gap of 3 possible distances from itself not the other objects.

Try to think of it as a multi-layered abacus where the beads are locked to a set distance apart from each other if that helps.

Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines on an 8x-width pixel by pixel basis.Hardware demands the playfield to be symmetrical, but coding can overcome hardware to be asymmetrical. [See BladeJunker's guide on how collumn splitting works]

Player sprites: Up to two unique sprites, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired. Can be copied*.

Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height. Corresponds to relative player sprites. Can be copied*.

Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height. Cannot be copied.

* Whenever you copy a sprite, it shares the same x origin of the original sprite for movement, and must be offset by 32, 64, or 128 pixels and + width pixels.

Technical Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)NOTE: Depending on the game, some horizontal pixels may be omitted where clock cycles were used to process game logic.

Some horizontal pixels may be omitted sounds kind of vague, if you are referring to what I said about pillarboxing then yes omission of certain Playfield columns is possible. I tend to find clipping the first 4 blocks off the left and right useful for some games as well as dedicating the first 12 blocks on either side of the screen for a menu or HUD.As far as processing game logic that is usually done in between graphics rendering passes. The reasons for omitting a column or bank of Playfield pixels tend to vary.

Quote

Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines on an 8x-width pixel by pixel basis.Hardware demands the playfield to be symmetrical, but can be coded to be asymmetrical. [See BladeJunker's guide on how collumn splitting works]

That looks right to me about Playfield pixel size. However the hardware defaults are Symmetry mode or mirroring and Tiling mode like you see in my column split chart. Only asymmetry requires special coding.

Quote

Player sprites: Up to two unique sprites on screen, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired. Can be copied*.

Okay pixel sizes look accurate to what I described. However up to two unique sprites on screen isn't exactly true since you can vary the Player sprite vertically based on a set height resolution. Let's say you use a Player sprite that is 24 pixels tall, based on 192 lines of vertical resolution you could vary that one sprite 8 times. A good example of this feature is Frogger where the type of sprite switches from different car styles up to logs and turtles which all use the same Player objects but are isolated into vertical bands.This will be featured as part of my scanline isolation post jsyk.

Quote

Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height. Corresponds to relative player sprites. Can be copied*.

Looks good on pixel size. I'd say Missile0 and Missile1 are associated to there Player counterparts as each share the same default color with there pair but should still be thought as there own separate independent movable object. Can be copied up to 3 times*. I'm guessing the * is related to the unique visual quirks when copies are invoked?

Quote

Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height. Cannot be copied.

Pixel sizes look good. Can not be copied is a little strict since by default the hardware may not support a copy per se, but with the right setup of multiplexing you could get more than one per scanline. I admit that multiplexing is a less stable and dependable option but it still exists. Perhaps another * is required? ^_^

Quote

* Whenever you copy a sprite, it shares the same x & y origin of the original sprite for movement, and must be offset by 32, 64, or 128 pixels.

It only really needs to share the X axis of the original sprite in movement, refer to what I said about Frogger. The offset pixel widths are fine but its important to remember that the said objects width is included as part of the offset distance rather than just added to the width of the object and the origin point is to the left most side. Can't hammer this point enough I'm afraid since its not at all like "regular" tiling on other platforms.

I edited my previous post based on your corrections. When you said that a game might not use the entirety of the 320 horizontal resolution I thought you meant games like Pitfall which hid the part of the screen that would have had black lines.

Quote

Okay pixel sizes look accurate to what I described. However up to two unique sprites on screen isn't exactly true since you can vary the Player sprite vertically based on a set height resolution. Let's say you use a Player sprite that is 24 pixels tall, based on 192 lines of vertical resolution you could vary that one sprite 8 times. A good example of this feature is Frogger where the type of sprite switches from different car styles up to logs and turtles which all use the same Player objects but are isolated into vertical bands.This will be featured as part of my scanline isolation post jsyk.

So... Two unique sprites per horizontal scanline as long as sprites are not occupying the scanlines? Or are you talking about a very specific programming trick.

I'm going to be honest, learning about Atari 2600 hardware restrictions becomes that much more difficult for the purpose of doing mockups (that have no programming backing) and pixel art when one also has to learn about every specific programming trick in very specific games that have broken the restrictions. I'm hoping to mostly get a summary of the hardware itself with some minor exceptions that can be made.

---

I did want to ask, is it possible to feasably alter a chunk of the playing field (such as the middle two columns) without affecting the rest of the playfield? I'm thinking about doing an Atari 2600 mockup of a first person view AD&D style game and I'd like the view of a first person area to change to that of a detailed creature.

So... Two unique sprites per horizontal scanline as long as sprites are not occupying the scanlines? Or are you talking about a very specific programming trick.

I know it seems confusing when compared to how scanline to sprite limits work on other platforms with block based sprites but it is different. Remember what I said about the 2 Player objects being capable of being any height resolution you choose, well the height of the sprite defines the amount of scanline height and its limitations for said Player object. Where ever the sprite is within the vertical field defines the zone at which only 3 copies can be rendered per Player object, and that's per object as Player0 & Player1 do not effect each others rendering limits.

Specific programming task, well everything on the 2600 would fall under that definition lol but if you're asking if its a common practice then yes it can be done without much difficulty. I'll always make sure to clarify anything that could prove difficult or proves to be unreliable for average use or only possible under certain contexts.

Quote

I'm going to be honest, learning about Atari 2600 hardware restrictions becomes that much more difficult for the purpose of doing mockups (that have no programming backing) and pixel art when one also has to learn about every specific programming trick in very specific games that have broken the restrictions. I'm hoping to mostly get a summary of the hardware itself with some minor exceptions that can be made.

Believe me I sympathize with what you say about no programmer backing as it can put you in a position of much doubt but that's where I'm everyday since starting this quest. I'm afraid there isn't much of anything done on the 2600 that isn't restricted or defined by its unique hardware, as far as breaking the restrictions we're talking hand and glove here since its more like if you want to do X then this is the particular setup you'll need. This is kind of why I described this guide being in terms of sprite contexts(Portraits/HUDs/Text/Sprites/Level Tiles) and or game Genres(Shooter/Platformer/Fighter/Etc.), a lot of my proposals on AtariAge are setups or structural templates for achieving the 2600 equivalent of things done on stronger gaming platforms.

Quote

I did want to ask, is it possible to feasably alter a chunk of the playing field (such as the middle two columns) without affecting the rest of the playfield? I'm thinking about doing an Atari 2600 mockup of a first person view AD&D style game and I'd like the view of a first person area to change to that of a detailed creature.

Yes you can alter specific Playfield columns while leaving the others unchanged, such setups have been done before since the Playfield columns constitute individual banks in the Playfield register.

I know it seems confusing when compared to how scanline to sprite limits work on other platforms with block based sprites but it is different. Remember what I said about the 2 Player objects being capable of being any height resolution you choose, well the height of the sprite defines the amount of scanline height and its limitations for said Player object. Where ever the sprite is within the vertical field defines the zone at which only 3 copies can be rendered per Player object, and that's per object as Player0 & Player1 do not effect each others rendering limits.

I still am not sure what you're trying to say.

Based on the Frogger example, is it just that you're using a single very tall sprite to draw several images, and delaying the drawing during different scanlines to change their positions?

Quote

Believe me I sympathize with what you say about no programmer backing as it can put you in a position of much doubt but that's where I'm everyday since starting this quest. I'm afraid there isn't much of anything done on the 2600 that isn't restricted or defined by its unique hardware, as far as breaking the restrictions we're talking hand and glove here since its more like if you want to do X then this is the particular setup you'll need. This is kind of why I described this guide being in terms of sprite contexts(Portraits/HUDs/Text/Sprites/Level Tiles) and or game Genres(Shooter/Platformer/Fighter/Etc.), a lot of my proposals on AtariAge are setups or structural templates for achieving the 2600 equivalent of things done on stronger gaming platforms.

I can see where you're going with that, I just think it'd be easier to know the sprite limitations and quirks before getting into how to work around them and apply them in certain scenarios.

Based on the Frogger example, is it just that you're using a single very tall sprite to draw several images, and delaying the drawing during different scanlines to change their positions?

Single tall sprite, no that is not the case in Frogger. Everything on the 2600 is being rendered in real time so it literally changes from one "bitmap"(Player0 or 1) to another bitmap over and over again as it draws the screen top to bottom. The 2600 doesn't have a frame buffer so it constantly has to manually refresh the pixels just to keep them lit. While this is a hectic process always "racing the beam" it makes the data highly modular thus using the same address or object across multiple sprites rather than one sprite per sprite like on other platforms. I know it sounds crazy the first time you hear it but that's the way it works.