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.
Simulating NES Scanline Limit
Moderators: marionline, SDHawk
Simulating NES Scanline Limit
Last edited by Soule X on Thu May 11, 2017 10:35 pm, edited 1 time in total.
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.
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.
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.
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.
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.
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.
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
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.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...
⊕ 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
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases