Offset change per column horizontally . . .

[+frankodragon]

Noboody should download that file due to spyware, adware and possible malware and viruses.

[Tanooki]

On 12/10/2023 at 12:17 PM, TrekkiesUnite118 said:

You should really not be posting random unverified exe's. That's generally a red flag and will set off most people's antivirus software.

Seeing how he's strangely quite aggressively doubling down on this thread which hasn't happened in awhile, my guess there's a shot he sourced some Chinese spyware(since coding it would take work) and if you run it, it'll take over your login here and edit out all the perceived negative comments to leave nothing but glowing comments and reviews of how right he is.  The virus would be named Stewart.Smalley.01 or similar.

[Austin]

On 12/10/2023 at 11:55 AM, TrekkiesUnite118 said:

Vertical scrolling like this is something that's inherently challenging on these older systems because they're designed around how a CRT draws. Each line is drawn horizontally and then there's a blanking period while the beam resets. During that period you can use interrupts to change certain values which is how you get stuff like line scrolling effects. You don't have that to play with in the vertical realm. The only blank period you have is VBlank which is between individual frames, not lines or columns. So the best these older systems can try to do is do this on a per column basis. Case in point, even Saturn's VDP2 which is leaps and bounds more powerful than the SNES's PPU or the Genesis VDP, has to make compromises in this area. A good example of this is Layer Section/Galactic attack. In TATE mode you have these nice vertical line scroll effects because the game is being drawn horizontally with the intent of rotating the monitor 90 degrees:

 

If you play it in non TATE mode though, those effects are completely absent because they're more challenging or flat out not doable:

 

That's great info! As a big fan of Layer Section, I had always wondered what was keeping them from replicating those effects in non-tate mode. Other vertical stgs on the Saturn that have both tate and non-tate modes seem to be pretty close if not identical to one-another (usually just having the top portion of the screen chopped off in non-tate). But now that I think of it, very few (if any) other vertical shooters on the platform have the same sort of dazzling scrolling effects that Layer Section does in its tate mode (and damn do they look good!). It makes perfect sense now, thanks!

Edited December 11, 2023 by Austin

[turboxray]

On 12/10/2023 at 4:53 PM, jeffythedragonslayer said:

The zsnes forum post referenced at the bottom by Grigori is excellent:

 

https://sneslab.net/wiki/Sprite_Line_Buffer

The site's stated sprite pixel line limit in incorrect. He gives the impression that the sprite pixel line limit is 256 when it's not.

Edited December 12, 2023 by turboxray

[turboxray]

On 12/10/2023 at 1:57 PM, Kirk_Johnston said:

 

What hahah. That's the crappiest example of per-offset-tile scrolling ever. You literally can do better without it - smh.

[jeffythedragonslayer]

1 hour ago, turboxray said:

The site's stated sprite pixel line limit in incorrect. He gives the impression that the sprite pixel line limit is 256 when it's not.

Oh, if there is something poorly worded in there I very much want to fix it.  Could you show me how you'd word it so it's clear?

[turboxray]

1 hour ago, jeffythedragonslayer said:

Oh, if there is something poorly worded in there I very much want to fix it.  Could you show me how you'd word it so it's clear?

This part, "The Sprite Line Buffer is where sprites are pre-rendered to during hblank before being compositied (typo) together with the backgrounds. It is 256 pixels wide, and a total of 2304 bits." That might be true that the line buffer itself is only 256px worth of composited pixels, but the sprite "rendering" is often attributed to the accumulated fetch line limit.. which is 272 pixels (or 34 8px wide cells). Most people only care about the "sprite pixel line limit", and not further under the hood, because it's something you have direct control over or rather your sprite cells per line do. I've already seen people stating this is 256px in other tech discussions (not sure if this is the source of that or not). Probably best to make the distinction here to avoid confusion.

Edited December 12, 2023 by turboxray

[jeffythedragonslayer]

44 minutes ago, turboxray said:

This part, "The Sprite Line Buffer is where sprites are pre-rendered to during hblank before being compositied (typo) together with the backgrounds. It is 256 pixels wide, and a total of 2304 bits." That might be true that the line buffer itself is only 256px worth of composited pixels, but the sprite "rendering" is often attributed to the accumulated fetch line limit.. which is 272 pixels (or 34 8px wide cells). Most people only care about the "sprite pixel line limit", and not further under the hood, because it's something you have direct control over or rather your sprite cells per line do. I've already seen people stating this is 256px in other tech discussions (not sure if this is the source of that or not). Probably best to make the distinction here to avoid confusion.

Oh, you were talking about the SnesLab page, not the forum post!  Typo fixed.  I see 272 is 8 times 34, but how did you learn about the fetch line limit?  Not sure how to further make that distinction.

