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

[Kirk_Johnston]

10 minutes ago, Creamhoven said:

It is a very sweet intro. It did, however, use the SuperFX2 chip.

The chip was actually used for other stuff beyond the intro, other than probably the scaling sack bit of the intro (I'd need to double check any moments). The intro is totally possible on a stock SNES no problem (for the most part). In fact, 99% of Yoshi's Island is actually possible on a stock SNES, but the chip did help make things easier with not having to optimize as well while still maintaining a solid framerate, plus doing some cool sprite scaling/rotation (not normally possible on stock SNES), and some 3D and such too (also not normally [practically] possible on stock SNES--but not impossible, which you can see below)

Edited May 24, 2023 by Kirk_Johnston

[Creamhoven]

4 minutes ago, Kirk_Johnston said:

The chip was actually used for other stuff, other than probably the scaling sack bit (I'd need to double check any moments). The intro is totally possible on a stock SNES no problem (for the most part). In fact, 99% of Yoshi's Island is actually possible on a stock SNES, but the chip did help make things easier with not having to optimize as well, plus doing some cool sprite scaling/rotation (not normally possible on SNES), and some 3D and such too.

Okay. Do you have a particular cartridge configuration you want to use?

[Kirk_Johnston]

11 minutes ago, Creamhoven said:

Okay. Do you have a particular cartridge configuration you want to use?

Not really sure as that's a long way off. I still don't even have anyone who's willing to get involved in the programming side yet, which is essential for it to ever move any further forward, as I'm not going to be doing the programming myself--unless by some miracle an actual good SDK and/or really intuitive SNES game creation tool along the lines of NESmaker or GameMaker 8.1 comes out in the near-ish future. But, I'd just want to make sure it's as big a cartridge as possible, like 48 Megabits or whatever, and it's running in FastROM. Outside of that, not really thought about it to be honest.

Edited May 24, 2023 by Kirk_Johnston

[Creamhoven]

31 minutes ago, Kirk_Johnston said:

Not really sure as that's a long way off. I still don't even have anyone who's willing to get involved in the programming side yet, which is essential for it to ever move any further forward, as I'm not going to be doing the programming myself--unless by some miracle an actual good SDK and/or really intuitive SNES game creation tool along the lines of NESmaker or GameMaker 8.1 comes out in the near-ish future. But, I'd just want to make sure it's as big a cartridge as possible, like 48 Megabits or whatever, and it's running in FastROM. Outside of that, not really thought about it to be honest.

Okay, I would suggest we work with original hardware in the graphical department, but use the Msu1 for audio. I have listened to the OST of a homebrew release and I don't want to be mean, but the audio was a**, which might be because of an abscense of approachable tools. Producing the audio in CD quality would be much better. When it comes to mode0 tech it is important I think to come with a killerapp, just like you sell consoles only with good games.

Edited May 24, 2023 by Creamhoven

[Kirk_Johnston]

At some point you start to wonder if the SNES can really do all of this on-screen at once:

 

It can.

 

And I thought I'd just add this too:

Edited May 25, 2023 by Kirk_Johnston

[Creamhoven]

1 hour ago, Kirk_Johnston said:

At some point you start to wonder if the SNES can really do all of this on-screen at once:

 

It can.

 

And I thought I'd just add this too:

Dear Kirk,

 

would you say there are any limits to the SNES in mode 0?

[Kirk_Johnston]

45 minutes ago, Creamhoven said:

Dear Kirk,

 

would you say there are any limits to the SNES in mode 0?

Absolutely. I'd say my mockups are nearing the limits now, but maybe not quite yet.

Edited May 25, 2023 by Kirk_Johnston

[JurassicDope]

Whoa... so far I think it's all doable in Mode 0, good work👏 also quite the party Dracula is throwing lol.

 

Iirc, for the entities made from windows + hdma combo, they can't be scrolled in a simple fashion such as planes or sprites. I'm guessing they need 2 values for its width per scanline (one for where it starts, and another value for where it ends). So to make them move around, we'd need to add or subtract an offset from the 2 values per scanline every frame... or, we store pre-calculated positions on a table that we can copy to each scanline.

 

So one one option eats into cpu, and the other eats into memory, where the taller the window-entity is, the more resources it'll need... Or I have no idea what I'm talking about 😖 either way, there's no way it'll have an effect on a demo such as this, but in a real game, it's something to consider and balance👍

 

Yeah, 4bpp is a big vram killer with a boss scenario like this. I too am super curious to see this running on roms for both snes and genesis to compare. I'm still practically a novice programmer, and I currently have some Unity and art asset duties to get to, but hopefully I can come around to demo-ing something for either console in a few weeks here 🙀

Edited May 25, 2023 by JurassicDope

[Kirk_Johnston]

57 minutes ago, JurassicDope said:

Whoa... so far I think it's all doable in Mode 0, good work👏 also quite the party Dracula is throwing lol.

 

Iirc, for the entities made from windows + hdma combo, they can't be scrolled in a simple fashion such as planes or sprites. I'm guessing they need 2 values for its width per scanline (one for where it starts, and another value for where it ends). So to make them move around, we'd need to add or subtract an offset from the 2 values per scanline every frame... or, we store pre-calculated positions on a table that we can copy to each scanline.

 

So one one option eats into cpu, and the other eats into memory, where the taller the window-entity is, the more resources it'll need... Or I have no idea what I'm talking about 😖 either way, there's no way it'll have an effect on a demo such as this, but in a real game, it's something to consider and balance👍

 

Yeah, 4bpp is a big vram killer with a boss scenario like this. I too am super curious to see this running on roms for both snes and genesis to compare. I'm still practically a novice programmer, and I currently have some Unity and art asset duties to get to, but hopefully I can come around to demo-ing something for either console in a few weeks here 🙀

Yeah, they can effectively be "scrolled" by changing the values each frame in some lookup table or whatever. I dunno the exact ins and outs of how it's specifically coded in Assembly on SNES, just that you can make move/scale/change them dynamically, as there's already plenty of examples of such dynamic window/shape/colour masks in quite a few SNES games (think of the scan beam in Super Metroid, the underwater light cone on DKC 2, the character-shaped scaling fade in/out effects at the start of the levels in Maui Mallard, the smart bombs in Contra III and Turrican 2, and during the boss battle in R-Type III, etc*). And I think, with well-written code that's properly optimized, it shouldn't be too much of a drain on resources to draw the ghost shapes and move them slowly back and forth. I mean, most of the values are going to modified in HDMA on each scanline during HBlank to draw the shape and position, so not really eating into the main code that runs during VBlank, at least as I understand it. And, assuming we're not doing more than the max eight operations or whatever they're called that are possible during each HBlank period, it shouldn't be an issue, again, at least as I understand it. It's probably not as "simple" as I imagine, but probably not as complex or resource hungry as some other people might imagine, if someone really knows the optimal way to go about it I guess. This is why I'd love for a SNES programmer to step up and actually try to make either my mockup for real or something like it, because once it's done even a single time it is then beyond doubt and debate. So, I sit and patiently wait . . . Lol

 

*

 

And, just to point out, I think it's clear that any slowdown we see in the likes of Contra and Turrican during the smart bomb moments are almost certainly due to the games running in SlowROM and/or not quite perfectly optimized code. We've seen how much just going to FastROM can improve Contra III for example. And we've seen just how much switching to FastROM plus properly optimizing code can improve the likes of Gradius III:

 

So I'd obviously be expecting that level of skilz from the ol' programmer in my example too.

Edited May 25, 2023 by Kirk_Johnston

[Kirk_Johnston]

I just noticed that the smart bomb in Contra III only displays every second frame in 2-player mode, so this is a better/smoother example of it in 1-player:

 

I might as well add in a slightly updated tile sheet now too, so people can see how it might be arranged and how the various sprite-based enemies would be made up of multiple 16x16 and 32x32 objects:

 

If you count the actual objects/sprites used, you can see that while the VRAM might be running out of space for unique tiles, there's still plenty of the max 128 objects/sprites on-screen available for adding a whole load more of say those 16x16 ghosts if I wanted (honestly, it's like about 80 more 16x16 objects/sprites that are still unused), just positioned so as to avoid going over the max objects/sprites/sprite-pixels per scanline obviously.

Edited May 25, 2023 by Kirk_Johnston

[Creamhoven]

43 minutes ago, Kirk_Johnston said:

I just noticed that the smart bomb in Contra III only displays every second frame in 2-player mode, so this is a better/smoother example of it in 1-player:

 

I might as well add in a slightly updated tile sheet now too, so people can see how it might be arranged and how the various sprite-based enemies would be made up of multiple 16x16 and 32x32 objects:

 

If you count the actual objects/sprites used, you can see that while the VRAM might be running out of space for unique tiles, there's still plenty of the max 128 objects available for adding a whole load more of say those ghosts on-screen if I wanted (honestly, it's like about 80 more 16x16 objects/sprites that are still unused), just positioned so as to avoid going over the max objects/sprites/sprite-pixels per scanline obviously.

