Small sprites made of Missles and Ball?

[BladeJunker]

I understand how the 2600 draws things but I'm dumb when it comes to cycle costs used to achieve functions.

[Thomas Jentzsch]

So what exactly is your question?

[BladeJunker]

Can you render and or animate a sprite built from Missles and the Ball in a practical manner within a gameplay scenerio?

I'm sorry if my question is overly vague or that it is an overly simple question with a complex answer.

Edited June 23, 2011 by BladeJunker

[LS_Dracon]

Yes, the diver from Sea Quest is made with ball object.

[Nukey Shay]

Missile sprites are used for 2 of the cops in Lock'N'Chase.

IIRC the ball is used to create the tank in the homebrew Duck Attack, and the Pac-Man sprite in the in-development game Super Pac-Man.

 

Such effects are done by rewriting the width and horizontal position registers on successive scanlines...so that the corresponding sprite can be something other than just a square "pixel".

 

However, rewriting width and position robs available time on each scanline it's done (which might not always be possible if a complex playfield and/or rewritten sprite copies are desired).

 

In Bowling, the "round" ball is made by stacking a missile sprite on top of a taller/narrower ball sprite.

[+atari2600land]

I don't mean to hijack this thread, but I was wondering if such a thing would ever be possible using batari Basic.

[Wickeycolumbus]

I don't mean to hijack this thread, but I was wondering if such a thing would ever be possible using batari Basic.

 

Probably not with the standard kernels.

[Nukey Shay]

Right...because you need to reset registers on a per-scanline basis.

[BladeJunker]

I have used that setup of rounding of Ball sprite method to a pinball game I've been screwing around with since I like my round things round, good to hear its been done in a running example.

[BladeJunker]

So if I stick to a strict vertical seperation per scan line would that make up for the overhead of this type of kernel, I'm guessing I can't put many sprites horizontally in a row.

[BladeJunker]

Question, what constitutes a complex Playfield and what am I getting on screen with a rewritten copy?

Also can you delete posts on this forum because the last three post I made could have been in a single post, this is my first time posting.

Edited June 24, 2011 by BladeJunker

[SeaGtGruff]

I don't mean to hijack this thread, but I was wondering if such a thing would ever be possible using batari Basic.

 

Probably not with the standard kernels.

Several years ago I made "bomb" and "explosion" sprites in a "bB Blitz" game I started working on. This was back in version 0.35 I think. I used the overlapping trick-- shorter/wider missiles on top of a taller/thinner ball. I never finished it-- it was just something I started because someone had posted a question whether "Blitz" could ever be done for the Atari 2600, and I never posted it or finished it because someone else said they had started doing it in assembly. The 0.35 code is probably funny-looking compared to what can be done now in 1.0 and 1.1, and you shouldn't try to compile it as-is, but a BIN is included, and the game (such as it is) is mostly playable. You have to press RESET to start, otherwise the game goes into "demo mode." The bombs have a slight drift to them (compared to the original Blitz, where I think they fall straight down), and the explosion must overlap a building at least 50% (or maybe more) or it won't count. I was going to have different levels or waves with increasing numbers and heights of buildings, plus bonus waves every so often where you get to bomb things like a big pyramid, a castle from Adventure, and an Atari building shaped like the fuji symbol. Also, I was going to try to have the pilot get out and do a little dance if you land safely, but right now it just goes back to the title screen.

 

Michael

bB_Blitz.zip

[BladeJunker]

Thank you Nukey Shay for your help so far. To atari2600land could I have stopped you?^_^

SeaGTGruff I like your game and hope you finish it as you described.

[BladeJunker]

I inquired with the description of small sprites based on a setup of secondary sprites to that of the main Player objects which you can see in the first example image but unless size or resolution actually affects the performance of a Missle/Ball sprite rendering kernel it would seem size doesn't matter as in the Super Pac Man sprite Nukey Shay mentioned and diver LS_Dracon referred to.

 

I have 2 examples one of Pikmin which requires heavy unit rendering through Missle and or Ball sprites although when not attacking slugs they can move in train like formations and the other is a Minecraft type setup where the game level is mostly Playfield lines with some flourishes, the player and creeper as either of the Player objects, and the remaining animals are Missles and Ball sprites. Please ignore any multicolor exceptions in sprites if such thing won't work as I can rework them to use per scan line coloring if needed.

 

I'm assuming a Missle/Ball rendered sprite involves multiplexing instead of copying otherwise you wouldn't have independent sprite movements. So does that mean I can only render one sprite per Missle or Ball or can I leverage all 3 objects across multiple sprites?

