I'm currently developing a simple application that displays map and draws some markers on it. I'm developing for Windows Mobile, so I decided to use DirectDraw and Imaging interfaces to make the application fast and pretty. The map moves when user moves finger on the touchscreen, so the whole map moving/scrolling animation has to be fast, but it is not.
On every map update I have to draw portion of the map, control buttons, and markers - buttons and markers are preloaded on DirectDraw surface as a mipmap. So the only thing I do is BitBlit from the mipmap to a back buffer, and from the back buffer to a primary surface (I can't use page flipping due to the windowed mode of my application).
Previously I used premultiplied-alpha surface with 32 bit ARGB pixel format for images mipmap, everything was looking good, but drawing entire "scene" was horribly slow - i could forget about smooth map scrolling. Now I'm using mipmap with native (RGB565) pixel format and fuchsia (0xFF00FF) color key. Drawing is much better.
My mipmap surface is generated on program loading - images are loaded from files, scaled (with filtering) and drawn on mipmap. The problem is, that image scaling process blends pixel colors, and those pixels which are on the border of a sprite region are blended with surrounding fuchsia pixels resulting semi-fuchsia color that is not treated as color key. When I do blitting with color key option, sprites have small fuchsia-like borders, and it looks really bad.
How to solve this problem? I can use alpha blitting, but it is too slow - even in ARGB 1555 format.
Related
I have some 64x64 sprites which work fine (no flicker/shuffling) when I move my camera normally. But as soon as I change the camera.zoom (was supposed to be a major mechanic in my game) level away from 1f the sprites flicker every time you move.
For example changing to 0.8f:
Left flicker:
One keypress later: (Right flicker)
So when you move around it's really distracting for gameplay when the map is flickering... (however slightly)
The zoom is a flat 0.8f and I'm currently using camera.translate to move around, I've tried casting to (int) and it still flickered... My Texture/sprite is using Nearest filtering.
I understand zooming may change/pixelate my tiles but why do they flicker?
Edit
For reference here is my tilesheet:
It's because of the nearest filtering. Depending on amount of zoom, certain lines of artwork pixels will straddle lines of screen pixels so they get drawn one pixel wider than other lines. As the camera moves, the rounding works out differently on each frame of animation so that different lines are drawn wider on each frame.
If you aren't going for a retro low-res aesthetic, you could use linear filtering with mip maps (MipMapLinearLinear or MipMapLinearNearest). Then start with larger resolution art. The first looks better if you are smoothly transitioning between zoom levels, with a possible performance impact.
Otherwise, you could round the camera's position to an exact multiple of the size of a pixel in world units. Then the same enlarged columns will always correspond with the same screen pixels, which would cut down on perceived flickering considerably. You said you were casting the camera translation to an int, but this requires the art to be scaled such that one pixel of art exactly corresponds with one pixel of screen.
This doesn't fix the other problem, that certain lines of pixels are drawn wider so they appear to have greater visual weight than similar nearby lines, as can be seen in both your screenshots. Maybe one way to get round that would be to do the zoom a secondary step, so you can control the appearance with an upscaling shader. Draw your scene to a frame buffer that is sized so one pixel of texture corresponds to one world pixel (with no zoom), and also lock your camera to integer locations. Then draw the frame buffer's contents to the screen, and do your zooming at this stage. Use a specialized upscaling shader for drawing the frame buffer texture to the screen to minimize blurriness and avoid nearest filtering artifacts. There are various shaders for this purpose that you can find by searching online. Many have been developed for use with emulators.
(Using WinApi) Is there a way to:
Make transparent pixels?
Somehow instead of using transparency just have the image dynamically get the background colors and textures, and fill certain Colors with those textures, For Example: If I had a video game sprite and the background color of it was white, could I somehow get those white pixels and fill them with the background colors/textures?
If you create a 32-bit bitmap, 24 bits of each pixel are used for RGB values and the extra 8 bits are used for an alpha channel. Just set the alpha to 0 for full transparency.
When creating a bitmap that uses 24-bit or smaller pixels, the transparent color is usually indicated by the pixel in the lower-left corner of the bitmap.
Either way, creating a transparent bitmap is only half the equation. Creating a transparent bitmap itself is easy, but you then have to render the bitmap in a transparent manner. The Win32 API has TransparentBlt() and AlphaBlend() functions for that purpose, and there are plenty of online turorials and blogs that explain how to use them.
I'm trying to create a display with a complex OpenGL image and some spinboxes on the image. Using http://doc.qt.digia.com/qq/qq26-openglcanvas.html I'm able to have a two layers object (inheriting from QGraphicsScene) with a simple OpenGL image as background and the controls on foreground.
So, now I'm trying to display my true OpenGL image as background. This image is created by:
A quad mapped on a structure,
Some small 2D objects represented by 2D textures with alpha channel and specific shaders, drawn on the quad (upper z value)
Some polylines.
With this image I have some strange behavior. The 2D textured objects are drawn with a white background. Some experiments seem to indicate that, in the drawing of this complex OpenGL image the alpha channel is disabled.
I tried different configurations for the QGLWidget used as viewport of the QGraphicsView but without result.
So I need help to be able to create this OpenGL image with the right transparency effects.
I recently started looking at cocos2d game development.
What's the difference between sprite and texture?
Maybe I could through in 'bitmap' in there. What is a bitmap?
They all seem to be the same thing as 2d image.
A texture is an in-memory image that the device can draw onto the screen.
A sprite actually draws the texture, or just a specific rectangle of the texture, on the screen. The sprite can be scaled, rotated, positioned, skewed, tinted (colorized) among other things.
Multiple sprites can share the same texture. The texture is only loaded to memory once regardless of how many sprites are using the same texture. Moreover with CCSpriteBatchNode you can "batch" the drawing of all sprites that are using the same texture to achieve better performance.
A bitmap is a general term for a computer image where each pixel is represented by one or more bits. There's also the image format BMP which is/was popular on Windows. Most people would just say "image" these days as there are other forms of "bitmaps" that are not images. For example in AI code you often have bitmaps (arrays of bits) that represent state information of the AI or pathfinding algorithms for all areas of the game world. Ie each area in the world could have a "blocking" bit, or a "resource" bit that helps the AI making decisions.
See also Wikipedia:
Texture Mapping
Bitmap
you can load texture into memory, for example your file with image is texture. sprite is object with set of parameters, several of them are pointer to the texture, size and texture coordinate.
you can load texture 2048x2048 into memory, then create sprite with part of this texture.
I'm currently developing a 2D mobile game, and I want the camera to be able to pan around and zoom in and out. One method would be to render the entire level to a backbuffer, and simply draw a region and scale it up/down to the device screen. Angry birds has the effect I'm looking for where the user can zoom out and see the whole level.
This would take huge amounts of memory to have a surface for the entire level. Another method would be to scale down each sprite and draw it in the view, but this may take more rendering power than resizing an entire surface.
Another option is similar to the first where I could have a large fixed surface to render the images on instead of having a surface for the whole level. Again, this would take huge amounts of memory especially if the user wanted to zoom out really far.
I've never really developed for mobile before. Would scaling each individual image be too expensive? Should I scale each sprite and then render, or render a large portion of the map to a surface and downscale/upscale that surface?
You shouldn't have to mess with the size of the buffer you're drawing to. What you could do is to adjust the viewport size, thereby fitting more of the world into your viewport (thus ending up on the buffer). Sprites will of course be smaller, and if it becomes to slow for you, you could implement some level of detail (LOD) so that for example "when the viewport is larger, draw the sprite using a smaller, pre-loaded, image". What would still make the solution slow/"inefficient" is that you'll be drawing more sprites, but that's not something you'll get around.