News : The level of daily SPAM has reached insane proportions, all registrations are now manual. I ask you to send me an e-mail (john (at) murga (dot) org), to confirm that you want me to create an account for you.


Post Reply  Post Thread 
Pages (5): « First < Previous 1 2 3 [4] 5 Next > Last »
slicing images
Author Message
Juergen
Member
***


Posts: 81
Group: Registered
Joined: May 2007
Status: Offline
Reputation: 0
Post: #31
RE: slicing images

iGame3D Wrote:
See above for seg faulting images.
All my tests have been Mac based.


If you mean the murgaLua.png image, this isn't in the murgaLua distribution. But I went extra (before I posted the last message) to the igames3d site and picked it out of the SVN, because I guessed it could be found there. If it is this (https://igame3dsource.svn.sourceforge.ne...rgaLua.png) image, I have tested it and it works perfectly.

Where the tests performed on a big endian machine or an intel based one?

Juergen

02-28-2008 04:30 AM
Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #32
RE: slicing images

I believe I found a solution to the alpha problem. I haven't looked into the last post by juergen, but the solution seems to be related. The Fl_RGB_Image() line was definitely incorrect. To fix it I obtained the color depth from the original unscaled and unsliced image data, and applied that to Fl_RGB_Image():

Code:
image2 = fltk:Fl_RGB_Image(test[1],ts*tc,ts*tc,image1:d(),test["ld"])

This will use 4 for RGBA images and 3 for RGB images. I haven't tested many images yet, but it works for the transparent PNGs that were crashing before.

There are also some changes to the puzzle behavior:
The preview/cheat is a button that overlays the puzzle instead of a separate window (right-click or middle-click to toggle it). It also behaves as an image-load button initially and when the puzzle has been solved.
I hopefully have fixed the most recent bug I found by returning all tiles to their original positions before scrambling.
The Escape key closes the program only if the preview is not displayed while the puzzle is scrambled. Otherwise it hides the preview.

Code:
#!/home/dsl/bin/murgaLua-0.6.4

-- slide puzzle for MurgaLua 0.6.4+
-- 2008 mikshaw

-- window and image size are determined by these variables
ts=80 -- tile size
tc=4  -- number of tiles in one line
fr=5 -- frame size
--img_dir="/mnt/hda4/shared/image/slide_puzzle"
--img_dir="/home/mik/image/slide_puzzle"

if not Fl_Image.getTiles then
err="This program requires murgaLua 0.6.4 or newer.\n\n"..
"http://www.murga-projects.com/murgaLua/index.html"
if fltk then fltk.fl_alert(err) else print(err) end
os.exit(1)
end

function load_callback(object)
-- mod of a function (and a piece) written by John Murga
fileName = fltk.fl_file_chooser("Choose an RGB image", "Image Files (*.{jpg,png,bmp})", img_dir, nil)
if fileName then
  start=1 -- used for controlling window callback and scramble behavior
  if image1 then image1:uncache() end -- don't know if this is needed
  image1 = Fl_Shared_Image.get(fileName)
  test = image1:copy(ts*tc,ts*tc):data()
  image2 = fltk:Fl_RGB_Image(test[1],ts*tc,ts*tc,image1:d(),test["ld"])
  myImages = image2:getTiles(ts,ts)
  for key,value in ipairs(myImages) do
    tile[key-1]:image(value)
    -- make sure all tile locations are reset correctly
    -- fixes a bug if image is changed while tiles are scrambled
    tile[key-1]:position(pos[key-1].col,pos[key-1].row)
  end
  preview:image(image2)  -- load the preview
  scramble()
  scrambutt:label("load an image")
end
end

