flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
edfed
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
Question: Is it a good practice to save the value of the registers that you change inside a function? or thats not important?
|
|||
![]() |
|
Teehee
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
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
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
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
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
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
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
whats GPU and überslow?
|
|||
![]() |
|
f0dder
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
and what would be the GPU acceleration?
|
|||
![]() |
|
edfed
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
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
1:google.com, osdev.org, osdever...etc.
2:fasm example named OPENGL in the official FASMW package. |
|||
![]() |
|
JohnFound
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
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
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
Mode 13h is good enough.
![]() |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.