IntyColor error -more than 64 defined cards in color block x,y

[Mik's Arcade]

Sigh...I feel like I take one step forward and two steps back.

 

 

8 hours ago, nanochess said:

In fact you can create sprites using Paint .Net in a strip of (let us say) 256x16 pixels.

 

And then convert this to BITMAP statements by means of IntyColor options -d -b -i2

 

These options instruct IntyColor to process the bitmap in chunks of 16 pixels high (the way the Intellivision handles 16-pixel high sprites).

 

I tend to draw the sprites in white and keep the background black.

 

For muticolor sprites you need to do it manually. Still you can use Paint.net but then separate the two color sprite in two separate sprites with a single color each.

 

This is a good idea.  Now that I know I have to overlay each colored part, I could make them this way.

 

 

But, I don't want to waste 2 sprites just to make one enemy have 2 colors.  I will only be able to put like 2 on the screen at once and they will have to take turns shooting.....that won't make the game any fun to play.  I guess I have a long way to go, there is just so much I don't understand.  I may have to stick with basic one color sprites....sacrifice quality for quantity...haha

[carlsson]

To some extent you can implement software sprites. That is a series of GRAM - either predefined or dynamically defined from ROM content - which display the same or different frames of a graphic shifted by one or more pixels. For each frame you either plot a different GRAM onto BACKTAB or redefine the same GRAM from ROM, which makes the character look like it moves. It is a fairly advanced technique, in particular if you want to move freely in all eight directions, but would let you overlay only one MOB on top of this software sprite. Also it would require special care to mix it with other background objects as it means you'd have to redefine GRAM that is a combination of two graphics. If you have nothing in the background that the sprite needs to move over, and movement is rather one directional, it could be a doable way but again you would need some code examples which might take a bit of work to understand.

[Mik's Arcade]

10 hours ago, carlsson said:

To some extent you can implement software sprites. That is a series of GRAM - either predefined or dynamically defined from ROM content - which display the same or different frames of a graphic shifted by one or more pixels. For each frame you either plot a different GRAM onto BACKTAB or redefine the same GRAM from ROM, which makes the character look like it moves. It is a fairly advanced technique, in particular if you want to move freely in all eight directions, but would let you overlay only one MOB on top of this software sprite. Also it would require special care to mix it with other background objects as it means you'd have to redefine GRAM that is a combination of two graphics. If you have nothing in the background that the sprite needs to move over, and movement is rather one directional, it could be a doable way but again you would need some code examples which might take a bit of work to understand.

as always, thanks for your input.

 

At this point, I think i need to keep it simple.  I want to complete a game from start to finish and then I will work on stepping up my game.  I'm sure there are plenty of advanced tricks I will pick up along the way.

 

This is the farthest I have come along on a single game not counting the stuff I entered from Oscar's books so I am going to get it done and then share it and hopefully everyone can critique it and offer shortcuts or ways to improve it. I want to be able to have up to six enemies on screen at once so I think I will just have to make them generic and one color for now.  Chapter 4.5 of Oscar's new book is required reading for this game I am making....haha.

 

 

Edited June 10, 2021 by Mik's Arcade