I am building a game and the main character's arm will be following the mouse cursor, so it will be rotating quite frequently. What would be the best way to rotate it?
With SDL you have a few choices.
Rotate all your sprites in advance (pre-render all possible rotations) and render them like you would any other sprite. This approach is fast but uses more memory and more sprites. As #Nick Wiggle pointed out, RotSprite is a great tool for generating sprite transformations.
Use something like SDL_gfx to do real-time rotation/zooming. (Not recommended, very slow)
Use SDL in OpenGL mode and render your sprites to primitives, applying a rotation to the primitives.
Option 3 is probably your best bet because you gain all of the advantages of using OpenGL. It's really up to you how to want to do it. It's also a possibility that you can load your sprites, perform all rotation calculations with SDL_gfx and then save the rotated versions to an SDL_Surface in memory.
EDIT: In response to your comment I would recommend checking out Lazyfoo's SDL tutorials. Specifically, this one about rotation. There is also an OpenGl function, glRotatef, which can be useful in your case. A quick search brought back this little tidbit which could also be helpful.
SDL_RenderCopyEx()
has extra arguments for rotation, flipping, and the rotation center.
You can use a library like SDL_gfx
Related
I'm trying to make a program that handles graphics and I am not quite sure how to implement zooming. I have done a zooming effect with primitive shapes such as lines and circles (with SDL_gfxPrimitives) by scaling them down but that wont work for a picture. How would I implement zooming?
There is a SDL library that supports zooming:
SDL2_gfx Library
The SDL_gfx library evolved out of the SDL_gfxPrimitives code which
provided basic drawing routines such as lines, circles or polygons and
SDL_rotozoom which implemented a interpolating rotozoomer for SDL
surfaces.
The current components of the SDL_gfx library are:
Graphic Primitives (SDL_gfxPrimitves.h)
Rotozoomer (SDL_rotozoom.h)
Framerate control (SDL_framerate.h)
MMX image filters (SDL_imageFilter.h)
Custom Blit functions (SDL_gfxBlitFunc.h)
Your question is not specific enough to produce a specific answer that is likely to get you what you appear to be looking for.
What I can offer you is the suggestion that you first come up with a way to represent zooming.
If you already know how to draw a picture, consider the fact that when it comes to computer graphics, it is almost always the case that "zooming in" or "zooming out" is nothing more than drawing your picture at a progressively larger or smaller size.
With that in mind, maybe you will begin to see that a reasonable way to represent the concept of zooming is with some form of Camera class that will unambiguously determine the size and location of the pictures you draw.
I have an SVG file.This file shows the outline of cartoon character(2D character).
My question is, can I make a program that It allows the user to interact with the outline and deform it.
An example is, to pull the outline of character's arm, with the mouse,and the arm gets bigger.
I suppose that Bezier Curves and Elliptical Arcs is a solution.I also wonder if i use OPENGL, I might be more flexible to do that.
The interaction aspect you'll need to deal with yourself. There is a recent OpenGL extension, NV_path_rendering which makes accurate, hardware-accelerated rendering of SVG and other vector formats pretty simple. The SDK includes at least one example where interaction with control points is shown, which might make a good starting place for you. Obviously, this would require you/the end user to have a GPU which supports the extension. Here's a video of the developer explaining the extension and what it can do.
I also wonder if i use OPENGL, I might be more flexible to do that.
OpenGL will not make things easier in any way. OpenGL is a drawing API, not some kind of magic scene and geometry manager. All it gives you are points, lines and triangles and methods to define how those are to be drawn to a framebuffer.
Interaction with the user lies completely outside the scope of OpenGL.
iscriptdesign allows you to create interactive graphics, but you need to program/script those yourself.
I'm trying to develop a custom set of libraries for creating GUIs in Linux, with, you know, widgets, buttons, etc. So I'm now learning to creating user interfaces using X11 and its Xlib. I get to the point of having a nice window of a size specified, at a position specified, of a specified background color, and the possibility of drawing points, rectangles, arcs. However as I drew my first circle I got really disappointed by the fact that the circle is not antialiased. I can see every single pixel as a square.
Now the question is easy. Is there any way to tell X: please antialias anything before drawing? Or do I have to avoid using XDrawArc and use a custom function which calls XDrawPoint for each point of the circle? Or there is a third solution?
Thanks in advance.
The short answer is "no". Xlib doesn't do anti-aliasing.
The longer answer is "you can use a higher level API such as Cairo Graphics". It's not necessary to roll your own.
What you encountered are the limitations of the X11 core protocol; technically it would be perfectly possible to add antialiasing to it, but that didn't happen.
Instead there's the XRender extension, that provides nice antialiased primitives. You'll also want to look into Xft to render antialiased text using vector fonts.
You can roll your own antialiasing algorithm. You have the only 2 primitives you need: 1) a function to draw TrueColor points (namely, xcb_poly_point(), if you're using XCB), and 2) for loops.
I am fairly new to openGL. I have a 3d game that I have running, and it seems to go fairly well. What I would like to do is display an image straight onto the screen, and I am not sure the easiest way to do that. My only idea is to draw a rectangle right in front of the screen and use the image as the texture. It seems like there should be an easier way.
This is for menu screens, and things, so if there is a better way to do that as well, please let me know.
I would recommend setting up OpenGL for 2D rendering via gluOrtho2d(); then, load the image into a texture and, as you said, draw it to the screen by creating a polygon and binding the texture to it. A good example can be found here.
You've got the basic idea. The other obvious alternative is to use glDrawPixels() but I think you'll find the texture method has much better performance. If you're feeling frisky, you might also take a look at Pixel Buffer Objects.
Good luck!
I guess I'll illustrate with an example:
In this game you are able to draw 2D shapes using the mouse and what you draw is rendered to the screen in real-time. I want to know what the best ways are to render this type of drawing using hardware acceleration (OpenGL). I had two ideas:
Create a screen-size texture when drawing is started, update this when drawing, and blit this to the screen
Create a series of line segments to represent the drawing, and render these using either lines or thin polygons
Are there any other ideas? Which of these methods is likely to be best/most efficient/easiest? Any suggestions are welcome.
I love crayon physics (music gets me every time). Great game!
But back to the point... He has created brush sprites that follow your mouse position. He's created a few brushes that account for a little variation. Once the mouse goes down, I imagine he is adding these sprites to a data structure and sending that structure through his drawing and collision functions to loop through. Thus popping out the real-time effect. He is using Simple DirectMedia Layer library, which I give two thumbs up.
I'm pretty sure the second idea is the way to go.
First option if the player draws pure freehand (rather than lines), and what they draw doesn't need to be animated.
Second option if it is animated or is primarily lines. If you do choose this, it seems like you'd need to draw thin polygons rather than regular lines to get any kind of interesting look (as in the crayon example).