flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
edfed 27 Feb 2011, 16:13
sure its slow (very slow compared to HW acceleration), but it works.
for faster execution, maybe use a different algorithm to fill a rectangle can be good. |
|||
![]() |
|
Teehee 28 Feb 2011, 00:26
Question: Is it a good practice to save the value of the registers that you change inside a function? or thats not important?
|
|||
![]() |
|
Teehee 28 Feb 2011, 11:24
Do you mean follow my own calling convention, or just in case if i was follow one? I don't even know if i want to follow one.
|
|||
![]() |
|
edfed 28 Feb 2011, 14:07
it juste depend, do you want your programm to be easy for you to debug, or do you want to deal with existing conventions, inducing a lot of learning, need to read a lot of documentation, and try, try, try again.
in both cases, your program will work, in the case of custom calling convention, you just have to "invent" a way you find easy to understand. if you "invention" is like an existing convention, use that convention, else, developp your convention. but wich is fastest? if you want to know, you can use the tricktest pseudo-application i wrote to compare many snippets one by one. http://board.flatassembler.net/topic.php?p=119650#119650 |
|||
![]() |
|
Teehee 28 Feb 2011, 16:05
JohnFound wrote: using putpixes is not a good idea especially in order to fill big areas with the same collor. edfed wrote: yep. Guys, im a lil bit lost on this. Help me understand this buffer thing. Isn't the VBE buffer fixed? so how can i change that buffer? this is how i rewrote the drawfillrect function (faster now), but i get the pixels in a different color (overlaps ![]() Code: drawfillrect: mov eax,[esp+2*4] ;y add eax,[esp+4*4] ;h mov ebx,[esp+1*4] ;x call moveTo mov eax,[esp+5*4] ;c ;shl eax,8 ; if i uncomment this line i got right colors, except the last one. mov edx,[esp+3*4] ;w shl edx,1 add edx,[esp+3*4] ;w edx = w * 3bytes mov ecx,[esp+4*4] ;h .for: mov ebx,edx @@: mov dword[edi+ebx],eax ;c sub ebx,3 jnz @b sub edi,1280*3 dec ecx jnz .for ret 5*4 _________________ Sorry if bad english. |
|||
![]() |
|
JohnFound 28 Feb 2011, 16:39
I wrote about using 32bit chunks to write 24bit pixels.
Let say you want to use 24bit color $112233 (in memory: $33 $22 $11) Then you need to construct 3 dwords (that will contains 4 pixels). Something like this: Code: mov eax, $33112233 mov ebx, $22331122 mov ecx, $11332211 Then you can write pixels like this: Code: mov [edi], eax mov [edi+4], ebx mov [edi+8], ecx With 3 instructions (memory writes) you write 4 pixels of color $112233 Of course you have to check the size of the rectangle (line) and if it is not multiply of 4 to make some different processing of the last pixels, but it concerns only 1..3 pixels and will not slow down the algorithm. |
|||
![]() |
|
edfed 28 Feb 2011, 18:53
the double buffer means:
1: you don't use directlly the Screen Memory 2: you write pixel anywhere in memory but screen memory 3: you transfert pixels from buffer to screen memory periodically 4: you can read pixel without reading to screen memory etc... john found: nice trick, i will try it one day.. ![]() |
|||
![]() |
|
Teehee 28 Feb 2011, 19:12
edfed wrote: 3: you transfert pixels from buffer to screen memory periodically it seems slower. (me and my speed obsession ![]() edfed wrote: 4: you can read pixel without reading to screen memory Quote: john found: nice trick, i will try it one day.. I tried, but no sucess yet. ![]() _________________ Sorry if bad english. |
|||
![]() |
|
f0dder 28 Feb 2011, 19:14
Reading GPU memory is überslow, so if you want to do software post-processing, double-buffering can be a win.
Outside of toy OS tinkering, try to go for GPU acceleration, in which case you don't want double buffering. |
|||
![]() |
|
Teehee 28 Feb 2011, 19:32
whats GPU and überslow?
|
|||
![]() |
|
f0dder 28 Feb 2011, 19:38
GPU = Graphics Processing Unit, semi-modern term for a capable graphics card.
überslow = super slow, very slow, crazy-ass slow, <insert your own term> ![]() |
|||
![]() |
|
Teehee 28 Feb 2011, 19:48
and what would be the GPU acceleration?
|
|||
![]() |
|
edfed 28 Feb 2011, 20:02
GPU acceleration is a set of instructions and data structures used in the GPU, exactlly as instructions and datas for the CPU, but close to the video DAC (digital to analog converter), and very different because it is a purpose specific processor, just made to compute faster the pixels in 3D, and fill faster the screen in 2D.
the 2D HW acceleration is a set of basic commands, passed to the GPU. for example to draw a line, fill a rectangle, put a bitmap,write font... and is specific to each model of GPU, not like the instruction set of X86. if you want to exploit the HW acceleration, it is better to use OPENGL, direct draw, win32, X, GTK, QT within an OS like windows or linux. for the moment, maybe latter, there will be a good way in BOOT asm. |
|||
![]() |
|
Teehee 28 Feb 2011, 20:07
edfed wrote: the 2D HW acceleration is a set of basic commands, passed to the GPU. and is specific to each model of GPU, not like the instruction set of X86. ![]() Quote: if you want to exploit the HW acceleration, it is better to use OPENGL, direct draw, win32, X, GTK, QT within an OS like windows or linux. for the moment, maybe latter, there will be a good way in BOOT asm. ![]() _________________ Sorry if bad english. |
|||
![]() |
|
edfed 28 Feb 2011, 20:11
1:google.com, osdev.org, osdever...etc.
2:fasm example named OPENGL in the official FASMW package. |
|||
![]() |
|
JohnFound 28 Feb 2011, 21:06
edfed wrote: GPU acceleration is a set of instructions and data structures used in the GPU, exactlly as instructions and datas for the CPU, but close to the video DAC (digital to analog converter), and very different because it is a purpose specific processor, just made to compute faster the pixels in 3D, and fill faster the screen in 2D. AFAIK, there is some VESA enhanced functions for dealing with HW accelerated video. But the last time I looked for it (5 years ago) it was closed specification that one have to buy from VESA. It was named VESA/AF of something similar. |
|||
![]() |
|
f0dder 28 Feb 2011, 21:13
I dunno if there were ever any video cards supporting that, JohnFound? (Except perhaps for a few expensive ones) - it seemed to come at too late a time, when things headed towards Windows/whatever very fast, and that became the place for accelerated graphics.
The univbe driver supported the spec, but that might have been software emulation rather than hardware supported. And it was all rather messy if you wanted to use it from pmode. |
|||
![]() |
|
JohnFound 28 Feb 2011, 21:23
So, what is the conclusion? Every OS maker must begin with decent video driver interface it he wants its OS to have any future.
![]() |
|||
![]() |
|
edfed 28 Feb 2011, 22:10
Mode 13h is good enough.
![]() |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.