[SeaGtGruff]

I'm assuming a Missle/Ball rendered sprite involves multiplexing instead of copying otherwise you wouldn't have independent sprite movements. So does that mean I can only render one sprite per Missle or Ball or can I leverage all 3 objects across multiple sprites?

I'm not sure I understand what you're asking, but you can display copies of the missiles, just like the players-- the number of copies and the spacing between them is the same as for the player that the missile goes with. That means you can't move the copies independently of each other on a given scan line, but you can move them independently if they're on different scan lines (just like with the players). If by "multiplexing" you mean "flickering," that would be the usual way to do independently-moving "copies" that overlap each other, as is done with players. So you could use an "intelligent flickering" routine that flickers only on the scan lines where it's necessary.

 

The ball can't have copies the way the players and missiles can, but you can trigger multiple copies of the ball on a line-- you just can't fine-tune their positions. In fact, you can do that with the missiles, too, by using the RESxx trick, but with the same lack of fine-tuning their positions.

 

Michael

[Zach]

Can you render and or animate a sprite built from Missles and the Ball in a practical manner within a gameplay scenerio?

I'm sorry if my question is overly vague or that it is an overly simple question with a complex answer.

Some of the best examples of sprites built with missiles are the animated bells in Hunchy II. See here for screenshots.

[BladeJunker]

Some of the best examples of sprites built with missiles are the animated bells in Hunchy II.

 

They are good and the placement and vertical seperations look fairly natural looking which is something I've been aiming for.

Edited June 25, 2011 by BladeJunker

[BladeJunker]

I'm not sure I understand what you're asking, but you can display copies of the missiles, just like the players-- the number of copies and the spacing between them is the same as for the player that the missile goes with.

 

You're too humble as I think you interpreted my left brain gibberish quite well and have given me the right path of thought to take. So multiplexing and flicker are independent systems that can exist separately as in multiplexing sprites in isolated vertical bands. The Ball object seems like it works better in a singular fashion for independent movement as in the Pac man sprite in Super Pac man while a group of Ball copies have to move in a Space Invaders like formation. Also the Ball seems ideal for decorative purposes as that context deals with motifs of equally spaced details that remain static.

 

-Do the Missle and Ball objects have an origin point like the top left corner that when you stretch them do they pull to the right of the origin point or do they expand equally left and right?

 

-Does zero work as a spacing value and if so does setting the Missle spacing value to zero then cause the Player object to have zero spacing.

 

-Can you change the width of a Missle or Ball object to different widths on the same scan line or do you have to switch to another object to achieve that.

 

Thank you Michael for your help.

 

Logan

[SeaGtGruff]

-Do the Missle and Ball objects have an origin point like the top left corner that when you stretch them do they pull to the right of the origin point or do they expand equally left and right?

 

-Does zero work as a spacing value and if so does setting the Missle spacing value to zero then cause the Player object to have zero spacing.

 

-Can you change the width of a Missle or Ball object to different widths on the same scan line or do you have to switch to another object to achieve that.

 

Thank you Michael for your help.

 

Logan

When you change the width of a player, missile, or ball, it starts at the same spot and is stretched to the right.

 

The width of a missile can be set separately from the width of its corresponding player, but the number of copies is the same for both. Players can be stretched to 1, 2, or 4 times their normal width. Missiles and the ball can be stretched to 1, 2, 4, or 8 times their normal width. They each have their own width controls.

 

If you display multiple copies of a missile on a line, all copies will have the same width. However, if you "race the beam" or time your code just right, you can change the middile's width between each of its copies, to give each copy a different width. These sorts of tricks can be very difficult to pull off in a kernel, because the timing of when to make the changes will vary depending on the positions of the missile's copies. So if the missile's position is static, you can always make the changes at the same times; but if the missile is moving, your code will need to make the changes at different times.

 

I suggest you download a copy of the "Stella Programmer's Guide." I recommend the 1979 version that was reconstructed by Charles Sinnett in 1993, because it incorporates the information from the "TIA Hardware Manual," which is the section where it describes each of the TIA's registers.

 

Briefly, the TIA registers that control the numbers and sizes of the players, missiles, and ball are as follows:

 

NUSIZ0 (address $04)

NUSIZ1 (address $05) -- These two registers control the number of copies-- and spacing between the copies-- of player0 and missile0 (NUSIZ0), and of player1 and missile1 (NUSIZ1). They also control the widths of the players and missiles.

 

