Jump to content

Photo

Scrolling with Lynx


15 replies to this topic

#1 jvaltane OFFLINE  

jvaltane

    Combat Commando

  • 2 posts
  • Location:Helsinki, Finland

Posted Tue Feb 9, 2016 7:50 AM

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.



#2 sage OFFLINE  

sage

    Dragonstomper

  • 803 posts
  • Location:Germany

Posted Tue Feb 9, 2016 2:17 PM

there is no hardware scrolling nor a real sprite engine (as in arcade sense).

thus you have to draw all "sprites" every frame.



#3 jvaltane OFFLINE  

jvaltane

    Combat Commando

  • Topic Starter
  • 2 posts
  • Location:Helsinki, Finland

Posted Wed Feb 10, 2016 5:42 AM

Thanks. I'll try make some test with sprites.


Edited by jvaltane, Wed Feb 10, 2016 5:43 AM.


#4 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Mon Feb 15, 2016 11:49 AM

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, Mon Feb 15, 2016 11:50 AM.


#5 TailChao OFFLINE  

TailChao

    Moonsweeper

  • 406 posts
  • Bup?
  • Location:United States

Posted Mon Feb 15, 2016 5:32 PM

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.



#6 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Tue Feb 16, 2016 2:45 PM

Hey thanks a lot for sharing this TailChao! Intressting info about the linked list and scrolling registers. I'm unsure if these features had been utilized in Karri's Lynx game template/"skeleton" I used to build my minigames on 10 years back. :?



#7 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Tue Nov 14, 2017 3:54 PM

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, Tue Nov 14, 2017 4:01 PM.


#8 sage OFFLINE  

sage

    Dragonstomper

  • 803 posts
  • Location:Germany

Posted Wed Nov 15, 2017 2:51 AM

no.

the offset "(scroll") registers have influence on all SCBs. but no SCB has position influence on the others



#9 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Wed Nov 15, 2017 5:03 AM

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.



#10 TailChao OFFLINE  

TailChao

    Moonsweeper

  • 406 posts
  • Bup?
  • Location:United States

Posted Wed Nov 15, 2017 8:45 AM

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

Suzy Scroll A.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.

Suzy Scroll B.png

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

Suzy Scroll C.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.

 



#11 karri OFFLINE  

karri

    River Patroller

  • 2,173 posts
  • Location:Espoo, Finland

Posted Wed Nov 15, 2017 10:38 AM

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 :)

 

pandaria.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, Wed Nov 15, 2017 10:46 AM.


#12 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Wed Nov 15, 2017 3:07 PM

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, Wed Nov 15, 2017 3:16 PM.


#13 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Wed Nov 15, 2017 3:29 PM

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!



#14 Matthias OFFLINE  

Matthias

    Stargunner

  • 1,166 posts
  • Location:Germany

Posted Wed Nov 15, 2017 3:36 PM

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.d...ng.htm#SPRDEMO4

Kind regards
Matthias

#15 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Wed Nov 15, 2017 3:42 PM

Thanks Matthias! I will have a look. I remember looking at these examples quite a lot a long time ago, but apparently I didn't remeber any of the hoff and voff stuff though! :P


Edited by Turbo Laser Lynx, Wed Nov 15, 2017 4:29 PM.


#16 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 291 posts
  • Location:Finland

Posted Wed Nov 15, 2017 4:15 PM

I looked at the example and it seems pretty straight forward, so thank you very much again! I don't think I will waste more time on my current demo, but this is golden information for doing scrolling properly next time.


Edited by Turbo Laser Lynx, Wed Nov 15, 2017 4:16 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users