framebuffer problem

[andyz74]

Hello and good evening!

I've done a little experimenting in doing easy graphic-stuff by writing direct to framebuffer /dev/fb0  (Debian Linux 64bit here)
Mainly in Free Pascal, before testing in Assembly.
While getting lots of garbage as output I also tested code, where I think it HAS to be good and HAS to work, I also got garbage.
( https://github.com/xmdi/SCHIZONE/tree/main/ex/ex020_framebuffer )   
If I test it on my Laptop (also Debian), it works, but not here on my beloved Desktopcomputer.

Now to my questions :
1) Is there anything I have to configure on my framebuffer in my Linux, and
2) Is it worth the time, or should I better invest time in SDL2 for doing graphics stuff?

Greetz, Andy

[fredericopissarra]

You have to make sure that your video drivers support /dev/fb? and make sure it is enabled in kernel configs, AND if it is accessible to your user...

It is better to use SDL2 (or 3, it is available now!).

[andyz74]

OK. I will check the Video drivers, If I manage to find Out how. 😂

Do you know If one of both framebuffer / sdl is faster as the other?

[fredericopissarra]

Do you know If one of both framebuffer / sdl is faster as the other?

fbdev don't offer any acceleration support, not even in 2D like Bit Block Transfers (Bitblt)... SDL (2 and 3) does.

[andyz74]

OK...  Thanks you Frederico!  I think, I will do my stuff at sdl2, It is already installed in my system.

[andyz74]

Ah, now i remember : sdl2 is using multithreading so Debugging (at least with my knowledge and radare2) is not working. Seems, that i have to create a  few macros for Output of Registers, while doing calculating stuff to find the Point of Errors.

[fredericopissarra]

Ah, now i remember : sdl2 is using multithreading so Debugging (at least with my knowledge and radare2) is not working. Seems, that i have to create a  few macros for Output of Registers, while doing calculating stuff to find the Point of Errors.

Here works perfectly:

Code: [Select]

/* test.c */
#include <stdio.h>
#include <pthread.h>

unsigned int count = -1;

static void *thread( void *p )
{
  while ( count-- );

  return NULL;
}

int main( void )
{
  pthread_t tid;

  pthread_create( &tid, NULL, thread, NULL );
  getchar();
  pthread_join( tid, NULL );

  return 0;
}


Code: [Select]

$ cc -g -pthread -o test test.c
$ gdb test
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
...
Reading symbols from test...
(gdb) list
1 #include <stdio.h>
2 #include <pthread.h>
3
4 unsigned int count = -1;
5
6 void *thread( void *p )
7 {
8   while ( count-- );
9
10   return NULL;
(gdb) b 8
Breakpoint 1 at 0x11b5: file test.c, line 8.
(gdb) r
Starting program: /mnt/vol2/work/tmp/test
Downloading separate debug info for system-supplied DSO at 0x7ffff7fc3000
[Thread debugging using libthread_db enabled]                                                                                               
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7bff6c0 (LWP 67336)]
[Switching to Thread 0x7ffff7bff6c0 (LWP 67336)]

Thread 2 "test" hit Breakpoint 1, thread (p=0x0) at test.c:8
8   while ( count-- );
(gdb) p count
$1 = 4294967295
(gdb) quit
A debugging session is active.

Inferior 1 [process 67332] will be killed.

Quit anyway? (y or n) y
$

[andyz74]

I will test it "as last option" with breakpoints, but I think, it might be easier for me to comment out the sdl and graphic stuff, so I have only the calculating part working.  I just want to control my calculated coordinates by hand.  This should work.

(If i get it to work I surely will be here in some days to ask you for faster and better calculating algorithms. ;-) )

 

[andyz74]

So, I am trying my luck with sdl2.  A llittle cube defined by 8 points and the lines between it...  Moving works, but the rotating stuff isn't working, it calculates wrong values.
Because of the sinus and cosinus, I had to go with sse2, but something seems to be wrong.

I have my data like this :

section .data
xs    dq 0,0,0,0,0,0,0,0,0,0,0,0
ys  dq 0,0,0,0,0,0,0,0,0,0,0,0
points resq 24
tempx dq 0
tempy dq 0
tempz dq 0



                              ; reminder 960 x 720 window, haelfte 480 / 360
