My Platformer Framework

Hi!

Based on my Physics Demo, I've been writing an object oriented platformer framework in C.
My goal is to achieve the highest possible performance while at the expense of having a high level of human-readable and maintainable code.
It's too early to open-source it, but I will do so as soon as it's stable enough.



Please test it out and let me know how the controls feel...
The collision detection is not perfect yet, but I hope there won't be any problems.

PS: I did the sprites as well.

Roadmap:

Controls: L/R Move, A Jump, B Run

EDIT: I added a new version with idle animation.

Good work so far!


The jump physics do feel a little odd to me. Maybe a little too fast vertically in comparison to the horizontal velocity? I'm not sure.

This looks really cool! Have you found any issues in performance or rom space developing in C as opposed to assembly?

How do you do your collision detection? With so many objects and platforms on screen, the fact that it stays at 60 fps is what I find most impressive.

BTW, How do you even debug your C code? I've only ever coded for NES in assembly..

Thanks!! Indeed, I'm still not fully satisfied with the current velocity/acceleration values, there's still a lot of room for improvement.



Thank you so much! I'm really glad you like it! Well, I've never coded in assembly so I'm not sure how much of a performance hit is the fact that I am writing it in C.
Nevertheless, I believe my C code is as tight as it can possible be, while keeping an high level of abstraction.


It took me around one month to come-up with this algorithm and make it work fast in the NES. Normally I would use sin(), cos() and atan2(), but since the <math.h> is not really available in this context, I had to wrap my head around it and come up with an entirely different solution. I'm attaching my collision detection module, but bear in mind that it's still a work in progress.


Well, first of all, I wrote my own printf(), so I can do stuff like print_at(3, 3, "Vx: %d", actor.vx);.
Second, I always check the generated assembly code in the compiler listings (both locally and on 8bitworkshop).
Finally, for benchmarking, I'm using the methods suggested in this thread: How can I benchmark my C code?

Thanks for sharing the attachment! I had a look at it but I'm ashamed to admit most of it went above my head! Will try to read through it some more though, as I'm sure there's lots I can learn from it.

Do each entity check it's collision against whatever tiles are loaded into the nametables behind them? Is that what you're doing when using your P2B() function? Or do you keep a buffer of collision boxes that gets updated with every nametable change?

I do a buffer kind of solution myself, but I only load in platforms that you can land on. For collision between entities I think maybe we're doing some things similarly. What I do is I take the coordinates for the collision box of entity_1, add all the sides to the collision box of entity_2, but mirrored and flipped upside down, then I compare the result of that to the pivot (or "hot spot" if you will) of entity_2. The result would be the same as comparing all corners of entity_1 to each side of entity_2 to see if they intersect, but this way I only check one point instead of four.


Anyways, since you shared so much of your code I thought I'd share the principle of mine. The actual assembly code is even more confusing even to myself, so I'll spare you that..

I'm looking forward to see how your engine comes along!

Cheers!

Hello again!


Yes, but I'm not using the nametable itself. I'm using a grid object char matrix[x][y] = {{...}, {...}, ...};.


P2B means "pixel-to-block", it gives me the result of the given pixel-coordinate divided by 8 (block size).


I'm not sure what you mean, but I'm guessing that the answer is no.

I've drafted a PDF on which I try to explain my reasoning in more detail, see attached.

Perhaps buffer wasn't the right word. What I meant was if you were keeping a representation of all the collision boxes in RAM and then update them accordingly whenever there's a change to the nametables. If your char matrix[x,y] is kept in RAM, then this would be that. But I'm guessing you're keeping it in ROM, since it should need 960 bytes for each full screen and keeping it in RAM would take up almost half the available RAM on NROM.

Yep! That's right, I'm keeping it in ROM (in C all I had to do was declare it as const char).