detailed missle sprite drawing trick, anyone?

[grafixbmp]

Is it possible to have a sprite drawing routine be created where when you come to a certain sprite and alter the width of the missle every 2 lines and THEN reposition the missle so that it stays centered like you could draw airplanes from a top down view or other air craft. Small trees or other items even with diffrent colors too. This only can give a solid object with no dicernable pixxles. Smalltest size won't work cause it can't be properly centered. I also figured out a way to use this to make fire effects (in theory) stationary fire effects to be exact. every frame it could reposition and change colors for other effects. Any thights on this? I can place an image up to illistrate.

 

PS All this would be is detailed manipualtion of the width and horizontal lication fine tunner address every 2 lines and also changing the color every 2 lines as well.

Edited December 27, 2007 by grafixbmp

[grafixbmp]

Here is just a smattering of a few examples I was thinking about. I was thinking there was a 2 bit switch for changing the width of a missle 00 01 10 or 11 . By changing location, width and the color, you can get quite a few effects and designs. If someone could design a rather simple consise piece of code to handle thoes variables, I bet several games could benifit from it. I was once remembering a few games that atleast changed the width of things for a cool effect. Mario Bros. did it for coins. I also think burger time did it too.

 

missle_graphic_tricks.bmp

[SeaGtGruff]

Assuming you won't have any lines where the missile could be off (i.e., once it's turned on, it will stay on for the full height of the sprite), you'd need something like

 

   lda missile0_width,x
  sta NUSIZ0
  lda missile0_shift,x
  sta HMM0

with an HMOVE on every line. Or a more versatile approach might be

 

   lda missile0_onoff,x
  sta ENAM0
  lda missile0_width,x
  sta NUSIZ0
  lda missile0_shift,x
  sta HMM0
  lda pm0_color,x
  sta COLUP0

Michael

[LS_Dracon]

Yes, it's possible.

The most impressive 1 bit sprite is the "dive man" from seaquest. If I'm not wrong, he is draw using "Ball" object.

The bad part is using HMOVE in every scanline, the black line in left will turn in a black colum. You can remove this line, but require some techniques.

And the sprite drawing will waste too much cicles, at least 5 for change the pixel wide + 5 for change the position + 5 for enable/disable (there a faster way, the combat trick).

Plus 5 for color change and more cicles for vertical position, if needed.

 

Basic :

 

lda Spritesize,x ;(If missile, using NUSIZ0 or NUSIZ1, if ball using CTRLPF)

sta NUMSIZ0 ;(lets use missile 0)

lda MoveLines,x ;(HMM0, HMM1, HMBL values)

sta HMM0 ;Set in missile 0

lda EnableBit,x ;Enable/disable lines)

sta ENAM0 ; Set in missile 0

 

 

X or you can use Y hadle a byte table, every table change the values, ex:

 

EnableBit ;<- This set the enable/disable the missile

.byte #%00000010

.byte #%00000010

.byte #%00000000

.byte #%00000010

.byte #%00000010

.byte #%00000010

.byte #%00000010

 

you have this sprite :

 

#

#

 

#

#

#

#

 

Changing the size and position :

 

...##

...##

 

.####

....#

....#

.####

 

Edit : Michael post while I was writing this reply.

Edited December 28, 2007 by LS_Dracon

[SeaGtGruff]

The missile on/off data could be combined with the shift data, since ENAM0 uses only bit 1 and HMM0 uses only bits 4-7. The missile size data would also affect the number and size of the corresponding player (0 or 1), and of course the color change would affect both the player and the missile. This is basically the same as what I posted before, except the names of the tables have been changed:

 

   lda enam0_hmm0_data,x  ; 4+
  sta ENAM0  ; 3
  sta HMM0  ; 3
  lda nusiz0_data,x  ; 4+
  sta NUSIZ0  ; 3
  lda colup0_data,x  ; 4+
  sta COLUP0  ; 3

Assuming you aren't using indirect,y addressing, the quickest routine would take 14 cycles (no changes to ENAM0 or COLUP0), and the more complete routine would take 24 cycles.

 

Michael

[grafixbmp]

Well, when it comes to saving cycles what could be done for maximum speed? considering that rom size isn't the issue that it use to be, can it be faster to load register values to the TIA by directly writing them instead of loading them from tables and then writing them. That way when you know you need the graphic at a certain vertical and horizontal position, then just call up the entire graphic as a subroutine that is writen just to draw it the way you want it without having to load from rom or ram just direct writes?

 

