Re: Background image problems
On Thu, 4 Jun 2009, Sumner, Walt wsum...@dom.wustl.edu wrote: Can anyone shed some light on using paint tools and imagedata on images in a bg group? (snip) Because the new picture might look a lot like the old picture, the script selects some gray color and uses the pencil to draw horizontal lines over the first picture. This is fairly quick and gives a clear impression that the picture is being rebuilt. This works fine if the image is not part of a group. It works if the image is not the only image in a group. It seems not to work if the image is the only image in a group (snip) Thanks, Walt Sumner Painting on images inside groups does not work as it should. Seems to be a bug, which I also encountered some time ago. A workaround would be to temporarily move the images out of the group (as I did in one of the versions of my Imagedata Toolkit) like in this script on mouseUp set the imagedata of img x to the imagedata of img x # cannot remember what the above line achieves set the relayergroupedcontrols to true put the layer of img x into tlayer set the layer of img x to top send mouseup to btn distortions: choose shape # the line above now paints on img x set the layer of img x to tlayer set the relayergroupedcontrols to false end mouseUp Maybe this helps? Regards, Wilhelm Sanke http://www.sanke.org/MetaMedia -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Snapshot stack (was: Import from rect)
On Sat Jan 24, 2009, Thomas McGrath III mcgrath3 at mac.com wrote: This is a good observation and study of the inner workings of snapshots. There are many variations in effects that can be accomplished here. I especially like the explanation of what I was troubled with at first that the first rect in parens is the size and the second is the location. I think the global location can use a bit more explanation. I will be playing with this for a bit. Tom, Thank you for the feedback. I have added four commented lines to the script of btn Globalloc... that shed some light on the procedure to convert rect values to global coordinates. It is interesting that using *globalloc()* to determine snapshots is so much faster - about five times as I have reported - than using import snapshot from the rect(the rect of grc 1) of this card. For applications or tools where speed is an issue and where snapshots are used repeatedly the globalloc variant should be helpful. I have also added the text of my last post as a basic information to the stack, and already have uploaded the newer version under the same URL as before. Regards, -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Snapshot stack (was: Import from rect)
For the few who might be interested in such things I have put together a stack demonstrating various ways of producing and using snapshots, thereby following the questions and findings in the recent thread Import from rect (especially of Thomas McGrath, Ken Ray, and Scott Rossi): http://www.sanke.org/Software/SnapshotTestStack.zip The Rev docs about snapshots have become increasingly detailed over time, but they do not - understandably - cover every aspect, and - they still contain an old error, namely concerning the paintcompression format of imported snapshots. The teststack allows to set the properties of the selection graphic - with the help of which snapshots are taken from an underlying image - in real time, i.e. you can set blendlevel, fillcolor, and the ink directly and watch the changes in the appearance of the area of the graphic and the image beneath it. 20 different ways related to snapshot taking are demonstrated (with almost no commentaries), concerning simple snapshots, alphadata, maskdata, and extracting blendlevel and inks. Additional remarks to some of the aspects: - I found it confusing at first when I encountered a syntax like import/export snapshot of rect(the rect of grc 1) of grc 1. Experimenting with this I understood that this twofold reference is not just tautological, but determines different components of the snapshot. The first term - in the brackets - determines the *dimensions* of the rect, the second states - as it were - the location of the snapshot. - In all cases but one - what you see in the test stack is not the snapshot taken, but the result of using the snapshot for masking the image underlying the selection graphic. - The exception to this is the Darkshot - listed by Ken Ray in his systematic overview - where I additionally display the actual snapshot (in a diminished size) to show that the color of the represented transparent areas is dependant (but not identical with) on the ink and fillcolor of the selection graphic. - Using *globalloc* to determine the rect and loc of the snapshot is about 5 times faster than using card, window, image etc. as the reference to the location, as in import snapshot from the rect(any rect) of this card - The syntax import/export snapshot from rect(any rect of this stack or of stack stackname is not possible. You have to get the windowID of the stack first and then write snapshot from rect(trect) of window twindowID. But it is possible to use card x of stack stackname and even - see the docs - access hidden or closed stacks this way. - Snapshots taken from the selection graphic contain both alphadata and maskdata, that can be used to mask the underlying image. Compared to alphadata using maskdata produces somewhat rough edges. - Other than when applying alphadata to the image to-be-masked, with maskdata you need to crop the image to-be-masked to the rect of the *group* that contains the selection graphic. The graphic and the group containing the graphic have different dimensions. When you group a graphic, width and height of the group are greater than those of the graphic. export snapshot from rect(the rect of grc 1) of group 1 combined with cropping the image-to be-masked to the rect of the graphic results in a distorted rectangle - instead of an oval. Cropping the image-to be-masked to the group produces the correct result. Regards, -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Sad News...
Returning home I have to learn that Eric Chatonet is dead. I want to join all the mourners who have expressed their sympathy with Eric's familiy. I have always been impressed by his strong commitment to the sake of Revolution and especially appreciated how he provided insights and practical help for users new to Revolution. I think this line of work must be continued. -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Import from rect
On Fri, 16 Jan 2009, Scott Rossi sc...@tactilemedia.com wrote: Recently, Thomas McGrath III wrote: Actually a snapshot of an object does not take an exact snapshot following the attributes of the object (transparency, etc.) but a snapshot of the rect of the object will follow the attributes (transparency, etc.) This is an excellent and useful observation -- I always thought that one had to group objects to get their alpha included in a screenshot, but using the object's rect as you say produces the same result. Nice find. Regards, Scott Rossi One of the steps of development in science as in programming is that we start on a preliminary level with assumptions or hypotheses which may be then falsified - or sometimes verified - when we reach the next intermediate level of our theory. The principle of falsification is the core element of Sir Karl Popper's theory of science. This usually happens to all of us from time to time, although the programming language we use is called Revolution. In my long post of Nov 29, 2008 (More about Masks (+ sample stack)) introducing stack More about Masks one paragraph reads: Scott's assumptions - expressed in the comments of his script - that the image to-be-masked must be in PNG-format and the selection graphic (from which the snapshot for the mask is being taken) must be grouped, could not be verified here. The stack compares and discusses in detail the attempts of Jim Hurley, Bernd Niggemann, and of myself to create masked images mainly with the use of snapshots - and included one script originally written by Scott to which the paragraph refers. - === and Thomas McGrath III mcgra...@mac.com wrote on Sat, 17 Jan 2009: Scott, Actually at first I thought this was a bug, but it makes a bit of sense. The rect and I guess grouping the objects will force a visible or visual snapshot of where the object physically resides including objects beneath that show through the alpha mask but using the actual object must allow the engine to reference the object itself programatically so it is not 'seeing' the alpha or better yet it is not seeing through the alpha to the objects underneath. As Richard said export snapshot which allows you to specify the object rather than merely its rect: This will cause the object specified to be rendered into an offscreen buffer directly, then that buffer is compressed into the specified format for writing to disk. It must be the ability to render offscreen in the buffer that is the difference here. This must be the case with the import snapshot as well. Tom I think Tom's interpretation of what is going on is an excellent analysis. Getting the alphadata is indeed possible both with import and export snapshot and besides the alphadata you also retrieve the maskdata as we have discussed and shown in detail in our above-mentioned stack of Nov 2008 http://www.sanke.org/Software/MoreAboutMasks.zip along with the possible dependency on the paintcompression format, which however effects only maskdata. A new version of the stack - released a few days ago on Jan 7 - http://www.sanke.org/Software/MoreAboutMasksRev3.zip additionally demonstrates two attempts to integrate the new gradient tools of Rev (therefore this stack needs at least engine version 3) as a component for creating masked images - based on a proposal from Bernd Niggemann.. I mention this stack here, too, because I see from the text of Tom's posts in this thread that he is apparently experimenting with using snapshots together with gradient tools. It could be interesting to have a look at these approaches, although they may be of a somewhat ideosyncratic nature. Regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
[ANN] More about Masks Rev3
To run this sample stack you need engine version 3.0 or higher: http://www.sanke.org/Software/MoreAboutMasksRev3.zip What's new in this version? - Create mask with export snapshot to variable / card Creating masks - Create masks with integrated gradient tools / card Using gradient tools - Optionally transparent frames for all masked images / card Mask images as selection tools 1. Button export snapshot to variable was proposed by Bernd Niggemann. Instead of exporting the snapshot to an external file, it is placed first in a variable and then the text of a hidden image is set to that variable. This procedure is about 10% faster than exporting the snapshot to an external file and then re-importing the image. 2. Creating masks with Gradient Tools Bernd Niggemann came up with the idea to integrate the gradient tools of Rev 3.0 into this stack. We present two slightly different approaches on card Using gradient tools - the essential elements of Bernd's original solution in the box on the right - the elements of my somewhat alternative approach in the box on the left and the buttons common to both solutions in the middle, namely showing/hiding the edit-mode controls, disabling gradient work, setting the gradient type (linear, radial,conical, diamond, spiral, XY, SqrtXY), setting the repeat pattern, wrap, mirror. Bernd creates a mask by transforming the gray values of a snapshot into transparency. My alternative option is based directly on the transparency values of a snapshot. The masked images created with the two approaches can be indeed identical, but in many cases differ considerably. Just experiment to find out the identities and differences. Enable--Gradient 1 and Enable--Gradient 2 generate different values and configurations, as do the slider scrollbars on the left and right. Be sure to move the sliders at least for a tiny distance - both of them! - when you change from one approach to the other. With Choose graphic shape you set the form of the selection graphic, either oval or rectangular. Oval is the default. 3. On card Mask Images as Selection Tools I have added the option to add frames of varying transparency to masked images of all shapes. After you have created a masked image, a button add frame appears which lets you choose the level of transparency for the frame and then adds a frame exactly fitting the chosen shape. There are now 11 image shapes that can be set to various sizes and forms and to which such frames can be optionally added. Best regards, Wilhelm Sanke -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Revolution moved to Reference Assemblies?
Today I wanted to access my Rev 3.0 folder (which had worked last night), clicked at the folder to open it and got an error message kind of check the path etc. I tried the same with the 2.9 folder and got the same result. Then suddenly all my Rev folders - from 2.7.4 to 3.5 - had disappeared. This is on Windows XP. I shut down my computer and started it again. All the revolution folders were still gone! After that I made a file search for revolution.exe and found out that all 13 revolution folders had been moved to folder Reference Assemblies - and fortunately they are all intact. Any ideas what could have caused this moving of folders? Bill Gates playing some Xmas tricks on me? I was online when the folders were moved. Regards, -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: snapshot problem 1
Thomas McGrath III mcgrath3 at mac.com wrote: When you import a snapshot - How do you get the name of the newly created image that the snapshot is placed in? Y From the Docs: Comments: The import snapshot command creates a new image in the center of the current card and places the snapshot in the image. Tom McGrath III Lazy River Software The new image is nameless. You can refer to it with last image and set a name for this last image. -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
[ANN]: More about masks (+ sample stack)
Accompanying is a sample stack with a side-by-side comparison of a number of approaches and containing most of the discussions with examples: http://www.sanke.org/Software/MoreAboutMasks.zip To run the stack you need Rev 2.9 or higher. As a starter for this overview about how to produce masked images in Revolution here is a two-liner: on mouseup crop image to-be-masked to the rect of image SelectionOval set the alphadata of image to-be-masked to the alphadata of image SelectionOval end mouseup This is the essential core-procedure to create masked images, one of several options. Usually such a two-liner would be sandwiched between lock screen and hide SelectionOval, and additionally there would be procedures in separate buttons that determine what to do with the newly masked image, copy it elsewhere, save it as an external file, patch it onto another image etc. Image to-be-masked can be of any format, JPEG, GIF, PNG, image SelectionOval must be a PNG of course. If a graphic is used as a selection tool to determine the area of the resulting masked image by capturing the transparency of the graphic with a snapshot, it is *not* necessary to group graphic SelectionOval. The selection graphics and images in my sample stack *are* all grouped, but only because they are combined with a handle-graphic for resizing and reshaping, otherwise a grouping of the selection tools as a prerequisite to capture transparency is not required. And, contrary to what the Rev docs state for import snapshot (The format of the resulting image depends on the current setting of the paintCompression property.), since Rev version 2.7 the resulting images are invariably PNGs, irrespective of what the current general setting of the paintcompression is, RLE, PNG, or JPEG. Although with pre-2.7 versions the snapshot images would not be PNGs, their formats are also not directly determined by the current paintcompression. Paintcompression, however, plays a role for the speed of processing imagedata and alphadata, RLE is fastest here, PNG the slowest setting.- Graphics do contain transparency in the area outside of the shape of the graphic, but this transparency is not represented by mask- and alphadata properties of the graphic. We have to make detours to get at these data or to reconstruct them. I hope that with future versions of Revolution graphics will additionally have alphadata and maskdata properties. If that would be the case, we could mask images with two-liners like in the starter script above. What follows here is mainly an overview of such detours, of different attempts to build masks along with the discussion of details and possible problems - derived partly from individual experience, but much of it is based on the results of a number of offlist-contacts and discussions during the last weeks between James Hurley, Bernd Niggemann, and myself about problems, solutions, and workarounds concerning the creation and application of masks to images. I have also considered the onlist exchange between Scott Rossi and myself - at the time after I had announced my first sample stack Three Masks. On Ken Ray's website (http://www.sonsothunder.com/devres/revolution/tips/imag009.htm, we found the trick to produce transparency with the help of the bucket tool. Ken presents a two-liner from Jeanne DeVoto, which I managed to integrate into one of the script examples. == We could distinguish between two major categories: Creating masks 'on the fly' and Using prefabricated masks. 1. Creating masks on the fly a) == within-functions== Jim Hurley has experimented with the native Rev within function to produce masks and encountered the edge problem, flat edges appearing at the right and bottom of the masked images. Variations of the original script did not help to overcome this problem. Curiously enough, when you reverse the direction of the scan in Jim's script, you get the edges on the left and on top. I found three workarounds for this problem (but not a real solution of the basic problem), namely super-imposing the edged alphamasks: 1. Double scan from right and left, and then superimposing the two resulting masks. 2. Flipping - by script - the left half of the alphadata onto the right half, and the top half onto the bottom half. 3. Capitalizing on the feature that since 2.9 flipped images preserve their alphamasks (and flip them also), I run a normal scan, after that flip the image horizontally and vertically, get the resulting second mask (then return the image to its previous state) and superimpose the two masks. All three workarounds produce masked images without edges.- Eventually Jim - as an expert in matters of mathematics and geometry - has now developed a within ellpse-function on the basis of the mathematical properties of an ellipse, which due to the more complex nature of the script takes a bit longer to implement, but produces perfectly rounded masked images. Script examples for the
Re: Seamless Tiles Generator 2 updated
Many thanks for your comments. -= JB =- sundown at pacifier.com wrote: That is a nice stack. Thank you. I do get a few error dialogs. I even get one when it first starts but I select ignore and the stack works. and Stephen Barncard stephenREVOLUTION2 at barncard.com wrote (using Twofold posting of mail as the subject): The stack is awesome! I've spent several hours with it... One note: no way to cancel out of some operations and the IDE was complaining about an Answer Dialog already existing... but it's wonderful. Lots of lessons here. I would very much like to know what kind of error dialog you get and which operations could not be cancelled. One of the already known issues is the unfriendliness of the Rev IDE towards customized answer and ask dialogs. On the one hand among the (once) praised features of Metacard and Revolution was the possibility to adapt even elements of the IDE to your specific needs; since long I prefer to embed my own dialogs into my stacks, because I need the option to place them anywhere on the stack or the screen and I do not like the far oversized widths of the dialogs Rev offers. On the other hand the Rev IDE is over-protective in some respects (and for reasons that escape me) and does not like such customized dialogs. Take a look at the script of btn revfrontscript of stack revlibrary which is inserted as a frontscript for the Rev IDE and comment out lines 992 to 1006 in handler revCheckStackCollision. This will stop the complaint about the answer dialog and otherwise will have no effects on how the Rev IDE will function. Alternatively it would be a good choice to get the Metacard IDE and just place the latest Rev engine into it. Most - if not all - of your problems will then disappear. Another annoyance is the fact that with version 3 of the Rev IDE the blue stack Rev Centre keeps popping up all the time after a customized answer or ask dialog has finished the execution of its script. I have not yet found out from where this annoyance originates. Same recommendation as above: Get the Metacard IDE.- And: I hope the mail service of our server will now work properly. I saw that even my post about Twofold posting of mail was sent twice. Best regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Seamless Tiles Generator 2 updated
-= JB =- sundown at pacifier.com wrote: I have only been using Revolution for less than a year now and before that I used hyperCard. I know about MetaCard but I thought it was replaced by Rev. So where do I get the MetaCard IDE and after I get it how do I install it properly? I have noticed others on the list mention they use MetaCard too. Will someone please explain why people use MetaCard even though they keep using the latest version of Rev. thanks, -=JB=- Hi -=JB=-, as you asked on this list, I'll give a short reply here: The proper place to get information about and discuss the MC IDE (an open source alternative development environment for Revolution's programming language) are two lists, one of which is indeed maintained by RunRev. You find the free archives of the Metacard list under http://mail.runrev.com/pipermail/metacard/ and can subscribe to this list (costfree) at http://lists.runrev.com/mailman/listinfo/metacard. Then there is a Yahoo list http://tech.groups.yahoo.com/group/MC_IDE/ where you can get the different versions of and help for the MC IDE in the files section. The chairman of the MC-user group as a subgroup of Revolution users is Klaus Major, whom you will have surely noticed on this use-revolution list. Formerly, Richard Gaskin filled this important position. It should be duly noted that the MC-IDE users thankfully acknowledge that the Revolution team maintain the compatibility of new Rev engines with the MC IDE. I think this was part of the parcel negotiated at the time when Revolution purchased the Metacard engine. I use both IDEs when developing, with a preference for the MC IDE. I personally get a much better workflow with MC. If you are interested, you could discuss details offlist or on the Metacard list. Best regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Seamless Tiles Generator 2 updated
Stephen Barncard stephenREVOLUTION2 at barncard.com wrote: I would very much like to know what kind of error dialog you get and which operations could not be cancelled. as I said, the IDE doesn't like the imbedded substack with the name Answer Dialog. The custom dialog just needs another name. The support code is trivial. I know. I use a number of totally customized dialogs - created from scratch - in my stacks. See the last public version of the Imagedata Toolkit http://www.sanke.org/Software/ImagedataToolkitPreview3.zip and especially my sample stack modal dialogs from 2003 http://www.sanke.org/Software/CustomModalDialogs.zip What I - and we as the MC-user group - have done is to further develop and improve the answer and ask dialogs, namely - to allow placing the dialogs anywhere - to avoid the truly oversized width of the Rev dialogs. This is now established standard for the dialogs in the MC IDE. Two things concerning the Rev IDE are trivial here: You would need only two additional script lines in the scripts of the Rev answer and ask dialogs to achieve the option to place the dialogs. Likewise it would be easy to diminish the disproportional width of the dialogs. The Revolution team has apparently never paid any attention to such possible and trivial changes. And it would be likewise trivial to exempt answer and ask dialogs from the stack-collision routine in the Rev frontscripts.- I agree with Jacqueline about much of what she stated in her post of Sun Oct 12 14:09:12 CDT 2008 about the relative merits of both IDEs, but I have the feeling that her argumentation is somewhat influenced by her double loyalty to Revolution and Metacard (which I appreciate, and which I also feel to some degree) - and in that downplaying disadvantages of the Rev IDE that have time and again been discussed on both lists. The Rev IDE has much improved over time, but IMHO is still the weakest part of Revolution. There have been stacks with specific features not long ago that simply could not be handled by the Rev IDE. The Application Browser would freeze. Stacks would slow down considerably and become virtually unusable etc. In the meantime many things have indeed improved, but a number of aspects still urgently needs further development. Jacqueline uses the example of the developer based on her own experience: But if the developer is not careful, it is possible to damage the native MC IDE dialogs during development. and I am working with a stack right now that has duplicates like this, and I am seeing lots of misdirection when I have my own answer dialog open. It's very important to make sure you supply a long stack reference to the copy you really want to save. This isn't always obvious to new users. I would distinguish here between a necessarily careful developer who should know what he is dealing with and who is able to overcome such possible misdirections and a user who simply wants to use whatever sort of dialog is provided in a given situation and who does not want to be annoyed by unwarranted error messages. To come back to the feedback from Stephen: Also the code doesn't recognize cancel from file dialogs -- deletes image and there is no cancel button on a couple of the dialogs. The dialog for amount of 'tile routine' effect for one. You are right here. Using cancel when importing an image deletes the existing image. I have already fixed that and will upload a new stack the next days. I am not so sure about a cancel button when choosing a width for the tile routines. Once you have decided on a tile border routine, why would you want to cancel selecting one of the width options? And there is the reset image button which can reset the tile image to its original state. On the other side it surely would not hurt to add a cancel option to the tile-routines dialogs. So, thanks again for your feedback and appreciation and go on enjoying the stack if you find the time. Best regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
ANN: Seamless Tiles Generator 2 updated
Just uploaded a slightly updated version of the Seamless Tiles Generator 2 to http://www.sanke.org/Software/SeamlessTiles2.zip See the descriptions on page Sample Stacks on my website http://www.sanke.org/MetaMedia. Among other things this stack features an improved resizable and draggable selection graphic that lets you choose a segment of any size from the imported source image to create a seamless tile. The ink of the selection graphic needed to be adapted both to the differences between Windows and MacOS and the stackfileversions 2.4 and 2.7. With engine versions 2.7 we need admin for MacOS and srcAnd for Windows. For engine versions 2.7 and higher srccopy is necessary for both platforms to show a transparent graphic. Moreover, I have changed the stack extension from *.mc to *.rev, to enable users of Rev 3.0 to see and load the stack. See the quote of my earlier post (to the Metacard- and Improve-lists) concerning this special problem: Strange change of file associations with Rev 3-gm-3 engine Wilhelm Sanke Sat, 20 Sep 2008 11:59:50 -0700 Rev engine 3-gm-2 displays both *.rev and *.mc-files in the open stack dialog as Revolution stacks. Engine 3-gm-3 restricts the displayed stacks to files with the *.rev extension; even when you choose All files the display of mc-files is suppressed, but other files like dlls and txt files are shown. It is even impossible to enforce the display of mc-files by typing *.mc into the file name box of the open stack dialog. Putting the Revolution.exe engine 3-gm-3 into the Metacard IDE shows the same restrictions: No mc-files are displayed. However, when you rename Revolution.exe to MC.exe, both Revolution stack-files rev and mc are displayed in the open stack dialog - like before in gm-2 with Revolution.exe. This holds for both IDEs, the Revolution and the Metacard IDE. The consequence for users that primarily work with the Rev IDE - but wish to access Metacard files once in a while - would be to rename their Rev engine to MC.exe. This works fine within the Rev IDE. Regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
ANN: Seamless Tiles Generator 2 updated
Just uploaded a slightly updated version of the Seamless Tiles Generator 2 to http://www.sanke.org/Software/SeamlessTiles2.zip See the descriptions on page Sample Stacks on my website http://www.sanke.org/MetaMedia. Among other things this stack features an improved resizable and draggable selection graphic that lets you choose a segment of any size from the imported source image to create a seamless tile. The ink of the selection graphic needed to be adapted both to the differences between Windows and MacOS and the stackfileversions 2.4 and 2.7. With engine versions 2.7 we need admin for MacOS and srcAnd for Windows. For engine versions 2.7 and higher srccopy is necessary for both platforms to show a transparent graphic. Moreover, I have changed the stack extension from *.mc to *.rev, to enable users of Rev 3.0 gm 3 to see and load the stack. See the quote of my earlier post (to the Metacard- and Improve-lists) concerning this special problem: Strange change of file associations with Rev 3-gm-3 engine Wilhelm Sanke Sat, 20 Sep 2008 11:59:50 -0700 Rev engine 3-gm-2 displays both *.rev and *.mc-files in the open stack dialog as Revolution stacks. Engine 3-gm-3 restricts the displayed stacks to files with the *.rev extension; even when you choose All files the display of mc-files is suppressed, but other files like dlls and txt files are shown. It is even impossible to enforce the display of mc-files by typing *.mc into the file name box of the open stack dialog. Putting the Revolution.exe engine 3-gm-3 into the Metacard IDE shows the same restrictions: No mc-files are displayed. However, when you rename Revolution.exe to MC.exe, both Revolution stack-files rev and mc are displayed in the open stack dialog - like before in gm-2 with Revolution.exe. This holds for both IDEs, the Revolution and the Metacard IDE. The consequence for users that primarily work with the Rev IDE - but wish to access Metacard files once in a while - would be to rename their Rev engine to MC.exe. This works fine within the Rev IDE. -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
ANN: Seamless Tiles Generator 2 updated
Just uploaded a slightly updated version of the Seamless Tiles Generator 2 to http://www.sanke.org/Software/SeamlessTiles2.zip See the descriptions on page Sample Stacks on my website http://www.sanke.org/MetaMedia. Among other things this stack features an improved resizable and draggable selection graphic that lets you choose a segment of any size from the imported source image to create a seamless tile. The ink of the selection graphic needed to be adapted both to the differences between Windows and MacOS and the stackfileversions 2.4 and 2.7. With engine versions 2.7 we need admin for MacOS and srcAnd for Windows. For engine versions 2.7 and higher srccopy is necessary for both platforms to show a transparent graphic. Moreover, I have changed the stack extension from *.mc to *.rev, to enable users of Rev 3.0 to see and load the stack. See the quote of my earlier post (to the Metacard- and Improve-lists) concerning this special problem: Strange change of file associations with Rev 3-gm-3 engine Wilhelm Sanke Sat, 20 Sep 2008 11:59:50 -0700 Rev engine 3-gm-2 displays both *.rev and *.mc-files in the open stack dialog as Revolution stacks. Engine 3-gm-3 restricts the displayed stacks to files with the *.rev extension; even when you choose All files the display of mc-files is suppressed, but other files like dlls and txt files are shown. It is even impossible to enforce the display of mc-files by typing *.mc into the file name box of the open stack dialog. Putting the Revolution.exe engine 3-gm-3 into the Metacard IDE shows the same restrictions: No mc-files are displayed. However, when you rename Revolution.exe to MC.exe, both Revolution stack-files rev and mc are displayed in the open stack dialog - like before in gm-2 with Revolution.exe. This holds for both IDEs, the Revolution and the Metacard IDE. The consequence for users that primarily work with the Rev IDE - but wish to access Metacard files once in a while - would be to rename their Rev engine to MC.exe. This works fine within the Rev IDE. Regards, Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Twofold posting of mail
Sorry for the fact that my last post concerning the Seamless Tiles stack was sent twice. There were problems with the mail service of our university server. -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: 3.0 for Linux is 8% slower than 2.6.1 ? (Bernard Devlin)
On Sun Oct 5, 2008, Bernard Devlin bdrunrev at gmail.com wrote: If anyone else has any other benchmarks, I'd be grateful to see them. Mine s3.0 for Linux is 8% slower than 2.6.1 ? eems pretty simple to me, and tests nothing more than a few functions, looping and adding to lists. It will only make any sense if you run the script on the same hardware, using a version of Rev = 3 and a version of Rev 3. Bernard Another test stack - also attached to bug report 5113 of the Rev Quality Center - has been around for some time: http://www.sanke.org/Software/TestStackPaintcompression.zip Although partly focusing on questions of paintcompression, it provides the possibility to compare engine and IDE speeds of different versions of Metacard and Revolution. One of the results measured by this test stack is that version 2.6.1 of the Rev engine has been the fastest so far when measuring imagedata processing. Other later versions have been shown to be up to 30 - 40 % slower than 2.6.1 in this respect - see the result page of the test stack. The new 3.0 Rev engine version has improved considerably over previous versions, but has not yet fully reached the level present in 2.6.1. Measuring speed differences with this stack is a very fast process, as scripts with a duration between few milliseconds and about 50 seconds at the utmost can be easily compared. Regards, Wilhelm Sanke http://www.sanke.org/MetaMedia -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: paintCompression and speed
On Sat Jul 21, 2007, viktoras didziulis viktoras at ekoinf.net wrote: Any pointers on how paintCompression works... Dictionary says: When an image is changed with a paint tool, it is recompressed the next time you leave the card it's on. Is this also true if imageData was directly updated - i.e. image gets compressed next time I leave the card it is on, isn't it? Or is image recompressed each time its imageData gets updated ? If so, likely RLE is the fastest method to choose or is it possible to disable paintCompression for images to get more speed for image updates or RLE is the only option to go ? Or if imageData and not the actual image is what is displayed on screen, then may paintCompression have no impact on how fast imageData is being redrawn. Best wishes Viktoras See Bugzilla 5113 and my accompanying test stack http://www.sanke.org/Software/TestStackPaintcompression.zip. Handling imagedata can be up to 12 times slower with paintcompression set to PNG than to RLE. Regards, Wilhelm Sanke http://www.sanke.org/MetaMedia -- Wilhelm Sanke www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: paintcompression and speed
An addendum to my first response: viktoras didziulis viktoras at ekoinf.net had written: Any pointers on how paintCompression works... Dictionary says: When an image is changed with a paint tool, it is recompressed the next time you leave the card it's on. The docs are wrong here: *Any* change of the imagedata will immediately set the image to the current paintcompression. Regards, http://www.sanke.org/MetaMedia This mail sent through http://www.uni-kassel.de/www-mail ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
