IntyBASIC Drawing Blocks with Correct Color?

[First Spear]

I created an 8x8 brown block, which paints on the screen as BACKTAB fine using SCREEN. I tried to write it to the screen as #BACKTAB with a FOR, and the color is no longer brown. What kind of additional information do I need to add to get the image to write as brown?

 

Thanks.

	INCLUDE "constants.bas"
	MODE 0,0,0,0,0
	Wait
	DEFINE 0,1,Block1_bitmaps_0
	WAIT
	SCREEN Block1_cards,0,0,1,1,1
	
	For stepX = 3 to 4
		For stepY = 4 to 7
			#BACKTAB(stepY * 20 + stepX) = $3800 ' I think this is GRAM position 0
		Next
	Next
	
  
loop:
	GOTO loop


Block1_bitmaps_0:
	DATA $FFFF,$FFFF,$FFFF,$FFFF


Block1_cards:
	DATA $1803
	

[Kiwi]

    For stepX = 3 to 4
        For stepY = 4 to 7
            #BACKTAB(stepY * 20 + stepX) = $3800 ' I think this is GRAM position 0
        Next
    Next

The $3800, is CSadvance/pastel color bit on.

This is printing light gray.

to get color brown, replace $3800 with $1803.

 

Edited October 25, 2017 by Kiwi

[First Spear]

Thanks! That worked. I was trying to come up with a Procedure callable throughout my game blank out parts of the screen regardless of back color, rediscovered #BACKTAB, and here I am.

 

It would be cool (ie better for lightweights like me) if a new PRINT statement could write GROM with any foreground color on any CS background. I understand that would not be straightforward, just wishing.

[+DZ-Jay]

It would be cool (ie better for lightweights like me) if a new PRINT statement could write GROM with any foreground color on any CS background. I understand that would not be straightforward, just wishing.

I thought you could do that already? Someone with IntyBASIC experience correct me, please, but I was under the impression that you could call PRINT with escaped hex values pointing to GROM cards, no?

[+nanochess]

Thanks! That worked. I was trying to come up with a Procedure callable throughout my game blank out parts of the screen regardless of back color, rediscovered #BACKTAB, and here I am.

 

It would be cool (ie better for lightweights like me) if a new PRINT statement could write GROM with any foreground color on any CS background. I understand that would not be straightforward, just wishing.

This is already supported in IntyBASIC:

 

PRINT COLOR 7,"\33\34\35"    ' Prints ABC from GROM in color 7
PRINT COLOR 7,"\256\257\258"  ' Prints first 3 GRAM in color 7
PRINT COLOR $1007,"\256\257\258" ' Prints first 3 GRAM in color 15 (not possible with GROM)

Only the colors 0 to 7 are available for GROM usage in Color Stack mode.

[First Spear]

Yes, I understand that. I am trying to use the color Brown, which is in the high set of color numbers ($B/10). JoeZ and Nanochess explained in another thread why this is (and referred me to the Wiki), I am just wishing that IntyBASIC PRINT would do that automagic for that. Not a big complaint, I now have code to paint with GROM and do it myself, I just thought it might be helpful, thats all.

 

 

Thanks everyone!

 

 

This is already supported in IntyBASIC:

PRINT COLOR 7,"\33\34\35"    ' Prints ABC from GROM in color 7
PRINT COLOR 7,"\256\257\258"  ' Prints first 3 GRAM in color 7
PRINT COLOR $1007,"\256\257\258" ' Prints first 3 GRAM in color 15 (not possible with GROM)

Only the colors 0 to 7 are available for GROM usage in Color Stack mode.

 

[+nanochess]

Yes, I understand that. I am trying to use the color Brown, which is in the high set of color numbers ($B/10). JoeZ and Nanochess explained in another thread why this is (and referred me to the Wiki), I am just wishing that IntyBASIC PRINT would do that automagic for that. Not a big complaint, I now have code to paint with GROM and do it myself, I just thought it might be helpful, thats all.

 

 

Thanks everyone!

It isn't an IntyBASIC limitation but rather an Intellivision hardware limit.

 

In color-stack mode no GROM card can be painted with colors 8-15 because it triggers the Colored Squares mode.

[First Spear]

Yes, it is an Intellivision limitation. You and JoeZ showed that to me before. No problem.

 

Dont worry I have another question or 2 that is actually relevant.

[+DZ-Jay]

Yes, it is an Intellivision limitation. You and JoeZ showed that to me before. No problem.

 

Dont worry I have another question or 2 that is actually relevant.

 

 

I guess I am confused by the following comment:

 

I am just wishing that IntyBASIC PRINT would do that automagic for that. Not a big complaint, I now have code to paint with GROM and do it myself, I just thought it might be helpful, thats all.

 

 

 

 

It sounds as if you were under the impression that there is a work around and wished IntyBASIC could implement it. Or perhaps you meant something else?

 

-dZ.

[mmarrero]

Maybe my experimental "hi-rez" print I made a while ago can be modified to overcome GROM foreground color limitations. The demo uses all 8 MOBs to display 2 lines of 8 characters. Instead of copying all fonts from GROM to GRAM, it copies the 16 GROMs to be printed (to GRAM cards 1,3,5,7 then 2,4,6,8 because I'm using doubley sprites). The copy code is in assembly, but it's fully commented.

Spritext.bas

[+DZ-Jay]

Maybe my experimental "hi-rez" print I made a while ago can be modified to overcome GROM foreground color limitations. The demo uses all 8 MOBs to display 2 lines of 8 characters. Instead of copying all fonts from GROM to GRAM, it copies the 16 GROMs to be printed (to GRAM cards 1,3,5,7 then 2,4,6,8 because I'm using doubley sprites). The copy code is in assembly, but it's fully commented.

 

I'll tell you, if I were to use GRAM for text, I wouldn't be loading the stock GROM cards in it!

 

To me, the only reason to use GROM is to conserve GRAM space. If I must use GRAM, it's custom cards all the way, baby!

 

-dZ.

[First Spear]

Kind of related to this - how to DEFINE a range of GRAM with a single GROM shape? I want to replace GRAM locations 9-13 with the GROM 0 location in a few colors (basically "blanking out" those shapes), trying to know how to do it with code only.

 

Thanks.

[carlsson]

Since GROM doesn't change, why don't you simply replicate the GROM pattern in your program and either define those GRAM locations 5 times or even be as wasteful as duplicating the GROM pattern five times and use one DEFINE statement? Or would that not solve your question, only be a workaround for a specific case?

[intvnut]

Kind of related to this - how to DEFINE a range of GRAM with a single GROM shape? I want to replace GRAM locations 9-13 with the GROM 0 location in a few colors (basically "blanking out" those shapes), trying to know how to do it with code only.

 

Why do you need to store a blank tile in GRAM? The color limitations only apply to the foreground color, not the background color. Also, there are no colors associated with individual GRAM cards. I gather from one of the other threads, though, that you're performing some sort of animation by replacing pictures in specific GRAM cards, if I got the gist correctly, so putting a blank image on a GRAM tile could make sense.

 

In any case, GROM 0 is just a blank tile. If IntyBASIC doesn't have a cheap mechanism to blank out GRAM tiles, then your best bet is to just load raw zeros the same way you'd load any other picture. It'll likely take less ROM space than implementing a more general mechanism. (Really!) 5 tiles will take 20 words of ROM. An empty FOR loop takes ~12 words of ROM. Adding even a single statement in the FOR loop makes it about as expensive as just having the raw data.

[+nanochess]

Never thought on it, but intvnut almost suggest it directly, just put those tiles to same color as background, black probably in your case.