So, regarding the sprites per scanline . . .

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: So, regarding the sprites per scanline . . .

Post by Pokun »

Yes at least on a CRT TV. Youtube videos of the game may make 50% flickering invisible instead since they tend to chop frame-rate in half.

As for an example of a game that doesn't do priority rotation Assault Suits Valken comes to mind. Specifically the Japanese version as Cybernator removed the portraits in the dialogue boxes so there are less sprites (since portraits are made of sprites). The result can often be seen when there are a lot of explosions and action going on and a dialogue box appears, some of the lines in the portraits drops out, no flickering.





And BTW, "sprite tiles" never made any sense to me. Sprites and tiles are like opposite things, or different things at least, apples and oranges.
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

Pokun wrote: Sat Jul 30, 2022 4:47 pm Yes at least on a CRT TV. Youtube videos of the game may make 50% flickering invisible instead since they tend to chop frame-rate in half.

As for an example of a game that doesn't do priority rotation Assault Suits Valken comes to mind. Specifically the Japanese version as Cybernator removed the portraits in the dialogue boxes so there are less sprites (since portraits are made of sprites). The result can often be seen when there are a lot of explosions and action going on and a dialogue box appears, some of the lines in the portraits drops out, no flickering.





And BTW, "sprite tiles" never made any sense to me. Sprites and tiles are like opposite things, or different things at least, apples and oranges.
Interesting.

So, I'd be curious to see what the visual difference would be there between not using the sprite priority rotation feature and using the sprite priority rotation feature.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: So, regarding the sprites per scanline . . .

Post by psycopathicteen »

TrekkiesUnite118 wrote: Sat Jul 30, 2022 12:58 pm
iNCEPTIONAL wrote: Sat Jul 30, 2022 12:36 pm Apparently I did respond to him, as he indicated below. but maybe someone should go find that video and see who engaged who first again, or how it all came about.
Sure, it's this video here:
https://www.youtube.com/watch?v=Rf2Gbflgxus

It came about because you've been spamming that video at people on Twitter in regards to SNES and Genesis beat'em ups, new Genesis homebrew projects, etc. and one of them eventually made it's way onto my twitter feed. I clicked the video, tried the ROM out, saw you asking how it ran on the real thing in the comments and said "If Ares is any indication, it flickers and slows down pretty badly."

EDIT: To be clear I didn't say this was about me or anything like that. I simply pointed out this is again coming from a console war discussion else where so people know what it's about and what direction it's going.
That's because your PC is older than shit, and can't run BSNES or Higan at full speed. Get a new computer.
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: So, regarding the sprites per scanline . . .

Post by TrekkiesUnite118 »

psycopathicteen wrote: Sat Jul 30, 2022 5:11 pm
That's because your PC is older than shit, and can't run BSNES or Higan at full speed. Get a new computer.
Is a 4 GHz 8-core Ryzen 2700 not powerful enough?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: So, regarding the sprites per scanline . . .

Post by lidnariq »

psycopathicteen wrote: Sat Jul 30, 2022 5:11 pm That's because your PC is older than shit, and can't run BSNES or Higan at full speed. Get a new computer.
Warning: No cussing.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

iNCEPTIONAL wrote: Sat Jul 30, 2022 4:20 pm By the way, my thinking around how the whole sprite order cycling should work, at least as I understand it, would be that it's changing the sprite order 60 times per second across probably five, six or even seven large characters onscreen (potentially made up of multiple objects horizontally), so the flickering probably shouldn't actually be that noticeable if it's done right. I mean, it's possible to flicker a single sprite on and off 60 times per second and it creates a relatively smooth effect of the sprite just being semi-transparent, so long as the framerate is steady. If that's happening across multiple sprites at 60fps, I would imagine the flickering effect would actually be pretty unnoticeable or you'd just see a little bit of semi-transparency on each character whenever it happens, like 20% transparency or something like that (depends on the amount of characters in a row, but it would obviously have to be enough to cause any flickering in the first place). But I might not be visualising how it would work in practice entirely accurately. I'd need to actually see it clearly working in a real example, and one where it's executed correctly and optimally, to properly decide for myself.
That's wishful thinking. I don't think you both understand and visualizing this correctly.

