Flip Your Lid

[richmond62]

'Naughty' Richmond "stole" the transition images from somewhere else.

This fakes a pagecurl. The 'only' snag is that it does not reveal the picture below the first one.

flip_my_lid.livecode.zip

(124.3 KiB) Downloaded 285 times

[Jellicle]

...by which you mean "it doesn't fake a page curl".

Gerry

[richmond62]

Digging around on the internet I found several articles claiming a page turn effect was available in Hypercard!

I wonder (????) if anybody has got a Hypercard stack anywhere that has that?

[[-hh]]

..........

[richmond62]

NO, but Thanks!; I meant a Hypercard stack "The Lost Pharaoh", which, gathering from an extensive internet search is, indeed, lost.

It was available, millions of computer years ago, on the AOL repository.

Richmond.

[richmond62]

So: I found the stack on a ZIP file of the old AOL Hypercard repository; lurking on an IOMEGA ZIP disk of mine [Arr! There be gold in them thar hills.]:

and I found out two things:

1. Daniel Molitor (who made "The Lost Pharaoh") was writing nonsense on a blog about Apple's attempted patenting of a page turn thing, claiming to having implemented
a page turn in Hypercard:

http://www.jdjournal.com/2012/11/17/app ... animation/#

" http://www.lulu.com/molitor daniel molitor
Insanity! I published an interactive “book” called The Lost Pharaoh on AOL’s original servers way back in 1994. Clicking on the pages triggered an animated page turn.
Ironically, this was done with apple’s original Hypercard software."

2. All that is used for a "page turn" is VISUAL EFFECT WIPE LEFT with a noise like a smoker clearing their throat.

While VISUAL EFFECT WIPE LEFT (especially if you slow the thing down) might be quite effective, it does NOT produce a page turn/curl effect.

[bn]

Hi Richmond,

I remember a discussion you started on page curl on the use-list.
http://runtime-revolution.278305.n4.nab ... ml#a340437

At the time I made a stack that shows some transitions built into Livecode, some of them using QuickTime and some CoreImage.

I posted that stack to revOnline
http://livecodeshare.runrev.com/stack/4 ... ransitions
it includes a curl effect and a ripple effect. But it needs MacOSX at least 10.4 and a graphic card > 64 Mb. Which today should be given for most Macs used.

Kind regards
Bernd

PS
To everyone using numToChar and charToNum on imageData. Those times are gone with the advent of LiveCode 7
I did not follow the advice from Runrev to give up using char and now I will have to convert a lot of stacks to numToByte and byteToNum

Also be aware that if you used the fact that numToChar accepted negative numbers you will find out that in Livecode < 7 numToByte does not so, it returns 0.
Whereas in Livecode 7 numToByte behaves like numToChar in Livecode < 7 with regards to negative numbers
Bug 11996

[[-hh]]

..........

[bn]

Hi Hermann,

Now YOU should stand up and argue against such code-breaking-changes.

No, I will not.
First I am glad that unicode support goes all the way.
And numToChar and charToNum have a different meaning in that context.
I think that it is the most appropriate use of these to refer to characters, and not bytes


Furthermore RunRev will tell me: We told you so.
from the release notes 4.0

Byte chunk and related functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A new chunk 'byte' has been added. This makes syntax such as the following legal:
the number of bytes of <expr>
byte <expr> of <expr>
byte <expr> to <expr> of <expr>
the first byte of <expr>
repeat for each byte tByte of <expr>
etc.

At present the byte chunk is identical to functionality to the char chunk. However, it should be used when strings containing binary data are being manipulated to ensure future efficiency: the expression 'byte <index> of <expr>' will continue to remain constant time assuming <expr> is a binary string in the future (the same cannot be said of the 'char' chunk).

In addition two new functions have been added:
byteToNum(<expr>) - converts a single byte to a numeric value in the range 0-255
numToByte(<expr>) - converts a number in the range 0..255 to the corresponding byte.
Unlike charToNum and numToChar, the local setting of 'useUnicode' has no effect.

Lastly it is not really that big a problem.
E.g. I took your stack and replaced numToChar with numToByte and charToNum with byteToNum wholesale using find and replace.
Your stack worked without a hitch in Livecode 7.

The only problem will be in stacks that use Char for both string manipulation and binary data manipulation.

One gripe one could have is that not everyone has the release notes of Revolution 4.0 handy and that this warning has not made it into a note in the dictionary entry for numToChar/charToNum.

(this one is for you: the logical class of char may have one or more bytes as member and a logical class can not be a member of itself...) or somesuch...

Kind regards
Bernd

[richmond62]

Considering my Devawriter Pro: http://andregarzia.on-rev.com/richmond/dwriterpro.html

and PISMO: http://andregarzia.on-rev.com/richmond/LANGTOOLS.html

both depend on numToChar for delivering obscure writing systems,

I, if anyone, should be frothing at the mouth about that change.

BUT, I'm not, for the very simple reason that while, should I want to build
versions using the latest version of Livecode, rather than 4.5, I would have to replace
all numToChar statements with numToCodepoint statements, this should be nothing more than
a prolonged search-N-replace thing in my source stacks, and the vastly expanded Unicode
possibilities/capabilities are worth that change.

Try making an omelette without breaking eggs!

[dave.kilroy]

Herman maybe you missed the extended conversation on the useList http://runtime-revolution.278305.n4.nab ... 76895.html (plus a similar thread on the devList) that covered the issue of new terms, re-using old terms, breaking old code etc - and the general weight of opinion (after some swings of opinion) by the end was to go ahead with what RunRev in the end did with LC 6.7 and 7.0

I was quite impressed with the (apparently) genuine consultation and thoughtful remarks, their appreciation that they were in a sense 'custodians' of a community resource, and the obvious thoughtfulness on their behalf as well as awareness that going down some routes would involve some code no longer working. It really did not seem to be a situation of some 'gung ho' people at RunRev bulldozing new changes through without regard for working existing code - by the end it appeared to be much more of a joint decision of the community than one imposed upon it. Read the thread(s) and you'll find a see a lot of supporting posts from people ...

So in a way we are all to blame for the pain of having to maintain numtochar/chartonum code - it's a shame you didn't see the discussion or take part in it - if you had I bet by now you would be fine with the decision rather than dreading the task of changing some of your stacks. Good luck with your code maintenance and I hope you get to see the upside of the new arrangements soon

Kind regards

Dave

[richmond62]

TO RETURN TO THE TOPIC OF THIS THREAD!

It is possible to do this:

import snapshot from card "TWO"

while one is on card "ONE"

this, while seeming simple has not been mentioned yet.

[richmond62]

This also works:

import snapshot from the next card

Now that IS a good step in the right direction.

[bn]

Hi Richmond,

this, while seeming simple has not been mentioned yet.

that is how the stack posted to Livecodeshare works for the coreImage effects.

Kind regards
Bernd

[[-hh]]

..........