function move_tile(t)
if Fl:event_button() >1 then preview:show() elseif image2 then
  local my_x,my_y,movex,movey=t:x(),t:y()
  -- tile must be adjacent to the missing piece
  if (my_x == tile[hidden]:x() and math.abs(my_y-tile[hidden]:y()) == ts)
  or (my_y == tile[hidden]:y() and math.abs(my_x-tile[hidden]:x()) == ts)
  then
    -- swap selected tile with the hidden one
    movex=tile[hidden]:x()
    movey=tile[hidden]:y()
    tile[hidden]:position(my_x,my_y)
    t:position(movex,movey)
    w:redraw()
  end
  -- check to see if puzzle is solved
  -- "ok" is incremented each time a tile is found in its proper place
  if start==0 then -- don't check puzzle during scramble
  local ok=0
  for i=0,tc*tc-1 do
    if tile[i]:x()==pos[i].col and tile[i]:y()==pos[i].row then
      ok=ok+1
    if ok==tc*tc then -- if ok == total number of tiles
      fltk.fl_beep()
      scrambutt:label(plize[math.random(1,table.getn(plize))])
      preview:show()
      start=1
      break
    end
    end
  end
  end
end
end

function scramble()
-- this picks a random tile to attempt to move and
-- repeats the process many times. Simply placing
-- tiles in random locations could potentially make
-- the puzzle impossible to solve
preview:hide()
if hidden then -- reset hidden tile
  tile[hidden]:box(fltk.FL_UP_BOX)
  tile[hidden]:labeltype(fltk.FL_NORMAL_LABEL)
end
-- turn a random tile into the missing piece
hidden=math.random(0,tc*tc-1)
tile[hidden]:labeltype(fltk.FL_NO_LABEL)
tile[hidden]:box(fltk.FL_DOWN_BOX)
local scram=0
while scram < 10000 do
  move_tile(tile[math.random(0,tc*tc-1)])
  scram=scram+1
end
start=0
w:redraw()
end

plize={"Great Job!", "Hooray for You!", "You don't suck!", "WIN!", "GODLIKE!", "CONGRATULATE YOU!"}

fltk.fl_register_images()
math.randomseed(os.time())
Fl:visible_focus(0) -- get rid of the ants
Fl:set_boxtype(fltk.FL_UP_BOX,fltk.FL_THIN_UP_BOX) -- looks a little more like tiles
Fl:set_boxtype(fltk.FL_DOWN_BOX,fltk.FL_THIN_DOWN_BOX)
w=fltk:Fl_Double_Window(ts*tc+fr*2,ts*(tc+0.5)+fr*3,"slide puzzle")

scrambutt=fltk:Fl_Button(fr,ts*tc+fr*2,ts*tc,ts/2,"load an image")
scrambutt:callback(load_callback)
scrambutt:tooltip([[
Click this button at any time to load a new image.

** Puzzle Controls **
Left click:  Move a tile.
Right or Middle click:  Toggle image display.
Esc:  Quit program, or close image display if it is visible.
]])

-- array of tiles, top left to right, then move down
tile={}; pos={}
-- allow space for the frame
row=fr; col=fr
-- subtract one is used because the number of tiles starts at one
-- but the table starts at zero (easier to position them from zero)
for i=0,tc*tc-1 do
  tile[i]=fltk:Fl_Button(col,row,ts,ts)
  tile[i]:align(80)
  tile[i]:callback(move_tile)
  pos[i]={col=col,row=row}
  -- next piece is ts pixels to the right
  col=col+ts
  -- start the next row
  if col == ts*tc+fr then col=fr;row=row+ts end
end

-- image preview (cheat)
preview=fltk:Fl_Button(fr,fr,ts*tc,ts*tc)
preview:callback(function()
if start==1 then load_callback()
else preview:hide() end
end)

--preview:hide()
w:callback(function()
  -- Esc just hides the preview if it's visible
  if preview:visible()==1 and start==0 then preview:hide()
  else os.exit() end
end)

start=1
w:show()
Fl:run()

This post was last modified: 02-28-2008 05:04 AM by mikshaw.

02-28-2008 04:55 AM
Find all posts by this user Quote this message in a reply
iGame3D
Moderator
***


Posts: 231
Group: Moderators
Joined: Apr 2007
Status: Offline
Reputation: 0
Post: #33
RE: slicing images

