Jump to content
IGNORED

Scrolling with Lynx


jvaltane

Recommended Posts

I'm wondering what would be the best way to do (tile-based) scrolling with Lynx? For example something like in Ninja Gaiden 3. I believe that NG3 is tile-based, at least background looks like it is.

 

Are there any Lynx related tricks ...or should I just copy whole screen at every frame? Copying at every frame sounds crazy so it probably is not option.

Link to comment
Share on other sites

I strarted wondering about this as well, I wonder what the ideal size of the sprites are for example in a "graphic heavy" platformer with multiple layers of scrolling like pacland and shadow of the beast. It makes sense not having huge sprites but splitting up the graphics to small tiles might not make sense on the lynx's architecture either.

Edited by Turbo Laser Lynx
Link to comment
Share on other sites

You should have a linked list of SCBs which define a tilemap that is large enough to cover the entire screen plus a one tile scroll border on the top and side. The scrolling registers are really the saving grace of the hardware here, so you only have to move the sprites on the edges of the tilemap rather than repositioning every single SCB.

 

I strarted wondering about this as well, I wonder what the ideal size of the sprites are for example in a "graphic heavy" platformer with multiple layers of scrolling like pacland and shadow of the beast. It makes sense not having huge sprites but splitting up the graphics to small tiles might not make sense on the lynx's architecture either.

 

Larger tiles will get you a better fillrate since you'll generally need less SCBs to define your tilemap (so Suzy can spend more time fetching and drawing pixels rather than reading SCBs). 32x32 pixel tiles are a performant size if you can spare the memory.

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

You only have to move the sprites on the edges of the tilemap rather than repositioning every single SCB.

 

So last year I went and linked all sprites in my newest wip demo game, but moved all SCBs separately, I guess that was a misunderstanding? I thought I was super smart and also linked the player sprites and animated the player by turning on and off the palette(s).

 

When I read your post again I get the feeling that I can have a few SCBs linked for a background and only move the first one, and the others will move after? So if I want parallax scrolling I would link groups of background elements and then move only the first SCB in every group?

 

Shouldn't linking all SCBs and move them separately result in a bunch of weird movement behaviour in the game then? Sorry, it's pretty clear to me now that I don't know what the linking exactly is good for -_-;

Edited by Turbo Laser Lynx
Link to comment
Share on other sites

Thanks for clearing it up for me! I remember someone (probably Karri) write that the sprite linking also makes Suzy draw everything faster.

 

I need to read the Lynx dev-documents again and try to find some info on the offset registers. I remember reading in them a long time ago and wondering how you guys are able to translate the info there into real usable code. :-o Or is there some more documentation somewhere that I might have missed that have more specific examples about how to make use of Lynx hardware capabilities? Obviously I've learnt some stuff over the years from other Lynx enthusiast's, their code and from lx.net's tutorials, but it seems to be a difficult process and a big step to move forward from copy/paste 'hack'-programmer to REALLY understanding the hardware and programming stuff from scratch.

Link to comment
Share on other sites

Here's an example of four-way scrolling using 32x32 tiles :

post-4322-0-46625100-1510756332.png

The black rectangle is your drawing window, the top left of which is what's written to Suzy's scrolling / offset registers.

Each red square is an individual 32x32 sprite, the letters on them represent unique SCBs. There's a large border around the drawing window so we can scroll smoothly.

post-4322-0-61377100-1510756343.png

We've started scrolling right just by modifying Suzy's scrolling registers and performing the draw again. There's nothing to recalculate until...

post-4322-0-47731000-1510756352.png

...we hit the border on our right. Then we'll shift over the x-position of our left column of SCBs and assign them new textures.

 

Again, this is just one way to handle a large playfield. Whatever is best for your project's requirements is what you should use.

 

Linking all the SCBs used to draw the tile background together rather than drawing each individually will improve performance. Generally, you want to minimize the number of times Mikey has to tell Suzy to draw sprites.

 

You also want to minimize the amount of data Suzy has to fetch. In the scrolling example above all tiles are the same size, so we don't need to have Suzy reload the scaling field on each SCB. It's actually faster to draw a dummy "prefix" SCB which just sets the scaling values to $0100,$0100 before the background. If you can chain palettes that's even better.

 

  • Like 1
Link to comment
Share on other sites

It is also important to think how to read in the tiles in RAM.

 

Here is how I split up Pandaria for making WoW on Lynx :)

 

post-2099-0-09396100-1510763824.png

 

As you can see I need 4 different buffers in memory. Tile nr 1 and tile nr 5 are never in memory at the same time. Same is true for 2 and 6 and so on.

 

This is a panorama background. So you can turn around a full 360 degrees. Then you can animate your hunter and pet to run around on the scenery. Just remember to scale the hunter and pet to smaller the higher up (further away) they get in the picture.

