Jump to content
IGNORED

The completely underappreciated possibilities of Mode 0 on SNES. . . .


Recommended Posts

5 hours ago, JurassicDope said:

You understand the concept of Vblank and Hblank (and I guess Forced Blank whenever that happens). However, during active scan (while a line of pixels is being drawn), is usually where the the CPU is doing stuff, typically with RAM. Such as a collision system. Basically, the "gameplay" bit. Of course, you can also handle game logic and math calculations during any of the Blanking times, those are the only times you can do DMA on the Snes (such as writing graphics data to the VRAM, which is stored in RAM or ROM), so you definitely want to get your game logic out of the way during active scan instead.

OK. Cool, thanks.

 

So, is there any way for me to know at a high level [in layman terms] roughly how many game logic things the SNES can do during active scan then per frame, and indeed how many of those things roughly I'm currently doing for comparison, just so I would have a rough idea of the limit and how close any game logic stuff I'm currently doing would be to it?

 

I mean, again, right now I think I'm doing very little of that stuff, just updating the position of a few backgrounds and sprites tiles, reading the controller for when the player moves left and right, making those small ghosts occasionally move towards the player's position, plus a little bit of timer-based stuff and that's about it really. Most of the rest would seem like it would be done during VBlank and HBlank thus far. So my guess is that this, while it looks like a lot going on, would barely be taxing the SNES.

Edited by Kirk_Johnston
Link to comment
Share on other sites

4 minutes ago, Kirk_Johnston said:

So, is there any way for me to know at a high level [in layman terms] roughly how many game logic things the SNES can do during active scan then per frame, and indeed how many of those things roughly I'm currently doing for comparison, just so I would have a rough idea of the limit and how close any game logic stuff I'm currently doing would be to it?

 

I mean, again, right now I think I'm doing very little of that stuff, just updating the position of a few backgrounds and sprites tiles, reading the controller for when the player moves left and right, making those small ghosts occasionally move towards the player's position, plus a little bit of timer-based stuff and that's about it really. Most of the rest would seem like it would be done during VBlank and HBlank thus far. So my guess is that this, while it looks like a lot going on, would barely be taxing the SNES.

Does this conversation help?

 

https://board.zsnes.com/phpBB3/viewtopic.php?t=12469

Link to comment
Share on other sites

6 hours ago, Creamhoven said:

Yeah, let's show many coins realistically could fall on that image within mode 0. (let's start with max possible coins falling in front of that background)

 

Sleep well!