Works awesome, nothing broke or crashed in anyway yet.
What ever mikshaw did fixed the problem, so far.

To answer Juergen quickly, that image is close enough, I had the path wrong earlier, its murgaLua/gfx/murgaLua.png, same thing. I'm on an Intel iMac.

02-28-2008 07:23 AM
Visit this user's website Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #34
RE: slicing images

It's still crashing when the tile size is "too big" for the number of tiles used (I don't know what makes it too big).
So far I haven't had any success creating an offscreen image as John suggested...can't seem to translate his offscreen drawing method to images.

I haven't seen any other problems apart from that and the slight pixel shift mentioned earlier.

I think the next step will be to see if I can create a tileable image from a xpm/xbm/gif. It seems like it should be easy enough by borrowing more from John's imageDecodingTest.lua

02-28-2008 08:04 AM
Find all posts by this user Quote this message in a reply
JohnMurga
Administrator
*******


Posts: 381
Group: Administrators
Joined: Apr 2007
Status: Offline
Reputation: 2
Post: #35
RE: slicing images

I'll do the off-screen thing ... Work has been kinda crazy and my better half is very sick, so murgaLua has been taking a back seat at the moment, but as soon as I get a minute ;-)

Off-screen would work transparently for all image types too, as they'd be converted to RGB.

Cheers
JohnM

02-28-2008 08:43 AM
Visit this user's website Find all posts by this user Quote this message in a reply
iGame3D
Moderator
***


Posts: 231
Group: Moderators
Joined: Apr 2007
Status: Offline
Reputation: 0
Post: #36
RE: slicing images

JohnMurga Wrote:
Off-screen would work transparently for all image types too, as they'd be converted to RGB.


RGBA I hope?
Else  every off screen render will produce a black background in the resulting image.

I was having some fun with this script, my old random square test, with the off screen drawing.
But you'll see there is always a black bacground. Need that alpha!


Code:
-- random squares drawn offscreen with murgaLua
-- modification of murgaLua/examples/new/offscreen.lua

math.randomseed(os.time())
-- these values will depend on the project
   offscreenHeight, offscreenWidth  = 320, 320

-- these values are used against copy() and are randomized later in this script.
   redrawHeight , redrawWidth  = 200, 200

-- counter values keep track of the color cycling on the random filled rects
   colorcounter, basecounter, counterStep, counterLimit = 0 ,1, 7, 255

-- if the quads are larger than the grid there will be overlap
   gridSize , quadSize = 8, 8  

function random_colorsquares()
-- cycle colors
    colorcounter = colorcounter + counterStep
    if colorcounter > counterLimit then colorcounter = counterStep end
    fltk.fl_color(basecounter + colorcounter)  
-- randomized quadsize
    local Rs = math.random(quadSize-15,quadSize)
    
-- distance from center on each side of the quad  
    local quadHalf = math.floor(Rs/2)
    
    -- find a Random Point in the buffer
    local Rx, Ry = math.random(1,offscreenHeight) ,  math.random(1,offscreenWidth)
    
    -- match x,y to a valid point based on grid size
    local Px = (math.floor((Rx+(quadSize/2))/gridSize)*gridSize)-1
    local Py = (math.floor((Ry+(quadSize/2))/gridSize)*gridSize)-1
    
    -- find the top left corner of the new quad
    local Left,Top = Px-quadHalf, Py-quadHalf
    -- draw the filled rectangle
    fltk.fl_rectf(Left , Top ,Rs,Rs)
end  