point dq    -100, -100, 300,
dq         100, -100, 300,
dq         -100, 100, 300,
dq         100, 100, 300,
dq         -100, -100, 500,
dq         100, -100, 500,
dq         -100, 100, 500,
dq         100, 100, 500   


yaussen dq 700                                 ; war erst 900 und 400
yscreen dq 100                                 ; reminder 960 x 720 window, haelfte 480 / 360

cos1 dq 0.9998477                     ; 0.9998477*x - 0.0174524*z;
sin1 dq 0.0174524

...the point-table will be written to the points-array.  Works, shifting to left, right, up, down, and in the depth worksall, but than comes a try of rotation ...

roty1:
   push rcx
   push r15
   mov rcx, 0
   nochmal8:                           ; tempx:= 0.9998477*x - 0.0174524*z
   movsd xmm0, qword [points+rcx*8]         ; load  x coordinate in xmm0
   movsd xmm1, qword [cos1]               ; load cos 1 from table in xmm1
   mulsd xmm0, xmm1                     ; multiply xmm0 and xmm1, store in xmm0
   movsd xmm2, qword [points+rcx*8+16]        ; load  z coordinate in xmm2
   movsd xmm3, qword [sin1]               ; load sin 1 from table in xmm3
   mulsd xmm2, xmm3                     ; multiply xmm2 and xmm3, store in xmm2
   subsd xmm0, xmm2                     ; subtract xmm2 from xmm0, store in xmm0
   mov r15, 0
   cvtsd2si r15, xmm0                     ; convert xmm0 to integer and store in r15
   mov qword [tempx], r15                  ; store tempx

                                    ; tempz:= 0.0174524*x + 0.9998477*z
   movsd xmm0, qword [points+rcx*8]         ; load  x coordinate in xmm0
   movsd xmm1, qword [sin1]               ; load sin 1 from table
   mulsd xmm0, xmm1                     ; multiply and store in xmm0
   movsd xmm2, qword [points+rcx*8+16]        ; load  z coordinate
   movsd xmm3, qword [cos1]               ; load cos 1 from table
   mulsd xmm2, xmm3                     ; multiply and store in xmm2
   addsd xmm0, xmm2                     ; add xmm0 and xmm2, store in xmm0
   mov r15, 0
   cvtsd2si r15, xmm0                     ; convet xmm0 to integer and store in r15
   mov qword [tempz], r15                  ; store tempz
   
   mov r15, 0
   mov   r15, [tempx]
   mov [points+rcx*8], r15                  ; write the new x coordinate to table
   mov r15, 0
   mov   r15, [tempz]
   mov [points+rcx*8+16], r15               ; same for z coordinate
   

   inc rcx
   inc rcx
   inc rcx
   cmp rcx, 24                           ; eight point in the cube, each with three coordinates...
   jne nochmal8

   pop r15
   pop rcx
ret

Rotation by y.
If I let calculate the stuff in Excel, I have good valuaes, but the conversion in Assembly-Code does not get me the right values.

Does anybody see obvious failures in the code?

Thanks in advance, Andy from the nightly sleeping Germany

[andyz74]

I found out the following by myself : 

a) if i have declared my points as integer values like "mydata dq 100" or whatever, I should not load them like "movsd xmm0, qword [mydata]" but with  "cvtsi2sd xmm0, qword [mydata]"

b) if I really work with my data as integer, they will get after a few rotation-calculations very fast unexact by the truncation/rounding.  After a 360 degree-rotation in 360 steps I will have no more a cube, but some totally other formation. ;-)    => Will have to do this with floating-point (also the storing of the coordinates)

[fredericopissarra]

a) if i have declared my points as integer values like "mydata dq 100" or whatever, I should not load them like "movsd xmm0, qword [mydata]" but with  "cvtsi2sd xmm0, qword [mydata]"

If you intend to use this data as a double, yes.

b) if I really work with my data as integer, they will get after a few rotation-calculations very fast unexact by the truncation/rounding.  After a 360 degree-rotation in 360 steps I will have no more a cube, but some totally other formation. ;-)    => Will have to do this with floating-point (also the storing of the coordinates)

Floating point is ALWAYS an approximation. Most exact fractional values in decimal cannot be exactly represented in binary...

[]s
Fred