As to the flicker part; If you have a crappy LCD, yeah it'll just appear as solid semi-transparency graphic. On a CRT, it will flicker - the more the contrast between the two sets of pixels flickering - the more you'll notice it. It's called "flicker" and not semi-transparent for a reason.

The whole reason why you want flicker, is because it would be disastrous if you were to miss a projectile that could kill or damage you because it got dropped due to sprite line limit - this works great for a shump or such (in the case of NES, then just in general haha). Otherwise, the trade off is that if you do this in large areas of sprites it's going to give off an "NES" feel.

I also don't think you got my comment about z-fighting (z priority fighting). On a beat'em up game this straight up looks ugly. Yeah, you MIGHT have fixed the issue of at least partially seeing an enemy or character, but now you caused z-fighting on everything else with some blind sprite rotation technique. There's also more than just two-set sprite alternation method. You can cycle more, which will be needed if more than two objects are being dropped out, but it'll now be the HZ at which you cycle at (i.e. "blinky" instead of flicker). Same z-fighting issue though.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

psycopathicteen wrote: Sat Jul 30, 2022 5:11 pm That's because your PC is older than shit, and can't run BSNES or Higan at full speed. Get a new computer.
How exactly did you derive this???? :lol:
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: So, regarding the sprites per scanline . . .

Post by psycopathicteen »

TrekkiesUnite118 wrote: Sat Jul 30, 2022 5:16 pm
psycopathicteen wrote: Sat Jul 30, 2022 5:11 pm
That's because your PC is older than shit, and can't run BSNES or Higan at full speed. Get a new computer.
Is a 4 GHz 8-core Ryzen 2700 not powerful enough?
Then there must be something else wrong with your computer.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: So, regarding the sprites per scanline . . .

Post by lidnariq »

I looked. There's conspicuously noticeable sprite dropout. You can see missing slivers starting at 12 seconds in in the linked video. (Go frame-by-frame and it'll be exceptionally glaring)
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

lidnariq wrote: Sat Jul 30, 2022 7:10 pm I looked. There's conspicuously noticeable sprite dropout. You can see missing slivers starting at 12 seconds in in the linked video. (Go frame-by-frame and it'll be exceptionally glaring)
I was barely into the game...
http://www.turboxraypce.org/pics/SNES/tit_ex1.jpg
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

lidnariq wrote: Sat Jul 30, 2022 7:10 pm I looked. There's conspicuously noticeable sprite dropout. You can see missing slivers starting at 12 seconds in in the linked video. (Go frame-by-frame and it'll be exceptionally glaring)
When there's seven characters onscreen total, one player and six enemies, I think the amount of dropout would be acceptable to any normal players. Switch out one of the enemies for a second player, so you'd have two players and five enemies, and you have a two player beat 'em up with enough enemies for the vast majority of normal players out there to be more than satisfied imo. Add in one more enemy, increasing the flicker further, and I personally think you're reaching the point of having enough enemies onscreen to be fun but also potentially stepping into bad game design territory by having too much flicker and also just too much going on onscreen at once in general. And, yes, I absolutely believe you can put too many enemies onscreen in a beat 'em up. My personal view is that having two to three [regular] enemies onscreen per player at any one time is the optimal amount, so I'd actually try to stick around the five [regular] enemies count for the most part, but anything between four and seven [regular] enemies in total is still fine in my book. I wouldn't go above that even if I could though, as the goal would always still be to design a genuinely good, well balanced and fun game above all, and too many enemies onscreen becomes an exercise in going-through-the-motions button bashing and little else as far as I'm concerned. So, yeah, I think the SNES in 2022 could manage a beat 'em up with more than the typical amount of enemies onscreen you usually see on the system and that also ticks all the meaningful boxes. I'm not seeing any actual real issues here at all in that regard. But that's just my take on it.
Last edited by iNCEPTIONAL on Sun Jul 31, 2022 6:58 am, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: So, regarding the sprites per scanline . . .

