becouse mine preaty sucks as i see.

btw. i was making it about month becouse of numerous bugs. :( :( :( :(

and dont tell me about strchblt pls
Posted on 2003-03-26 11:35:24 by AceEmbler
Can't a box filter be used? The algorithm should collect the errors around each pixel in the destination image. I can think of it visually, but it is not easy to explain. I did a linear algorithm for Thomas ( here ), but you want to work in two dimensions and with three color components.
Posted on 2003-03-26 19:59:14 by bitRAKE
i dont wona use FPU if i can.
Posted on 2003-03-27 11:07:27 by AceEmbler
Can we see your algo please?
I assume it could be greatly optimized...
How are you resampling the image(s)?
Is it just the flickering that concerns you? Or is it slow?
Posted on 2003-03-28 09:41:21 by Homer

Can we see your algo please?
I assume it could be greatly optimized...
How are you resampling the image(s)?
Is it just the flickering that concerns you? Or is it slow?



Heh and here is the problem, becouse it is not flickering, it's just looking ugly.
it's not slow.

here is the code but it's preaty messed so dont be scared.
Posted on 2003-03-30 14:45:18 by AceEmbler
So what do u think about the code ?? Is it good ?? btw how can i measure speed of my prog. (becouse i need to know if it's profitable enought to plays with registery so much) :confused:
Posted on 2003-04-08 09:29:35 by AceEmbler
Using cpu registers the way you are isn't the problem.
The problem is the nested blitting.
BitBlt is notoriously slow stuff.
I'm informed that it doesn't really work on a hardware level as its name implies.
Have you considered that the image is not large?
It might be faster to copy pixel color data around inside a bitmap yourself, say using the FPU?
Also, if you decided to flip the image vertically rather than horizontally, you could be moving whole horizontal lines which would be much faster, even using BitBlt to do it.
How can we get closer to the video hardware then?
We could look at HAL and DirectDraw type stuff.
Or we could go the OpenGL path.
Either will allow us transparent access to hardware in a more efficient way than BitBlt could dream of. These api are interfaces to "whatever" graphic card is being used, and are decently optimized in most cases.
Seems odd to go to a high level api to get closer to the hardware, but thats the result.
Posted on 2003-04-08 11:04:54 by Homer