Bits 0-2 control the number of copies and their spacing, as well as the width of the player:

 

%000 = 1 copy, normal-width player (8 color clocks, or 1 pixel = 1 color clock wide)

%101 = 1 copy, double-width player (16 color clocks, or 1 pixel = 2 color clocks wide)

%111 = 1 copy, quadruple-width player (32 color clocks, or 1 pixel = 4 color clocks wide)

 

%001 = 2 copies, "close" spacing (16 color clocks apart), normal-width player

%010 = 2 copies, "medium" spacing (32 color clocks apart), normal-width player

%100 = 2 copies, "far" spacing (64 color clocks apart), normal-width player

(See the note below about the size of the spacings.)

 

%011 = 3 copies, "close" spacing, normal-width player

%110 = 3 copies, "medium" spacing, normal-width player

 

Note that the size of the spacings as I've listed them here are measured from the left edge (start) of a copy to the left edge (start) of the next copy, so it includes the width of the player. Another way to express the spacing is by the number of color clocks *between* each copy, or from the right edge (end) of a copy to the left edge (start) of the next copy. Expressed in that fashion, the "close" spacing is 8 color clocks (16 from start to start, minus 8 for the width of the first copy), the "medium" spacing is 24 color clocks (32 from start to start, minus 8 ), and the "far" spacing is 56 color clocks (64 from start to start, minus 8 ).

 

Unless you use special tricks that require precise timing, you can't display more than 1 copy of a double-width or quadruple-width player, and you can't display copies that have irregular spacing between them. This is due to the way the bits control each copy and the way multiple bit settings are interpreted by the TIA. Basically, you have four copies in all-- the main copy, the "near" copy, the "medium" copy, and the "far" copy. The main copy is always displayed (although you can set its graphics bit pattern to %00000000 to make it "invisible"). The other three copies are turned on or off by setting or clearing their controlling bits:

 

bit 0 of NUSIZ0 (or NUSIZ1) = the "near" or "close" copy, 16 color clocks from the start of the main copy

bit 1 of NUSIZ0 (or NUSIZ1) = the "medium" copy, 32 color clocks from the start of the main copy

bit 2 of NUSIZ0 (or NUSIZ1) = the "far" copy, 64 color clocks from the start of the main copy

 

If you turn only one of these bits on, you get two copies-- the main copy plus either the close/near copy, the medium copy, or the far copy, depending on which bit you turned on.

 

If you turn on any two of these bits, you either get three equal-spaced copies-- the main copy plus either the close/near copy and the medium copy, or the medium copy and the far copy-- or you get one double-width player. So %011 gives you three copies at the close/near spacing, and %110 gives you three copies at the medium spacing, but %101 gives you one double-width copy.

 

If you turn on all three bits, you get one quadruple-width copy.

 

The number of copies for missile0 or missile1 is determined by the number of copies for its corresponding player, but the widths of the missiles are controlled separately by bits 4-5:

 

%00xxxx = normal-width missile (1 color clock)

%01xxxx = double-width missile (2 color clocks)

%10xxxx = quadruple-width missile (4 color clocks)

%11xxxx = octuple-width missile (8 color clocks)

 

In the bit patterns shown above, x means "don't care what it's set to," since it doesn't affect the width of the missile. So if you set NUSIZ0 to, say, %00110011, you'll get three copies of player0 and three copies of missile0, where player0 is normal-width and missile0 is octuple-width.

 

CTRLPF (address $0A) -- This registers controls the width of the ball, as well as three different aspects of the playfield (whether the playfield is drawn duplicated or reflected, whether the playfield uses its own color register or the color registers for the two players, and whether the playfield is drawn in front of or behind the players and missiles). The controlling bits for the ball's width are bits 4-5, just as in NUSIZ0 and NUSIZ1:

 

%00xxxx = normal-width ball

%01xxxx = double-width ball

%10xxxx = quadruple-width ball

%11xxxx = octuple-width ball

 

Michael

Edited June 26, 2011 by SeaGtGruff

[BladeJunker]

TIA manual

 

I've downloaded a PDF of the manual you specified which looks like it can be read by a layman such as myself so that should keep me busy for a while. Do you think I should continue posting topics even if I don't grasp programming very well? I mostly came here because pixel art forums don't do Atari and I was getting tired of phony 2600 mockups that don't take into account the hardware limitations. Do you think artistic ventures are worth pursuing on the 2600 which is more popular but is underpowered compared to the 5200 and 7800? Lastly I think new games on retro hardware are needed to keep this activity alive in the long run since without fresh titles we are a snake eating ourselves forever, what do you think?

 

