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
iGame3D
Moderator
***


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

I noticed that green line of pixels at the bottom as well.

I'm having great luck with this function now:
It will resize large images and prevent most of the problems so far.

Code:
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})", nil, nil)
if fileName then
  if image1 then image1:uncache() end -- don't know if this is needed
  image1 = Fl_Shared_Image.get(fileName)
-- set a window (or an object) image property to the image data
  w:image(image1,ts*tc,ts*tc)
-- set the image data to the a resized copy of the image data  
  image1 = w:image():copy(ts*tc,ts*tc)  
-- get table of tiles getTiles  
  myImages = image1:getTiles(ts,ts)
-- parse tile table into image data of objects
  for key,value in ipairs(myImages) do
  if  key < 16 then
    tile[key-1]:image(value)
tile[key-1]:redraw()
end
end
scramble()
  scrambutt:label("load an image")
end
end


However I broke the game play functionality so I have to go back a few steps somewhere.

I  think I've still segfaulted, and I've got some weird crash logs.

Code:
Thread 0 Crashed:
0   <<00000000>>     0xffff08a0 __memcpy + 256 (cpu_capabilities.h:228)
1   murgaLua                0x000595a6 0x1000 + 361894
..etc..etc
7   murgaLua                0x0015cd53 Fl_Widget::do_callback() + 29
8   murgaLua                0x0009d252 0x1000 + 639570
..etc..etc
12  com.apple.HIToolbox     0x92def4d7 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
13  com.apple.HIToolbox     0x92deeb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
14  com.apple.HIToolbox     0x92df5f7c SendEventToEventTarget + 56

etc...etc..

Once I've got the game play back I'll see if those crashes persist.

02-27-2008 07:52 AM
Visit this user's website 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: #22
RE: slicing images

We have a saying where I come from about people who make assumptions :-)

Juergen, in a fraction of the time that took to compose your response you could have checked the source ...

This would have demonstrated that no assumptions are being made about colour depth, as I actually added an additional PNG specifically test the different RGB type.

I haven't had time to look at this properly yet, but I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles.

Either way it segfaults, which it shouldn't, and sucks big time, so it's my priority one bug.

Cheers
JohnM

02-27-2008 08:04 AM
Visit this user's website 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: #23
RE: slicing images

BTW ...

What I would suggest for this is :

+ Create an off-screen buffer of the required size (which is a multiple of the tile dimensions).
+ Draw the re-sized picture to this off-screen buffer.
+ Get the image for the off-screen buffer (which should be perfectly normal).
+ Call getTiles on this.

I'll try it myself if I get through all my mails.

Cheers
JohnM

02-27-2008 08:28 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: #24
RE: slicing images

That sounds reasonable. I'll test it out after dinner.
Thank you again.

02-27-2008 08:31 AM
Find all posts by this user Quote this message in a reply
Juergen
Member
***


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

JohnMurga Wrote:
We have a saying where I come from about people who make assumptions :-)

Juergen, in a fraction of the time that took to compose your response you could have checked the source ...

Now you are under the assumption that I had the code readily available at the time. ;-)

JohnMurga Wrote:
This would have demonstrated that no assumptions are being made about colour depth, as I actually added an additional PNG specifically test the different RGB type.

In the meantime I have looked into the code and saw that it is depth independent.

JohnMurga Wrote:
I haven't had time to look at this properly yet, but I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles.

After a first quick scan it looks like it doesn't matter. I first thought this also when I saw the code, but it looks like (if I haven't overlooked anything) that it truncates w()%xSize pixels at the right and h()%ySize lines at the bottom part of the image.

JohnMurga Wrote:
Either way it segfaults, which it shouldn't, and sucks big time, so it's my priority one bug.

I haven't had the time to look deeper into it, but have you checked if ld() is always !=0?

Juergen

02-27-2008 09:41 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: #26
RE: slicing images

I didn't test yet. I have to learn about the offscreen drawing functions first, and since I got kinda buzzed at dinner I lost my ability to grasp new concepts =op

There is one thing I'm curious about, though. You said "I suspect that it could have something to do with the resizing process (which I am unfamiliar with), and what happens when the dimensions of the picture are not divisible by the dimensions of tiles". In this particular instance the dimensions of the picture are always divisible by the dimensions of the tiles because the dimensions of the picture are a multiple of the dimensions of the tiles.