I was also thinking this may be easier if it only changes things every 2 scanlines allowing the code to be spread out allowing for other things. and when it comes to priorities, giving the player graphics color priority.

Edited December 28, 2007 by grafixbmp

[SeaGtGruff]

Well, when it comes to saving cycles what could be done for maximum speed? considering that rom size isn't the issue that it use to be, can it be faster to load register values to the TIA by directly writing them instead of loading them from tables and then writing them. That way when you know you need the graphic at a certain vertical and horizontal position, then just call up the entire graphic as a subroutine that is writen just to draw it the way you want it without having to load from rom or ram just direct writes?

 

I was also thinking this may be easier if it only changes things every 2 scanlines allowing the code to be spread out allowing for other things. and when it comes to priorities, giving the player graphics color priority.

Yes, both of those would help save cycles. The fastest load/store commands are

 

   lda #value  ; 2
  sta register  ; 3

which take a total of 5 cycles to load and store one register. There are at least three ways you could do that:

 

(1) Have the instructions for the necessary number of scan lines to draw the missile shape prewritten in ROM, with the data embedded in the immediate load instructions for each of those scan lines. You could use a generic scan line routine for the lines that don't have the missile shape on them, branch to the special "unrolled" scan line routine when it's time to draw the missile shape, and then branch back to the generic scan line routine after the missile shape has been drawn.

 

(2) Place the special missile-drawing scan line routine in RAM. The advantage of doing this, as opposed to putting it in ROM, is that you could change the embedded data as needed, presumably during the vertical blank period between frames. If you put the special routine in zero-page RAM, then there would be a limited amount of RAM space for it. But if you use a cartridge format that has a large enough amount of expansion RAM-- e.g., the 4A50 bankswitching format, which has 32K of extra RAM-- then you could "unroll" the entire display kernel in RAM, embed all of the display data in it, and update the display data as needed between each frame. I'm not sure about the availability of 4A50 cartridges, though.

 

(3) Use the Chimera cartridge, and have it "automatically" plug the display data into the scan line drawing routine. Again, I'm not sure of the availability of Chimera cartridges. Also, I presume that the scan line drawing routine would need to be in RAM, so the Chimera's ARM processor can modify the RAM locations where the load instructions occur, but I'm not sure.

 

For the time being, the first option-- putting one or more special scan line drawing routines in ROM-- would probably be the way to go.

 

Michael

[TROGDOR]

Labyrinth makes heavy use of missile graphics to draw the swords. The kernel performs an HMOVE and resize on every line that the sword is drawn, using a 2LK with half vertical resolution. Since the width can vary from 1 to 8 pixels, the sword can rotate 360 degrees to nice effect.

 

In Coastal Chaos, I did a lot of experimentation with using a repositioned and resized Ball graphic to make the cannonball appear round. During this work I discovered the same tip that Michael suggested, using one byte to define both the ENABL and HMBL values. After getting it to work, I decided it wasn't worth it. (I never published the round ball version.) It just uses up too many cycles for what you get out of it. I'd rather figure out tricks to reuse the more versatile player graphics, which would consume similar amounts of kernel time, but provide better graphic effects.

[vdub_bobby]

Yeah, using the missile in this way is very heavy on CPU time for not a lot of payoff.

 

But if you want...another trick:

 

Use the unused bit in color data:

   lda (ColorData),Y
  sta COLUP0
  asl
  sta ENAM0

That's good for using a missile as an extra pixel on a sprite. See the very old Prince of Persia thread for examples of this. Both TJ and I used this to draw the sword of the protagonist in some demos we wrote. Looks pretty impressive.

Edited January 4, 2008 by vdub_bobby

[+SpiceWare]

M Network games used missiles as sprites. Check out Lock 'N' Chase and Dark Cavern.

 

That's a slick trick for a 9-pixel sprite - I'll have to remember that.

[vdub_bobby]

I've been thinking about this for a game lately, and here's a routine:

   lda (),Y
  sta HMM0
  sta ENAM0
  asl
  asl
  sta NUSIZ0

Where the data is of this form (binary): %XXXXYYZ0

XXXX is HMxx value

Z is ENAxx value

the whole thing shifted left twice becomes:

%XXYYZ000

So you can slam it into NUSIZx (or CTRLPF) and change the width of the missile/ball without affecting the width/duplication of the player or the other properties of the playfield. Plus it's all in one byte.

 

Still takes a ton of cycles, of course.

Edited January 11, 2008 by vdub_bobby

[grafixbmp]