Post by Pokun »

Yeah realistically there can only be so many people ganging up on one person before they risk hitting each other, maybe 3 or 4 people max. Of course in a belt-scroll you can only attack from 2 directions, left and right (although you can usually attack "diagonally" without having to stand exactly lined up with target), and characters tends to overlap each other which allows unlimited number of opponents in the same spot and the player can also usually hit them all with a single punch dealing the same damage to the whole lot and send them all flying equally far as a single opponent would from the same punch.

For this reason I think limiting the number of enemies is generally a good thing.
Many games like Double Dragon even have enemies taking turns engaging the player so the player never has more than 2 or maybe 3 opponents at a time.


iNCEPTIONAL wrote: Sat Jul 30, 2022 5:03 pm I'd be curious to see what the visual difference would be there between not using the sprite priority rotation feature and using the sprite priority rotation feature.
The lines that drops out would be flickering instead, plus a few other sprites (some of the bullets and explosions for example). Flickering means they take turns dropping out each frame, since the drop-out depends on the sprite's priority which you rotate each frame.
But like others said, sprites overlapping each other might take turns to have have priority over each others, which would look very weird as they keep appearing in front of each other every frame.

Although there may be advanced priority rotation programming that takes care to avoid this, I suppose the programmers thought sprite drop-out was fine in this game as it doesn't happen too much. They just make sure that important things like bullets have high priority so that they never drop out while less important things like the portraits have low priority and are the first sprites to drop out.

As for an example of a game that doesn't do any priority rotation even though it really needs it, check out the MSX version of Gradius. The MSX1 video chip (TMS9918A) only allows 4 sprites/scanline so sprite drop-out is very common in a horizontal shooting game like this. Dying from invisible bullets is very common in this version of the game, but you probably can't see that in a video.
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

Pokun wrote: Sun Jul 31, 2022 5:13 am They just make sure that important things like bullets have high priority so that they never drop out while less important things like the portraits have low priority and are the first sprites to drop out.
Ah, interesting. I never realised that if you're not using the sprite priority rotation feature that you could still have some level of granular controller over what's going to be most likely to drop out.

Would this mean that in a beat 'em up, where sprites are constantly being set to different priorities so characters appear in front of others based on their position on the screen--at least that's how I imagine it works--it's generally going to be the characters that are behind other characters or higher up the screen that would get sprites dropped out first anyway?

I guess there's probably some way to make it so that, along with any characters who are obviously in front of others, the player and any character(s) they are currently fighting are set to a higher priority than any off to the side that you would be paying less attention to anyway. And, while it may be obvious there's flicker when watching these games obsessively on YouTube videos playing in slow motion and counting frames like nerds analysing data points, the drop-out that's happening off to the side like that likely wouldn't be so obvious to the people actually playing the game and focussing on the action. You could probably even do a combination approach, if it's possible, where any characters that are off to the side and furthest back but aren't the player or the immediate character(s) they're attacking, would use the sprite priority rotation feature too, so, not only are they the most likely to drop out but also they'll be sharing the flickering between themselves regularly, so the flickering wouldn't be quite so obviously in the one place with large chucks of a character missing for multiple frames.

That's probably a potentially more effective solution for single player than in multi player mind you. And, to be clear, it might not make much difference at all or even work like that at all. This is one of those things were I'd have to see a few possible methods in action to decide what approach ultimately works best.

But, assuming it has even some positive benefit, with a solution something like that, and going with characters that are around TMNT to Streets of Rage 2 size, not as large as those in the later Final Fight series, and having two players and generally no more than five enemies onscreen at once, I think any drop out won't be too much of a problem for the average person anyway. Basically, that TMNT Arcade Edition hack with normally up to five [regular-sized] enemies would look spot-on and be around the right balance for gameplay too imo.