A happy coincidence, though (or what seems to be a coincidence), is that your getTiles() seems to create the tiles from right to left, top to bottom, which is precisely the method I used to create the tiles in the interface. So the index of the image tiles table is the same as the index of the interface tiles, with the exception that I started at 0 and you start at 1

I've been wondering what other uses getTiles could have. Maybe an image map that is controlled by buttons rather than coordinates (buttons would be easier to program, i think). Maybe an image-based gui that is resizable, although I'm not sure if the images can be dynamically resized as a resizeable window is dragged.

This post was last modified: 02-27-2008 12:52 PM by mikshaw.

02-27-2008 12:40 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: #27
RE: slicing images

Ok to test bugs see:

Working file:
murgaLua/examples/images/Globe.png

and

segfault file:
murgaLua/gfx/murgaLua.png

--------------------------------------------
I mangled that segfault file a dozen different ways.
The final difference between crash and no crash is that
segfault files load into photoshop with the initial layer set to "background".
If layers are flattened in photoshop, a working file will become a segfault file.

Files that work load into photoshop with the initial layer on "layer 0".
If that image is saved with a solid layer at the bottom, it segfaults.

If an alpha channel is then applied to that bottom layer and saved it works.

Ok here's something wierd.
It will segfault if the alpha channel is 100% solid.
I put a one pixel dot into the alpha channel.
It doesn't segfault.

This post was last modified: 02-28-2008 07:00 AM by iGame3D.

02-27-2008 03:04 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: #28
RE: slicing images

Your last mod of the load function, Bill, initially sets the image on a separate window, resizing it at that time. The size of the copy therefore doesn't need to be specified.

Do you think setting the image to a hidden window first and then tiling that data does any help over tiling the original data? Logically I don't see any difference between the two methods, but if there is an improvement I already have a "preview" window implemented that can be used for this purpose. The script I have locally is becoming quite different than the last one posted, so after I do some experiments with John's suggestion I'm going to post the newer version.

02-27-2008 11:51 PM
Find all posts by this user Quote this message in a reply
Juergen
Member
***


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

I have now tested it a little bit and I can't get any segmentation faults (is there a png somewhere available that faults?)
I have tested mikes sliding puzzle and I haven't found any problems with RGB or RGBA png's.

Although in the previously posted source the following lines:

Code:
test = image1:data()
-- force d(3) to prevent problems with alpha channel
image2 = fltk:Fl_RGB_Image(test[1], test["w"], test["h"], 3, test["ld"])

will definitely not work, because it only "lies" to the Fl_RGB_Image constructor about the data, but doesn't actually change it.
image2=image1 works on my system without a problem. (If there is a png that pruduces a crash then could someone post it?)
Also if the picture should be scaled (and not cropped, which doesn't make sense since the program doesn't know which side it should crop) image1=image1:copy(math.floor(image1:w()),math.floor(image1:h())) would make sense.

Juergen

P.S.: On which OS have those tests been performed?

02-28-2008 03:50 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: #30
RE: slicing images

The path to a segfaulting file is: murgaLua/gfx/murgaLua.png
All my tests have been Mac based.

mikshaw Wrote:
Your last mod of the load function, Bill, initially sets the image on a separate window, resizing it at that time. The size of the copy therefore doesn't need to be specified.
Do you think setting the image to a hidden window first and then tiling that data does any help over tiling the original data?


I set  the image of the main window, the preview window
never did anything so I didn't even notice the code for it until you mentioned it.

When importing images for the iGame3D interface icons,
I had to place the image inside of a button and copy the image at the size I needed it
to be, else I ended up with icons bigger than my buttons.
I don't think just setting the size of the image actually resizes it.

Code:
  image1 = Fl_Shared_Image.get(fileName)
  image1:h(ts*tc); image1:w(ts*tc)


Doesn't do any resize to the image.
Adding:

Code:
  w:image(image1,ts*tc,ts*tc)
  image1 = w:image():copy(ts*tc,ts*tc)


gets the image resized. I could have added an object for that purpose, a button, whatever, but its easier to use the window as a storage device, since it can hold the image data and allow the copy just as easily.

If I don't resize then anything larger than 320 pixels crashes.

This post was last modified: 02-28-2008 07:01 AM by iGame3D.

02-28-2008 04:22 AM
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: