I know this topic is one that has been causing people a lot of problems, so I thought I should cover it here. Next week we'll finally start doing some audio stuff - music/sfx etc. Have a great weekend!
Are these the variables we need to change for making sprites stay on screen in Widescreen emulator? My instinct says probably after watching this video. Trying to learn so I can contribute to rom hacking someday.
Each game may do this in a slightly different way, but I think the principle should be the same, so it might be possible (I've never hacked a game myself)@@NoSpamForYou
funny i just figured out about hiding the sprites last night while trying to clear them; and this! exactly what i needed couldn't fathom how to get the map and sprite to interact as if all is based off tilemap size. THANK YOU!
I just started practicing since the start of this year and it's not easy! I hope I'll get better (and faster) at it as time goes by. Let me know if you have any special tips or advice
What if the enemy sprite width is dynamic? For example if the baddy leaps into the air for a mid-air kick. Or to include x and y (you'd need an offset for Y too)... a flying craft that transforms from a wider aircraft to a taller mecha? Is there an easy way to retrieve the sprite width and height for the current frame of animation? Or is that too resource-wasteful to constantly update those numbers, and would you then just recommend taking the widest/tallest frame values and using those values? I'm not a programmer, but I did a little Pascal and C++ a couple decades ago.
Taking the widest and tallest values would work, but you might also be able to define variable for their width and height, and have those variables update with the correct info (added manually) every time it switches frames of animation. That might be more complex than needed for the camera system, but it could help out with other things like collision.
Just set the visibility past the largest possible sprite width in the character sheet. Also the further out you keep them visible the better it will work in Widescreen emulator like Genesis Plus Gx Wide.
@@GreyMatterShades Yeah that's what I was implying by "resource-wasteful" - but if you already generate the data for collision, might just cost you a few bytes...
@@AlexvrbX Yup, though a lot of games handle collision differently via hit/hurt boxes, which might use totally different data. Sort of depends on how you're building your game, but it could be useful in some cases.
Another REALLY great video, I found this ads to much helpful body to the overall coding design process. I was wondering two things though, With SGDK, is there somewhere that you can pull 'HORIZONAL_RESOLUTION and 'VERT...' as a global variable that the library at large knows is being used when setting the different resolution modes? It's a small detail, but I know in each of my projects I'm always re-creating the same constants with very standard methods like camera definition. The other is, all of this code looks really clean and ready to ship when all the parts are put together. When all of the stuff in the game design DOES work, what refactoring do you expect to perform? What stage do you (if at all) pull out large bodies of related functions and code to their own (maybe modular?) source files? Appreciate any of your thoughts about these matters, I'm in the Discord too if that's where text is easier. :) Thanks!
You can use that HORIZONAL_RESOLUTION constant as many times as you like in different parts of the code. If you ever need it to change it then you could define a global variable instead. I'll be covering organising the code into different files next year!
dude, is there a way to do this with background tiles, for example a fighting game with a really complex background that would overload the vdp, you have all tiles that are offscreen unloaded and then when the screen scrolls the tiles that fall off screen unload and the new tiles load? cheers.,
You can use software scaling and/or multiple different graphic sizes to simulate the effect, but it generally works best for small sprite, trying to do the whole screen would be too much. One day I really want to learn how to use the Mega CD's scaling hardware and trying to do that Samurai Showdown effect would be a nice test for it!
also dude, thanks for supplying the graphics, would it be possible for you to supply the base code where the tutorial starts? or is that a patreon only thing?
It was said that C ran rather slowly on the Megadrive hardware. Sonic Spinball's game framerate was the evidence of such an hardware issue. Do you have any experience with a Megadrive As68k assembler by chance 🤔🤔
I know this topic is one that has been causing people a lot of problems, so I thought I should cover it here. Next week we'll finally start doing some audio stuff - music/sfx etc. Have a great weekend!
Thanks a lot for this series. I would have never figured this out on my own, and reading docs hurts my noggin.
I'm glad that these tutorials are making developing for the console more accessible to people!
Are these the variables we need to change for making sprites stay on screen in Widescreen emulator? My instinct says probably after watching this video.
Trying to learn so I can contribute to rom hacking someday.
Each game may do this in a slightly different way, but I think the principle should be the same, so it might be possible (I've never hacked a game myself)@@NoSpamForYou
Still the same high quality, well done :)
🙏
funny i just figured out about hiding the sprites last night while trying to clear them; and this! exactly what i needed couldn't fathom how to get the map and sprite to interact as if all is based off tilemap size. THANK YOU!
You're welcome!
No idea why there is even a SINGLE dislike on this video. Love your videos dude!
Just 3 dislikes on this one - can't please everyone!
@@PigsysRetroGameDevTutorials Haters gon’ hate, that’s a fact. Keep it up man, I’m learning a ton from these vids!
They hate sega Genesis 😂
Some people hate themselves so bad they can’t stand anything from anyone else
cant wait for the slope tutorial, if you are doing that :D
I'll get around to it eventually for sure, but lots more to cover before then
cool@@PigsysRetroGameDevTutorials
i like sonic too much XD
well its like the only tutorial series@@clonador.206
also its not that bad
Great and very instructive video, thanks
Glad you enjoyed it
Pixel artist here. I've done work on everything from the SMS to Windows to Mac.
Surprisingly difficult work to maintain consistency.
What program should use to draw the hero sprite? Is there a video on how to draw a hero?
I just started practicing since the start of this year and it's not easy! I hope I'll get better (and faster) at it as time goes by. Let me know if you have any special tips or advice
What if the enemy sprite width is dynamic? For example if the baddy leaps into the air for a mid-air kick. Or to include x and y (you'd need an offset for Y too)... a flying craft that transforms from a wider aircraft to a taller mecha? Is there an easy way to retrieve the sprite width and height for the current frame of animation? Or is that too resource-wasteful to constantly update those numbers, and would you then just recommend taking the widest/tallest frame values and using those values? I'm not a programmer, but I did a little Pascal and C++ a couple decades ago.
Taking the widest and tallest values would work, but you might also be able to define variable for their width and height, and have those variables update with the correct info (added manually) every time it switches frames of animation. That might be more complex than needed for the camera system, but it could help out with other things like collision.
Just set the visibility past the largest possible sprite width in the character sheet.
Also the further out you keep them visible the better it will work in Widescreen emulator like Genesis Plus Gx Wide.
@@GreyMatterShades Yeah that's what I was implying by "resource-wasteful" - but if you already generate the data for collision, might just cost you a few bytes...
@@AlexvrbX Yup, though a lot of games handle collision differently via hit/hurt boxes, which might use totally different data. Sort of depends on how you're building your game, but it could be useful in some cases.
Is there anything like adding simple sprites to any specific number on a tile array? Like the rings on Sonic for example.
Another REALLY great video, I found this ads to much helpful body to the overall coding design process. I was wondering two things though,
With SGDK, is there somewhere that you can pull 'HORIZONAL_RESOLUTION and 'VERT...' as a global variable that the library at large knows is being used when setting the different resolution modes? It's a small detail, but I know in each of my projects I'm always re-creating the same constants with very standard methods like camera definition.
The other is, all of this code looks really clean and ready to ship when all the parts are put together. When all of the stuff in the game design DOES work, what refactoring do you expect to perform? What stage do you (if at all) pull out large bodies of related functions and code to their own (maybe modular?) source files?
Appreciate any of your thoughts about these matters, I'm in the Discord too if that's where text is easier. :) Thanks!
You can use that HORIZONAL_RESOLUTION constant as many times as you like in different parts of the code. If you ever need it to change it then you could define a global variable instead.
I'll be covering organising the code into different files next year!
mate do you have a github rep to visit the sor proyect??
dude, is there a way to do this with background tiles, for example a fighting game with a really complex background that would overload the vdp, you have all tiles that are offscreen unloaded and then when the screen scrolls the tiles that fall off screen unload and the new tiles load?
cheers.,
There is a way to alter VRAM tiles dynamically if needed)
Couldn't the Samurai Shodown Game at the time it was ported to the SEGA Genesis support the zoom-in and zoom-out feature?
The MD version most definitely lacked the effect iirc. But I think maybe the Sega CD version had it?
Looking at videos on UA-cam of the Sega CD and Mega CD versions, there is no zoom in and zoom out effect.@@dacueba-games
@@rafaelbaugis Indeed, it does not. By the way, Sega Lord X released a video about that port a couple of days ago.
You can use software scaling and/or multiple different graphic sizes to simulate the effect, but it generally works best for small sprite, trying to do the whole screen would be too much. One day I really want to learn how to use the Mega CD's scaling hardware and trying to do that Samurai Showdown effect would be a nice test for it!
I did this in my game without knowing it was the correct way, I thought I was doing a trick.
I'd be interested to see if there are alternative ways, but maybe this is just the most obvious method
Could you make a tutorial demonstrating how to develop enemy AI?
That one will probably have to wait until next year I'm afraid, as there is still lots of other stuff I need to cover first
also dude, thanks for supplying the graphics, would it be possible for you to supply the base code where the tutorial starts? or is that a patreon only thing?
The source code is an extra bonus I offer Patreon supporters
Hello Pigsy's I tell you that Ami I would like to know how the Sega Saturn and MD/Genesis VDPs work but more about Saturn Xd
Eventually I'd like to do more videos on the Saturn, but I need to learn how to use it properly myself first :)
It was said that C ran rather slowly on the Megadrive hardware. Sonic Spinball's game framerate was the evidence of such an hardware issue. Do you have any experience with a Megadrive As68k assembler by chance 🤔🤔