I hope everyone enjoys this one on large level maps. This lesson could almost be thought of as part one of a multi-part lesson, as we still need to do the camera, level collision etc. Next week's will be about converting graphics from SNES to the MD and using this to create you own level maps.
I was lucky enough to attend a talk by Hirokazu Yasuhara, who among other things was responsible for the layout of the levels of Sonic 1. I recall he said that in the engine Yuji Naka had created, each level was limited to I think 32 types of segments, each about the size of one screen horizontally and two screens vertically. I may not be remembering this perfectly, but the gist is, the repetition in the stages isn't laziness of copying and pasting groups of tiles around, it was to get around some limitation in getting a big map to work well. I don't know what this limiting factor is exactly, but I also know that there's a bunch of hidden tile data that exists just for the physics of the undulating ground, so maybe with that added in as well, some bottleneck is reached.
I think the different segments was referring to different types of level collision (the collision/physics engine for that game was incredibly impressive!). There's only so many unique tiles that can fit into VRAM, but I think they did a great job making it look very natural.
@@PigsysRetroGameDevTutorialsThe way the map is made out of reused sections that are larger than the tiles is perhaps more apparent with Act 2. But in the very first scene in your video, you can see an example there, where the first 16 columns and the second 16 columns are identical, and sections of this size (perhaps 256 by 256 pixels, not two screens as I said before) are shared between all three acts of each zone. The repetition is obscured somewhat by enemies, rings and other sprite placements. Unfortunately I don't remember why this was done, beyond perhaps just saving some memory on the 4Mbit cartridge.
Haha, I'm much more interested in any new 8/16/32 bit homebrew projects than the latest AAA games too :) One of the main reasons for creating these tutorials is in the hope that more people will get into the hobby and make even more new Mega Drive games
Fantastic, it's amazing how devs back in the day could make so much with the little that they have. Great video AND explanation, Pigsy! Keep up, brother! 💪
Thanks for the tutorial, I didn't even know that SGDK would automatically generate the tileset, I thought it would just show a big picture on the screen and that would be all lol
I don't quite understand all that, I am in no way a developper but still interested and anyway here is a comment for the algo and to thank you for being passionate on what you are doing. GG
Thanks for this! Impressed by how much easier this stuff has become since I last poked around SGDK four or five years ago, as I remember having to do a lot of the leg work myself when it came to creating tile sets and setting up smooth scrolling beyond the dimensions of a single plane. Really great improvement. Given that the map you've set up here is just the foreground, how would you go about setting up a background in the same dimensions? Would it be a case of creating a separate image with just the background tiles, defining that as a separate tileset in resources, and then defining / displaying a second map alongside the first, but with its own palette specified and on the other background layer?
Yes, you could create a second MAP, but I normally use an IMAGE background instead (as in my previous lesson), as you can use tile scrolling etc with that type. I will have a future lesson covering this in more detail.
Im not a coder ....well except BASIC lol. I found this very interesting though. I really hope your port of castlvania eventually makes it, along with GG shinobi.
@@inceptional That's not what I meant. I am fully aware that tile based graphics was the standard for games back then, but european developed games for home computers had a distinct look about them. They always looked very flat an inorganic compared to japanese or american developed games, because of the way the tiles were drawn.
@@Sheepy007 Well, I'm not seeing a particularly "European" look here personally--I have my own take on what actually makes stuff look "European", and it mostly revolves around not using hue shifting when doing highlights and shadows on things (the shading), so everything has that kinda dull and low-colour look to it (exactly the same as what happens when using the Genesis' shadow/highlight mode basically), or it's often limited to 16 colours total (kinda like a lot of Amiga and ST stuff)--but if you think the Sonic art and tiles look "European", so be it. My personal opinion is that Sonic typically has a much nicer look to it than most European games, particular the colour choices.
I think repetitive tiling was more a feature of 8 bit games, as the 16 bit consoles generally had enough VRAM to achieve a more varied look (although 8 bit games still have their charm). I tend to prefer the look of Japanese games over European, although I think that is more to do with art-style rather than tile usage.
for anyone getting the error: pixel at position [6278,5] uses a color not present in palette. when trying to define the TILESET in resources.res you may need to go into Asprite and upload the map png, at the top, click sprite > color mode > indexed. then save the file and recompile that fixed the error for me. for some reason it was set to RGB for me and it gave me a bit of a headache trying to figure out what went wrong because I followed the videos instructions exactly.
man, you're the man.. I want to create a little game for my megadrive and my first move will be to take some old games graphics to mod them, see how it works... also i've just bought a" C language for beginners" book, as i just know a little bit of basic programming, do you think those kind of books could be handy? thanks
It seems that the & symbol no longer works. While compiling, VSC just gives me errors like; "our_XXXX_tileset/map/palette undeclared (first use in this function)" and such. So how can one fix this in order to make background images to compile in the ROM?
hey how's it going?. Do you possible port Castlevania Aria of Sorrow from game boy advance to mega drive? I think your work is incredible congratulations
Sometimes vscode gives an error (with a red squiggly line underneath) but it still compiles fine nonetheless. Other times it recognises it just fine. So long as it compiles ok, then I wouldn't worry about it
so when i followed the tutorial, the green hill flower/tree tiles sorta just corrupted and idk what i did differently (besides changing names but i dont think that's it)
I hope everyone enjoys this one on large level maps. This lesson could almost be thought of as part one of a multi-part lesson, as we still need to do the camera, level collision etc. Next week's will be about converting graphics from SNES to the MD and using this to create you own level maps.
I was lucky enough to attend a talk by Hirokazu Yasuhara, who among other things was responsible for the layout of the levels of Sonic 1. I recall he said that in the engine Yuji Naka had created, each level was limited to I think 32 types of segments, each about the size of one screen horizontally and two screens vertically. I may not be remembering this perfectly, but the gist is, the repetition in the stages isn't laziness of copying and pasting groups of tiles around, it was to get around some limitation in getting a big map to work well. I don't know what this limiting factor is exactly, but I also know that there's a bunch of hidden tile data that exists just for the physics of the undulating ground, so maybe with that added in as well, some bottleneck is reached.
I think the different segments was referring to different types of level collision (the collision/physics engine for that game was incredibly impressive!). There's only so many unique tiles that can fit into VRAM, but I think they did a great job making it look very natural.
@@PigsysRetroGameDevTutorialsThe way the map is made out of reused sections that are larger than the tiles is perhaps more apparent with Act 2. But in the very first scene in your video, you can see an example there, where the first 16 columns and the second 16 columns are identical, and sections of this size (perhaps 256 by 256 pixels, not two screens as I said before) are shared between all three acts of each zone. The repetition is obscured somewhat by enemies, rings and other sprite placements.
Unfortunately I don't remember why this was done, beyond perhaps just saving some memory on the 4Mbit cartridge.
Why is this more fascinating than anything going on with "AAA" games? Also, you're making more progress than Microsoft's "AAAA" studio...
Must have something to do with CREATIVE FREEDOM!😊
Haha, I'm much more interested in any new 8/16/32 bit homebrew projects than the latest AAA games too :) One of the main reasons for creating these tutorials is in the hope that more people will get into the hobby and make even more new Mega Drive games
Top notch content as usual
Thanks, I hope it's useful
Fantastic, it's amazing how devs back in the day could make so much with the little that they have.
Great video AND explanation, Pigsy! Keep up, brother! 💪
But actuallly, they had not what is shown in this video (it's a modern sdk developped for years). I assume it was far more complex back then
Yeah, it was impressive what they achieved. We are lucky to have so many tools these days.
@@axelriviere7605 Indeed
Thanks for the tutorial, I didn't even know that SGDK would automatically generate the tileset, I thought it would just show a big picture on the screen and that would be all lol
Aseprite 1.3 (now in RC) has tile support, which should make building such maps much easier.
That sounds useful, I should update my Aseprite
I don't quite understand all that, I am in no way a developper but still interested and anyway here is a comment for the algo and to thank you for being passionate on what you are doing.
GG
Appreciated
Thanks for this! Impressed by how much easier this stuff has become since I last poked around SGDK four or five years ago, as I remember having to do a lot of the leg work myself when it came to creating tile sets and setting up smooth scrolling beyond the dimensions of a single plane. Really great improvement.
Given that the map you've set up here is just the foreground, how would you go about setting up a background in the same dimensions? Would it be a case of creating a separate image with just the background tiles, defining that as a separate tileset in resources, and then defining / displaying a second map alongside the first, but with its own palette specified and on the other background layer?
Yes, you could create a second MAP, but I normally use an IMAGE background instead (as in my previous lesson), as you can use tile scrolling etc with that type. I will have a future lesson covering this in more detail.
Very nice and straight forward video mate !
Next one will probably be about... map collision ? :)
Thanks! Next one is about converted graphics from SNES and creating tilesets :)
Thanks for all those tutorials 😊
You're welcome
Yoooo! This is exactly what I needed!!!! Thanks!
You're welcome!
Im not a coder ....well except BASIC lol.
I found this very interesting though.
I really hope your port of castlvania eventually makes it, along with GG shinobi.
There is actually a development kit that uses basic, so you could try that (I believe the new RPG, Infinity Sorrow, is using it)
Great tutorial as always
Thanks :)
Repetetive tiling a signature feature in the look of many european developed games of the time.
@@inceptional That's not what I meant. I am fully aware that tile based graphics was the standard for games back then, but european developed games for home computers had a distinct look about them. They always looked very flat an inorganic compared to japanese or american developed games, because of the way the tiles were drawn.
@@Sheepy007 Well, I'm not seeing a particularly "European" look here personally--I have my own take on what actually makes stuff look "European", and it mostly revolves around not using hue shifting when doing highlights and shadows on things (the shading), so everything has that kinda dull and low-colour look to it (exactly the same as what happens when using the Genesis' shadow/highlight mode basically), or it's often limited to 16 colours total (kinda like a lot of Amiga and ST stuff)--but if you think the Sonic art and tiles look "European", so be it. My personal opinion is that Sonic typically has a much nicer look to it than most European games, particular the colour choices.
I think repetitive tiling was more a feature of 8 bit games, as the 16 bit consoles generally had enough VRAM to achieve a more varied look (although 8 bit games still have their charm). I tend to prefer the look of Japanese games over European, although I think that is more to do with art-style rather than tile usage.
Thanks!
Thanks! Next week's tutorial will be on parallax scrolling in conjunction with a camera, so I hope that one is useful too
@@PigsysRetroGameDevTutorials Yes Sir! That's one I've been waiting for.
for anyone getting the error:
pixel at position [6278,5] uses a color not present in palette.
when trying to define the TILESET in resources.res you may need to go into Asprite and upload the map png, at the top, click sprite > color mode > indexed. then save the file and recompile that fixed the error for me.
for some reason it was set to RGB for me and it gave me a bit of a headache trying to figure out what went wrong because I followed the videos instructions exactly.
Nice!
Thanks!
man, you're the man..
I want to create a little game for my megadrive and my first move will be to take some old games graphics to mod them, see how it works...
also i've just bought a" C language for beginners" book, as i just know a little bit of basic programming, do you think those kind of books could be handy?
thanks
It seems that the & symbol no longer works.
While compiling, VSC just gives me errors like; "our_XXXX_tileset/map/palette undeclared (first use in this function)" and such.
So how can one fix this in order to make background images to compile in the ROM?
From the error message it seems that you are forgetting to declare something earlier on in the process (probably the palette in resources.res)
i shouldve known how to do this over 20 years ago and be good at it by now. my life sucks
hey how's it going?. Do you possible port Castlevania Aria of Sorrow from game boy advance to mega drive? I think your work is incredible congratulations
Hopefully someone will in the future, but I'm too busy with the SotN project at the moment
@@PigsysRetroGameDevTutorials humm ok I see your very amazing Castlevania project
What you did to vscode recognize "#include " ?
Sometimes vscode gives an error (with a red squiggly line underneath) but it still compiles fine nonetheless. Other times it recognises it just fine. So long as it compiles ok, then I wouldn't worry about it
what software did you use?
Aseprite
so when i followed the tutorial, the green hill flower/tree tiles sorta just corrupted and idk what i did differently (besides changing names but i dont think that's it)
ok nvm i fixed it
@@jumpygamer123 Glad to hear you solved the problem in the end