Shifty Geezer
Your camera technique sounds very interesting. There is some pain in working out the math for positioning the sprite's depth in relation to screen's dimensions for pixel perfect clarity. Using an Orthogonal Cam could probably eliminate unnecessary math, I really like to see this system in action.
I start to run into trouble with the texturing the sprites. I haven't quite figured out the formula to map the texturecoords with the sprite and maintain clarity in proportion to the sprites dimensions. Single Surface sprites adds more complexity.
I intend to have animated motion and image effects. The GUI is being designed more so with Games in mind. But, Games can have built in apps like editors and such, so I want to support them as well.
Another area of my concern is maintaining high performance and drawing of text and shapes like rects and ovals. I fear that these functions will be slower than Blitz2D commands.
Truly appreciate the insight.
Your camera technique sounds very interesting. There is some pain in working out the math for positioning the sprite's depth in relation to screen's dimensions for pixel perfect clarity. Using an Orthogonal Cam could probably eliminate unnecessary math, I really like to see this system in action.
I start to run into trouble with the texturing the sprites. I haven't quite figured out the formula to map the texturecoords with the sprite and maintain clarity in proportion to the sprites dimensions. Single Surface sprites adds more complexity.
I intend to have animated motion and image effects. The GUI is being designed more so with Games in mind. But, Games can have built in apps like editors and such, so I want to support them as well.
Another area of my concern is maintaining high performance and drawing of text and shapes like rects and ovals. I fear that these functions will be slower than Blitz2D commands.
Truly appreciate the insight.