Ufo Navigation

[Aaron]

Hello Easter,

Some new demos.

Code: [Select]

include "gp.inc"
OpenWindow 320,240,1
fo = LoadFont "verdana",16,3
single fz, vz

skull = LoadImage("png/new_ufo.png",16)
font  = LoadTile ("png/font2.png",16,6)

while KeyDown(27)=0
ClsColor Argb(255,0,0,240)

DrawImage skull,80,40,fz
TileText  font,112,0,"MY UFO"
DrawText fo,10,220,"Drunken Ufo Navigator!",Argb 255,200,100,0

vz +=.2
if vz >=1 then
   vz =0
   fz +=1
   if fz=16 then
      fz=0
   end if
end if

Sync
wend
CloseWindow

.

[Aaron]

New stupid circles.

Code: [Select]

include "gp.inc"
OpenWindow 640,480,1

sys x, y
Single a

SetSmoothMode 2
while KeyDown(27)=0
ClsColor &HFFFFFFFF

for y=0 to <480 step 40
   for x=0 to <640 step 40
      DrawCircle x,y,40,1,&HFF000000
      DrawCircle x+10,y+10,20,1,&HFF000000
      DrawCircle x+15,y+15,10,1,&HFF000000
   next
next

for y=0 to <480 step 40
   for x=0 to <640 step 40
      DrawPoint 20+x+(sin(rad(a)))*20,y+20+cos(rad(a))*20,4, &HFFFF0000
      DrawPoint 20+x+(cos(rad(a)))*20,y+20+sin(rad(a))*20,4, &HFF0000FF
   next
next

a +=2
if a>=360 then a =-a
Redraw
SetFps 200
wend
CloseWindow


[JRS]

Glad to see you posting here again Peter. You were missed.

[Aaron]

You were missed.

No tears please!

selling snow cones in Antarctica

best sentence of the day 

Gdiplus Pixel-speed test
Pixel-test need a new gp.dll

Code: [Select]

INCLUDE "gp.inc"
OPENWINDOW 320,240,1
'SETSMOOTHMODE 2

CLSCOLOR ARGB 255,255,255,255
FOR y=0,240
FOR x=0,320
    SETPIXEL x,y,ARGB 255,RND(32,255),RND(32,255),RND(32,255)
NEXT
NEXT
FILLCIRCLE 100,100,80, GETPIXEL 20,20
FILLRECT   100,20,80,60, GETPIXEL 10,10
WAITKEY
CLOSEWINDOW

.

[JRS]

Peter,

Here is your version running under Wine. It started with a transparent window and after 7-10 seconds the following appeared.


 

I took a shot at converting your example to SB GFX. I don't have a get pixel function yet and faked it with a RND.

Code: [Select]

'Peter's Pixel Test - SB GFX

IMPORT gfx.inc

s = gfx::Window(320, 240, "Peter's Pixel Test - SB GFX")
RANDOMIZE(gfx::Time())
gfx::ClearScreen s, 0xffffff
ts = gfx::Time()
FOR y = 0 TO 240
  FOR x = 0 TO 320
    gfx::pixelRGBA s, x, y, RND() AND 255, RND() AND 255, RND() AND 255, 255
  NEXT
NEXT
gfx::filledCircleColor s, 100, 100, 80, RND() AND 255
gfx::boxColor s, 100, 20, 80, 60, RND() AND 255
gfx::Update
te = gfx::Time()
gfx::stringColor s, 20, 215,"Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0xffffffff
WHILE gfx::KeyName(1) <> "+escape"
WEND
gfx::Close


[Aaron]

I don't have a get pixel function yet

Hi John,

I have done something like that:

Code: [Select]

Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Declare Function GetPixelEx Lib "gdi32.dll"  Alias "GetPixel"    (ByVal hdc As Long, ByVal x As Long, ByVal y As Long) As Long

string sys_cap = "SDL_app"
long hwnd, hdc
 
Sub FindWindowSDL()
    Hwnd = FindWindow 0, *sys_cap
    hdc  = GetDC hwnd
End Sub

Function GetPixel(long x, y) as long
    Return GetPixelEx hdc, x, y
End Function   


[JRS]

What I meant was I haven't wrapped the SDL get pixel function yet for the SB GFX ext. module.

[Aaron]

Okay, I have understood! 

[JRS]

It was interesting to see the SB GFX module calculate the fill color alpha channel for the circle even though it was in the gray color range. I was happy to see the rendering speed at a 1/10 of a second. Seems GDIPlus is pretty slow. (on Wine ?)

[JRS]

Peter,

I tried your pixel test in a VirtualBox XP session and it displayed almost instantly. The problem (slow) seems to be related to Wine. I know OpenGL/SDL runs great under Wine but GDI seems to be a kludge. 

[JRS]

I was able to add a gfx::GetPixel function and did it without locking the surface. I was unable to determine if locking the surface is only needed when creating the pixel.

Code: [Select]

'Peter's Pixel Test - SB GFX

IMPORT gfx.inc

s = gfx::Window(320, 240, "Peter's Pixel Test - SB GFX")
RANDOMIZE(gfx::Time())
gfx::ClearScreen s, 0xffffff
ts = gfx::Time()
FOR y = 0 TO 240
  FOR x = 0 TO 320
    gfx::pixelRGBA s, x, y, RND() AND 255, RND() AND 255, RND() AND 255, 255
  NEXT
