I'm now familiar with allegro. But now allegro learning leads me to learn sprite sheets for my character animations.
This time I want some help on how to create, load and use the sprite sheets in allegro 5.
I'm using Dev c++ in windows PC. And without network connection(thought I should specify).
Creating a spritesheet is just a matter of creating an image in the art program of your choice, divided up into rectangular regions. For the sake of this example, lets say each region in your spritesheet is 32x32 pixels.
To load the spritesheet, just use al_load_bitmap
There is an example here.
To draw 'sprites', you can use al_draw_bitmap_region and tell it what subsection of the spritesheet to draw.
Assuming our spritesheet is divided up into 32x32 pixel rectangles and x, y is the location you want to draw the sprite at:
al_draw_bitmap_region(spritesheet, 0, 0, 32, 32, x, y) would draw the 'first sprite' (from the very top-left corner of the sheet),
al_draw_bitmap_region(spritesheet, 32, 0, 32, 32, x, y) would draw the sprite just to the right of the first one, and so forth...
Related
I have some images captured from an wide angle appx. (180 degree) camera.
I am using opencv 2.4.8 which gives some details about camera matrix n distortion matrix.
MatK = [537.43775285, 0, 327.61133999], [0, 536.95118778, 248.89561998], [0, 0, 1]
MatD = [-0.29741743, 0.14930169, 0, 0, 0]
And this info I have used further to remove the distortion.
But the result is not as expected.
I have attached some input images of chess board which i have used to calibrate.
Or Is there any other tools or library by which it can be removed.
input images
from a Normal Camera or even captured by my smart phone
This is not an answer to the question, but something about the "discussion" of distortion and planarness.
In reality you have some straight lines on a pattern:
With (nearly any) lens you'll get some kind of distortion so that those straight lines aren't straight anymore after projection to your image. This effect is much stronger for wide angle lenses. You could expect something like this (for wide angle stronger but similar):
But the images you provided look more like this, which can be because of your pattern wasnt really planar on the ground, or because the lens has some additional "hills" on your lens.
The whole point of the calibration process is to tell OpenCV what a straight line looks like under distortion. A chess board is used to present a number of straight lines that are easy for OpenCV to detect. In your image, these lines are simply not straight. I'm moderately sure that OpenCV also needs square boxes.
So, use a real chess board pattern. Print it out, glue it to a piece of wood or hard plastic or whatever. But make sure it's a regular chessboard pattern on a level plane.
The most common method (used by the Oculus Rift Runtime for example) draws a fine enough textured grid for which the texture coordinates or the grid node positions are chosen to compensate the distortion. To obtain the grid normally one fits a polynomial or a spline to some reference picture. For example the checkerboard in your camera is a common calibration target.
I have a 6 vertex rectangle 100x100 in size, this i covered with a 100x100 background image. now i would like to render two "sub textures" on top of it.
lets say i have two sub textures size 20x20 one of then i like to position at x:10 y:10 and the other x:50 and y:50
(these are actually to get used as masks on the background image.)
how should i go with this ? my first thought was to send a uniform vec2 with the position of the two sub textures info the fragment shader, but i cant really figure out how to convert those into texture2d(subtexture, coordinate) because texture2d takes 0-1 values. i cant really wrap my head around this, and i hope to get some pointers in what direction i should go.
(this is to be used on OpenGL ES 2.0)
Then I think what you're really looking for is how to update a texture. In you case, the simplest method may be to use glTexSubImage2D. The following will do what you ask in your original post
glTexSubImage2D( GL_TEXTURE_2D, 0, 10, 10, 20, 20, <format>, <type>, <subimage1> );
glTexSubImage2D( GL_TEXTURE_2D, 0, 50, 50, 20, 20, <format>, <type>, <subimage2> );
where <format>, and <type> describe the pixels in the sub-texture stored at <subimage*>. There are quite a lot of additional answers in other questions; just search for glTexSubImage2D.
A more complex method (for when things aren't as simple as your problem) is to use framebuffer objects to render to textures (have search for that one too, if you need).
Could you please share some code (any language) on how draw textured line (that would be smooth or have a glowing like effect, blue line, four points) consisting of many points like on attached image using OpenGL ES 1.0.
What I was trying was texturing a GL_LINE_STRIP with texture 16x16 or 1x16 pixels, but without any success.
In ES 1.0 you can use render-to-texture creatively to achieve the effect that you want, but it's likely to be costly in terms of fill rate. Gamasutra has an (old) article on how glow was achieved in the Tron 2.0 game — you'll want to pay particular attention to the DirectX 7.0 comments since that was, like ES 1.0, a fixed pipeline. In your case you probably want just to display the Gaussian image rather than mixing it with an original since the glow is all you're interested in.
My summary of the article is:
render all lines to a texture as normal, solid hairline lines. Call this texture the source texture.
apply a linear horizontal blur to that by taking the source texture you just rendered and drawing it, say, five times to another texture, which I'll call the horizontal blur texture. Draw one copy at an offset of x = 0 with opacity 1.0, draw two further copies — one at x = +1 and one at x = -1 — with opacity 0.63 and a final two copies — one at x = +2 and one at x = -2 with an opacity of 0.17. Use additive blending.
apply a linear vertical blur to that by taking the horizontal blur texture and doing essentially the same steps but with y offsets instead of x offsets.
Those opacity numbers were derived from the 2d Gaussian kernel on this page. Play around with them to affect the fall off towards the outside of your lines.
Note the extra costs involved here: you're ostensibly adding ten full-screen textured draws plus some framebuffer swapping. You can probably get away with fewer draws by using multitexturing. A shader approach would likely do the horizontal and vertical steps in a single pass.
I am using pygtk and cairo (...wonderful stuff I must say. Thanks to all)
I am wondering how to present parts of images on my my cairo surface on a large drawingarea.
I would like to have areas within the displayed surface that appear to act clipped so I can scroll images through these areas without disturbing the surrounding drawn items.
Can I cut images for part drawing onto a surface or must I just get the drawing sequence in the proper order so that the images needing to be clipped are overlain and so part hidden as required and appear clipped?
thanks for any pointers
nick
Cairo is indeed wonderful! ctx.clip() is one way to do it, using a clipping path (shown below in just pycairo, where the final draw rectangle only hits the triangular clipped area).
You could also use a transfer mode of CAIRO_OPERATOR_OUT (I think), but I'm less familiar with the transfer modes. And that would only work on the first draw, since your content would fill the alpha a bit.
(Your suggestion of "Painting Order" will work fine, too, of course!)
import cairo
WIDTH, HEIGHT = 256, 256
surface = cairo.ImageSurface (cairo.FORMAT_ARGB32, WIDTH, HEIGHT)
ctx = cairo.Context (surface)
ctx.rectangle(0,0,300,300)
ctx.set_source_rgb(0,0,0)
ctx.fill()
ctx.move_to(0,0)
ctx.line_to(200,90)
ctx.line_to(90,200)
ctx.line_to(0,0)
ctx.close_path()
ctx.clip()
ctx.rectangle(0,0,300,300)
ctx.set_source_rgb(1,1,0)
ctx.fill()
surface.write_to_png("clipped.png")
I come from a 2D animation background and so when ever I us an animated sequence I prefer to use a sequence of images. To me this makes a lot of sense because you can easily export the image sequence from your compositing/editing software and easily define the aspect.
I am new to game development and am curious about the use of a sprite sheet. What are the advantages and disadvantages. Is file size an issue? - to me it would seem that a bunch of small images would be the same as one massive one. Also, defining each individual area of the sprites seems time cumbersome.
Basically, I dont get why you would use a sprite sheet - please enlighten me.
Thanks
Performance is better for sprite sheets because you have all your data contained in a single texture. Lets say you have 1000 sprites playing the same animation from a sprite sheet. The process for drawing would go something like.
Set the sprite sheet texture.
Adjust UV's to show single frame of animation.
Draw sprite 0
Adjust UV's
Draw sprite 1
.
.
.
Adjust UV's
Draw sprite 998
Adjust UV's
Draw sprite 999
Using a texture sequence could result in a worst case of:
Set the animation texture.
Draw sprite 0
Set the new animation texture.
Draw sprite 1
.
.
.
Set the new animation texture.
Draw sprite 998
Set the new animation texture.
Draw sprite 999
Gah! Before drawing every sprite you would have to set the render state to use a different texture and this is much slower than adjusting a couple of UV's.
Many (most?) graphics cards require power-of-two, square dimensions for images. So for example 128x128, 512x512, etc. Many/most sprites, however, are not such dimensions. You then have two options:
Round the sprite image up to the nearest power-of-two square. A 16x32 sprite becomes twice as large with transparent pixel padding to 32x32. (this is very wasteful)
Pack multiple sprites into one image. Rather than padding with transparency, why not pad with other images? Pack in those images as efficiently as possible! Then just render segments of the image, which is totally valid.
Obviously the second choice is much better, with less wasted space. So if you must pack several sprites into one image, why not pack them all in the form of a sprite sheet?
So to summarize, image files when loaded into the graphics card must be power-of-two and square. However, the program can choose to render an arbitrary rectangle of that texture to the screen; it doesn't have to be power-of-two or square. So, pack the texture with multiple images to make the most efficient use of texture space.
Sprite sheets tend to be smaller
files (since there's only 1 header
for the whole lot.)
Sprite sheets load quicker as there's
just one disk access rather than
several
You can easily view or adjust multiple frames
at once
Less wasted video memory when you
load the whole lot into one surface
(as Ricket has said)
Individual sprites can be delineated by offsets (eg. on an implicit grid - no need to explicitly mark or note each sprite's position)
There isn't a massive benefit for using sprite sheets, but several small ones. But the practice dates back to a time before most people were using proper 2D graphics software to make game graphics so the artist workflow wasn't necessarily the most important thing back then.