now see, this is what I like. Everyone is figureing out how to narrow this task down bit by bit so that it could become more feasable dow the road. Some were talking about using the missle as an extra pixel in a regular player but this only makes the graphic more detailed and gives you a separate place for collision detection. making the missle a sprite unto it's own self, gives you an extra player with some detail. As in Lock 'n' chase and dark caverns, which are nice by the way, I figured some could pull the code out and see how they do it then see if it could be shaved down even more.

remember that when repositioning the offset register that the ratios are always fixed for your graphic so these will never change. THe can be direct loaded as immediate writeseach or every other scan line for this expanded missle graphic for this subroutine or unrolled scanline. It bight be cool to save the most on cycles to knock out the settings for both missle graphics in one go so you get twice as much with less cycles lost allowing player graphics color priority. and with the nice code in the post above, not affecting player width but missle only.

[vdub_bobby]

remember that when repositioning the offset register that the ratios are always fixed for your graphic so these will never change.

They might change if the sprite's shape changes.

THe can be direct loaded as immediate writeseach or every other scan line for this expanded missle graphic for this subroutine or unrolled scanline.

Well, sure - the code snippet above is a general case, assuming that the missile-sprite can move vertically and that you are using the scanline counter (in Y) as an index into the data tables. You'd want to write specific code for whatever your kernel required.

[SeaGtGruff]

I've been thinking about this for a game lately, and here's a routine:

   lda (),Y
  sta HMM0
  sta ENAM0
  asl
  asl
  sta NUSIZ0

Where the data is of this form (binary): %XXXXYYZ0

XXXX is HMxx value

Z is ENAxx value

the whole thing shifted left twice becomes:

%XXYYZ000

So you can slam it into NUSIZx (or CTRLPF) and change the width of the missile/ball without affecting the width/duplication of the player or the other properties of the playfield. Plus it's all in one byte.

 

Still takes a ton of cycles, of course.

Nope, that *will* affect the width/duplication of the player.

 

As long as you want only one copy, normal width, of the player, then you're hunky dory.

 

But if you want multiple copies of the player/missile, or a double- or quadruple-width player, then you should ORA the shifted value from above with the other value you want to use for the player copies/width.

 

Of course, the copies will affect both the player and the missile at the same time, so unless you do some fancy mid-line GRPx or ENAMx clearing to prevent multiple copies of the player or missile while still having multiple copies of the other, then you'll have to live with the same number of copies of the player and missile on those scan lines.

 

On the other hand, you could conceivably display 12 sprites per scan line-- 3 copies of player0, 3 "sculpted" copies of missile0, 3 copies of player1, and 3 "sculpted" copies of missile1.

 

Michael

[vdub_bobby]

Nope, that *will* affect the width/duplication of the player.

Ah...of course, you're right.

[grafixbmp]

I've been thinking about this for a game lately, and here's a routine:

   lda (),Y
  sta HMM0
  sta ENAM0
  asl
  asl
  sta NUSIZ0

Where the data is of this form (binary): %XXXXYYZ0

XXXX is HMxx value

Z is ENAxx value

the whole thing shifted left twice becomes:

%XXYYZ000

So you can slam it into NUSIZx (or CTRLPF) and change the width of the missile/ball without affecting the width/duplication of the player or the other properties of the playfield. Plus it's all in one byte.

 

Still takes a ton of cycles, of course.

 

On the other hand, you could conceivably display 12 sprites per scan line-- 3 copies of player0, 3 "sculpted" copies of missile0, 3 copies of player1, and 3 "sculpted" copies of missile1.

 

Michael

you may actualy have something there. I wonder about some new variation onthe old space invaders type game. It would be rather cool to have a tech demo display concievably like 8 x 12 sprites on the screen at once or more, just for show. who knows, with some tweaks and less elaborate layout, a nice little game might come out of it.

[vdub_bobby]

you may actualy have something there. I wonder about some new variation onthe old space invaders type game. It would be rather cool to have a tech demo display concievably like 8 x 12 sprites on the screen at once or more, just for show. who knows, with some tweaks and less elaborate layout, a nice little game might come out of it.

That's an interesting idea - about 5-7 years ago, when the [stella] list was where most of the 2600 programming action was, there was a lot of work done on making a better SI or, more generally, getting lots of aliens in a row across the screen. I don't remember, from my somewhat random reading of the archives, whether this technique was ever considered and/or developed.

 

