![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
symbioidljMeh.
So, with some trickery with the double buffering code, I got the animation to work -- no need for timer (which is good at this point, I didn't think there should have been any)
EXCEPT...
Right now the code for animating it is only drawing the bullet as it flies for 100 steps (my loop). I don't have it properly double buffering.
I think my next step in the code is to refactor(?) and clean up the input, logic, output sections and make sure that my drawing is separate from the logic code.
I still don't quite grok some things, since some of my logic loop requires mouse input (which is an internal variable that the library automatically does the reading) and then to draw based upon it. But since it's real time... I guess I'm still trying to get a handle on the whole event-driven system.
But not only that, there are some things in the library that are dumb. Like "rotate_bitmap" doesn't rotate the bitmap in memory and then you separately draw to screen. Nope... It rotates it on the screen right away. This means that if I have a logic loop "if(x) rotate_bitmap();" I can't separate the logic and the drawing portion (which is one problem I had with hexbgon...)
Oh well. I can do it, it's just a hassle.
But yeah, I think I need to figure this out now. I know I can get that bullet trajectory drawing and animated, I just need to have a proper draw routine down.
Once I get that, I think I next need to work on boundary conditions of the screen so when the bullet hits the edge, it's destroyed. THEN I'll work on multiple bullets on the screen at a time...
So, with some trickery with the double buffering code, I got the animation to work -- no need for timer (which is good at this point, I didn't think there should have been any)
EXCEPT...
Right now the code for animating it is only drawing the bullet as it flies for 100 steps (my loop). I don't have it properly double buffering.
I think my next step in the code is to refactor(?) and clean up the input, logic, output sections and make sure that my drawing is separate from the logic code.
I still don't quite grok some things, since some of my logic loop requires mouse input (which is an internal variable that the library automatically does the reading) and then to draw based upon it. But since it's real time... I guess I'm still trying to get a handle on the whole event-driven system.
But not only that, there are some things in the library that are dumb. Like "rotate_bitmap" doesn't rotate the bitmap in memory and then you separately draw to screen. Nope... It rotates it on the screen right away. This means that if I have a logic loop "if(x) rotate_bitmap();" I can't separate the logic and the drawing portion (which is one problem I had with hexbgon...)
Oh well. I can do it, it's just a hassle.
But yeah, I think I need to figure this out now. I know I can get that bullet trajectory drawing and animated, I just need to have a proper draw routine down.
Once I get that, I think I next need to work on boundary conditions of the screen so when the bullet hits the edge, it's destroyed. THEN I'll work on multiple bullets on the screen at a time...