We could create a scene where all the money of the Evil Nooker is falling from the sky. This way we can reuse tiles and have 128 objects in use, right?

Edited May 25, 2023 by Creamhoven

[Kirk_Johnston]

1 minute ago, Creamhoven said:

We could create a scene where all the money of the Evil Nooker is falling from the sky. This way we can reuse sprites and have 128 objects in use, right?

Well, we could have say 128 coins/wads falling minus however many objects are already taken up for the other sprites that would be on-screen, plus we'd just need to make sure not too many of them are on the same scanline(s) at any time if we want to avoid flicker.

[Creamhoven]

1 minute ago, Kirk_Johnston said:

Well, we could have say 128 coins/wads falling minus however many objects are already taken up for the other sprites that would be on-screen, plus we'd just need to make sure not too many of them are on the same scanline(s) at any time if we want to avoid flicker.

You are a genious, Kirk.

[Kirk_Johnston]

10 minutes ago, Creamhoven said:

You are a genious, Kirk.

Dang it--now I kinda feel like making a bunch of Mario coins fall down the screen too!

 

But, man, I'd really need to try and make sure I'm not breaking any of the rules and showing too many coins in a row, especially down the bottom half of the screen where there's not much space left if I account for the few small ghosts that could be fly down there at any time that takes me very close to the max objects/sprites per scanline limit, or you know someone is immediately gonna jump on it and claim the SNES couldn't do that (well, at least not without flicker anyway).

 

