Hello, I was inspired and decided to follow along! I noticed rex does not have a collisioncenter rectangle, but mario does. what is the difference for that? when I have it, mario gets snagged on block corners, something we were trying to avoid
I find your video to be very edjucational about godot. As I am starting with that software, it can be a great ressource to figure out things, as Super Mario world is so familiar to me, that it is immediatly imaginable how the various variables are gonna feel, and why super mario world feels so good, in my opinion. It is for sure my favourite Mario-Game, and I always played the version on the GBA.
Hey, love this series of video ! Highly entertaining and lots of learning value. Waiting to see what's next ! At 4:13 you say you can't put logic in a tile form a tilemap. If you don't already know that, you can write a script that looks for block tiles in your tilemap, erase them and create an instance of your block scene at that coordinates. Pretty neat !
4:30 *please* make that an AnimatableBody, moving StaticBodies break the physics. also of course bodies know what they collide with, not sure what you think "turned out" there at 5:30 but yeaaah no. same applies to most your conclusions about "collisions vs interactions" implying some kinda limitation they don't.
Hi, thanks for your insights! No worries, I'm only moving the bounce sprite, not the body itself. (: As for collision vs. interaction, what I'm doing right now is the only way I've found that seems reasonable and able to recreate SMW behavior. Feel free to point me to the relevant docs - or fork my code once I've put it out there, which I bet will help a lot more people along! :)
These videos are really well made. This is basically how I learn everything too. Take a thing that exists, reverse engineer it as accurately as possible, and then move onto something with different elements to teach me different features. Coding is so frustrating but so satisfying when it just works.
One twip is equal to 1/20th of a pixel. a subpixel is a single color to a pixel, so you meant that you are moving them by twips when under a single pixel, not by a color reference.
You're right - I'm sure that's what those terms mean in your area of expertise! (and I do know that other meaning of subpixel). But words mean different things in different places, and retro gaming terminology is just weird sometimes. Twips would definitely not be the right word to use here, because I'm really talking about 16ths of a pixel, not 20ths. :)
Hey man I really loved both videos truly inspiring but I got one question for you: how do you make your code look so nice 😭. Unfortunately when I was younger I decided to get into Roblox programming and my code looks doodoo, it works well it’s just not visually appealing. Looks like an essay lmao but yours looks clean and very easy to dive into, how u do that?
Glad you like them! Broadly speaking, I try to be generous and consistent with whitespace, avoid nesting too much, and cut long lines into shorter ones by splitting them into multiple steps.
love that you accurately captured the physics of the original game, the movement has gotta be one of the most overlooked yet important parts of all games
Making mario 1-1 is a great way to learn a new engine I did not go nearly as depth as this video did and it was mario one not super mario world. but the first thing I did with godot to get familiar was to remake the mario 1-1 world very good exercise for people trying to learn a new engine
At 5:04 I don't think you need to multiply "y_speed" with "delta" in "position.y += ..." due to deltatime already being implemented in "y_speed += gravity * delta". Edit: Now that I think of it, since "y_speed" is after calculated after applying it to "position.y", you will have to multiply by deltatime twice due to "position.y" will be added with an older deltatime. You could probably just calculate "y_speed" with "delta" then apply it to "position.y". At this point I might be splitting hairs with this response😅but eh I like to focus on weird stuff like that.
its debatable, most would say that making and distributing rom hacks is mostly legal as long as theres no money being made from it, however nintendo has taken down many pokemon rom hacks before, even if you were to follow the law perfectly, nintendo would still probably find a way to sue your ass if you made a popular rom hack
