It's funny, I've been slowly developing my own little game engine over the last few months. I think this is now the 3rd time I've hit a wall with a feature, and then found one of your videos explaining very clearly where I went wrong. This time around, I was really pleased with myself that I'd been able to apply a bunch of matrix math that I'd learnt from your 3d engine videos. It was one of those lovely shower thoughts "Hold on, if I want to rotate a 2d sprite, surely I can just use a 3x3 matrix just like the 4x4 ones I was fiddling with for cameras". And it worked! And then I had holes. And I left it for a while and did some other stuff, came back to it and there's another OLC video explaining exactly what I needed to do! I'm slowly working my way through your back catalogue of hits, and I thought now was as good a time as any to let you know that even 4 years later, your hard work is still paying off. Thank you :)
Nice video on that method. The way I used to do it back when I was making games on dos was the basic rasterization method. Get the 4 corners break the shape into triangles start at the left edge and of the resulting shape and work across to the right edge. It means you only end up needing to calculate the pixels that are part of the sprite rather than all the one's in an over sized bounding box. Of course when opengl and directx came along you could make a face or surface of an object and just rotate that in orthogonal view.
I was about to try and write a program using PGE that involved sprite transformations, and then you just went ahead and made an extension that already does it :P
Hey Javid. Amazing channel! You are an incredible teacher. When scaling you didn't talk about bicubic/bilinear interpolation. It'd be great if you talk about it. Thanks!
Hi and thanks Gabriel! Yeah, I didnt mention interpolation. The PGE supports it too! As part of my Top Down Car Crime series, I will be looking at interpolation to filter the textures, so its coming! :D
How about you make a follow-up video where instead of transforming every single pixel you'd calculate the corner vertices of the drawable area in texture space, clip it, and iterate over the texture using fixed point math. My 90's coder instincts are screaming at the thought of all those cycles wasted on multiplication...
I did contemplate doing a cost analysis verses my software texture renderer form the 3D graphics series. I didnt for this video, but I think I will, though Im unconvinced. A system like that has potentially more branching. This approach, although uses a lot of macs for sure, I could stream that through SSE perhaps. I dunno - I know this is not optimal, its never intended to be, but so long as people get the idea I'm happy to leave it where it is. I probably will follow this up with anti-aliasing though.
Same here! My mind was jumping to the fixed point maths and sampling techniques. Good to have an explicit "I'm not optimising" disclaimer in these parts to keep me sane. *Great* video. Now I'm going to rewrite this for a very old machine indeed. :)
Its a tough call. I like to create videos that explain the ideas and concepts behind a thing, particularly as im trying to show these things are not as complex as they seem, but the embedded systems developer in me is screaming to optimise it all 😂
You could at least define a more general definition for matrices and a more general method for multiplying them. That's what I did. What for? Finding the roots of a polynomial equation, for instance. I have even overloaded the multiplication operator * which I know full well is syntactic sugar, and outlined a QR function based on Householder matrix reflections.
Since the SNES Mode 7 is done using a hardware accelerated affine transformation you could in theory perform a much faster version of your Mode 7 demonstration from back in the OLC Console Game engine days using this
Another fab video, javidx9. Following along, I've been able to get the program working fine (although I have to admit the matrices have flown over my head). I especially like the way you extracted all the math and wrapped it into the extension. I'm thinking I'll go back to the start of your videos and work through them all again, one at a time until I fully understand every one. I love the way you've built upon previous ones to get where we are now. Keep going!
Hey Jock, Cheers! Yeah matrices can be a bit of a pain if you have not seen them before. I dont do anything advanced with matrices, so just think of them as the coefficients in a set of equations.
@@javidx9 maybe that's an idea for another extension? You could arrange it so that you use the same code for different view styles: top-down, isometric, perspective, just by swapping out an extension-or even change it on the fly ;-)
Sounds great, but in reality, if you create an isometric game, you want premade graphics. Usually the only things you do rotation and the like on are characters, like a player's vehicle for example. I can't think of a practical use for shearing except maybe special effects, which would be rare. Or perhaps an editor where you make your own graphics.
Hi javid, please make tutorial build game engine like stronghold game(i have no idea to handling many object > 10^10, to slow if i call update every object in same time) thanks
Hi Rizal, I think the topic of managing large numbers of agents is quite interesting. I'll try and think of a way to demonstrate it thats accesible and fun. Typically you would "batch" objects and only update subsets of them per frame.
Something I'm wondering about is if you'll ever work over converting previous projects to a form more efficient for the graphics card/cpu/etc I like learning the concepts behind things, but I'd also like to know methods for simplifying it and making it efficient in a more advanced followup video
Yes! Yes I will. Im working on a game project right now that fuses C++ and Lua. My videos are currently two months behind my projects, but ill see what can do to bring it forward.
Hey javid, the pixel engine is coming along nicely. An idea for the future could be implementing software based shaders. I'm not expecting anything crazy, but it could be a cool idea to mess around with.
Hi Xenthera, cheers buddy! It "kinda" does already :D You can set a lambda function as the pixel blending mode where you can modify how things get drawn. Ive not pushed it in a video yet, but its on the github.
@@javidx9 Oh nice! I bet with some clever programming you could achieve some interesting things! I'll have to mess around with it when i'm better at C++ lol
Hi Jin, in the demosntration, i do offset the sprite first so the origin is in the middle of the sprite (not its top left corner), this way when i scale, the offset remains in the middle, allowing me to rotate it around the centre point.
Awesome explanations as always. Javid, is the technique you used to prevent the "holes" called inverse texture mapping? Can you point me to a computer graphics book or other resource so that I can investigate it further? Thanks!!!!
Hey thanks raol, oh just whilst I got you, Ive changed the PGEX_Graphics.h file. Rotations now go the other way, so you'll need to invert them if you are using them. Sorry about that, I found an inconsistency in the maths but fixed it.
I think it's possible by doing rotations with sheers. It sacrifices subpixel accuracy for consistent pixels (every pixel remains in the image, they just get moved around)
@@vibaj16 Sheers are part of affine transformation, so in order to draw a sheer (to rotate), you must use the inverse transformation. I want to skip the inverse since it involves multiple divisions and floating point for the determinant.
everything is fine, backprojection resampling is explained very well, but the code is written in a veeery slow manner, 2D matrix access...painfully slow
Unity is a valid tool, and its quick and (relatively) easy to work with. If what you want is just the result, then Unity is fine. If you want to understand how the result was obtained then learning about fundamentals is quite important. Especially when you want to do that one thing unity can't do.