Edited by karri
  • Like 1
Link to comment
Share on other sites

Thanks so much guys for taking time and write these tips! But actually I already knew these things (I'm sure they will still be helpful for other people reading the programming forums), the only thing I don't know is how to actually modify Suzy's scrolling registers in code or where to read about how to do it. I had a look into the Lynx dev documents "Write the horizontal pixel offset from zero to the left edge of the screen into HOFF." hmm, is it one of the SCB "parameters" I have to do something with or...? Sorry the dev docs seem a bit cryptic to me still :/

 

Of course how to do parallax scrolling in an efficient manner would be an interresting topic too, since I know there's beautiful parallax in Zaku for example :)

 

In my latest demo game I tried an approach where I had one small static blue square stretched out for the sky and one small static orange square stretched out for the ground, and then a bunch of sprites of various sizes that I pulled left with x-position in various speeds to achieve parallax. It's working ok, but started having hickups when drawing every frame and adding more and more stuff. Recalculating the z position of the player in comparison with the 'enemies' and 'things the player collects' seems to be the worst bottleneck (it was a misstake to create a game demo with z order, but I realized that way too late haha).

Edited by Turbo Laser Lynx
Link to comment
Share on other sites

It's actually faster to draw a dummy "prefix" SCB which just sets the scaling values to $0100,$0100 before the background. If you can chain palettes that's even better.

 

Actually this was news to me, thanks for the tips. I wonder what chaining the palettes imply in practice?

 

 

It is also important to think how to read in the tiles in RAM.

 

Here is how I split up Pandaria for making WoW on Lynx :)

 

attachicon.gifpandaria.png

 

As you can see I need 4 different buffers in memory. Tile nr 1 and tile nr 5 are never in memory at the same time. Same is true for 2 and 6 and so on.

 

 

This is one thing I actually had understood from the dev documents (yay) but failed to implement in my demo because I was more worried about the graphics than about perfect subdivisions :P But as said before thanks for the tips guys!

Link to comment
Share on other sites

Hello!

 

Thanks so much guys for taking time and write these tips! But actually I already knew these things (I'm sure they will still be helpful for other people reading the programming forums), the only thing I don't know is how to actually modify Suzy's scrolling registers in code or where to read about how to do it. I had a look into the Lynx dev documents "Write the horizontal pixel offset from zero to the left edge of the screen into HOFF." hmm, is it one of the SCB "parameters" I have to do something with or...?

No, HOFF and VOFF are registers of the chip, you can set them at any time.

 

On my Lynbx-page you can find the sources for two small C-programs demonstrating the usage of both offset registers and a SCB-chain to implement a scrolling playfield:

 

http://www.mdgames.de/lynx_eng.htm#SPRDEMO4

 

Kind regards

Matthias

  • Like 1
Link to comment
Share on other sites

  • 11 months later...

Hi guys! I'm planning a new game that would perhaps have a little bit of scrolling where I would try to keep the number of sprites/things going on on the screen to a "reasonable minimum", so I'm not trying to push the Lynx to its limits in terms of a million sprites or high-speed graphics. I wouldn't want too much slowdown though when a few things are moving on the screen.

 

I've read a few posts about 32 pixels wide tiles and/or columns being a performant size on the Lynx. But does it matter much if I would have columns instead of tiles or if the columns would be slightly wider, say 60 pixels wide for three columns with 10 pixel scrolling room in both directions?

 

I guess it helps to have "smartly" sized graphics anyway, allthough I don't know any fancy low level tricks how to make the absolute most of it?

 

A few quotes:

So actually, I would dare imagine that the optimal horizontal scroller would do something like keep a set of pre-rendered columns, e.g. each of 32 pixels wide to contain four or two columns of your source tile map.

 

 

You should have a linked list of SCBs which define a tilemap that is large enough to cover the entire screen plus a one tile scroll border on the top and side. The scrolling registers are really the saving grace of the hardware here, so you only have to move the sprites on the edges of the tilemap rather than repositioning every single SCB.

 

Larger tiles will get you a better fillrate since you'll generally need less SCBs to define your tilemap (so Suzy can spend more time fetching and drawing pixels rather than reading SCBs). 32x32 pixel tiles are a performant size if you can spare the memory.

 

 

It is also important to think how to read in the tiles in RAM.

 

Here is how I split up Pandaria for making WoW on Lynx :)

 

attachicon.gifpandaria.png

 

As you can see I need 4 different buffers in memory. Tile nr 1 and tile nr 5 are never in memory at the same time. Same is true for 2 and 6 and so on.

 

This is a panorama background. So you can turn around a full 360 degrees. Then you can animate your hunter and pet to run around on the scenery. Just remember to scale the hunter and pet to smaller the higher up (further away) they get in the picture.

Edited by Turbo Laser Lynx
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...