-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Player.cpp #3116
base: master
Are you sure you want to change the base?
Refactor Player.cpp #3116
Conversation
This exposes some Squirrel methods such as set_sprite. Pretty fun. Big tux is still jank but this may be somewhere in the file.
I think this pr is cool . |
83cb6a1
to
230b867
Compare
Unrelated note but kind of surprised git doesnt allow for true commit renaming in 2024 because "Oh no" was not a good commit message and force pushing is not a great decision |
State machine code is done, though right now, MovingSprite has broken Tux's logic (still looking into why) but its likely due to disgusting jank code... but anyone is welcome to take a look at this right now and note any thoughts (overall code still sucks ass). You can use squirrel |
About damn time.
Highlights:
Tux.set_sprite
calls and have fun with that. Custom sprites are possible now. This was so easy to do it hurts.Main things on my bucketlist are refactoring the majority of state into either a) their own smaller classes, b) into more functions, and c) maybe bitwise state and/or std::bitset. The input code is kind of disgusting and could be set up some. State machinery stuff related to switching the players sprite likely has room for improvement. Update function is just putrid. Input/shooting/powerup code MIGHT be able to get refactored out of player, i'll see what I can do :)