How to Manage VRAM Limits for the Sega Genesis & Mega Drive

How to Manage VRAM Limits for the Sega Genesis & Mega Drive - Beginner Game Dev Tutorials

Рет қаралды 1,703

Pigsy's Retro Game Dev Tutorials

Ай бұрын

Please consider supporting me on Patreon:
/ pigsysretrogamedevtuto...
My X/Twitter account:
x.com/PigsyRetro

Пікірлер: 39

@man4171 Ай бұрын

Thanks for the video, it's fantastic how you explain things. For this and the previous ones they deserve a subscription to the patreon.

@PigsysRetroGameDevTutorials Ай бұрын

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)

@martinhardy7659 27 күн бұрын

Great tutorial this is really interesting work

@MaxAbramson3 Ай бұрын

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.

@MaxAbramson3 Ай бұрын

@rafaelantonio6765 So in VRAM, tiles must be tagged as either sprite or background?

@MaxAbramson3 Ай бұрын

@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?

@iwanttocomplain Ай бұрын

@@rafaelantonio6765 or colour cycling

@PigsysRetroGameDevTutorials Ай бұрын

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

@zummone Ай бұрын

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

@Genesis814 Ай бұрын

Thanks, Pigsy.

@guillaumenunes9319 Ай бұрын

A new jewel tutorial.

@inceptional Ай бұрын

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.

@inceptional Ай бұрын

@@rafaelantonio6765 I'm not quite sure what you are meaning here?

@inceptional Ай бұрын

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

@inceptional Ай бұрын

@@rafaelantonio6765 In what way would that work?

@PigsysRetroGameDevTutorials Ай бұрын

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

@inceptional Ай бұрын

@@PigsysRetroGameDevTutorials Yeah, I think that makes sense.

@GreyMatterShades Ай бұрын

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.

@PigsysRetroGameDevTutorials Ай бұрын

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!

@ThatOldTV Ай бұрын

I guess tutorial season is over.

@panzerdragonlegend6664 Ай бұрын

I always wondered what the difference is between Pigsy's RAM and VRAM.

@PigsysRetroGameDevTutorials Ай бұрын

VRAM stores the graphics and RAM stores things such as variables (player and enemy co-ordinates etc)

@GimblyGFR Ай бұрын

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.

@PigsysRetroGameDevTutorials Ай бұрын

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!

@TheNomcognom Ай бұрын

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

@georgemouhawesse5355 Ай бұрын

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

@luisoleiro135 Ай бұрын

Great Video, very interesting content... What about SOTN, is it close to be completed? Will it be released till the end of 2024?

@ThePhantomviper Ай бұрын

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.

@nintendo4life132 Ай бұрын

Nice demonstration, are you planning to show how to convert a video into 16-bit quality

@PigsysRetroGameDevTutorials Ай бұрын

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

@Dieg987 Ай бұрын

Hi pigsy, are you gonna do mega cd videos at some point?

@PigsysRetroGameDevTutorials Ай бұрын

Maybe a couple of years from now I'll do some MCD stuff (I need to learn this myself first)

@Dieg987 Ай бұрын

@@PigsysRetroGameDevTutorials your SOTN port gonna be insane with MCD

@iwanttocomplain Ай бұрын

I can't stop thinking about how badly Sculptured Software did the backgrounds on Genesis MK3: Ultimate.

@PigsysRetroGameDevTutorials Ай бұрын

Unfortunately, the console's palette just isn't great at doing those kind of digitised graphics

@iwanttocomplain Ай бұрын

@@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 Ай бұрын

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.