Show Posts
1
General / Newbie questions: vector graphics, sprites, and zooming
« on: March 02, 2014, 08:16:11 am »
Greetings. I've got a couple of different applications I've been toying with for a long time, and I'm looking at SFML as a possible graphics layer (with native UI around or over the canvas). One is a golf GPS app that would primarily target Android, and the other is a port of a board game that would primarily be on Windows. Both apps need the ability to draw 2D vector Bezier-curve outlined polygons filled with either solid colors or colored textures, as well as sprite images whose screen size should stay the same while zooming in and out. I'm developing both using C#, and I've attached a screenshot of the board game and a screenshot of someone else's golf GPS app as examples.
My existing code for both the board game and the GPS app has used the Piccolo2D scene graph library. It's worked well, but the C# port has fallen way behind the Java version, and the project seems mostly dead anyway. Both versions are heavily dependent on their respective 2D drawing APIs (GDI+ and Java2D), and neither works on Android.
So, I've been doing a ton of research on possible other options. I'm generally an applications and desktop GUI developer, not a game developer, and my knowledge of OpenGL is just about zilch. Because of that, I'm looking for something that will keep me several abstraction levels above the nitty-gritty details of rendering if at all possible. Generally, SFML's "put this shape here"-type API seems like the kind of thing I'm aiming for.
What I'm trying to figure out at the moment is what the right approach is for implementing a zooming rendering behavior. Example scenario: when a player is on the tee of a golf hole, the vector rendering of the hole should be zoomed out to show the entire hole. As the player walks forward, the camera zooms in on a box containing the back of the hole and the player's current location. In the process, the outlines for the polygons should stay the same pixel width, and the bitmap sprites for things like bushes and trees should stay the same pixel size on screen (and start moving out of view).
I see that SFML has scalable items, including polygonal shapes and sprites, and I see that the View class has various zoom / viewport abilities. So, I suspect something could be done with those. I've found the Zoost and Zoom libs, which are supposed to allow much more in-depth geometry rendering over the base Shapes. Meanwhile, I've also been looking at AGG-Sharp, a C# port of the Anti-Grain Geometry rendering library. It seems like that has a lot of potential somehow, although I'm not sure what the right conceptual approach would be for tying that into SFML (textures / resizing / re-render / something?).
I've pulled down SFML.Net and played around with it for a couple hours. I've got a couple shapes and a small icon sprite on screen, textured one of the shapes, and tried both scaling the shapes and changing the View's zoom. Neither approach seems to immediately do what I want, though. Scaling the shapes leads to the textured shape rendering the texture larger and larger, when what I really want is for the shape to get bigger and keep tiling the texture. Zooming the view out seems to produce a somewhat similar problem.
In general, I have a pretty good idea WHAT I want to do, I just don't know enough about the game programming domain to know how exactly to go about it. If anyone has any suggestions on how I should approach these concepts, I'd greatly appreciate it.
Thanks!
Mark Erikson
My existing code for both the board game and the GPS app has used the Piccolo2D scene graph library. It's worked well, but the C# port has fallen way behind the Java version, and the project seems mostly dead anyway. Both versions are heavily dependent on their respective 2D drawing APIs (GDI+ and Java2D), and neither works on Android.
So, I've been doing a ton of research on possible other options. I'm generally an applications and desktop GUI developer, not a game developer, and my knowledge of OpenGL is just about zilch. Because of that, I'm looking for something that will keep me several abstraction levels above the nitty-gritty details of rendering if at all possible. Generally, SFML's "put this shape here"-type API seems like the kind of thing I'm aiming for.
What I'm trying to figure out at the moment is what the right approach is for implementing a zooming rendering behavior. Example scenario: when a player is on the tee of a golf hole, the vector rendering of the hole should be zoomed out to show the entire hole. As the player walks forward, the camera zooms in on a box containing the back of the hole and the player's current location. In the process, the outlines for the polygons should stay the same pixel width, and the bitmap sprites for things like bushes and trees should stay the same pixel size on screen (and start moving out of view).
I see that SFML has scalable items, including polygonal shapes and sprites, and I see that the View class has various zoom / viewport abilities. So, I suspect something could be done with those. I've found the Zoost and Zoom libs, which are supposed to allow much more in-depth geometry rendering over the base Shapes. Meanwhile, I've also been looking at AGG-Sharp, a C# port of the Anti-Grain Geometry rendering library. It seems like that has a lot of potential somehow, although I'm not sure what the right conceptual approach would be for tying that into SFML (textures / resizing / re-render / something?).
I've pulled down SFML.Net and played around with it for a couple hours. I've got a couple shapes and a small icon sprite on screen, textured one of the shapes, and tried both scaling the shapes and changing the View's zoom. Neither approach seems to immediately do what I want, though. Scaling the shapes leads to the textured shape rendering the texture larger and larger, when what I really want is for the shape to get bigger and keep tiling the texture. Zooming the view out seems to produce a somewhat similar problem.
In general, I have a pretty good idea WHAT I want to do, I just don't know enough about the game programming domain to know how exactly to go about it. If anyone has any suggestions on how I should approach these concepts, I'd greatly appreciate it.
Thanks!
Mark Erikson