Simulating NES Scanline Limit

Ask and answer questions about making games and related topics. Unrelated topics go in that other forum.

Moderators: marionline, SDHawk

Post Reply
User avatar
Soule X
Red Slime
Posts: 84
Joined: Wed Sep 19, 2012 4:18 pm
Location: Indianapolis

Simulating NES Scanline Limit

Post by Soule X »

I am interested in "semi" recreating some of the nes limitations. I have a pretty good handle on the pallets, which was my priority, but I also think the Scanline limit is possible without a huge amount of effort. I know that the limit per line is 8 sprites. My question is what exactly happens after that and what is the best way to simulate that?

I'm thinking I can have 200 variables representing each Scanline, and run a loop in each sprites command loop to increment each y line they are occupying. If the variable for any Scanline is over 8 it will run the slowdown, flicker, whatever script.

EDIT: Upon further research, I think the way it works is over 8 sprites in a Scanline means it can only show 8 at any given time, so anything over will be invisible. Priority can be set to determine which sprites show up over others.
The slowdown occurs only when there are too many sprites on screen and that is usually when the disappearing sprites are noticed because they are gone for more frames.
They are independent of each other, bit it seems like they happen together due to more sprites on screen increasing the possibility of a Scanline filling up.

I changed the way I decided to check Scanline once I started. It's not necessary to use global, except for storing sprites that are erased on the next tick.
To check the Scanline I just need to go through each line and check the y range of each object, and add up all the ones occupying that scanline. Then go through and blank out however many sprites are over the limit, in a pattern so they aren't gone for more than a tick if possible.

I think I almost have it implemented but I messed up a few minor details I think.
Last edited by Soule X on Thu May 11, 2017 10:35 pm, edited 1 time in total.
TMC
Metal King Slime
Posts: 4101
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Oh, I never knew about the slowdown.

Both ways of implementing the scanline limit would work. I think I would prefer the first way. If you find that it's to slow, you can easily speed it up by only processing every second or third scanline; the difference will be imperceptible.
User avatar
Soule X
Red Slime
Posts: 84
Joined: Wed Sep 19, 2012 4:18 pm
Location: Indianapolis

Post by Soule X »

I thought about that, but what I have so far doesn't seem to be slowing anything down. At least on Android when I've tested it at work. I still have an error somewhere so it's not swapping the sprites out for blanks just yet, but it's definitely detecting how many objects are in each scan line with no problem.

I thought the first way would work, but once I started on it I realized I would have to save each sprite I was removing so I could put them back in on the next tick, so that wouldn't really work unless you went through and ran another script to gather all the sprite set numbers afterwards. Easier to just do it all in one loop where you can save the sprites at the same time and recall them later.
TMC
Metal King Slime
Posts: 4101
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

I can't see what difference it makes to tracking hidden slices, although I see another reason it would be easier to do it the way that you are.
Why would you have to save which sprites you're hiding? Are you using setspritesetnumber instead of setslicevisible? I would use slice extra data to mark any slices that need to be ignored (remain hidden), and use setslicevisible.

However, I've just realised that the engine resets the visibility of hero walkabout (container) slices each tick, so you can't override them. However, it doesn't override NPC slices in the same way. You could work around the hero slices by setting the visibility of the sprite component of the walkabout instead.
User avatar
Soule X
Red Slime
Posts: 84
Joined: Wed Sep 19, 2012 4:18 pm
Location: Indianapolis

Post by Soule X »

Wow. This is why I come here for you knowledge. I never knew Set Slice Visible was a command. I was using Replace Small Enemy Sprite to set each one to a blank sprite and then saving the original to set it back later. This will free up even more globals! Thanks!

I'm still having an issue with my variables, as in right now when it triggers it's turning almost all of them off and only a few are showing up at once, but it's semi working. They ARE blinking out, just too many at once. With this command and sorting out the variables I think I will have this working very soon.
User avatar
sheamkennedy
Liquid Metal Slime
Posts: 1110
Joined: Mon Sep 16, 2013 9:29 pm
Location: Tama-shi, Tokyo, Japan
Contact:

Post by sheamkennedy »

Soule X wrote:...as in right now when it triggers it's turning almost all of them off and only a few are showing up at once, but it's semi working. They ARE blinking out, just too many at once...
If you are having an issue processing too many scanlines at once how about you instead flicker a backdrop which consists of scanlines and transparent lines. This will only require you to flicker one single backdrop. If you want to add a pulsing effect try cycling through line colours by cycling through a variety of backdrop scanline colours.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Post Reply