OK. But, just to be clear, with that specific background using one layer (although it wouldn't look very good in Mode 0), you could literally have three more full background screens worth of coins falling at one of three speeds depending on what background they are on, plus around 128 coins (or even groups of coins in some of the object/sprite tiles) minus however many objects/sprites are required for the player. So there's gonna be a dang lot of coins falling (and the SNES should absolutely be able process that amount at 60fps based on this demo https://youtu.be/Xf1SreRlbZQ)!

 

With that specific background image though (and you might want to adjust it so the text isn't visually too distracting when the coins start falling), it might be better to just use the normal Mode 1 and do it using one of the high colour backgrounds and then have two more backgrounds of coins plus all the sprites. Or, to really get the image looking good (and much better than on the competition), it would be best to use Mode 3 and have that background in 8bpp 256-colour, and then use the other background for a layer of coins and have all the additional sprite coins on top of that. So, it can be probably kinda meh looking background [although I can test this] and LOADS of coins or great looking background and still loads of coins. Do you have a preference?

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

34 minutes ago, jeffythedragonslayer said:

Not really, for me at least, other than indicating the CPU can be used by different things used it in different ways, but without really saying how much. 

 

Looking at my game, I'm curing how much all of that would genuinely be taxing the CPU. I mean, I presume moving three backgrounds a little every frame is basically trivial, just setting a scroll value or whatever (the other one is always static). And I think reading left and right inputs on the joystick and moving the player left or right should be too. I expect streaming in/out new tiles for the player every frame is more taxing. And I expect drawing the window/shape masks and moving them is a little taxing, but that actually much of it is being updated during HBlank periods anyway. And I think probably the little ghosts are actually the most taxing, as they have a couple of animation frames, move position, check when to attack the player, and then check his position and move towards that point, etc. I think the giant foot is likely one of the most taxing things too, as that's drawing a window/shape mask that changes every frame and moves quickly while also updating the colour on each scanline too to get that slightly gradient on the sole of his feet, but again, wouldn't much of that be handled during the HBlank anyway, other than however the lookup table or whatever it is is stored and handled?

 

I only really understand most of the stuff above at a high level rather than the low level specific writing of the code and how that interacts with the CPU, so I'm generally just using a bit of rationalising based on what the effect is and how intense I reckon it would be in terms of using up the system's resources while making sure to stay within the obvious VRAM, sprites on-screen and sprites per scanline, background layer, etc, limits. This is why I'm keeping all the actual gameplay stuff very simple and doing very little actual sprite animation [other than the player and small ghosts] and such in the demo for now, as well as doing literally no collision checks whatsoever currently.

Edited by Kirk_Johnston
Link to comment
Share on other sites

12 minutes ago, Kirk_Johnston said:

I mean, I presume moving three backgrounds a little every frame is basically trivial, just setting a scroll value or whatever (the other one is always static).

 

Correct.

12 minutes ago, Kirk_Johnston said:

And I think reading left and right inputs on the joystick and moving the player left or right should be too.

Reading the joysticks is relatively cheap but I'd expect collision detection to be expensive.  There are two ways to read the joysticks on the SNES.

12 minutes ago, Kirk_Johnston said:

I expect streaming in/out new tiles for the player every frame is more taxing.

Definitely.

12 minutes ago, Kirk_Johnston said:

And I expect drawing the window/shape masks and moving them is a little taxing, but that actually much of it is being updated during HBlank periods anyway.

I guess.

 

12 minutes ago, Kirk_Johnston said:

I only really understand most of the stuff above at a high level rather than the low level specific writing of the code and how that interacts with the CPU, so I'm generally just using a bit of rationalising based on what the effect is and how intense I think it would be in terms of using up the system's resources plus making sure to stay within the obvious VRAM, sprite, background layer, etc, limits.

I think you have a good understanding.  Once I have working code in front of me I usually use this document to count cycles, and then try to refactor it into faster code: https://undisbeliever.net/snesdev/65816-opcodes.html  So at this point, coding it up is probably the best way to figure out the real answer.

 

Are you familiar with those games mentioned in the zsnes thread?

 

Edited by jeffythedragonslayer
  • Like 1
Link to comment
Share on other sites

And, just to be clear, in case some people are maybe thinking my aim here is actually different to what it is, this is just a simple mockup to show what you can do when you have the four full background layers of Mode 0 to display a bunch of overlapping stuff on-screen (plus the normal sprites and some window/shape masks and such) and showing that the limited colours there also aren't that much of an issue either, rather than a gameplay test of any kind whatsoever. Hopefully no one was getting confused with that in the first place, but just wanted to make sure we're all on the same page. :)

Edited by Kirk_Johnston
Link to comment
Share on other sites

16 minutes ago, jeffythedragonslayer said:

Correct.

Reading the joysticks is relatively cheap but I'd expect collision detection to be expensive.  There are two ways to read the joysticks on the SNES.

Definitely.

I guess.

 

I think you have a good understanding.  Once I have working code in front of me I usually use this document to count cycles, and then try to refactor it into faster code: https://undisbeliever.net/snesdev/65816-opcodes.html  So at this point, coding it up is probably the best way to figure out the real answer.

 

Are you familiar with those games mentioned in the zsnes thread?

 

Yeah, I've seen those games but never really considered how taxing they were on the CPU side of things specifically. I guess like someone in the thread said, they could be 100% using the CPU and cause no slowdown or 70% [or whatever] using the CPU and cause slowdown, so it's hard to gauge. And, for me at least, I do not care one bit how taxing it is on the CPU under the hood (up to its limits, obviously), so long as the end frame rate is still 60fps. I mean, I obviously try to take into consideration that I'm not doing crazy gameplay and collision and calculation and physics stuff at the design stage, but, either way, that's ultimately where I would hope the programmer could do their part and get that stuff coded really well under the hood. I mean, programmers, they talk like they must imagine they are some kind of genius Gods all the time, at least in SNESdev, so I'm gonna be dang well holding them too that when it comes to them actually doing some coding! Lol

Edited by Kirk_Johnston
Link to comment
Share on other sites

30 minutes ago, jeffythedragonslayer said:

Reading the joysticks is relatively cheap but I'd expect collision detection to be expensive. 

 

Once I have working code in front of me I usually use this document to count cycles, and then try to refactor it into faster code: https://undisbeliever.net/snesdev/65816-opcodes.html

OK, that seems coolio.

 

I am not doing any collision checks at all in my current mockup, so that shouldn't be an issue here.

 

Haha, at that point (looking at that page with all the opcode stuff), that's where I'm like brain melting--and where I'm reminded why I'm not a SNES programmer and kinda never want to be. Lol

 

But, basically, is the idea that the SNES takes a certain amount of cycles to do each operation and can process a certain amount of cycles per frame total (how many is that?) and you basically have to add up everything you're doing and make sure it does not add to more cycles every frame than the system is capable of (or else you get slowdown, I presume)?

Edited by Kirk_Johnston
Link to comment
Share on other sites

6 minutes ago, Kirk_Johnston said:

Yeah, I've seen those games but never really considered how taxing they were on the CPU side of things specifically. I guess like someone said, they could be 100% using the CPU and cause no slowdown or 70% [or whatever] using the CPU and cause slowdown, so it's hard to gauge. And, for me at least, I do not care one bit how taxing it is on the CPU under the hood, so long as the end frame rate is still 60fps. I mean, I try to take into considering that I'm not doing crazy stuff at the design stage, but that's where I would hope the programmer could do their part and get that stuff coded really well under the hood. I mean, programmers, they talk like they must imagine they are some kind of genius Gods all the time, at least in SNESdev, so I'm gonna be holding them too that! Lol

One thing I really found inspiring in one of Near's articles is that it says none of us are more important than anyone else in emulation; no one is a god.  I think that's the reason I find the ares crowd so easy to work with - a noob like me who is just getting started, never published a game on these systems or wrote an emulator before, is just as important as the most experienced veteran.  If people are going to act all holier-than-thou then I absolutely support you expecting divine results from them.

1 minute ago, Kirk_Johnston said:

OK, that all seems coolio.

 

Note: I am not doing any collision checks at all in my current mockup, so that shouldn't be an issue here.

I noticed 😛  lol

  • Like 1
Link to comment
Share on other sites

21 minutes ago, jeffythedragonslayer said:

I noticed 😛  lol

Yeah, and it was very intentionally so, because that's the bit I don't have a true grasp on. I mean, I honestly have no clue how many operations the SNES can process under the hood and how every single thing you ask the game to do takes a little bit from that total ultimately, so I just stick to mostly the stuff I can design that I don't think takes up too much CPU resources to actually do for now, other than maybe the streaming in/out new sprites and the window/shape masks of the current mockup, which I know don't come for free, but I typically go quite light on those normally. Most of the stuff I've done to date is just overlapping background layers, priority shifting for the illusion of even more layers, and some row/line scrolling, plus some semi-transparency that would use colour math--and there's obviously usually some basic gameplay element shown just so people can see/imagine it in the context of an actual game--and the trick is really just trying to make that look visually and technically impressive to the eyes of the end gamer (who are ultimately all I care about in terms of what I'm trying to achieve with my game ideas and who I want to leave satisfied when all is said and done). 😛 

 

If I actually knew how to program directly on SNES, I can only imagine what I might actually try to do then if I could manipulate things far more directly. :-o

Edited by Kirk_Johnston
Link to comment
Share on other sites

7 minutes ago, Kirk_Johnston said:

Yeah, and it was very intentionally so, because that's the bit I don't have a true grasp on. I mean, I honestly have no clue how many operations the SNES can process under the hood and how every single thing you ask the game to do takes a little bit from that total ultimately, so I just stick to mostly the stuff I can design that I don't think takes up too much CPU resources to actually do for now, other than maybe the streaming in/out new sprites and the window/shape masks of the current mockup, which I know don't come for free, but I typically go quite light on those normally. Most of the stuff I've done to date is just overlapping background layers, priority shifting for the illusion of even more layers, and some row/line scrolling, plus some semi-transparency that would use colour math--and there's obviously usually some basic gameplay element shown just so people can see/imagine it in the context of an actual game--and the trick is really just trying to make that look visually and technically impressive to the eyes of the end gamer (who are ultimately all I care about in terms of what I'm trying to achieve with my game ideas and who I want to leave satisfied when all is said and done). 😛 

 

If I actually knew how to program directly on SNES, I can only imagine what I might actually try to do then if I could manipulate things far more directly. :-o

Eh, well if we end up running out of CPU, we can just shove it onto SA-1 and get 5x the computing power.

Link to comment
Share on other sites

12 minutes ago, jeffythedragonslayer said:

Eh, well if we end up running out of CPU, we can just shove it onto SA-1 and get 5x the computing power.

Exactly. Although, in an ideal world, I'd always like to stick to what the stock SNES can do, because I feel like it's kinda admitting defeat or cheating if we have to use an enhancement chip. And my absolute belief is it really is possible to do amazing stuff on the stock SNES--Rendering Ranger R2 anyone--so a great team of designers, artists, programmers, and musicians should be able to make the system sing and shine just as is. Also, with any real games I'm going to try to make, I'm not sure how easy it is to actually have cartridges with these kinds of enhancement chips in them anyway, or how much additional cost they'd add for that matter, so I'd really want to avoid that kind of complication if possible and ensure the games can genuinely be made and sold in standard real-world conditions for all to enjoy. :D

Edited by Kirk_Johnston
Link to comment
Share on other sites

11 minutes ago, Kirk_Johnston said:

Exactly. Although, in an ideal world, I'd always like to stick to what the stock SNES can do, because I feel like it's kinda admitting defeat or cheating if we have to use an enhancement chip. And my absolute belief is it really is possible to do amazing stuff on the stock SNES--Rendering Ranger R2 anyone--so a great team of designers, artists, programmers, and musicians should be able to make the system sing and shine just as is. Also, with any real games I'm going to try to make, I'm not sure how easy it is to actually have cartridges with these kinds of enhancement chips in them anyway, or how much additional cost they'd add for that matter, so I'd really want to avoid that kind of complication if possible and ensure the games can genuinely be made and sold in standard real-world conditions for all to enjoy. :D

Enhancement chips are how Nintendo intended the console to be used, so that's why I don't consider it admitting defeat or cheating.  I don't even consider the Uniracers trick to be cheating, because it's a valid cartridge you stick in and the game works.  Extra VRAM tricks that only work in special emulators or modded consoles is cheating.  But keeping complexity under control is not a bad idea either.

  • Like 1
Link to comment
Share on other sites

1 hour ago, jeffythedragonslayer said:

Enhancement chips are how Nintendo intended the console to be used, so that's why I don't consider it admitting defeat or cheating.  I don't even consider the Uniracers trick to be cheating, because it's a valid cartridge you stick in and the game works.  Extra VRAM tricks that only work in special emulators or modded consoles is cheating.  But keeping complexity under control is not a bad idea either.

Yeah, I actually agree with you ultimately, but it helps silence the haters when they can't argue it was/is only possible because an enhancement chip was used (and I do still have a bee in my bonnet about that). I still want to avoid using them if necessary though, and especially if it's not something that's entirely frictionless to add into actual physical cartridges if I do eventually get around to releasing a real game at some point. And, yeah, it's just good practice to ideally try and work within the stock SNES limits if possible methinks, as it means the team really is doing things efficiently and optimally through the process from design to code. But, hey, if someone has an idea for a SNES games that will utterly blow people's minds but requires an enhancement chip to run properly, I have no problem with that whatsoever. That's still a totally legit real SNES game as far as I'm concerned, just like Pilotwings, Super Mario Kart, Super Mario RPG, Star Fox and so on absolutely are. I'd just be happy to see a bunch more new indie/homebrew games either way. :)

Edited by Kirk_Johnston
Link to comment
Share on other sites

17 minutes ago, Kirk_Johnston said:

Yeah, I actually agree with you ultimately, but it helps silence the haters when they can't argue it was/is only possible because an enhancement chip was used (and I do still have a bee in my bonnet about that). I still want avoid using them if necessary though, and especially if it's not something that's entirely frictionless to add into actual physical cartridges if I do eventually get around to releasing a real game at some point. And, yeah, it's just good practice to ideally try and work within the stock SNES limits if possible methinks, as it means the team really is doing things efficiently and optimally through the process from design to code. But, hey, if someone has an idea for a SNES games that will utterly blow people's minds but requires an enhancement chip to run properly, I have no problem with that whatsoever--that's still a totally legit real SNES game as far as I'm concerned, just like Pilotwings and Super Mario Kart and Super Mario RPG and Star Fox and so on absolutely are--I'd just be happy to see a bunch more new indie/homebrew games either way. :)

Oh, I see.  How are you planning on handling the haters that will say "That's only possible because of 40 years of SNES research?" 😜

 

Seriously though, in some sense I feel like any publicity is good publicity for the snes scene.  It's like the people who constantly talk about how much they hate Kim Kardashian, they are fans whether they realize it or not.  Every time a hater decides to interact with you they only make the SNES more popular because they're giving you information on what to focus on debunking.

  • Thanks 1
Link to comment
Share on other sites

8 minutes ago, jeffythedragonslayer said:

Oh, I see.  How are you planning on handling the haters that will say "That's only possible because of 40 years of SNES research?" 😜

 

Seriously though, in some sense I feel like any publicity is good publicity for the snes scene.  It's like the people who constantly talk about how much they hate Kim Kardashian, they are fans whether they realize it or not.  Every time a hater decides to interact with you they only make the SNES more popular because they're giving you information on what to focus on debunking.

Tell me about it--on both points! :D

Link to comment
Share on other sites

12 hours ago, jeffythedragonslayer said:

I believe you can kick off a DMA outside of the blanking periods just fine, it's just that if the target location is VRAM then the writes will fail.

Shoot! I feel like this is 101 stuff I should've known... 😅 Thanks for this clarification 😁 

 

6 hours ago, Kirk_Johnston said:

OK. Cool, thanks.

 

So, is there any way for me to know at a high level [in layman terms] roughly how many game logic things the SNES can do during active scan then per frame, and indeed how many of those things roughly I'm currently doing for comparison, just so I would have a rough idea of the limit and how close any game logic stuff I'm currently doing would be to it?

 

I mean, again, right now I think I'm doing very little of that stuff, just updating the position of a few backgrounds and sprites tiles, reading the controller for when the player moves left and right, making those small ghosts occasionally move towards the player's position, plus a little bit of timer-based stuff and that's about it really. Most of the rest would seem like it would be done during VBlank and HBlank thus far. So my guess is that this, while it looks like a lot going on, would barely be taxing the SNES.

You're safe, I'm sure the SNES isn't breaking a sweat in your demo. One minor caveat is that if the window gfx is using color math, the translucent ghosts won't blend together with it. One will simply clip out the other (I'm guessing any overlapping will just show the next opaque thing being blended). This should go for any translucent gfx overlapping each other.

 

However it might be a pain to do masking in game maker, not sure if it's worth it for a mock up lol 😅 maybe you can use GM's "surfaces" to mimic the effect.

 

 

Edited by JurassicDope
  • Like 1
Link to comment
Share on other sites

2 hours ago, JurassicDope said:

You're safe, I'm sure the SNES isn't breaking a sweat in your demo. One minor caveat is that if the window gfx is using color math, the translucent ghosts won't blend together with it. One will simply clip out the other (I'm guessing any overlapping will just show the next opaque thing being blended). This should go for any translucent gfx overlapping each other.

 

However it might be a pain to do masking in game maker, not sure if it's worth it for a mock up lol 😅 maybe you can use GM's "surfaces" to mimic the effect.

Yeah, I put a wee note of that in the description of the YouTube video explaining that it's not 100% SNES accurate there, so hopefully people read that. I also added a link to Super Mario World so people can see what it basically should look like.

 

I'll just leave it as is in the GameMaker 8.1 mockup though. Lol

 

Also, as a wee side point on the transparency stuff, this game has some great examples of overlapping semi-transparent objects/sprites (both the obvious ghosts and the subtle mist in the background), and it really shows that even though it's not true multi-layered semi-transparency, the overall effect when two or more of the ghosts cross over each other still looks great (and they're technically always crossing over the mist too):

 

I'll definitely be cool with how it works in any game I eventually make myself. :D

 

And, as per usual, I'm shocked more SNES developers didn't use this type of thing much more often, and that the guys in SNESdev actively seem to dissuade people from such a thing in my experience, or at least just make it seem like a bad thing, something to be avoided, rather than something 99.9% of people wouldn't even notice and/or be totally fine with, indeed maybe even rather impressed by.

 

I totally have an idea for a Ghostbusters or Luigi's Mansion game done like this, which I think would look just awesome. And either the proton beam or Luigi's torch would also use semi-transparency too. :D

 

Also, since I just posted about it, that final boss battle in Prehistoric Man is very cool visually too (as are quite a few moments in the game):

Some of the choice moments I marked for future reference (for various reasons): 9:25, 15:13, 31:00, 31:35, 35:08, 1:16:40, 1:19:00, 1:42:58, 2:03:11, 2:05:05, 2:07:19, 2:18:39, 2:19:45, 2:23:19

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

9 hours ago, Kirk_Johnston said:

So, is there any way for me to know at a high level [in layman terms] roughly how many game logic things the SNES can do during active scan then per frame, and indeed how many of those things roughly I'm currently doing for comparison, just so I would have a rough idea of the limit and how close any game logic stuff I'm currently doing would be to it?

Whoops, I forgot to address this: I suppose whenever I jump into things and find the actual answer, I can make some visuals so the layman can have a real good idea of what they are working with. Nothing fancy like Retro Mechanics Explained videos, but hopefully interesting and understandable.

Edited by JurassicDope
  • Like 1
Link to comment
Share on other sites

26 minutes ago, JurassicDope said:

Whoops, I forgot to address this: I suppose whenever I jump into things and find the actual answer, I can make some visuals so the layman can have a real good idea of what they are working with. Nothing fancy like Retro Mechanics Explained videos, but hopefully interesting and understandable.

That would be awesome! :D

 

PS. I love the Retro Game Mechanics Explained videos. His SNES stuff is probably the best resource I've found online to date just explaining how most of the system works under the hood. If only all the SNES resources online and indeed tools were as well put together and as [relatively] easy to follow as those videos. I messaged the guy once and asked if he was ever planning on doing some actual tutorials on how to learn to code for SNES, with nice clear game/demo/practice examples and stuff plus details on even how to just get the development environment setup and so on too, and he said it was something he's thinking of but maybe a while down the line. I look forward to that very much. :D

 

PPS. I did try a wee go at a background modes guide myself (not a video mind you, just a blog post), but that's about as deep as I can go on a technical level: 

 

https://inceptionalnews.wordpress.com/2022/08/26/snes-background-modes/

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

41 minutes ago, Kirk_Johnston said:

That would be awesome. 

 

PS. I love the Retro Game Mechanics Explained videos. His SNES stuff is probably the best resource I've found online to date just explaining how most of the system works under the hood. If only all the SNES resources online and indeed tools were as well put together and as [relatively] easy to follow as those videos. I messaged the guy once and asked if he was every planning on doing some actual tutorials on how to code for SNES, with nice clear game/demo/practice examples and stuff, and he said it was something he's thinking of but maybe a while down the line. I look forward to that very much. :D

 

PPS. I did try a wee go at a background modes guide myself (not a video mind you), but that's about as deep as I can go on a technical level: 

 

https://inceptionalnews.wordpress.com/2022/08/26/snes-background-modes/

Nice! Yeah, I'd probably explain something in a blog-like manner. I'll check your post little by little on my downtime, good stuff 👍 

 

Quick question: would you or jeffythedragonslayer happen to know if SNES mode 2 can separately tilt both layers? I've only seen this in MD games, but never in Snes. RGME says both layers can activate Offset Per Tile at the same time, but doesn't specify if they can tilt separately. I've also once read that it cannot (from a reputable source who I won't name, especially since I just can't find that quote for the life of me), I'll honestly be surprised if that's true.

 

 

chrome_screenshot_1683136062915.png

chrome_screenshot_1683135805309.png

gunstar-heroes-sega-mega-drive.gif

Edited by JurassicDope
Link to comment
Share on other sites

32 minutes ago, JurassicDope said:

Nice! Yeah, I'd probably explain something in a blog-like manner. I'll check your post little by little on my downtime, good stuff 👍 

 

Quick question: would you or jeffythedragonslayer happen to know if SNES mode 2 can separately tilt both layers? I've only seen this in MD games, but never in Snes. RGME says both layers can activate Offset Per Tile at the same time, but doesn't specify if they can tilt separately. I've also once read that it cannot (from a reputable source who I won't name, especially since I just can't find that quote for the life of me), I'll honestly be surprised if that's true.

 

 

chrome_screenshot_1683136062915.png

chrome_screenshot_1683135805309.png

gunstar-heroes-sega-mega-drive.gif

What you have read about offset change mode appears to be true according to the official manual; there is only one page describing it so it's not that bad, but worded a bit weird (how do you "perform" a value?):

 

https://archive.org/details/SNESDevManual/book1/page/n77

 

I think a picture of the effect would have been more valuable here than the flowchart.

 

fullsnes seems to confirm it too, Ctrl+F for "Scroll offset to be applied to BG1/BG2"

There are only about half as many bits as precision I'd expect to be there if BG1 and BG2 could be scrolled separately.

Edited by jeffythedragonslayer
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, JurassicDope said:

Nice! Yeah, I'd probably explain something in a blog-like manner. I'll check your post little by little on my downtime, good stuff 👍 

 

Quick question: would you or jeffythedragonslayer happen to know if SNES mode 2 can separately tilt both layers? I've only seen this in MD games, but never in Snes. RGME says both layers can activate Offset Per Tile at the same time, but doesn't specify if they can tilt separately. I've also once read that it cannot (from a reputable source who I won't name, especially since I just can't find that quote for the life of me), I'll honestly be surprised if that's true.

 

 

chrome_screenshot_1683136062915.png

chrome_screenshot_1683135805309.png

gunstar-heroes-sega-mega-drive.gif

I would say it surely must be able to given this demo literally changes background mode seven times down the screen and obviously does different column scrolling on each of the background modes that use it:

 

https://forums.nesdev.org/download/file.php?id=6153&sid=68906f9999bf10432659c700b09620f6

 

And here's a link to a SNES emulator in case you actually want to run it and don't have one installed yet:

 

https://www.mesen.ca/snes/download.php

 

I mean, I'm not entirely 100% sure if it can do the exact method in your clips above, and I can't recall off the top of my head if I've seen a clear example of two full background layers being column scrolled separately, but I would think it's possible.

 

Again, it seems like another case where SNES developers were just not taking full advantage of the system.

 

Edit: What the hell am I talking about--it's actually doing it in that demo I posted already, multiple times. So, unequivocally, YES. LOL

 

The side tilting would just be done with HDMA per scanline and combined with the column scrolling, and even with a higher fidelity than on Genesis.

 

I mean, let's be honest, if someone actually knows what they're doing and we have a talented designer, artist and programmer working together, they could have way more than just two or three differently tilting layer-based objects, clearly. The dude has five in his demo, along with all the other layer stuff also going on at the same time.

 

For me, the thing with SNES is it has all this untapped potential just waiting for the right people to come along and actually tap into it.

Edited by Kirk_Johnston
  • Like 1
Link to comment
Share on other sites

36 minutes ago, jeffythedragonslayer said:

What you have read about offset change mode appears to be true according to the official manual; there is only one page describing it so it's not that bad, but worded a bit weird (how do you "perform" a value?):

 

https://archive.org/details/SNESDevManual/book1/page/n77

 

I think a picture of the effect would have been more valuable here than the flowchart.

 

fullsnes seems to confirm it too, Ctrl+F for "Scroll offset to be applied to BG1/BG2"

There are only about half as many bits as precision I'd expect to be there if BG1 and BG2 could be scrolled separately.

Ahhhh, thank you for this great detective work!

8 minutes ago, Kirk_Johnston said:

I would say it surely must be able to given this demo literally changes background mode seven times down the screen and obviously does different column scrolling on each of the background modes that use it:

 

https://forums.nesdev.org/download/file.php?id=6153&sid=68906f9999bf10432659c700b09620f6

 

And here's a link to an emulator in case you actually want to run it and don't have on installed yet:

 

https://www.mesen.ca/snes/download.php

 

I mean, I'm not entirely 100% sure if it can do the exact method in your clips above, and I can't recall off the top of my head if I've seen a clear example of two fully background layers being column scrolled separately, but I would think it's possible.

 

Again, it seems like another case where SNES developers were just not taking full advantage of the system.

 

Edit: What the hell am I talking about--it's actually doing it in that demo I posted already, multiple times. So, unequivocally, YES. LOL

 

I mean, let's be honest, if someone actually knows what they're doing and we have a talented programmer working with a talented designer, they could have way more than just two or three different tilting layer-based objects, clearly.

Unfortunately I temporarily don't have Internet service for a few days to D/L stuff to my computer, do you happen to have a screenshot of the demo running?

 

If it indeed can pull it off, it's a bit strange it wasn't taken advantage of in the past 🤔

Link to comment
Share on other sites

23 minutes ago, JurassicDope said:

Ahhhh, thank you for this great detective work!

Unfortunately I temporarily don't have Internet service for a few days to D/L stuff to my computer, do you happen to have a screenshot of the demo running?

 

If it indeed can pull it off, it's a bit strange it wasn't taken advantage of in the past 🤔

Here's some footage of the demo:

 

And here's some footage of the SNES doing the row/line scrolling plus column scrolling on a single layer along with just row/line scrolling on the other layer in an actual game too (unfinished and unreleased, unfortunately):

 

Also worth noting, the SNES can actually do higher fidelity column scrolling than Genesis, down to every 8 pixels rather than just every 16, so the effect of tilting the screen using row scrolling plus row/line scrolling can in fact look smoother on SNES. I know a direct comparison for this but can't remember the name of the game just now, so give me a sec and I'll post a clip of each. . . .

 

Edit: Yeah, it's the tilting helicopter in Time Trax:

 

SNES:

 

Genesis:

Edited by Kirk_Johnston
  • Thanks 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...