I really shouldn't do it . . .

 

😛

Edited May 25, 2023 by Kirk_Johnston

[Creamhoven]

1 minute ago, Kirk_Johnston said:

Dang it--now I kinda feel like making a bunch of Mario coins fall down the screen too!

 

But, man, I'd really need to try and make sure I'm not breaking any of the rules and showing too many coins in a row, especially down the bottom half of the screen where there's not much space left if I account for the few small ghosts that could be fly down there at any time that takes me very close to the max objects/sprites per scanline limit, or you know someone is immediately gonna jump on it and claim the SNES couldn't do that (well, at least not without flicker anyway).

 

I really shouldn't do it . . .

 

😛

Yes, beware the mode 0 deniers. We could have a big Evil Nooker with the title 'Let the money grabbling commence!' and all the coins falling.

[JurassicDope]

Heck, I'd even say your demo running on real hardware could handle full screen window shapes scaling / rotating at a full 60fps. However on action intense gameplay like Turrican or Contra, you'll want to keep an eye on pretty much any additional real-time calculations you are doing with tall windows (you won't have to worry about width, though). Since something like a beam of light that starts at the top of the screen, and ends at the bottom would need maybe:

 

448 "adds" to some values stored in work RAM per frame to move it any amount of pixels to the right (the amount would be insignificant, could be one pixel, or 255 pixels to the right, we'll be dealing changes in values that would fit in 8-bits). I'm not sure how many cpu cycles worth is adding 448 times, it should be a piece of cake even in action games like the aforementioned Turrican / Contra to maintain 60fps (the smart bombs slow down since they are doing scaling in real-time I bet), but when you are in the business of pushing the limits like us, it'll start to be a bigger deal.

 

Quote

I mean, most of the values are going to modified in HDMA on each scanline during HBlank to draw the shape and position, so not really eating into the main code that runs during VBlank, at least as I understand it

Hmm, I reckon the main game code is processed during active scan (such as doing the math on your values in RAM, and game logic such as your character's physics and player states), while you reserve VBlank to do your DMA stuff (loading tiles and map data into VRAM). (Hopefully I'm not coming off like a "know-it-all" nerd, just wanted to give some perspective of my understanding so you won't be completely left in the dark. I've been on the same boat for a long time, being more of an artist and game designer, so maybe sharing what I have been learning can help further discussion 😎👍)

Quote

It's probably not as "simple" as I imagine, but probably not as complex or resource hungry as some other people might imagine, if someone really knows the optimal way to go about it I guess. This is why I'd love for a SNES programmer to step up and actually try to make either my mockup for real or something like it, because once it's done even a single time it is then beyond doubt and debate. So, I sit and patiently wait . . . Lol

I only have a vague idea of how hdma works, so I can't confirm much about it, along with many other SNES particularities. Though I think you have the basic gist of it. I really do look forward to a SNES maker myself, would be fun to get some more indie devs involved!

 

Edit: Dang mobile, made me send my post to early... wait for next edit #2...

 

Edit2: finished

 

Edit #3:

I for one am interested in making games in the style circa 1995-98. All the tricks are known and already put to good use. 4MB (32 megabits) sizes seems to become viable for developers, not yet in the realm of gigabytes of media, keeping cd media relevant. The rise of 3d and C language becoming used more in game development. 

Edited May 25, 2023 by JurassicDope

[Kirk_Johnston]

22 minutes ago, Creamhoven said:

Yes, beware the mode 0 deniers. We could have a big Evil Nooker with the title 'Let the money grabbling commence!' and all the coins falling.

I also think I need to be somewhat careful when it comes to how many sprites/tiles I'm animating on-screen at once too, as, if I have this correct, the SNES can only update a max of around 180 8x8 tiles per frame in 4bpp mode (I think more if HDMA is used) and 360 in 2bpp mode (I think more if HDMA is used)--unless that's not quite the same thing as streaming in new tiles, which is what I think I was was asking someone about before--so that's another thing to keep in mind also, especially considering this also all takes up some of the CPU resources and the like as well along with the other stuff I'm currently doing like scrolling each of the boss layers, streaming in new tiles for Alucard, updating the window masks, and so on. The poor SNES is gonna have a hissy fit! But, I still feel like if it's all managed properly, the SNES can handle it--I think. Lol

Edited May 25, 2023 by Kirk_Johnston

[Kirk_Johnston]

25 minutes ago, JurassicDope said:

Heck, I'd even say your demo running on real hardware could handle full screen window shapes scaling / rotating at a full 60fps. However on action intense gameplay like Turrican or Contra, you'll want to keep an eye on pretty much any additional real-time calculations you are doing with tall windows (you won't have to worry about width, though). Since something like a beam of light that starts at the top of the screen, and ends at the bottom would need maybe:

 

448 "adds" to some values stored in work RAM per frame to move it any amount of pixels to the right (the amount would be insignificant, could be one pixel, or 255 pixels to the right, we'll be dealing changes in values that would fit in 8-bits). I'm not sure how many cpu cycles worth is adding 448 times, it should be a piece of cake even in action games like the aforementioned Turrican / Contra to maintain 60fps (the smart bombs slow down since they are doing scaling in real-time I bet), but when you are in the business of pushing the limits like us, it'll start to be a bigger deal.

 

Hmm, I reckon the main game code is processed during active scan (such as doing the math and your values in RAM, and game logic such as your character's physics and player states), while you reserve VBlank to do your DMA stuff (loading tiles and map data into VRAM). (Hopefully I'm not coming off like a "know-it-all" nerd, just wanted to give some perspective of my understanding so you won't be completely left in the dark. I've been on the same boat for a long time, being more of an artist and game designer, so maybe sharing what I have been learning can help further discussion 😎👍)

I only have a vague idea of how hdma works, so I can't confirm much about it, along with many other SNES particularity.

 

Edit: Dang mobile, made me send my post to early... wait for next edit #2...

Yeah, this is exactly why it would be great to be working directly alongside a proper open-minded SNES programmer with each step of this, so we could add one thing at a time and really make sure it's all being done correctly and indeed optimally. At the moment I don't think I'm doing anything extreme--it just looks like a lot for the most part because of all the huge objects moving independently, even though most of them are actually doing really basic stuff--so it should still be good as far as I'm aware.

 

So, I obviously got a little bit confused about how and when the SNES is actually running code stuff under the hood. Can you try to explain a bit further about how the code runs during the different times from drawing a line of the image on-screen to HBlank and Vblank, etc? My thinking was a line of pixels gets put/drawn on-screen, then during the blank time where the beam moves back to the other side of the screen before drawing again the SNES can use HDMA to do some stuff (not a lot, but some), then at the bottom of the screen it also has a bit of VBlank time to do some more stuff before it returns to the top of the screen and starts drawing a line again. Basically, my thinking was the machine runs whatever code when it's not actively drawing something to the screen, so you have to get everything codewise done during VBlank and HBlank (or forced blank), but it seems I may have totally gotten that wrong. 

 

PS. This is why I've never seriously taken up the coding mantle--because it's all so convoluted and obscure. Lol

Edited May 25, 2023 by Kirk_Johnston

[Creamhoven]

22 minutes ago, Kirk_Johnston said:

I also think I need to be somewhat careful when it comes to how many sprites/tiles I'm animating on-screen at once too, as, if I have this correct, the SNES can only update a max of around 180 8x8 tiles per frame in 4bpp mode (I think more if HDMA is used) and 360 in 2bpp mode (I think more if HDMA is used)--unless that's not quite the same thing as streaming in new tiles, which is what I think I was was asking someone about before--so that's another thing to keep in mind also, especially considering this also all takes up some of the CPU resources and the like as well along with the other stuff I'm currently doing like scrolling each of the boss layers, streaming in new tiles for Alucard, updating the window masks, and so on. The poor SNES is gonna have a hissy fit! But, I still feel like if it's all managed properly, the SNES can handle it--I think. Lol

We will have to see and find out. If you want to give the coin demo a shot here is a fitting background:

 

[Kirk_Johnston]

1 minute ago, Creamhoven said:

We will have to see and find out. If you want to give the coin demo a shot here is a fitting background:

 

Well, if it's literally just that background, a bunch of falling coins, and the player running around grabbing them, we could get a crap-load on-screen. Is that what you mean?

[Kirk_Johnston]

I have to head of to bed now, so I will continue with both you guys the morrow. . . .

 

[Creamhoven]

28 minutes ago, Kirk_Johnston said:

Well, if it's literally just that background, a bunch of falling coins, and the player running around grabbing them, we could get a crap-load on-screen. Is that what you mean?

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!

Edited May 26, 2023 by Creamhoven

[JurassicDope]

23 minutes ago, Kirk_Johnston said:

Yeah, this is exactly why it would be great to be working directly alongside a proper open-minded SNES programmer with each step of this, so we could add one thing at a time and really make sure it's all being done correctly and indeed optimally. At the moment I don't think I'm doing anything extreme--it just looks like a lot for the most part because of all the huge objects moving independently, even though most of them are actually doing really basic stuff--so it should still be good as far as I'm aware.

 

So, I obviously got a little bit confused about how and when the SNES is actually running code stuff under the hood. Can you try to explain a bit further about how the code runs during the different times from drawing a line of the image on-screen to HBlank and Vblank, etc? My thinking was a line of pixels gets put/drawn on-screen, then during the blank time where the beam moves back to the other side of the screen before drawing again the SNES can use HDMA to do some stuff (not a lot, but some), then at the bottom of the screen it also has a bit of VBlank time to do some more stuff before it returns to the top of the screen and starts drawing a line again. Basically, my thinking was the machine runs whatever code when it's not actively drawing something to the screen, so you have to get everything codewise done during VBlank and HBlank (or forced blank), but it seems I may have totally gotten that wrong. 

 

PS. This is why I've never seriously taken up the coding mantle--because it's all so convoluted and obscure. Lol

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.

[JurassicDope]

AFAIK, you can also write to VRAM using the CPU, but DMA is built for that kind of stuff and goes way faster. If someone else would like to correct me or confirm, that'll be nice 👍 

 

I'll be actually dabbling in this stuff soon, I'll update in the future.

Edited May 26, 2023 by JurassicDope

[jeffythedragonslayer]

7 minutes 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.

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.