Sharing what I've noticed

You may or may not know these things, but I want to get these out just in case some of you don't know yet. #1: All of the graphic screens are 512x512. This means you could buffer the top or bottom screens (assuming you're not in XSCREEN 4) just hidden underneath the screen without changing the graphics screen! #2: Don't let the nice RGB() function make you assume that you get full 0-255 color resolution. You actually get an equivalent of 0-31 in R, G, and B. I suggest dithering by adding +RND(8) to each color component in RGB() to reduce the appearance of color banding. #3: If you want to, you can easily exploit the cross GRP BG system to allow you to essentially let you see an up to 512x512 GRP screen that can be easily shifted, scaled and even rotated with a single command each. This is the code I would use.

GPAGE 0,5
BGSCREEN 0,32,32
FOR Y=0 TO 31
FOR X=0 TO 31
BGPUT 0,X,Y,1024+X+(Y*32)
NEXT
NEXT
GCLS 0

'The "1024+" is a quick way around the first 16x16 pixels being hidden. Now, using graphics commands as normal will look normal, but now you can manipulate the display with the BG commands like BGOFS, BGSCALE, and BGROT. I'm way too excited for this. It seems great for image manipulator programs.

BG tile 0 is always invisible so that exact 8x8 space can't be used. Use the sprite page instead.

BG tile 0 is always invisible so that exact 8x8 space can't be used. Use the sprite page instead.

It worked in my test. It's invisible for 0, but after 1024, it wraps around and 1024, the first 16x16 pixels, are visible. Try it.

BG tile 0 is always invisible so that exact 8x8 space can't be used. Use the sprite page instead.

It worked in my test. It's invisible for 0, but after 1024, it wraps around and 1024, the first 16x16 pixels, are visible. Try it.

I almost forgot. The first 16x16 pixels on the GRP5 screen are blank by default, so if you look at BG 1024, it will be blank. Fill it before testing it.

yeah, I filled it and it was blank. maybe 1024 will show up?

I just realized it's easier to use SPPAGE and SPDEF to make a large sprite that shows a part of the graphics screen too. It's easier and works a bit better.

Why do BG tiles loop 4 times? 0-1023 1024-2047 2048-3071 3072-4095 I just can't figure out a reason.

Why do BG tiles loop 4 times? 0-1023 1024-2047 2048-3071 3072-4095 I just can't figure out a reason.

Probably because they didn't have time to make over 4000 BG tiles, so they created 1000 and just looped them. SmileBASIC may have room for over 4000 bg tiles, and to show you this, they loop the bg tiles.

That doesn't make any sense, unless they intend to add more room in a future update. Oh - perhaps they will for the Wii U version!

Sorry for double-post, I just noticed something. OP says:

#1: All of the graphic screens are 512x512.

But the official reference says:

Coordinates of which to get the color (X: 0-399, Y: 0-239)

It's possible (probable, even!) that the reference is outdated, and at some point in development they had the GRP screen the same resolution as the screen - just like it was in PTC. Can you just confirm please? The reference guide is sub-par sometimes. PS: what the HELL does GSPOIT stand for? This has bugged me since Petit Computer.

Quick check. SPANGLE, SPCOLVEC, TALKCHK() and SENDFILE are just 4 examples of longer function names. That's not it.

Quick check. SPANGLE, SPCOLVEC, TALKCHK() and SENDFILE are just 4 examples of longer function names. That's not it.

He may mean functions with parenthesis like THIS() back in Petit Computer. I don't believe TALKCHK() was in PTC.

I took it straight out of the PTC manual PDF ;) Edit: more long PTC () functions, just for you:

BGMGETV
CHRREAD
COLREAD
SPHITRC
SPHITSP
TALKCHK

what the HELL does GSPOIT stand for? This has bugged me since Petit Computer.

GSPOIT is supposedly some corrupt English term Japan uses for color pickers. It came about as an incorrect translation from a language that isn't even English IIRC (Danish or something for "needle point"? don't remember).

That doesn't make any sense, unless they intend to add more room in a future update. Oh - perhaps they will for the Wii U version!

3.3.0 update will allow you to use an 8x8 tile mode on the BG layer (and a 32x32 tile mode). These extra bits afford just enough room. They also allowed the bitfield to be more symmetrical to PTC's I think?

Oh, I see. If they knew in advance that they would do this, I wonder why they didn't do it before launch.

They didn't, they're adding it for Namco DLC (which we won't get) compatibility.

They left the 2-bit headroom in advance.