Jump to content
42bs

Chained vs. un-chained SCBs

Recommended Posts

I find partly redrawing difficult if you use double buffering. But if only a few tiles change per game cycle then you can go for 60fps and can do w/o double buffering.
 

Share this post


Link to post
Share on other sites

In Xump I do double buffering and udate only the changed tiles: I do it with a two step update (I keep track of the previous frame changes and of the ones for the current frame).

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites

This is one of my early attempts to use chains when I started getting into Lynx.

LOTS OF THEM. More than 300 in this case. The sprites mimic C64 characters and are a mere 8x8 pixel in size.

The screen scrolls in pixel steps. Press Button A or B while moving for faster scrolling.

The map is quite large! It consists of (iirc) 96x85 tiles. Each tile is 32x32 pixel large and consists of 4x4 characters a 8x8 pixel.

The full level is 3072 x 2720 pixel large and stored as those aforementioned pointers into pointers into pointers and thus fits into those few KBs of this unpacked binary.

turrican.o

shot2.png

Edited by enthusi
  • Like 2

Share this post


Link to post
Share on other sites

Long day doing automation test debugging so my brain is melting... what would be the benefit of this approach? More modularity with the tileset  blocks? Or am i missing something?

Share this post


Link to post
Share on other sites

Size and variety are the main drivers here.

The map is 3072 x 2208. That are 420 full Lynx screens! Stored in ~30 KB.

The full map (fullscreen attachment) consists of 32x32 tiles. But WAY too many of them to store those as sprites, either (see 2nd attachment).

Those 32x32 tiles again are constructed out of 4x4 tiles with 8x8 pixel size each. And of those we only have 180 or so. THAT fits easily into memory.

Of course it is an effort to make such graphics. Those were made on C64. Only very few games really tried HARD on the Atari Lynx to max out its specs in my opinion.

This is quite common for any plattform with such limited commercial lifetime. I hope we will see in the time to come what this beast is really capable of. WITHOUT cheating by giving it more power or larger carts that it ever had.

The last shot shows the 32x32 tiles in the full screen map.

 

fullscreen.png

32x32tiles.png

8x8characters.png

 

32x32infullmap.png

 

8x8in32x32infullmap.png

Edited by enthusi
  • Like 1
  • Thanks 3

Share this post


Link to post
Share on other sites

But you are not chaining all tiles, right? Even though Suzy can clip, the x/y position should not exceed 511, else you get a notably slowdown.

 

Share this post


Link to post
Share on other sites

No, obviously not!

I only chain enough sprites to draw a fully visible screen + one 4x4 tile to the right and bottom (it is not optimized as this were really by first footsteps :).

Ideally you only draw 8 pixel into the right and bottom border, not 32 ;-)

So the screen is 192x160 or so. ~ 432 sprites or in the range of that. I wrote a routine to update all points of the sprite-chain once we move by more than 1 tile.

 

 

Share this post


Link to post
Share on other sites
Quote

the x/y position should not exceed 511

What is exactly this 511? (I love magic values and this one sure looks like one :D)

 

What actually happen if you have a sprite on x=512 ?

Also in BLL, how does that impact the use of hoff/voff ?

Share this post


Link to post
Share on other sites

Sprite drawing slows down. Maybe not the position (long time ago that I tested it). But for sure the size.

 

You can draw a sprite 300x300 and move it with hoff/voff. Suzy does the clipping and I did not see any impact.

But if the sprite exceeds the 512 (height or width) then drawing slows down.

  • Thanks 1

Share this post


Link to post
Share on other sites
29 minutes ago, enthusi said:

No, obviously not!

I only chain enough sprites to draw a fully visible screen + one 4x4 tile to the right and bottom (it is not optimized as this were really by first footsteps :).

Ideally you only draw 8 pixel into the right and bottom border, not 32 ;-)

So the screen is 192x160 or so. ~ 432 sprites or in the range of that. I wrote a routine to update all points of the sprite-chain once we move by more than 1 tile.

 

 

So pixel move with hoff/voff until the edge of the tile and then update the chain for the new set?! Wow!

  • Like 1

Share this post


Link to post
Share on other sites

Yes, exactly like that. Even that is fast enough (just for scrolling at least ;-).

8x8 really isnt well suited for Lynx but this is just a demo.

Share this post


Link to post
Share on other sites

OMG. I will re-write On Duty to work like that just to see if I get the character moves smoother. In On Duty I use 16 by 16 sprites and I do the hoff/voff in software instead of using these registers. It would be nice to see if there is some speed advantage I could gain by using linked sprites and hoff/voff.

  • Like 1

Share this post


Link to post
Share on other sites
Quote

Sprite drawing slows down. Maybe not the position (long time ago that I tested it). But for sure the size.

I support "neverending" scrolling images in the inside world and havent seen any fps drop when I go over 500 or more. So yeah that's probably the sprite size that matters :)

Share this post


Link to post
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.

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...