flat assembler
Message board for the users of flat assembler.

Index > DOS > Fade in/out

Author
Thread Post new topic Reply to topic
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Hi, i have a problem and i can not find a way round it, so i thought one you may be able to help.
I want to fade a image in and out, now fade out works fine, but fade in, is ether slow or jumpy
One thing to note, is i am talking high res vesa 24/32bpp, without palette.
To fade out you just take the each byte from the buffer dec it by 8, write it back, you do this to the whole image, looping 32 times.

But to fade in, you can not do this, so far i have tryed shr 8 though to 0, with delay in between, but because there only 8 jumps instead of 32, it look abit jumpy.

Anyone got any ideas ?
Thanks advance
Post 08 Jan 2008, 00:04
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
to get reversed effect, just do this:

Code:
;cl = 8*(32 - fadetime) = 256 - 8*fadetime = - 8*fadetime
mov cl, [fade_time]
shl cl, 3
neg cl

;ESI = backbuffer
;EDI = front buffer
;color 
mov al, byte [esi] ;any part of RGB
sub al, cl
jnc .ok
mov al, 0
.ok:
mov byte [edi], al    
Post 08 Jan 2008, 00:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
But to fade in, you can not do this, so far i have tryed shr 8 though to 0, with delay in between, but because there only 8 jumps instead of 32, it look abit jumpy.


Trivial (but untested):

You need 2 buffers. Walk through "frontbuffer" and "backbuffer" parallelly ... pick value from "front", add 1 (or 8 or whatever), compare with "back", avoid that new value exceeds "back" value (reduce if necessary), count successful additions, write back to "front", next pixel, after one pass, abort if no successful additions done in last pass, delay, loop.

PS: This algo should not rely on stupid "Ms-DOS" (evidence pending Laughing )

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 08 Jan 2008, 01:25
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
sub al, cl
jnc .ok 
mov al, 0 
.ok: 
    
~=
Code:
mov dl, $ff
sub al, cl
adc dl, 0
and al, dl
    
Or
Code:
sub al, cl
sbb dl, dl
not dl
and al, dl    
(One byte shorter than previous)

It is just to try to make the time constant but I'm not sure if the overall performance will be better with ADC Razz

BTW, is correct that NEG?
Post 08 Jan 2008, 01:34
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i didn't test or optimize that code, it was just an idea written dow as assembly pseudo-code Wink
Post 08 Jan 2008, 02:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
vid wrote:
i didn't test or optimised that code, it was just an idea written dow as assembly pseudo-code Wink


Well your pseudo-code worked great, thank vid Smile
And thank to everyone that answer and i will give your optimised code a test LocoDelAssembly and report back.
Post 08 Jan 2008, 06:33
View user's profile Send private message Reply with quote
Vov4ik



Joined: 20 May 2007
Posts: 28
Location: USSR, Moscow Region
Vov4ik
It would be faster, if source image is placed not in video RAM, but in the main memory, because VRAM is optimized for writing, not for reading. And you didn't mention if you use bank switching or linear fideo buffer. Linear buffer is faster, it is especially appreciable on dynamic images.
Post 08 Jan 2008, 09:37
View user's profile Send private message ICQ Number Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Thanks for the info Vov4ik, but i do have the main image in main memory and l use LFB.
Post 08 Jan 2008, 17:48
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
AFAIK It's best to have both and backbuffer in frontbuffer in video RAM, and just flip() between them. I think I've rad that writing to "active" video ram is much slower than to rest of it.

It may not be best case for fading, but fading seldom needs to be very fast these days... it's time/bound, not CPU bound
Post 08 Jan 2008, 18:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.