# Why I'm not getting any kind of output in SDL?

Here's the code that supposed to display the texture:

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, mainRaster.getOutput,null,null);
SDL_RenderPresent(renderer);


The code that runs the update process:

if(doubleBufferRegisters[0] == 0){
doubleBufferRegisters[0] = 1;
doubleBufferRegisters[1] = 0;
}else{
doubleBufferRegisters[0] = 0;
doubleBufferRegisters[1] = 1;
}
SDL_LockTexture(frameBuffer[doubleBufferRegisters[0]], null, &fbData[doubleBufferRegisters[0]], &fbPitch[doubleBufferRegisters[0]]);
1);

for(int i ; i < layerList.length ; i++){
layerList[i].updateRaster(fbData[doubleBufferRegisters[0]], fbPitch[doubleBufferRegisters[0]], palette);
}
SDL_UnlockTexture(frameBuffer[doubleBufferRegisters[0]]);
r = false;


My engine uses CPU based rendering for the most part. I had to remove some of the overhead, as the engine first had to create an SDL_Surface from the proprietary bitmap format, then an SDL_Texture, now the palette conversion is done on the fly, enabling the use of transparencies and non-paletted graphics. However, an old problem came back after this, namely I'm getting a black screen. Even back then it was almost impossible to fix and still don't know what I did to make it work (other that trial and error with small modifications). Bypassing the "double buffering" doesn't change anything.

I'm writing my engine in D, however any help for C++ also would be helpful.

• Is there a member variable called getOutput, or are you actually missing parenthesis there? (Or is that some D stuff?) – Tyyppi_77 May 2 '16 at 5:31
• Yes, there is, however I obscured it. That function returns the unlocked texture now, as it gives a bit of boost on the framerate. Changing to return the same exact texture only results in lower update rate, still no output. – László Szerémi May 2 '16 at 14:46
• I think you would have to provide more code. As a side note, you should try coloring your buffers with a static red or something to see if the problem is the SDL rendering, your CPU rendering or potentially something else. – Tyyppi_77 May 2 '16 at 18:57

## 1 Answer

Well, it seems I had some problem with the alpha-blending algorithm I wrote in the in-line assembler, that uses MMX. While I could test that the code actually works and wrote actual data to the framebuffer, the image didn't show on the window.

Here's the assembly part to the alpha-blending:

asm{
//mov       edi,dest;
//mov       ebx,src;
//mov       ecx,len;
mov     EDX, alpha;

//movzx   EAX,DL;
movq    MM7,alphaMMXmul_const1;

shl     EAX,16;
add     EAX,EDX;
mov     [alphaMMXmul_0],EAX;
mov     [alphaMMXmul_0 + 4],EAX ;
movq    MM6,alphaMMXmul_0; //mm6(X) = alpha (4 words)
pxor    MM5,MM5;
psubusw MM7,MM6; //mm7(Y) = 256 – alpha (4 words)

//ALIGN 16
//  MixAlphaMMX32_MainLoop:

//movd      MM0,[EDI]; //mm0(A) = 0 0 0 0 | 0 Ra Ga Ba
movd        MM0,dest;
//movd      mm1,[ebx]; //mm1(B) = 0 0 0 0 | 0 Rb Gb Bb
movd        MM1,src;

punpcklbw   MM0,MM5; //mm0 = 0 0 0 Ra | 0 Ga 0 Ba
punpcklbw   MM1,MM5; //mm1 = 0 0 0 Rb | 0 Gb 0 Bb
pmullw      MM0,MM6; //mm0 = 0 Ra*X | Ga*X Ba*X
pmullw      MM1,MM7; //mm1 = 0 Rb*Y | Gb*Y Bb*Y
paddusw     MM0,MM1; //mm0 = 0 Ra*X+Rb*y | Ga*X+Gb*y Ba*X+Bb*Y
psrlw       MM0,8; //mm0 = 0 0 0 Rc | 0 Gc 0 Bc
packuswb    MM0,MM0; //mm0 = 0 0 0 0 | 0 Rc Gc Bc
//movd      [edi],mm0;
movd        dest,MM0;

//dec       ecx ;

emms        ;
}


Going to use some non-scalar method until I come up with something better. The assembly code had built-in type conversion, most samples I could find on the internet even used floating point operations. Then I can focus on fixing the framerate issues either by reducing the redraw calls (by using a different framebuffer for all layers), or finding a faster way to update the framebuffer.