function offScreenDraw(w)
    collectgarbage()
    offScreenBuffer = murgaLua.createOffscreenBuffer(offscreenWidth , offscreenHeight)
    offScreenBuffer:startOffScreenDrawing()    
  -- On Linux we have to clear the buffer (not on Mac or Win32)
    fltk.fl_color(0)
  -- Linux will segfault unless we set the font before using fl_draw
     fltk.fl_font(fltk.FL_HELVETICA_BOLD,14)
     fltk.fl_draw("OffScreen Drawing",10,20)
  -- the offscreen bufffer is now ready for input on all platforms

  -- some random colored squares
     for i = 1 , 2048 do random_colorsquares() end
      
  -- randomized redraw height for fun
     local rH = math.random(redrawHeight,redrawHeight*4)
     local rW =  math.random(redrawWidth,redrawWidth*4)
  
  -- the offscreen buffer can be copied and resized
     imageData = offScreenBuffer:getOffScreenImage():copy(rH , rW)
  
  -- insert the offscreen buffer as image data of an object
     getOffScreen_Button:image(imageData)
    getOffScreen_Button:redraw()
  
-- end the off screen drawing
    offScreenBuffer:endOffScreenDrawing()
  
end
  
  do local object = fltk:Fl_Double_Window(210, 210, "OffScreen drawing");
    window = object;
    do getOffScreen_Button = fltk:Fl_Button(5, 5, 200, 200, "Get off screen image");
    end -- Fl_Button* getOffScreen
  end
  
  getOffScreen_Button:callback(offScreenDraw);
  getOffScreen_Button:when(9)
window:show();
Fl:run();



Attached File(s)
.lua File  offScreenSquares.lua (Size: 2.77 KB / Downloads: 2)
02-28-2008 03:41 PM
Visit this user's website Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #37
RE: slicing images

I'm just guessing here, but I think maybe RGB/RGBA images require either fl_draw_image() or fl_read_image() rather than fl_draw()

02-28-2008 07:29 PM
Find all posts by this user Quote this message in a reply
iGame3D
Moderator
***


Posts: 231
Group: Moderators
Joined: Apr 2007
Status: Offline
Reputation: 0
Post: #38
RE: slicing images

mikshaw Wrote:
I'm just guessing here, but I think maybe RGB/RGBA images require either fl_draw_image() or fl_read_image() rather than fl_draw()


Fl draw just creates that text.
FL draw over a button or in a window will act as if it has an alpha, only drawing
the pixels for the text, when it comes back from the buffer however, it has
an unwanted background. The same with any other offscreen data.

Is there a way to force an alpha channel?

This post was last modified: 02-29-2008 05:32 AM by iGame3D.

02-29-2008 05:29 AM
Visit this user's website Find all posts by this user Quote this message in a reply
mikshaw
Senior Member
****


Posts: 522
Group: Registered
Joined: Apr 2007
Status: Offline
Reputation: 5
Post: #39
RE: slicing images

All I can say is that alpha is mentioned in fl_read_image(), but I don't yet know how to use it.

Quote:
uchar *fl_read_image(uchar *p, int X, int Y, int W, int H, int alpha = 0);

Read a RGB(A) image from the current window or off-screen buffer. The p argument points to a buffer that can hold the image and must be at least W*H*3 bytes when reading RGB images and W*H*4 bytes when reading RGBA images. If NULL, fl_read_image() will create an array of the proper size which can be freed using delete.

The alpha parameter controls whether an alpha channel is created and the value that is placed in the alpha channel. If 0, no alpha channel is generated

02-29-2008 05:42 AM
Find all posts by this user Quote this message in a reply
iGame3D
Moderator
***


Posts: 231
Group: Moderators
Joined: Apr 2007
Status: Offline
Reputation: 0
Post: #40
RE: slicing images

mikshaw Wrote:
The p argument points to a buffer that can hold the image and must be at least W*H*3 bytes when reading RGB images and W*H*4 bytes when reading RGBA images.


How do you create a buffer ?


Also can you believe this.
FLTK 1.1.8rc1 released yesterday, this is in the notes:

Quote:
fl_read_image() was broken on Intel-based Macs (STR #1490)
Fixed Quartz fl_read_image


Its been a while since a compiled murgaLua looks like I get my chance.

This post was last modified: 02-29-2008 04:24 PM by iGame3D.

02-29-2008 04:16 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply  Post Thread 

View a Printable Version
Send this Thread to a Friend
Subscribe to this Thread | Add Thread to Favorites

Forum Jump: