Spritley Old Guy
in [Visual Basic]
|
Prev: Simple Obfuscation
Next: Flag test
From: Mike Williams on 29 Mar 2010 12:55 "Bee" <Bee(a)discussions.microsoft.com> wrote in message news:D7ACEFAF-A0E6-4708-883F-128E17B30ABD(a)microsoft.com... > Mike, This is my plan <lots of stuff snipped> This is > then saved as a BMP Reading through what you are doing there are a number of points that spring to mind that you might need to consider, but before mentioning any of those it might be wise for me to first ask whether you intend your app to work properly on all current Windows machines, including those that are not running at full colour depth (virtually no machines run at the old 8 bit colour depth any more, but from my own experience there are still quite a few that run at 16 bit colour depth, sometimes without the user even realising it). If your program is running on such a machine and if it loads a normal full colour picture into a VB PictureBox and if you then do something to it and save the resultant PictureBox Image property to file (as you are undoubtedly doing) then the colours in the image will be degraded so that the saved image contains only the screen colours that are available on the 16 bit colour depth machine. With some images many people find it hard to tell the difference, but with others it is very noticeable. If you do not want to degrade the pictures in this fashion then you need to change your code quite a lot so that it uses DIBSections instead of VB PictureBoxes, which will require quite a lot of modification of your existing code depending on how much code you've already written, and it is something you should consider right now, before you move any further with your coding. If you are happy to degrade the images in such a way when your code is run on a 16 bit colour depth machine (which admittedly is probably just a small percentage of machines these days) then that's okay, but if not then now is the time to change all your code before you go any further. As I've already mentioned, some pictures look reasonably okay after such colour depth degradation and others look quite poor, it all depends on the picture and on the person viewing it. As an admittedly rather obvious example of such degradation try running the following code (first make sure your display is already running at full 32 bit colour depth if it is not already doing so, a process which I assume you know how to carry out). Then paste the following code into a new VB Form containing one PictureBox and two Command Buttons. The code assumes that you have a folder called "c:\temp" so create one if you do not already have one, or alternatively change the hard coded paths in the code. Run the program and click the Command1 button. This will create a 512 x 512 pixel image and it will save it as a file called blue1.bmp. Now right click your desktop and select Personalize (It's got a "Z" in it whether you have paid the exorbitant UK price for an English copy of Windoze or not!) and use Display Settings to change your display to 16 bit colour depth, clicking YES when asked to confirm that you want to keep those settings. Now go back to the VB program (or load it up again) and click Command2 button. This will load the original blue1.bmp file into a VB PictureBox and save the Image property out again as a new file called blue2.bmp. Now right click the desktop again and set your display back to full colour 32 bit. When you have finished, go to your c:\Temp folder (or whatever folder you might have changed the hard coded path to) and load the two files (blue1.bmp and blue2.bmp) one at a time into MS Paint. You should immediately see the difference between the two images. This is admittedly an image that was specifically created so as to be behave very badly to a reduction in colour depth, so when you have done all this you might try setting your machine to 16 bit colour depth again and loading some of your own existing full colour pictures into the picture property of an Autosize and Autoredraw VB Picture Box and saving the Image property as a new bmp file. Then set your desktop back to full 32 bit colour again and load the originals and the saved bmps into MS Paint one at a time to compare the difference. If you are happy with the colour degradation, or if you are not overly concerned about it on the grounds that you do not expect your program to be run on 16 bit colour depth machines, then that's okay, otherwise you've got a lot of coding to do in order to change your existing code (which I assume you are well ahead with) so that it overcomes those problems. Anyway, this is something you should think about right now because you really should come to a decision on it before you proceed much further with your existing code. Anyway, here's the test code that I mentioned above (into a Form with a pictureBox and two Command Buttons) . . . Mike Private Sub Command1_Click() Me.ScaleMode = vbPixels Picture1.BorderStyle = vbBSNone Picture1.ScaleMode = vbPixels Picture1.AutoRedraw = True Picture1.Move 0, 0, 512, 512 Picture1.Visible = False Dim y As Long, z As Long, p As Long p = 1 For y = 0 To Picture1.ScaleHeight Picture1.Line (0, y)-(Picture1.ScaleWidth, y), RGB(0, 0, z) z = z + p If z > 254 Or z < 1 Then p = -p Next y SavePicture Picture1.Image, "c:\temp\blue1.bmp" Caption = "Image saved as c:\temp\blue1.bmp" End Sub Private Sub Command2_Click() Picture2.AutoRedraw = True Picture2.AutoSize = True Picture2.Visible = False Picture2.Picture = LoadPicture("c:\temp\blue1.bmp") SavePicture Picture2.Image, ("c:\temp\blue2.bmp") Caption = "Copy of blue1.bmp saved as c:\temp\blue2.bmp" End Sub
From: Bee on 29 Mar 2010 18:34 I will make mention that the PC requirements are to have 32 bit color. This is after all a section of my app that does all sorts of things with images most that probably would not work well at 16 bits and would make a user unhappy. Thanks for the tutorial ... again! "Mike Williams" wrote: > "Bee" <Bee(a)discussions.microsoft.com> wrote in message > news:D7ACEFAF-A0E6-4708-883F-128E17B30ABD(a)microsoft.com... > > > Mike, This is my plan <lots of stuff snipped> This is > > then saved as a BMP > > Reading through what you are doing there are a number of points that spring > to mind that you might need to consider, but before mentioning any of those > it might be wise for me to first ask whether you intend your app to work > properly on all current Windows machines, including those that are not > running at full colour depth (virtually no machines run at the old 8 bit > colour depth any more, but from my own experience there are still quite a > few that run at 16 bit colour depth, sometimes without the user even > realising it). If your program is running on such a machine and if it loads > a normal full colour picture into a VB PictureBox and if you then do > something to it and save the resultant PictureBox Image property to file (as > you are undoubtedly doing) then the colours in the image will be degraded so > that the saved image contains only the screen colours that are available on > the 16 bit colour depth machine. With some images many people find it hard > to tell the difference, but with others it is very noticeable. If you do not > want to degrade the pictures in this fashion then you need to change your > code quite a lot so that it uses DIBSections instead of VB PictureBoxes, > which will require quite a lot of modification of your existing code > depending on how much code you've already written, and it is something you > should consider right now, before you move any further with your coding. If > you are happy to degrade the images in such a way when your code is run on a > 16 bit colour depth machine (which admittedly is probably just a small > percentage of machines these days) then that's okay, but if not then now is > the time to change all your code before you go any further. > > As I've already mentioned, some pictures look reasonably okay after such > colour depth degradation and others look quite poor, it all depends on the > picture and on the person viewing it. As an admittedly rather obvious > example of such degradation try running the following code (first make sure > your display is already running at full 32 bit colour depth if it is not > already doing so, a process which I assume you know how to carry out). Then > paste the following code into a new VB Form containing one PictureBox and > two Command Buttons. The code assumes that you have a folder called > "c:\temp" so create one if you do not already have one, or alternatively > change the hard coded paths in the code. Run the program and click the > Command1 button. This will create a 512 x 512 pixel image and it will save > it as a file called blue1.bmp. Now right click your desktop and select > Personalize (It's got a "Z" in it whether you have paid the exorbitant UK > price for an English copy of Windoze or not!) and use Display Settings to > change your display to 16 bit colour depth, clicking YES when asked to > confirm that you want to keep those settings. Now go back to the VB program > (or load it up again) and click Command2 button. This will load the original > blue1.bmp file into a VB PictureBox and save the Image property out again as > a new file called blue2.bmp. Now right click the desktop again and set your > display back to full colour 32 bit. > > When you have finished, go to your c:\Temp folder (or whatever folder you > might have changed the hard coded path to) and load the two files (blue1.bmp > and blue2.bmp) one at a time into MS Paint. You should immediately see the > difference between the two images. This is admittedly an image that was > specifically created so as to be behave very badly to a reduction in colour > depth, so when you have done all this you might try setting your machine to > 16 bit colour depth again and loading some of your own existing full colour > pictures into the picture property of an Autosize and Autoredraw VB Picture > Box and saving the Image property as a new bmp file. Then set your desktop > back to full 32 bit colour again and load the originals and the saved bmps > into MS Paint one at a time to compare the difference. > > If you are happy with the colour degradation, or if you are not overly > concerned about it on the grounds that you do not expect your program to be > run on 16 bit colour depth machines, then that's okay, otherwise you've got > a lot of coding to do in order to change your existing code (which I assume > you are well ahead with) so that it overcomes those problems. Anyway, this > is something you should think about right now because you really should come > to a decision on it before you proceed much further with your existing code. > > Anyway, here's the test code that I mentioned above (into a Form with a > pictureBox and two Command Buttons) . . . > > Mike > > Private Sub Command1_Click() > Me.ScaleMode = vbPixels > Picture1.BorderStyle = vbBSNone > Picture1.ScaleMode = vbPixels > Picture1.AutoRedraw = True > Picture1.Move 0, 0, 512, 512 > Picture1.Visible = False > Dim y As Long, z As Long, p As Long > p = 1 > For y = 0 To Picture1.ScaleHeight > Picture1.Line (0, y)-(Picture1.ScaleWidth, y), RGB(0, 0, z) > z = z + p > If z > 254 Or z < 1 Then p = -p > Next y > SavePicture Picture1.Image, "c:\temp\blue1.bmp" > Caption = "Image saved as c:\temp\blue1.bmp" > End Sub > > Private Sub Command2_Click() > Picture2.AutoRedraw = True > Picture2.AutoSize = True > Picture2.Visible = False > Picture2.Picture = LoadPicture("c:\temp\blue1.bmp") > SavePicture Picture2.Image, ("c:\temp\blue2.bmp") > Caption = "Copy of blue1.bmp saved as c:\temp\blue2.bmp" > End Sub > > > . >
From: Mike Williams on 30 Mar 2010 04:22 "Bee" <Bee(a)discussions.microsoft.com> wrote in message news:2B815315-E364-455A-A26F-6C8E85A0B20A(a)microsoft.com... > I will make mention that the PC requirements are to have > 32 bit color. This is after all a section of my app that does > all sorts of things with images most that probably would > not work well at 16 bits and would make a user unhappy. Okay. But regarding your statement "would not work well at 16 bits" don't forget what I said about DIBSections, which allow you to work with (load and draw into and save) full colour bitmaps in full colour depth even on a machine that is running its display at 16 bit colour depth (although of course only 16 bits of colour depth will be shown on the display). But it's okay if you don't want to do that. The reason I mentioned it is that using DIBSections would require you to change your existing code quite a lot, something which I thought you might not wish to do in the circumstances. Your decision to stick with your existing code is fine. You can still perform your various sprite editing jobs using your existing code in such a way that they will work okay on 16 bit colour depth machines, as long as you take the 16 bit fact into account in just one or two little places. If you do that then the only problem if your code does happen to get run on such a machine is that the output bitmap will in many cases not have the full colour depth that it would have had on a 32 bit display machine, but your sprite code will still work okay. Anyway, sticking with your existing code is fine. Reading your previous email I can see more or less what you are doing, although you haven't asked any specific questions in it so I'll assume that you haven't any at the moment. Post again of course if you do. Mike
From: Bee on 1 Apr 2010 19:02 Mike, Well, here is where I am and I am stuck. I used your sample code and Used my own background image Used my own sprite image. My sprite has a tranparency color of vbWhite and the upper left pixel is that color along with a large area. I added mouse move capability to your example. This all works so I am stumped why my app code using your code does not work. My code only works if the sprite transparency area is vbBlack. I am passing the tranparency color to the routine. I am set up so when I hover my mouse over the sprite thumbnail I read out colors. I have a small picturebox that I pipette this transparency color into and this reads out correctly. I am using a bitmap since I saw that a bitmap converted to a JPG was maintaining the vbBlack all through the transparency are. The conversion from BMP to JPG actually slightly modified the colors. I also found that I had to set the background of the working picturebox to vbBlack. In order to make it easy tfor me to see pictureboxes on the form (not running in the IDE) I color the .Background. This color kept showing up in my final sprite on picBackground with the sprite overlayed on it. This colored background responded to Alpha. I do not see anywhere in the code or in the porperties box where the backgound s set to anything other than default. I foolishly spent some time trying to use .CLS and .Picture=LoadPicture() to clear the background thinking something was wrong there. Of course I was barking up the wrong tree. Anyway, my code does alpha, size, flip and rotate but only with a vbBlack transparency area. Too much code to post and then there are the pictureboxes and controls with their properties. So, is there some rule I am missing about setting properties in thes pictureboxes or something else obvious to you and invisible to me? So close and yet so far away. "Mike Williams" wrote: > "Bee" <Bee(a)discussions.microsoft.com> wrote in message > news:2B815315-E364-455A-A26F-6C8E85A0B20A(a)microsoft.com... > > > I will make mention that the PC requirements are to have > > 32 bit color. This is after all a section of my app that does > > all sorts of things with images most that probably would > > not work well at 16 bits and would make a user unhappy. > > Okay. But regarding your statement "would not work well at 16 bits" don't > forget what I said about DIBSections, which allow you to work with (load and > draw into and save) full colour bitmaps in full colour depth even on a > machine that is running its display at 16 bit colour depth (although of > course only 16 bits of colour depth will be shown on the display). But it's > okay if you don't want to do that. > > The reason I mentioned it is that using DIBSections would require you to > change your existing code quite a lot, something which I thought you might > not wish to do in the circumstances. Your decision to stick with your > existing code is fine. You can still perform your various sprite editing > jobs using your existing code in such a way that they will work okay on 16 > bit colour depth machines, as long as you take the 16 bit fact into account > in just one or two little places. If you do that then the only problem if > your code does happen to get run on such a machine is that the output bitmap > will in many cases not have the full colour depth that it would have had on > a 32 bit display machine, but your sprite code will still work okay. > > Anyway, sticking with your existing code is fine. Reading your previous > email I can see more or less what you are doing, although you haven't asked > any specific questions in it so I'll assume that you haven't any at the > moment. Post again of course if you do. > > Mike > > > > . >
From: Bee on 1 Apr 2010 20:02
Finally! Victory! The stupid here was using BitBlt to put the sprite centered into an oversize picturebox so the sprite could be rotated. I was using SRCPAINT instead of SRCCOPY. I do not know why I figured that out, just stumbled on it. So I am still not qualified to be anything other than a rank amateur at this. Where is that graphics book you need to write? Please! Since it would be all API stuff it would apply to any language under Windows. |