flat assembler
Message board for the users of flat assembler.

Index > OS Construction > virtual screen size

Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
while playing with pixel
Code:
pixel:
;eax=x
;ebx=y
;ecx=color
        push eax ebx ecx
        cmp eax,0
        jl @f
        cmp eax,320
        jge @f
        cmp ebx,0
        jl @f
        cmp ebx,200
        jge @f
        imul ebx,320
        mov [fs:eax+ebx],cl
@@:
        pop ecx ebx eax
        ret
    




it is fun, but slower than no pixel subfunction for graphics..
but still fast enough. then, ignored for the moment.

it seems that many things are possibles.

x and y can be:
.xchged
.added
.subed
.imuled
.idived
.xored
.ored
.anded
.noted
.neged
.etced

then, playing with just imul and idiv,

Code:
pixel:
;eax=x
;ebx=y
;ecx=color
        push eax ebx ecx
        call zoomin
        cmp eax,0
        jl @f
        cmp eax,320
        jge @f
        cmp ebx,0
        jl @f
        cmp ebx,200
        jge @f
        imul ebx,320
        mov [fs:eax+ebx],cl
@@:
        pop ecx ebx eax
        ret
    

Code:
zoomin:
        push edx esi edi
        mov esi,[zoom.mul]
        mov edi,[zoom.div]
        cmp esi,edi
        je @f
        imul eax,esi
        imul ebx,esi
        cdq
        idiv edi
        xchg eax,ebx
        cdq
        idiv edi
        xchg eax,ebx
@@:
        pop edi esi edx
        ret
    


here a single screen shot in 3200*2000 virtual screen
zoom.div=100
zoom.mul=10
Image
Very Happy

BIG problem (previouslly ignored):
the speed!
the 2 imuls and idivs on x,y for each pixel are very slow...

then, for this, it will be important to evolve and start to use MMX and SVGA.

all my machines support them, then, i don't care about expanded compatibility.

screenshot in 2:10 with test above:
Image
seems to be a poor text quality, but the zoom feature is very interresting.
and differnt ratios (mul:div) can be applied to items (not implemented for the moment)


Last edited by edfed on 24 Jan 2010, 23:21; edited 1 time in total
Post 24 Jan 2010, 17:57
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
imul...idiv...youre killing me Razz

Or, two shifts per pixel, enough said...
http://board.flatassembler.net/topic.php?p=108398#108398
Post 24 Jan 2010, 20:35
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
the two shifts you are talking about are only this imul.
Code:
        imul ebx,320
        mov [fs:eax+ebx],cl
    

this one can be replaced by two shits of course.

but what about them:

x=(x*zoom.mul)/zoom.div
y= (y*zoom.mul)/zoom.div

this vectorial math trick can be made with MMX, but ...
without mul and div, i don't know...
or interpret it like arithmetic shifts combinaisons...?
Post 24 Jan 2010, 23:20
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Bit-shifting can be used if (zoom ^ 2) is acceptable.

zoom1 = 0
zoom2 = 2
zoom3 = 4
zoom4 = (You get the idea...)

But zoom resolution goes off the chart very quickly!
Post 24 Jan 2010, 23:35
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
Code:
x*3
lea eax,[eax*2+eax]
x*5
lea eax,[eax*4+eax]
x*6
lea eax,[eax*8+eax]
    

are acceptable but then, how can i do the right operations in real time?

enter a number [mul]
compute it
enter a number [div]
compute it


but div will be a little harder to do.

Code:
x*3/4
mov ebx,eax
shr ebx,2
sub eax,ebx

x*7/8
mov ebx,eax
shr ebx,3
sub eax,ebx

    


maybe only a combinaison of 1shl and 1shr is enough
Code:
x=x*7.5
mov ebx,eax
shl eax,3
shr ebx,1
sub eax,ebx
    

and then, the zoom ratio should be processed before to be used.
a simple set of lut can be enough to set both shl and shr values.
the valid coeficients will be less than 256
less than 100.
then, it can be coded on a single byte for div and mul.

M=6
D=2
db: M*16+D

pretty cool.

with shl 0,2,3,4,5,6,7 and shr 0,2,3,4,5,6,7
64 ratios combinaisons are possibles. enough for a LUT.
Post 25 Jan 2010, 00:36
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Clipping against [0..n] can be done with one CMP/Jcc per component (negative signed numbers count as "very big" unsigned, and thus fall below n).

Forget about LUTs for (x,y)->offset, they take up too much memory and will probably end up being slower because of cache trashing.

While PutPixel is a basic thing you want to get implemented, forget about optimizing it much - you won't be basing the more complex algorithms on PutPixel calls. For something like "DrawSprite" you'll be doing a few MULs outside your loops once, and then you'll be adding your calculated "goto_next_line" value to EDI/whatever after each line is drawn. Clipping can also be handled once, outside the drawing loop.
Post 25 Jan 2010, 01:14
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
thanks for the trick.
i did not think about it but it should be very good for fast limit check.

it is not offset, but zoom.

as i use eax for X, ebx for Y and ecx for color, i can do funny things with X and Y.
translate, 90┬░rotates, zoom. and many other things.

i use zoom in order to obtain a virtual screen resolution of 3200*2000

LUT will be for the fast ZOOM ratio selection, it will not work with X or Y but only with zoom.div and zoom.mul.
Post 25 Jan 2010, 01:45
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
edfed wrote:
i use zoom in order to obtain a virtual screen resolution of 3200*2000
Hm, do you zoom or do you use the visible screen as a window into the virtual screen? From the above image it does look a bit like you do actual zooming Smile
Post 25 Jan 2010, 01:54
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
i use visible screen as the windows for virtual screen.
if screen = 320*(50/7), 200*(50/7) it will give you 50/7┬▓ pixels for one screen pixel.

the interresting thing with fractional maths is that it conserve ratios as long as you do the correct adjustments on divisor and dividend.

the effexct of this zoom is a sensation of greater screen. even the poor 13h can give the impression of a 1600*1000 screen. good for desktop view.

zoom into application, ratio 1:1, maybe 2:1 for very precise graphix software.
zoom on desk, ratio 1:5, then, you have an overview of what is currently running.

below, a screenshot for a 5:2 ratio
Image

with boxes instead of pixel it will fill entirelly the screen, but will slow down one more time the FPS.
Post 25 Jan 2010, 02:07
View user's profile Send private message Visit poster's website 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. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.