Edited December 12, 2023 by jeffythedragonslayer

[turboxray]

1 hour ago, jeffythedragonslayer said:

Oh, you were talking about the SnesLab page, not the forum post!  Typo fixed.  I see 272 is 8 times 34, but how did you learn about the fetch line limit?  Not sure how to further make that distinction.

The 272 pixel fetch limit? It's in the official manual (when it talks about up to 34 "cells" fetched per line.. which is different from the 32 "sprites" eval'd per line), in emulator source code, has been tested on real hardware (multiple times and in discussions over the past two decades in dev circles). It's also stand out feature (argument point for tech discussions) because the limit is more than the display width (6.25% bigger than 256px) where as on the PCE and MD.. their spite pixel fetch line limits don't exceed the display width. So it also comes up a lot. There's at least one game I know that relies on it too (for mode 7 effect)

 

 Something that doesn't come up a lot, is the quirk where if the 32 sprite limit is not met but the 34 cell limit is met.. then SNES drops cells in the reverse priority order than it would drop for sprites; i.e. the top most priority "cells" get dropped! And doesn't look so great for games with z-depth importance (beat'em ups like Final Fight). Like on the SNES or PCE, you can have shadow sprites, or items, or characters laying wounded.. and set those to low z-depth priority which also means low priority in the sprite table.. and normally they're get dropped out which is fine (visually acceptable). But on the SNES there's a good chance that the player and other foreground sprites will get dropped instead (because of the cell rendering oddity).

Edited December 12, 2023 by turboxray

[jeffythedragonslayer]

1 hour ago, turboxray said:

The 272 pixel fetch limit? It's in the official manual (when it talks about up to 34 "cells" fetched per line.. which is different from the 32 "sprites" eval'd per line), in emulator source code, has been tested on real hardware (multiple times and in discussions over the past two decades in dev circles). It's also stand out feature (argument point for tech discussions) because the limit is more than the display width (6.25% bigger than 256px) where as on the PCE and MD.. their spite pixel fetch line limits don't exceed the display width. So it also comes up a lot. There's at least one game I know that relies on it too (for mode 7 effect)

 

 Something that doesn't come up a lot, is the quirk where if the 32 sprite limit is not met but the 34 cell limit is met.. then SNES drops cells in the reverse priority order than it would drop for sprites; i.e. the top most priority "cells" get dropped! And doesn't look so great for games with z-depth importance (beat'em ups like Final Fight). Like on the SNES or PCE, you can have shadow sprites, or items, or characters laying wounded.. and set those to low z-depth priority which also means low priority in the sprite table.. and normally they're get dropped out which is fine (visually acceptable). But on the SNES there's a good chance that the player and other foreground sprites will get dropped instead (because of the cell rendering oddity).

Very fascinating.  Thank you.  If you have any videos of that please share.  Do you happen to know on what page the manual talks about that on?  I'm not getting any hits for "272" "34" or even "cell" when I search the PDF of Book I, and definitely no hits for "pixel fetch limit".

 

I don't think you're talking about 35's Time Over or 33's Range Over, because those are about OBJs not cells?  On the other hand, I think it makes sense that there is a limit of 34 on the cells because that same fetch limit applies to the sprites.  So I suppose that page on those PPU limitations is what you mean.

Edited December 12, 2023 by jeffythedragonslayer

[turboxray]

17 minutes ago, jeffythedragonslayer said:

Very fascinating.  Thank you.  If you have any videos of that please share.  Do you happen to know on what page the manual talks about that on?  I'm not getting any hits for "272" "34" or even "cell" when I search the PDF of Book I, and definitely no hits for "pixel fetch limit".

Super Famicom Documentation SFX01 Software Manual, page "-34-".. Section 20, sub-sections 1 and 2. They're oddly mentioned as "33's RANGE OVER" and "35's TIME OVER".

[jeffythedragonslayer]

12 minutes ago, turboxray said:

Super Famicom Documentation SFX01 Software Manual, page "-34-".. Section 20, sub-sections 1 and 2. They're oddly mentioned as "33's RANGE OVER" and "35's TIME OVER".

Ooh, very rare reference to the Megaboys manual.  Yeah, that threw me for a loop because virtually that entire page is about OBJs when I was thinking about cells on the bg.

[Kirk_Johnston]

I don't know what most of this conversation above is about (only skimmed bits of it to be honest), but if it's related to the SNES' ability to both smoothly vertically column scroll and horizontally shift 8-pixel-wide columns in the likes of Modes 2 and 4, then it's good that people are even just talking about this feature imo. And maybe some SNES modern-day creators out there might even consider using it in their games/demos going forward. I'm sure there's a few ideas they could come up with that would take full advantage of it. 

Edited December 12, 2023 by Kirk_Johnston

[jeffythedragonslayer]

24 minutes ago, Kirk_Johnston said:

I don't know what most of this conversation above is about (only skimmed bits of it to be honest), but if it's related to the SNES' ability to both smoothly vertically column scroll and horizontally shift 8-pixel-wide columns in the likes of Modes 2 and 4, then it's good that people are even just talking about this feature imo. And maybe some SNES modern-day creators out there might even consider using it in their games/demos going forward. I'm sure there's a few ideas they could come up with that would take full advantage of it. 

Yeah like I feel like at this point Mode 0's existence has been drilled into people's brains pretty well.  "Touch Fuzzy Get Dizzy" is a pretty fun level, it deserves that same treatment.

[Kirk_Johnston]

54 minutes ago, jeffythedragonslayer said:

Yeah like I feel like at this point Mode 0's existence has been drilled into people's brains pretty well.  "Touch Fuzzy Get Dizzy" is a pretty fun level, it deserves that same treatment.

Well, here's a pretty cool example of the vertical scrolling (plus some nice row/line scrolling and palette cycling too):

 

I'd be real interested in seeing some cool uses of the horizontal column shifting too though. And that can be alongside line/row scrolling and the like as well. Since the main strength on SNES with this feature is the granularity of the columns, down to every 8 pixels wide, the fact it can both smoothly scroll them vertically and shift them horizontally at the same time, and that it can do this alongside the likes of colour math and such. 

 

Edited December 12, 2023 by Kirk_Johnston

[jeffythedragonslayer]

32 minutes ago, Kirk_Johnston said:

Well, here's a pretty cool example of the vertical scrolling (plus some nice row/line scrolling and palette cycling too):

 

I'd be real interested in seeing some cool uses of the horizontal column shifting too though. And that can be alongside line/row scrolling and the like as well. Since the main strength on SNES with this feature is the granularity of the columns, down to every 8 pixels wide, the fact it can both smoothly scroll them vertically and shift them horizontally at the same time, and that it can do this alongside the likes of colour math and such. 

 

I've played so much Wolfenstein 3D that my brain keeps mentally filling in the top of those red banners with swastikas off-screen.

[turboxray]

The horizontal offset, being course 8px positions, is convenient for some things... but there's nothing it can do that you can't just do with direct tilemap manipulation (modifying the entries). Matter of fact, direct tilemap manipulation would give you more control/flexibility than this. Vertical offset, sure, but not horizontal offset. At the most, it would potentially save you some cpu resource if it's faster than doing the operations on the tilemap directly for the same effect.

[jeffythedragonslayer]

24 minutes ago, turboxray said:

The horizontal offset, being course 8px positions, is convenient for some things... but there's nothing it can do that you can't just do with direct tilemap manipulation (modifying the entries). Matter of fact, direct tilemap manipulation would give you more control/flexibility than this. Vertical offset, sure, but not horizontal offset. At the most, it would potentially save you some cpu resource if it's faster than doing the operations on the tilemap directly for the same effect.

Well, the manual says to engage offset change mode you write a 16 bit datum to a certain VRAM address.  That sounds a lot easier to code up than modifying an entire row of tilemap entries to me.

[Kirk_Johnston]

1 hour ago, jeffythedragonslayer said:

Well, the manual says to engage offset change mode you write a 16 bit datum to a certain VRAM address.  That sounds a lot easier to code up than modifying an entire row of tilemap entries to me.

Yeah. And I think the interesting thing about it is the fact it works in conjunction with all the other types of typical scrolling (row/line, vertical column, full layer, part layer, whatever). This particular horizontal column shifting option to this level of granularity is only available in Modes 2 and 4, so you kinda have to think of ways to actually use it rather than just ignore or even actively come up with excuses to not use it and not take full advantage of it. Now, I've seen many examples of people not using it, but what I've not seen is more than literally about two people actually using the horizontal column shifting on SNES in any way at all, certainly not in a way that really pushes it, and absolutely not also in conjunction with a whole bunch of the other features and elements that can run at the same time as it too. So that's what interests me the most here, the potential to do something that properly/fully takes advantage of this kind of stuff on SNES.

Edited December 12, 2023 by Kirk_Johnston

[jeffythedragonslayer]

On 12/10/2023 at 12:17 PM, TrekkiesUnite118 said:

You should really not be posting random unverified exe's. That's generally a red flag and will set off most people's antivirus software.

My antivirus didn't have a problem with it.  If it did and couldn't tell me why, my opinion of that antivirus would lower.  Rice's theorem applies.

[+Biff Burgertime]

22 minutes ago, jeffythedragonslayer said:

My antivirus didn't have a problem with it.  If it did and couldn't tell me why, my opinion of that antivirus would lower.  Rice's theorem applies.

At the very least, public courtesy when linking an exe is also linking a VirusTotal result along with the exe.

 

For example, here's one of the tools of mine I created for a popular online game a decade ago - still in use today despite most other user-made tools being replaced by official versions years ago... call me overly-ambitious, I guess. It basically allows their forum to work in conjunction with a couple other tools and voila, their forum is a full-featured map submission system (maps in the game are user-made), complete with a maximum limit submitted per category, blacklist, etc.

 

https://www.virustotal.com/gui/file/a5da64f37058f4b262eec2b025d4e10c33cd0977bd1ba092b9f4dfa94a967448/detection

 

No matter what, 1 or 2 overly-cautious virus scanners will flag it because it doesn't recognize my name as a reputable developer/publisher. But it allows for some confidence as many reputable antivirus tools (such as Malwarebytes, for example) turn up nothing. That, combined with my reputation in the game  allows anyone on the map team who might be overly-cautious of such things to feel more secure in downloading some random dude's executables.

[jeffythedragonslayer]

18 hours ago, Kirk_Johnston said:

Well, here's a pretty cool example of the vertical scrolling (plus some nice row/line scrolling and palette cycling too):

 

I'd be real interested in seeing some cool uses of the horizontal column shifting too though. And that can be alongside line/row scrolling and the like as well. Since the main strength on SNES with this feature is the granularity of the columns, down to every 8 pixels wide, the fact it can both smoothly scroll them vertically and shift them horizontally at the same time, and that it can do this alongside the likes of colour math and such. 

 

Also thanks for another example of mosaic which appears at 8:15.

[jeffythedragonslayer]

11 minutes ago, Biff Burgertime said:

At the very least, public courtesy when linking an exe is also linking a VirusTotal result along with the exe.

 

For example, here's one of the tools of mine I created for a popular online game a decade ago - still in use today despite most other user-made tools being replaced by official versions years ago... call me overly-ambitious, I guess. It basically allows their forum to work in conjunction with a couple other tools and voila, their forum is a full-featured map submission system (maps in the game are user-made), complete with a maximum limit submitted per category, blacklist, etc.

 

https://www.virustotal.com/gui/file/a5da64f37058f4b262eec2b025d4e10c33cd0977bd1ba092b9f4dfa94a967448/detection

 

No matter what, 1 or 2 overly-cautious virus scanners will flag it because it doesn't recognize my name as a reputable developer/publisher. But it allows for some confidence as many reputable antivirus tools (such as Malwarebytes, for example) turn up nothing. That, combined with my reputation in the game  allows anyone on the map team who might be overly-cautious of such things to feel more secure in downloading some random dude's executables.

Here you go:

 

Mode2test.exe

https://www.virustotal.com/gui/file/5c69404a5f7fd431c5ef89e15b989d412e75a897eb9dee8673ab01aa474eab09?nocache=1

 

ShmupTestMode0.exe

https://www.virustotal.com/gui/file/d6180d58554255f5c233e8090a00cbdcc4d885d5a21709d38340c390e2af0e88?nocache=1

[+Biff Burgertime]

15 minutes ago, jeffythedragonslayer said:

Here you go:

 

Mode2test.exe

https://www.virustotal.com/gui/file/5c69404a5f7fd431c5ef89e15b989d412e75a897eb9dee8673ab01aa474eab09?nocache=1

 

ShmupTestMode0.exe

https://www.virustotal.com/gui/file/d6180d58554255f5c233e8090a00cbdcc4d885d5a21709d38340c390e2af0e88?nocache=1

Cool. But uh, that's not your job... it's his. I'm not sure what the status of his ignore list is at the moment - I suspect it's still in effect, he just thought better of how foolish he looked listing everybody explicitly in his signature - but if so, consider this simply one more piece of genuinely useful advice he willfully won't read or consider.

 

I have no interest nor any intention on downloading whatever this crap is.

[jeffythedragonslayer]

12 minutes ago, Biff Burgertime said:

Cool. But uh, that's not your job... it's his. I'm not sure what the status of his ignore list is at the moment - I suspect it's still in effect, he just thought better of how foolish he looked listing everybody explicitly in his signature - but if so, consider this simply one more piece of genuinely useful advice he willfully won't read or consider.

 

I have no interest nor any intention on downloading whatever this crap is.

I ran those exe's through VirusTotal because I do not like seeing Kirk's work libeled.