In a shmup, I'd probably set it so the player's bullets and any explosions were most likely to drop out first, followed by any ships that were either furthest away from the player or closet to the edges of the screen, where people are less likely to be paying attention to what's going on. I'd try to make it so the player and enemy bullets [at least close to the player] never drop out ideally. And I'd be more inclined to use the sprite priority rotation in a shump too, assuming I can target specific lower priority spites in the pool before it affects something like the player ship and enemy bullets in the way I imagine. Something like that.

Again though, I'd need to see tests of all of this in action to properly make a decision, and it all might not even work in the way I imagine anyway.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: So, regarding the sprites per scanline . . .

Post by Pokun »

The way the priority works is that sprite 0 (first sprite in OAM) has the highest priority and sprite 127 (last sprite in OAM) has the lowest priority. This is both display priority (compared to other sprites, not compared to the BGs) and drop-out priority. On older systems like the NES, the only way to create flickering instead of drop-out was to rotate the OAM itself so that sprites are always in a new OAM slot every frame and thus rotates, sprites takes turns to drop out and thus appears to flicker.

On the SNES you can instead change which OAM slot should have the highest priority (wrapping around to 0 after 127) so you don't have to move all the sprite data to another slot. This is just writing a single value to a special register and BANG priority has been rotated (compared to copying 4 bytes + 1 bit for every sprite in OAM in order to move sprites to other OAM slots).
Example: If you set sprite 125 to have the highest priority, then sprite 126 will have 2nd highest, sprite 127 is third highest, sprite 0 is 4th highest, sprite 1 is 5th highest and so on until sprite 124 which will have the lowest priority.

In other words you don't have full control over what sprites have what priority, so things like making sprites at the edges having lower priority would require moving sprites around in OAM.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

Pokun wrote: Sun Jul 31, 2022 5:13 am Yeah realistically there can only be so many people ganging up on one person before they risk hitting each other, maybe 3 or 4 people max. Of course in a belt-scroll you can only attack from 2 directions, left and right (although you can usually attack "diagonally" without having to stand exactly lined up with target), and characters tends to overlap each other which allows unlimited number of opponents in the same spot and the player can also usually hit them all with a single punch dealing the same damage to the whole lot and send them all flying equally far as a single opponent would from the same punch.

For this reason I think limiting the number of enemies is generally a good thing.
Many games like Double Dragon even have enemies taking turns engaging the player so the player never has more than 2 or maybe 3 opponents at a time.
Having 6-7 enemies on screen does not mean you're fighting all 6-7 enemies at once (i.e. all of them are swarming you). And there is also a thing called "crowd control" in beat'em up games, which is basically lacking from SNES games beat'em ups when you have like 3 enemies on screen. Fight Final 2 and 3 are kinda boring because it's weak in this element (because of the limited number of enemies). Good game design strikes balance; you don't need massive amount of enemies coming at you at all times, but there needs to be points of congestion - feeling overwhelmed, and then coming through that victoriously. For a successful beat'em up game, you DO need points where 6,7, or even 8 enemies will come at you at times. It doesn't need to be "Michael Bay" level of intensity 100% of the time, because then you've just normalized the intensity, but it does need to be part of the design.






Being able to have a lot of enemies on screen is crucial to a beat'em up game design. And however you need to cheat that (smaller enemies for those sections, or using a BG layer for an enemy for some areas, etc) - do it. If there's a little bit of sprite drop out during such intensity, usually not a problem. If one or more characters becomes half visible for longs periods of time (and it's really apparent visually), then you have a problem. I mean, you can only do what you can only do. But I find this direction of this discussion is turning is a bit disingenuous; "Well if the snes can't do it, then I'll just pretended that it doesn't matter and dismiss it - regardless of what real/good game design means for a beat'em up." And convince yourselves that the number of enemies being more than what the snes can handle is superficial anyway. If you're going to make a beat'em up game, you should really understand all the mechanics that go into a good beat'em up. I.e. Don't use existing SNES beat'em ups are your template.
Post Reply