Index
> OS Construction > virtual screen size |
| Author |
|
|
bitshifter 24 Jan 2010, 20:35
imul...idiv...youre killing me
Or, two shifts per pixel, enough said... http://board.flatassembler.net/topic.php?p=108398#108398 |
|||
24 Jan 2010, 20:35 |
|
|
edfed 24 Jan 2010, 23:20
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...? |
|||
|
24 Jan 2010, 23:20 |
|
|
bitshifter 24 Jan 2010, 23:35
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! |
|||
|
24 Jan 2010, 23:35 |
|
|
edfed 25 Jan 2010, 00:36
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. |
|||
|
25 Jan 2010, 00:36 |
|
|
f0dder 25 Jan 2010, 01:14
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. |
|||
|
25 Jan 2010, 01:14 |
|
|
edfed 25 Jan 2010, 01:45
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. |
|||
|
25 Jan 2010, 01:45 |
|
|
f0dder 25 Jan 2010, 01:54
edfed wrote: i use zoom in order to obtain a virtual screen resolution of 3200*2000  |
|||
|
25 Jan 2010, 01:54 |
|
|
edfed 25 Jan 2010, 02:07
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 
with boxes instead of pixel it will fill entirelly the screen, but will slow down one more time the FPS. |
|||
|
25 Jan 2010, 02:07 |
|
< Last Thread | Next Thread > |
Forum Rules:
|