Logan

[SeaGtGruff]

Do you think I should continue posting topics even if I don't grasp programming very well?

Certainly! The documentation is great, but it can't/doesn't explain everything, and once in a while it may even contain a mistake or omission.

 

Do you think artistic ventures are worth pursuing on the 2600 which is more popular but is underpowered compared to the 5200 and 7800?

Yes, I do. You could substitute "artistic ventures" with "new video games" and the question would essentially be the same. Is *any* new creation worth pursuing on the 2600, which is a dead video game console from the dawn of video games, when there are much newer consoles and computers that still have marketplace shelf life and power/features light years ahead of the 2600? That's a question each would-be creator must answer for him- or herself. My answer reflects my own interests and emotions-- because, let's not kid ourselves, this sort of hobby or venture is definitely fueled by emotions. I choose to focus my time and energy on the Atari 2600 because it held-- and still holds-- a "special place" in my heart and mind (all together now, with your head tilted toward you right shoulder... "Aaaaaaahhh!"). For other people it might be the Intellivision, or the Commodore 64, or the Apple II, or whatever console/computer captivated their imagination and made them dream dreams of one day creating their own game or program or painting or musical piece on it.

 

Lastly I think new games on retro hardware are needed to keep this activity alive in the long run since without fresh titles we are a snake eating ourselves forever, what do you think?

I guess it depends on why a person got into the "retro gaming scene." Some people are into the collecting side of it-- they enjoy buying and selling and trading the games and the consoles, looking for all the "rare" games and hardware, hoping to one day acquire a true "holy grail," trying to complete their collection of games by each company, etc. I've never been into the collecting side of it-- there were plenty of very good games back in the day that I simply had no interest in buying and playing, and today I still have no desire to acquire them. I used to think I was into the programming side of it, so I could make all those games that I dreamed of making back in the day-- except I've been into this scene for several years now, and I've yet to produce a completed game of my own, so I guess that's not it, either. I think what interests me the most is the challenge of figuring out how to do things the 2600 wasn't really designed to do-- which is just about anything that isn't "Combat" or "Pong." Most (if not all) of the "tricks" were figured out long ago when the 2600 was still alive in the marketplace, but that doesn't make them any less difficult to apply to a particular idea, because you still have to "race the beam" and figure out how to make everything happen you want to happen at just the right time within 76 cycles per scan line.

 

Anyway, I think new creations are important to keeping the console "alive" in some sense, even if it's been dead in the commercial marketplace for over a decade. But even without new titles, there will still be some people who enjoy collecting all the old games, keeping their eyes peeled for rare pieces of equipment or offbeat clones, and otherwise trying to preserve the 2600 and everything related to it, either for "historical" purposes or just to satisfy some personal emotional itch.

 

Michael

[BladeJunker]

Thanks for the vote of confidence Michael I'll continue posting in the future, I've read most of your posting on fellow posters and have found them well balanced and fair. As far as "new games" versus "artistic ventures" I agree whole hardily that game play should be the primary goal of 2600 projects but if David Crane hadn't tried to push for something other than a spaceship we wouldn't have Pitfall nor the colorful games of Activision. I've never had a problem with solid simple graphics that convey the subject matter very well which your work has in spades but it does bug me when things are abstracted to a point that I can't understand what I'm looking at. I'll do my best not to get overly focused on bells & whistles but people do like them.

 

I'm afraid I will always be artistically driven as my emotional drive for the 2600 is tempered by those that make statements of pity or excuse for every single 2600 game made even for the classic titles as in "What can you expect, its an Atari game." or "This game looks bad like Atari graphics.". Much of my research in the 2600 has been working towards a guide of sorts for pixel artists on what to expect in limitations and how to convert content and game play into 2600 equivalents. As crazy as it sounds I've been trying for stronger character and narrative representations on the 2600 despite having a weak history for that.

 

Lastly I don't have a particular connection to the 2600 since I was very young when I played Atari but have fond memories of Stampede and Combat. I instead have an even distribution of interest at making games for all retro platforms including the NES, Commodore 64, ZX Spectrum, and even the 32X. I have found 2600 graphics stimulating as it reminds me a great deal of polygonal rendering for its careful balancing of limited rendering resources.

 

Anyway I'll talk to you later Michael, I have the TIA manual to read among other things that will keep me from this forum.

 

Logan.