tag:blogger.com,1999:blog-6997440551610060560.post212878613858710485..comments2023-05-20T03:34:03.651-05:00Comments on Nathan's Development Blog: Optimizing space, adding a switch.Nathanhttp://www.blogger.com/profile/14248157226095069791noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6997440551610060560.post-47463813387030581452016-05-16T21:56:58.424-05:002016-05-16T21:56:58.424-05:00Great question. I totally could, although it means...Great question. I totally could, although it means sacrifices other places. Really, I should have done it completely differently (parallel arrays), but now that I'm this far along, it comes down to optimizations within the enemy definitions vs the amount of code in other places to support it.<br /><br />For example, the last byte (enemy size and missile size) is currently in the right format to copy directly to a sprite hardware register. I could probably overload it with more information, but I'm not sure I'd save more than the 24 bytes in the long run once I wrote the code to break the data out and get it in the right format. It was just easier at this point to do my cheesy hack instead. But I like your line of thinking...I might do a blog post just detailing some of the options I could have done to improve it.Nathanhttps://www.blogger.com/profile/02763963217187530121noreply@blogger.comtag:blogger.com,1999:blog-6997440551610060560.post-16220434613086742652016-05-16T06:48:42.861-05:002016-05-16T06:48:42.861-05:00Are you sure you can't cram all the enemy info...Are you sure you can't cram all the enemy info into 10 bytes instead of 11? So you'll have room for 25 enemies. Some of your info in those structs look like they can actually occupy just few bits, or can be turned into an enum to save even more...<br />sverxhttps://www.blogger.com/profile/13552101081332715415noreply@blogger.com