Jump to content
IGNORED

Some questions regarding PLOTSPRITE4 in 7800Basic


Recommended Posts

Posted (edited)

I'm working on a project that might do 4-way scrolling.  I'm doing it the dumbest way possible, by drawing a tons of sprites tiles DLLs, one for each tile on screen.

 

I can fit around 40ish 32 wide x 16 tall tiles, plus blackout boundaries, and squeak by using PLOTSPRITE4.  Unfortunatey, I have an odd behavior where it seems to misalign the graphic from the block.

 

image.png.c399f3839a115106fbb815a3126483fc.png

The black squares and blocks of brown and yellow should be other numbers, but instead are draw in farther places on the graphics block. Typically I add in one sprite that's the size I want with incgraphic, then an "atlas" of the rest that size, so I can call them using the frame parameter of plotsprite/PLOTSPRITE4:

 

incgraphic gfx/atlas_firstSprite.png 0 1 2 3 ;i.e. the 32x16 pixel tile "0"
incgraphic gfx/atlas_sprites.png 0 1 2 3 ; the rest in a 244x16 png.

 

it's worked great for many games, and seems to work pretty well, at least at first, using PLOTSPRITE4.  Above 4 or so, it won't draw 5, 6 or 7 but seem to take pixels from later on in the graphics block (I'm trying to figure out if there's a systme to the error in pixels...)

 

I will say that the normal plotsprite seems to draw them as expected (although slower, of course), but when switching to PLOTSPRITE4 the upper end of the tiles (anything above "4") gets shifted over a few columns.

 

pseudocode is basically this:

for x = 0 to 5
for y = 0 to 8

tile = (calculate tile using a function)

;(multiply x and y values based on scrolling and tile size of 32x16 pixels)

PLOTSPRITE4 x y tile

next
next

 

 

As you can see, the tiles/sprites are not tallsprites (but should be fine being 32 pixels wide, I believe).  Palettes being their power of 2 seem to work OK, but I rolled that back to make sure that wasn't the issue.

One test I did had the far right side not drawn properly, but that doesn't seem to fit into this case, which seems to draw everything, just using the wrong graphics above a certain index.

 

The index *doesn't* seem to be related to the byte limit imposed by PLOTSPRITE4 - I don't think the byte limit/numbers match up, and besides, I *think* I'm just drawing 32x16 sprites as far as the chip is concerned.

 

Any other limitations of quirks for PLOTSPRITE4 that I'm forgetting?  

 

Thanks for any help in advance!

 

Edited by Revontuli
Link to comment
Share on other sites

49 minutes ago, Revontuli said:

Palettes being their power of 2 seem to work OK, but I rolled that back to make sure that wasn't the issue.

Don't know if it's relevant but one of the quirks listed for PLOTSPRITE4 is: If you use a variable for the palette argument, the variable value must be 32 times the actual palette index you want.

 

  • Thanks 1
Link to comment
Share on other sites

45 minutes ago, playsoft said:

Don't know if it's relevant but one of the quirks listed for PLOTSPRITE4 is: If you use a variable for the palette argument, the variable value must be 32 times the actual palette index you want.

 

Yeah - that part seems to work just fine for me - I have a table of multiples of 32 so I can look up the palette quickly (the loop and performance is tight enough that it actually makes a difference).  I'm just using one palette in the screenshot above so I don't worry about it being another factor.

 

My suspicion is that there's some quick about PLOTSPRITE4 I'm missing or forgetting with regards to how it accesses the graphics block in ROM, but I'm checked all the documentation I can find, and I know it's a relatively new feature.

Link to comment
Share on other sites

Have you checked that atlas_firstSprite and atlas_sprites ended up in the same graphics block? That would not explain it working properly with normal plotsprite though.

 

I did a quick test using PLOTSPRITE4 and everything seemed to work as expected. It's not doing proper scrolling but I assume the calls will be similar to what you are doing. Attached if it's of any use.

zero.png

atlas.png

test.bas

  • Thanks 1
Link to comment
Share on other sites

That made me debug it using that tack - the math I was using in the nested loop was causing underflow (and calling sprite 254/255) so no wonder it was drawing the wrong sprite 😆

 

I'm testing to see how many sprites I can get on-screen using these newer routines, it's quite impressive!  Hopefully I'll have something to show soon.

 

Thank you for your help!

  • Like 1
Link to comment
Share on other sites

Posted (edited)
On 5/26/2024 at 10:41 AM, Revontuli said:

I'm doing it the dumbest way possible, by drawing a tons of sprites tiles DLLs, one for each tile on screen.

This is the correct way :) IMHO Indirect mode should be forbidden (except for text)

 

In your example DMA for one line has 160 Maria cycles comparing 190 cycles in Indirect mode (2char)

You can use 25 colours on screen vs 4 in indirect.

For background graphics data you can use up to 28KB vs 4KB

 

Best way is to use full dynamic DL with variable size of tiles (my engine can do tiles in 320B/C between 16 and 128 pixels width per DL entry)

Every line can has mixed size of tiles per line. For empty area I'm skipping DL entry for tiles.

 

Took me a long time to make this proc fast enough to make 320x192 screen every frame and still can have lots of sprites on the screen.

 

 

 

Edited by Eagle
  • Like 5
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...