BACKGRND ?

[fultonbot]

I don't see BACKGRND mentioned in the Atari 7800 Basic Guide.
I'm trying to figure out how ofnten it can be used to update the background color, or what needs to be done to make the background color chage.

I know this seems simple, but I can't find any info. 

[+SmittyB]

You're right, that is an odd omission. Fortunately you can just write a colour value to BACKGRND as you would on the 2600 and it will work. (You can't read the value back from BACKGRND so if you ever want your code to know what it is, it can be a good idea to store the background colour you want in a variable and then copy it when you want to).

 

As for how often it can be changed, the answer is as quickly as you can change it. The below example is the smallest loop you can have to rapidly change the background colour and the results as shown in both A7800 (first screenshot) and Bupsystem (second screenshot) with Bupsystem being the more accurate. Unless you're changing the background mid-screen you don't need to worry about the difference though.

	a=0
mainLoop
	BACKGRND=a
	a=a+1
	goto mainLoop

[CPUWIZ]

	LDX	#0
.deathLoop:
	STX	BACKGND
	INX
	JMP	.deathLoop

 

I believe that is as fast as you can go, can't remember, if CLC/BCC is faster than JMP right now.

 

EDIT: Of course you could remove the LDX #0 as well, as we don't care where the color starts.

[+SmittyB]

Well sure if you want to use assembly (which I do when I can, just because), but strictly sticking to 7800basic you get a slightly slower loop. JMP is faster at 3 cycles compared to 5/6 for CLC/BCC.

[fultonbot]

1 hour ago, SmittyB said:

You're right, that is an odd omission. Fortunately you can just write a colour value to BACKGRND as you would on the 2600 and it will work. (You can't read the value back from BACKGRND so if you ever want your code to know what it is, it can be a good idea to store the background colour you want in a variable and then copy it when you want to).

 

As for how often it can be changed, the answer is as quickly as you can change it. The below example is the smallest loop you can have to rapidly change the background colour and the results as shown in both A7800 (first screenshot) and Bupsystem (second screenshot) with Bupsystem being the more accurate. Unless you're changing the background mid-screen you don't need to worry about the difference though.

	a=0
mainLoop
	BACKGRND=a
	a=a+1
	goto mainLoop

 

 

 

Perfect, this solves it.
It does make me want to start using some in-line assembly though.

[+SmittyB]

I'll always encourage learning a bit of assembly. 7800basic creates some nicely efficient code when compiled, but with assembly you can make assumptions about your code that the compiler can't especially when doing a lot of complex mathematics.

[RevEng]

Definitely BACKGRND is an omission. Will need to update the docs.

 

One thing to note, is that a loop like that is only really warranted when you want to do 2600 style colorbars or have more than 3 different color areas in your game. It has a huge cost in terms of the cycles available to your game.

 

To change the colors 2 or 3 times mid-screen you can use the interrupts, as demonstrated in the "splitmodedemo*" samples.

[fultonbot]

2 hours ago, RevEng said:

Definitely BACKGRND is an omission. Will need to update the docs.

 

One thing to note, is that a loop like that is only really warranted when you want to do 2600 style colorbars or have more than 3 different color areas in your game. It has a huge cost in terms of the cycles available to your game.

 

To change the colors 2 or 3 times mid-screen you can use the interrupts, as demonstrated in the "splitmodedemo*" samples.

Is this a way to get more than 23 colors on the screen?
when I finally get my basic games done, I'll look at some more elaborate stuff like this.

 

[RevEng]

Changing the background color for each zone isn't presently supported. If you change the colors using the previous colorbar method, I fear you'll find the result disappointing - if there is moderate-to-heavy number of objects on the screen, the colors will sometimes be pushed a line or two down for some frames.

 

For various reasons, giving the program full access to the interrupts for color changes (which requires tight timing) means I can't use them reliably for other purposes. (visible screen flagging, scrolling, non-dma device communication, etc.)

 

[fultonbot]

5 hours ago, RevEng said:

Changing the background color for each zone isn't presently supported. If you change the colors using the previous colorbar method, I fear you'll find the result disappointing - if there is moderate-to-heavy number of objects on the screen, the colors will sometimes be pushed a line or two down for some frames.

 

For various reasons, giving the program full access to the interrupts for color changes (which requires tight timing) means I can't use them reliably for other purposes. (visible screen flagging, scrolling, non-dma device communication, etc.)

 

My goal right now is to be creative within the confines of what you have created.