Software blitter

**h3ro** · 04-19-2008

16 bit colour can still look nice, but you will lose your alpha channel. In the 2d APIs I have used you can set the bit depth when setting up the screen. The parameters usually go something like: graphics width, graphics height, bit depth, display mode. However, without knowing what api you are using its impossible for anyone to answer that accurately.

The API is called HAPI and does file loading and creates the window for me. It gives me a pointer to the screen, which is in 32bit colors. So im not sure if I can use 16bit.

Looks like this is going to be to complicated for me to pull of.

EDIT:
What I will try to do is first trying the pre-processing you posted about before. After that I will try to take two 32bit colors into a 64bits variable. (My processor is 64bit, so I assume that would be the same as taking two 16 bits on a 32bits processor?)

**mike_g** · 04-19-2008

Hmm. I have never used HAPI. Maybe someone else would know, but if theres nothing about it in the docs then maybe you are stuck with 32 bit.

**h3ro** · 04-19-2008

HAPI is based on directX and is made by one of the teachers at my university. The point of the API is to get the students to create all the graphic stuff them self. I have learned a lot from working on this, especially when it comes to writing faster code and finding bottle necks.

And since im not taking the module, and can play around with the blitting routines for ever as I dont need to hand anything in

**VirtualAce** · 04-19-2008

Just as a side note MMX technologies can 'operate' on 64-bits but they cannot copy 64 bits to memory. So you couldn't go from MMX registers straight to your buffer. Regardless of what you do on a 32-bit system you are stuck with 32-bit fetches. A STOSD is exactly that. It stores 32 bits in EAX into ES:EDI and a MOVSD will store 32 bits at DS:ESI into ES:EDI. If you precede these with the REP prefix they will perform this operation for ECX count.
Even on 64-bit systems the MMX registers AFAIK cannot copy directly to memory. Perhaps SSE(x) can. I left the assembly scene when the SSE and SSE2 techs were introduced. By that time hardware was fast enough and the need for the pure assembly code was next to nil. Now with vertex and pixel shaders that run on the hardware even finely tuned assembly will never come close to shaders.

My code is slower than yours because it does not 'skip' pixels it does not need to write. Essentially:

if (mask[image_offset] != 1) image_offset++.

Assuming a one bit mask.

**h3ro** · 04-19-2008

Thank you again Bubba.

So MMX would not be able to take advantage of a 64bits processors. In a way im glad for that, cause now MMX is out if the picture (I think? )

Not sure if you looked at the article, but in there he takes two 16bit values and store them in an unsigned 32bit variable. What I think will work is if I take two 32bit variables and store them in a long long? It will not be as fast as MMX, but in the article it gives a 35% speed increase. (MMX is 309%!)

A side question to Bubba; Is it still useful to learn assembly/mmx? Or should I mostly just focus on learning how to write efficient c++ code?

To mike_g, if you liked the first article you might want to look at this as well:
Fast Blit Strategies
Fladmirs alpha blending

Thread: Software blitter

Thread Tools

Search Thread

Display

Similar Threads

Software Developer Opportunity in Delaware

Software Design/Test - Redmond, WA

Why C Matters

Adding trial period to software