NEXT
gfx::filledCircleColor s, 100, 100, 80, gfx::GetPixel(s, 20, 20)
gfx::boxColor s, 100, 20, 80, 60, gfx::GetPixel(s, 10, 10)
gfx::Update
te = gfx::Time()
gfx::stringColor s, 20, 215,"Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0xffffffff
WHILE gfx::KeyName(1) <> "+escape"
WEND
gfx::Close

I think I'm going to have to change my gfx::GetPixel function to return the RGBA color components in a SB passed array. All the pixels were created with the alpha channel at 255 so I should be generating a solid colored circle and box. I think there is a difference in our radius values. I think you are passing full radius value of the circle and I'm passing the radius from the center (origin) of the circle. I haven't looked and the box differences yet.

Code: [Select]

gfx::GetPixel screen, x, y, color
PRINT "R: ",color[0],"\n"
PRINT "G: ",color[1],"\n"
PRINT "B: ",color[2],"\n"
PRINT "A: ",color[3],"\n"


[Aaron]

I think there is a difference in our radius values.

Gdiplus does not draws the circle around its center. 
That's pitty, I love the centre.

[JRS]

I would have never guessed that getting the RGBA color value(s) would be such a complex and elusive task.

If anyone has an example of passing a X and Y position of a pixel in RGBA 32 format and returning it's color value, I would be grateful.

What I'm returning from this function may be correct and all I need to do is get the alpha channel enabled.

videoflags = SDL_HWSURFACE | SDL_SRCALPHA | SDL_RESIZABLE | SDL_DOUBLEBUF;

Code: [Select]

besFUNCTION(gfx_GetPixel)
  DIM AS SDL_Surface PTR this_surface;
  DIM AS int x, y;
  DIM AS Uint32 PTR pixels;
  besARGUMENTS("iii")
    AT this_surface, AT x, AT y
  besARGEND
  pixels = (Uint32 *)this_surface->pixels;
  besRETURN_LONG(pixels[(y * this_surface->w) + x]);
besEND


[Aaron]

Hi John,

'Getting the value of a pixel

Code: [Select]

Uint32 getpixel(SDL_Surface *surface, int x, int y)
{
    int bpp = surface->format->BytesPerPixel;
    /* Here p is the address to the pixel we want to retrieve */
    Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;

    switch(bpp) {
    case 1:
        return *p;
        break;

    case 2:
        return *(Uint16 *)p;
        break;

    case 3:
        if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
            return p[0] << 16 | p[1] << 8 | p[2];
        else
            return p[0] | p[1] << 8 | p[2] << 16;
        break;

    case 4:
        return *(Uint32 *)p;
        break;

    default:
        return 0;       /* shouldn't happen, but avoids warnings */
    }
}


'Setting the value of a pixel

Code: [Select]

void putpixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
{
    int bpp = surface->format->BytesPerPixel;
    /* Here p is the address to the pixel we want to set */
    Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;

    switch(bpp) {
    case 1:
        *p = pixel;
        break;

    case 2:
        *(Uint16 *)p = pixel;
        break;

    case 3:
        if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
            p[0] = (pixel >> 16) & 0xff;
            p[1] = (pixel >> 8) & 0xff;
            p[2] = pixel & 0xff;
        } else {
            p[0] = pixel & 0xff;
            p[1] = (pixel >> 8) & 0xff;
            p[2] = (pixel >> 16) & 0xff;
        }
        break;

    case 4:
        *(Uint32 *)p = pixel;
        break;
    }
}


[Mike Lobanovsky]

RGBA 32 is actually the easiest of all. RGB 24 would be much more tiresome.

I'm not very well accustomed to this funny syntax but from what I can see, your function will return exatly what you need. R will be the low-order byte and A will be the high-order byte as is typical for the SDL-compliant color formats; you can then mask out each color and alpha component by AND-ing the return value with &HFF for R, &HFF00 for G, &HFF0000 for B, and &HFF000000 for alpha. Then if you need each component as a separate 32-bit value, you can shift the masked-out value right by a corresponding number of bits, e.g. 24 for alpha, 16 for B, 8 for G, and none for R.

If your color array pixels[] is initialized with zeros then the alpha component of each pixel will be 0 which is completely transparent (invisible). Setting it to 255 will make it completely opaque. The intermittent values will yield varying degrees of transparency. If you decompose your color to separate components, then the algo to reassemble the color will be a direct reverse to what I described above:

Code: [Select]

// C pseudocode
RGBA32 = (A << 24) + (B << 16) + (G << 8) + R;
RGB 24 is much trickier due to colors being coded in byte triplets (RGBRGB...) rather than quads (RGBARGBA...). Each scan line will also have to be aligned on a DWORD boundary with an arbitrary number of bytes which are not painted but serve as alignment placeholders only. But if course if you're not planning to use RGB 24 then this info is irrelevant for your purposes.

P.S. Hehe, Peter has already given you an exhaustive answer while I was still typing mine. However, you need only case 4 from his code and you don't need the pitch parameter or endianness (as long as you code for Intel CPU's) because your colors will always be DWORD's. So you can safely stick to your own implementation of this function.