You can see some of the fruit of the other techniques they came up with in Space Instigators and INV+ and in many demos floating around. The main problems that I see with the missile-technique are figuring out alien shapes that work, and the spacing - at the closest spacing, 12 aliens across wouldn't fit on the screen! To get them closer you'd have to interleave them and use narrower bitmaps for spacers.

 

A cool idea, though.

[grafixbmp]

you may actualy have something there. I wonder about some new variation onthe old space invaders type game. It would be rather cool to have a tech demo display concievably like 8 x 12 sprites on the screen at once or more, just for show. who knows, with some tweaks and less elaborate layout, a nice little game might come out of it.

That's an interesting idea - about 5-7 years ago, when the [stella] list was where most of the 2600 programming action was, there was a lot of work done on making a better SI or, more generally, getting lots of aliens in a row across the screen. I don't remember, from my somewhat random reading of the archives, whether this technique was ever considered and/or developed.

 

You can see some of the fruit of the other techniques they came up with in Space Instigators and INV+ and in many demos floating around. The main problems that I see with the missile-technique are figuring out alien shapes that work, and the spacing - at the closest spacing, 12 aliens across wouldn't fit on the screen! To get them closer you'd have to interleave them and use narrower bitmaps for spacers.

 

A cool idea, though.

 

Why not just do 9 of them. 3 player 0 3 player 1 and 3 of missle 0. besides, this will allow for the code to fit better. more room for the detailed missle code. I could come up with some ship designs that would be doable.but remember, that in order to save cycles for the missle, it must be a dedicated scanline routine. that does not load then store. but only stores an immediate value which is just a matter of calling up the routine based on a condition.move ment would have to be done ndependantly for each leg of the missle since each part would be repositioned any way due to the design of the invader.

[supercat]

Why not just do 9 of them. 3 player 0 3 player 1 and 3 of missle 0. besides, this will allow for the code to fit better. more room for the detailed missle code.

 

For a grid-marching aliens game, I would suggest the multi-RESP trick is probably the way to go, combined with Venetian blinds. That would allow for aliens every eighteen pixels on each line, or every nine pixels in each line pair. Getting a full grid of eleven across should be no problem under such a scenario.

 

Allowing aliens to get near the left side of the screen would be a bit tricky, but there are ways of doing it. People will soon be seeing a multi-RESPx demo which shows eight 15-pixel wide letters across, all hires sprites, with sprites much closer to the left than would be typical.

[vdub_bobby]

Why not just do 9 of them. 3 player 0 3 player 1 and 3 of missle 0. besides, this will allow for the code to fit better. more room for the detailed missle code. I could come up with some ship designs that would be doable.

I tend to think that having that much space (8 pixels) between columns of aliens is a little too much, but maybe not. I'd like to see your ship designs, though. If you or somebody posts some good ones I could probably be persuaded to whip up a quick demo.

but remember, that in order to save cycles for the missle, it must be a dedicated scanline routine. that does not load then store. but only stores an immediate value which is just a matter of calling up the routine based on a condition.

You can't store an immediate value, you can only load an immediate value. And you can't store anything until you first load it into one of the 6502's registers. But really, if all you are doing is drawing sprites and missiles you have plenty of time, no need for anything fancy. You need something like 25 cycles to draw with the missiles and about 25 cycles to draw the players - that still leaves ~25 cycles on each line for whatever else you want to do.

For a grid-marching aliens game, I would suggest the multi-RESP trick is probably the way to go, combined with Venetian blinds. That would allow for aliens every eighteen pixels on each line, or every nine pixels in each line pair. Getting a full grid of eleven across should be no problem under such a scenario.

Doesn't Space Instigators use the multi-RESP trick to get 9 aliens across? 11 across would be cool but the flicker kinda takes away a lot of the coolness - if you are going to flicker, might as well use the Stellar Track method and get 12 across. At that point the only real advantage of the multi-RESP trick is getting a better spacing of your aliens, and I have to think that is mitigated to some extent by the overhead necessary for the multi-RESP trick and the difficulties in positioning.

Allowing aliens to get near the left side of the screen would be a bit tricky, but there are ways of doing it. People will soon be seeing a multi-RESPx demo which shows eight 15-pixel wide letters across, all hires sprites, with sprites much closer to the left than would be typical.

I wonder what this could be...

Edited January 15, 2008 by vdub_bobby

[grafixbmp]

Why not just do 9 of them. 3 player 0 3 player 1 and 3 of missle 0. besides, this will allow for the code to fit better. more room for the detailed missle code. I could come up with some ship designs that would be doable.

