How big can you make a sprite?

[STGuy1040]

If I wanted to use a single sprite, with colors, how big can I make it? I tried making large sprites in bBatari Basic but only parts of them display.

[Impaler_26]

You can make a sprite 8 pixels wide and (nearly) as high as you want. Are you using Visual bB?

[STGuy1040]

You can make a sprite 8 pixels wide and (nearly) as high as you want. Are you using Visual bB?

 

Yes, I am, I was half asleep when I wrote that. lol I meant to say Visual bBasic.

[+Random Terrain]

Say you want to make a large character for your game that is made of two sprites. Instead of working on 2 separate sprites and trying to picture how they would look next to each other, you can make a wider sprite using the editor, draw your big sprite, then highlight half of it, copy it, open a new editor, then paste it. Do the same for the other half and be sure to keep your huge sprite in case you ever want to work on it some more.

[jrok]

If I understand you correctly, you're asking how "wide" a sprite can be? The quick answer is that each of the hardware sprites can be 8 pixels wide (no limit on height).

 

If you are using Visual bB's nifty sprite editor, you probably noticed that the editor allows you to set the width anywhere from 1-24 px. But this is really only for "planning" purposes, since the max hardware resolution is 8 px. Using NUSIZ0 or NUSIZ1 to make the sprite double or quadruple wide will "stretch" the image (pixels are rendered at 2x or 4x wide), but won't allow for a higher resolution.

 

If you want to create the illusion of a higher-res sprite with bB, AFAIK you have to do one of the following:

 

1) Use both the player0 and player1 sprites to create each half of the image. You can then line the sprites up on the same vertical position, and have them move together, i.e.

 

   player1x = player0x + 8 : player1y = player0y

 

2) Same as above, except use 30hz flicker, so that on the even frames a player sprite displays the left half of the "big sprite" and on odd frames it displays the right half. i.e.

 

frame1
  player0x = x
  gosub ShowLeftSide
  goto frame2

frame2
  player0x = x + 8
  gosub ShowRightSide
  goto frame1

 

The second method is *probably* preferably for in-game graphics, since method one would use up both sprite objects and leave you with just the ball if you are using multicolor sprites. I've been experimenting with some higher res graphics over at Homebrew Discussion if you want to check it out. Its basically "method 1" but if I was going to make a game out of it, I'd probably convert it to method two.

 

Cheers,

Jarod.

Edited February 3, 2009 by jrok

[MausGames]

Actually, I think what he was asking has to do with the vbB sprite editor, but I'm not sure...could you be less obscure in what you are asking here STGuy?

[STGuy1040]

Actually, I think what he was asking has to do with the vbB sprite editor, but I'm not sure...could you be less obscure in what you are asking here STGuy?

\

 

 

Yes, sorry; I was wondering what the maximum sprite size was for the bBasic sprite editor because I find it a bit confusing. My reason being; when using bBasic, it allows you to expand the sprite grid far beyond what the 2600 can display (from what I have found) but jrok pretty much answers the question by stating that each sprite can be 8 pixels wide and no limit on height, so it looks like bBasic gives more room for planning (like someone previously said) and I didn't realize this.

Edited February 3, 2009 by STGuy1040

[MausGames]

Well obviously there is a finite height for the sprites, my guess it is either 256 pixels, or if there is no limit then the maximum size would be 4k worth, which would be pretty long

[MausGames]

dp

Edited February 4, 2009 by MausGames

[+Random Terrain]

Well obviously there is a finite height for the sprites, my guess it is either 256 pixels, or if there is no limit then the maximum size would be 4k worth, which would be pretty long

Yep, there seems to be a 256 height limit. I found that out when I was working on Tone Toy 2008.

[CurtisP]

In bB, the height of a sprite is stored in a single byte, so the largest height would be 255. This is far higher than what would actually get displayed on screen though, since the default playfield height is 88 lines and maximum would be about 120 lines.

 

 

Well obviously there is a finite height for the sprites, my guess it is either 256 pixels, or if there is no limit then the maximum size would be 4k worth, which would be pretty long

Yep, there seems to be a 256 height limit. I found that out when I was working on Tone Toy 2008.

[freshbrood]

Does changing the default playfield block sizes, or overall screen size use up much more memory?

 

For example: If I want to squeeze every last single little bit out of my game, and ONLY make as many different unique sprites from player0 and player1 as possible, would using the default playfield size (88?) yield me more memory space?

 

Can I squeeze a bit more space by making the playfield size smaller? Is playfield size and playfield pixels/blocks the same thing?

 

And finally, I understand that using the multicolor player kernel causes the loss of the missile. Can this be toggled on and off? For example: a 6 colored player that becomes one solid color while firing a missile, then when the missile disappears, becomes 6 colors again?

 

If player graphics are always stored in the last bank (when using multiple banks), then couldn't you put a "player colors off/missiles on" sort of kernel in a different bank than the first kernel that causes the loss of the missile?

[+Random Terrain]

And finally, I understand that using the multicolor player kernel causes the loss of the missile. Can this be toggled on and off? For example: a 6 colored player that becomes one solid color while firing a missile, then when the missile disappears, becomes 6 colors again?

This is all I know about using the missiles when they are lost:

 

atariage.com/forums/topic/250879-can-a-tall-rectangular-sprite-be-made-of-copies-of-one-row/?p=3479250

 

Somebody else will have to answer the other questions.

[freshbrood]

I'm having trouble making a sprite higher than 35 lines. I'm using the set kernel_options player1colors playercolor pfcolors And for some odd reason, it will fail to compile when I draw a sprite higher than 35 lines. Is this a known issue? What am I doing wrong? It's even less when I try to add colors- it just won't compile unless I lower the number.

 

 

 

 

 

 

 

Also, if anyone cares to help, I am still quite lost over using pfres. When I do, I either get giant blocks, or small squares in no discernable order. I cannot draw a decent looking playfield using pfres. A simple sample tutorial or .bas would be much appreciated.

Edited July 26, 2018 by freshbrood

[+Gemintronic]

I'm having trouble making a sprite higher than 35 lines. I'm using the set kernel_options player1colors playercolor pfcolors And for some odd reason, it will fail to compile when I draw a sprite higher than 35 lines. Is this a known issue? What am I doing wrong? It's even less when I try to add colors- it just won't compile unless I lower the number.

 

 

 

 

 

 

 

Also, if anyone cares to help, I am still quite lost over using pfres. When I do, I either get giant blocks, or small squares in no discernable order. I cannot draw a decent looking playfield using pfres. A simple sample tutorial or .bas would be much appreciated.

 

I'd double check Random Terrains kernel options chart.

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

Looks like you forgot an "s" in playercolors

 

This works fine for me with two 36 pixel tall sprites.

tallsprite.bas