Thanks! The Patreon is small at the moment, but I appreciate everyone who can contribute. The more support I get the more I can potentially do (in terms of tutorials, fan projects etc)
This doesn't seem like an actual hardware limit but a limitation of SGDK. That is, that games have the ability on the Genesis to draw tiles either as sprites, backgrounds, or foreground tiles. SGDK seems like a great tool for building platformers, but not limit pushers.
@rafaelantonio6765 But can't we get more usable tiles by seeing if there's already a Background or Foreground tile where you can just select a different color palette for it?
SGDK allows you to strip away any parts of it you don't want (or that you need something different from). For example, Shannon Birt is using lots of custom stuff for Lufthoheit (but he's also still using lots of SGDK functions too). Of course, any non SGDK solution you think of will have its own limitations. Ultimately, there are no absolute solutions, only trade-offs
@@MaxAbramson3I haven't watched the video but the problem with using background tiles as sprites is that they're drawn with a different method: backgrounds follow a simple rasterized tile array that spans the whole drawing area, which you also store into VRAM with color information and all. Sprites also have their own sort of array, but they are drawn using 16 different tile combinations according to their size, which might result in a "line break" while reading the tiles, so to speak. In order for them to display as a random set of background tiles would, you'd have to make an object out of multiple sprites to suit your needs with no line breaks. Otherwise, you can do what you want with the graphical tiles loaded into VRAM with no hierarchy between the different drawing methods.
So, just to double check, you can basically freely allocate all of VRAM to background tiles or sprite tiles or any amount of a mix of both as you see fit, minus any space required for tile maps and such, yes? And the SGDK itself just defaults to the 1000 tiles allocated to backgrounds and 400 to sprites. Which is interesting that it does this and with those amounts, as it seems to be an arbitrary amount but is possibly based on what the tool creator(s) considered a pretty typical allocation of unique background tiles vs unique sprite tiles in the average game scene or something like that. Also interesting to note that the more of VRAM you allocate to background tiles the less you have for sprite tiles and visa versa on a kind of 1:1 basis basically, so it's always a bit of a balancing act in the typical game that tends to have both backgrounds and sprites of course, and you generally can't just allocate the entirety of VRAM memory to either backgrounds or sprites in most use cases. Nothing for free I guess.
@@rafaelantonio6765 Yes, you could limit the backgrounds to just one layer and simplify things to save some unique background tiles that way. You'd obviously lose proper overlapping parallax and such, but in certain cases that would be fine, and you can still do faux parallax row/line scrolling there. So that's one way to allow for more of the available memory to be allocated to sprites.
The graphics (both sprites and backgrounds) all share the same 64KB VRAM and I suppose the creator had to decide on a default position where the sprite tiles are loaded and I think the 1000/400 split is a reasonable one for most games. I will explain a bit more about VRAM again in the next lesson
Definitely a useful thing to know! I'm curious, would it be possible to set the number in SPR_initEx as a variable, and update it based on the needs of various scenes? Would it be possible to have a function to find how many background tiles are in a particular level, then update the SPR_initEx variable to change the sprite allocation as needed? I guess it could just be done manually, but it might be handy to automate it through code.
In my games I store the number of VRAM tiles dedicated to sprites as part of each level data. I do this manually, but it would be neat if you could do this automatically as you suggested. I think there probably is a way to do this so I might look into it!
Now I understand your response to my comment last week (you told me I should be watching that TPQ doesn't generate too many unique tiles). I completely forgot about VRAM limits. Thanks for taking on the topic in this video. I have a question for you: How would you manage the palettes to allow for palette swapping of sprites? For example, in beat'em up games, you have many enemies that are palette swaps. Given that you have only four palettes, and most likely two of them are being used for the backgrounds, you are left with two palettes for all sprites. Can you change the palette when a specific sprite is being drawn without altering the other elements on screen? Thank you very much for the video.
Every sprite is made up of indexed colours and changing the palette will change the way the colours are displayed. For the different coloured mermen enemies in SotN, we have three different sprites sharing the same palette, but the way the sprites are indexed are different). I think I featured this in one of my sotN dev videos, but can't remember exactly which one it was!
@PigsysRetroGameDevTutorials May i ask you a question? When using an emulator like gens or any other that has frameskip options... which option is more accurate regarding the "real" hw speed? Auto? 0? thanks.
I tried making a shooter uusing another game engine but there were so few learning resources.. If I obtain the genesis tools does it have everything as far as understanding code things like targeting, AI, etc. I really think I can make it a Genesis game if all the resources are available. I realy emjoyed your video on space shooters, I have all my own sprite animations andspecial effects I just can't code.
Is this an issue if I am using dynamic memory allocation? I am moving from one level state to another. But I only initiated the sprite engine once.... and the rest of the states I just reset the sprites...
@@PigsysRetroGameDevTutorials they left single colour pixels everywhere. I zoomed in. My guess is they used a palette for each bg layer, one for each fighter and one for the ui.
@@jc_dogen Sculptured are nothing special, like at all. The Mega Drive is just like going downhill compared to the snes. Was it their first smd game? Anyway. Using snes palettes is no walk in the park either for kind of different reasons.
Thanks for the video, it's fantastic how you explain things. For this and the previous ones they deserve a subscription to the patreon.
Thanks! The Patreon is small at the moment, but I appreciate everyone who can contribute. The more support I get the more I can potentially do (in terms of tutorials, fan projects etc)
Great tutorial this is really interesting work
This doesn't seem like an actual hardware limit but a limitation of SGDK. That is, that games have the ability on the Genesis to draw tiles either as sprites, backgrounds, or foreground tiles.
SGDK seems like a great tool for building platformers, but not limit pushers.
@rafaelantonio6765 So in VRAM, tiles must be tagged as either sprite or background?
@rafaelantonio6765 But can't we get more usable tiles by seeing if there's already a Background or Foreground tile where you can just select a different color palette for it?
@@rafaelantonio6765 or colour cycling
SGDK allows you to strip away any parts of it you don't want (or that you need something different from). For example, Shannon Birt is using lots of custom stuff for Lufthoheit (but he's also still using lots of SGDK functions too). Of course, any non SGDK solution you think of will have its own limitations. Ultimately, there are no absolute solutions, only trade-offs
@@MaxAbramson3I haven't watched the video but the problem with using background tiles as sprites is that they're drawn with a different method: backgrounds follow a simple rasterized tile array that spans the whole drawing area, which you also store into VRAM with color information and all. Sprites also have their own sort of array, but they are drawn using 16 different tile combinations according to their size, which might result in a "line break" while reading the tiles, so to speak. In order for them to display as a random set of background tiles would, you'd have to make an object out of multiple sprites to suit your needs with no line breaks. Otherwise, you can do what you want with the graphical tiles loaded into VRAM with no hierarchy between the different drawing methods.
Thanks, Pigsy.
So, just to double check, you can basically freely allocate all of VRAM to background tiles or sprite tiles or any amount of a mix of both as you see fit, minus any space required for tile maps and such, yes?
And the SGDK itself just defaults to the 1000 tiles allocated to backgrounds and 400 to sprites. Which is interesting that it does this and with those amounts, as it seems to be an arbitrary amount but is possibly based on what the tool creator(s) considered a pretty typical allocation of unique background tiles vs unique sprite tiles in the average game scene or something like that.
Also interesting to note that the more of VRAM you allocate to background tiles the less you have for sprite tiles and visa versa on a kind of 1:1 basis basically, so it's always a bit of a balancing act in the typical game that tends to have both backgrounds and sprites of course, and you generally can't just allocate the entirety of VRAM memory to either backgrounds or sprites in most use cases. Nothing for free I guess.
@@rafaelantonio6765 I'm not quite sure what you are meaning here?
@@rafaelantonio6765 Yes, you could limit the backgrounds to just one layer and simplify things to save some unique background tiles that way. You'd obviously lose proper overlapping parallax and such, but in certain cases that would be fine, and you can still do faux parallax row/line scrolling there. So that's one way to allow for more of the available memory to be allocated to sprites.
@@rafaelantonio6765 In what way would that work?
The graphics (both sprites and backgrounds) all share the same 64KB VRAM and I suppose the creator had to decide on a default position where the sprite tiles are loaded and I think the 1000/400 split is a reasonable one for most games. I will explain a bit more about VRAM again in the next lesson
@@PigsysRetroGameDevTutorials Yeah, I think that makes sense.
Definitely a useful thing to know! I'm curious, would it be possible to set the number in SPR_initEx as a variable, and update it based on the needs of various scenes? Would it be possible to have a function to find how many background tiles are in a particular level, then update the SPR_initEx variable to change the sprite allocation as needed? I guess it could just be done manually, but it might be handy to automate it through code.
In my games I store the number of VRAM tiles dedicated to sprites as part of each level data. I do this manually, but it would be neat if you could do this automatically as you suggested. I think there probably is a way to do this so I might look into it!
I guess tutorial season is over.
Now I understand your response to my comment last week (you told me I should be watching that TPQ doesn't generate too many unique tiles). I completely forgot about VRAM limits. Thanks for taking on the topic in this video. I have a question for you: How would you manage the palettes to allow for palette swapping of sprites? For example, in beat'em up games, you have many enemies that are palette swaps. Given that you have only four palettes, and most likely two of them are being used for the backgrounds, you are left with two palettes for all sprites. Can you change the palette when a specific sprite is being drawn without altering the other elements on screen? Thank you very much for the video.
Every sprite is made up of indexed colours and changing the palette will change the way the colours are displayed. For the different coloured mermen enemies in SotN, we have three different sprites sharing the same palette, but the way the sprites are indexed are different). I think I featured this in one of my sotN dev videos, but can't remember exactly which one it was!
I always wondered what the difference is between Pigsy's RAM and VRAM.
VRAM stores the graphics and RAM stores things such as variables (player and enemy co-ordinates etc)
A new jewel tutorial.
Great Video, very interesting content... What about SOTN, is it close to be completed? Will it be released till the end of 2024?
@PigsysRetroGameDevTutorials
May i ask you a question? When using an emulator like gens or any other that has frameskip options... which option is more accurate regarding the "real" hw speed? Auto? 0?
thanks.
I tried making a shooter uusing another game engine but there were so few learning resources.. If I obtain the genesis tools does it have everything as far as understanding code things like targeting, AI, etc. I really think I can make it a Genesis game if all the resources are available. I realy emjoyed your video on space shooters, I have all my own sprite animations andspecial effects I just can't code.
Pigsy I'm trying to find the value for VRAM used at any point in a game. I have Gens/GS r7 but it's just a wall of characters.
Nice demonstration, are you planning to show how to convert a video into 16-bit quality
I don't think video is suitable for regular cartridge games do to how much memory it takes up. Maybe later for the Mega CD
Hi pigsy, are you gonna do mega cd videos at some point?
Maybe a couple of years from now I'll do some MCD stuff (I need to learn this myself first)
@@PigsysRetroGameDevTutorials your SOTN port gonna be insane with MCD
Is this an issue if I am using dynamic memory allocation? I am moving from one level state to another. But I only initiated the sprite engine once.... and the rest of the states I just reset the sprites...
I can't stop thinking about how badly Sculptured Software did the backgrounds on Genesis MK3: Ultimate.
Unfortunately, the console's palette just isn't great at doing those kind of digitised graphics
@@PigsysRetroGameDevTutorials they left single colour pixels everywhere. I zoomed in. My guess is they used a palette for each bg layer, one for each fighter and one for the ui.
yeah but consider how tight the schedule probably was and didn't they do the snes port as well? I think they're decent conversions in the end.
@@jc_dogen Sculptured are nothing special, like at all. The Mega Drive is just like going downhill compared to the snes. Was it their first smd game? Anyway. Using snes palettes is no walk in the park either for kind of different reasons.