I tend to think that having that much space (8 pixels) between columns of aliens is a little too much, but maybe not. I'd like to see your ship designs, though. If you or somebody posts some good ones I could probably be persuaded to whip up a quick demo.

but remember, that in order to save cycles for the missle, it must be a dedicated scanline routine. that does not load then store. but only stores an immediate value which is just a matter of calling up the routine based on a condition.

You can't store an immediate value, you can only load an immediate value. And you can't store anything until you first load it into one of the 6502's registers. But really, if all you are doing is drawing sprites and missiles you have plenty of time, no need for anything fancy. You need something like 25 cycles to draw with the missiles and about 25 cycles to draw the players - that still leaves ~25 cycles on each line for whatever else you want to do.

For a grid-marching aliens game, I would suggest the multi-RESP trick is probably the way to go, combined with Venetian blinds. That would allow for aliens every eighteen pixels on each line, or every nine pixels in each line pair. Getting a full grid of eleven across should be no problem under such a scenario.

Doesn't Space Instigators use the multi-RESP trick to get 9 aliens across? 11 across would be cool but the flicker kinda takes away a lot of the coolness - if you are going to flicker, might as well use the Stellar Track method and get 12 across. At that point the only real advantage of the multi-RESP trick is getting a better spacing of your aliens, and I have to think that is mitigated to some extent by the overhead necessary for the multi-RESP trick and the difficulties in positioning.

Allowing aliens to get near the left side of the screen would be a bit tricky, but there are ways of doing it. People will soon be seeing a multi-RESPx demo which shows eight 15-pixel wide letters across, all hires sprites, with sprites much closer to the left than would be typical.

I wonder what this could be...

 

Here are 4 designs in diffrent colors. The one thing that will need to be doneafter the sprites but before the missles will ned to be increasing the width of the missles. If you can do anything with these, that would be awesome.

invaders_2600.bmp

[grafixbmp]

You can't store an immediate value, you can only load an immediate value. And you can't store anything until you first load it into one of the 6502's registers. But really, if all you are doing is drawing sprites and missiles you have plenty of time, no need for anything fancy. You need something like 25 cycles to draw with the missiles and about 25 cycles to draw the players - that still leaves ~25 cycles on each line for whatever else you want to do.

 

I thought when sending data to the TIA, you normaly load a byte from the ram or rom and then send it to the TIA. that takes a load and then write to the TIA based upon the current place you are in the code.

 

But why cant you just have code that says I want to put This number strait into a TIA register without having to put it into the A register first ? Is there no way to change values in the TIA by using the code you write itself to send it?

 

So is it, nothing gets to the TIA unless it comes from one of 3 registers in the 6802 and not fromthe code the 6802 is executing?

[supercat]

But why cant you just have code that says I want to put This number strait into a TIA register without having to put it into the A register first ? Is there no way to change values in the TIA by using the code you write itself to send it?

 

So is it, nothing gets to the TIA unless it comes from one of 3 registers in the 6802 and not fromthe code the 6802 is executing?

 

It would be nice if the 6507 has a "store immediate" instruction which would load the first operand into a temp address buffer, load the second operand into the ALU latch, and store the ALU data to the address in the temp address buffer. Such an instruction could store an immediate value in 4 cycles. Unfortunately, no such instruction exists.

 

It is, however, possible to store certain values to TIA registers without disturbing any 6507 registers. An "INC", "DEC", shift, or rotate instruction will read an address, write back the original value while modifying it internally, and then write the modified value. Reads of TIA registers will return in the bottom 6 bits the last thing that was on the data bus.

[grafixbmp]

I was thinging if maybe one of the index registers could be sent to the TIA and it was just like say the x was INX or DEX depending of the values you needed during the duration of the missle graphic. then when it is needed, it is already set up with the value needed then it is just sent strait to the TIA. like IN/DE the index register in the Hblank before you even start then when the last player sprite is drawn, write that register to the TIA where it is needed and then after it is done reset the tia for the players again and load the next value into the index for the next pass.

 

This was just a passing thought. There is probably a better way to do it.

 

I just thought it may not be the amount of clock cycles it takes up, but the order that the commands are placed that makes it possible.

[supercat]

Doesn't Space Instigators use the multi-RESP trick to get 9 aliens across? 11 across would be cool but the flicker kinda takes away a lot of the coolness - if you are going to flicker, might as well use the Stellar Track method and get 12 across.

 

I was thinking of non-flickering Venetian Blinds. A Stella-Track-style kernel could do that, too, but I think 9 or 12 pixel spacing would be better than 8 (thinking about it, 12 is most likely better than 9).