Pode's Forum Posts

  • bjadams : does it works that way when you say to respect white pixels, not to respect white pixels, or all the time ?

  • DeMayunn : I suggest to go the WebWorker way for your plugin, because WebCL isn't available in browser, apart from installing a dedicated plugin or using a special built (from Ericsson, or other vendors).

  • : they decided that after you have started your application with the launcher, there is no way to go back to the launcher "homepage" without killing the app as a prior. Their argument : your final app will be seen as completely independent of the launcher by the final user, so, in the end, you won't have a "option" to "go back to homepage".

  • chrisbrobs : I made it to work with simple properties. Your gradient is a declared filter. I need to check how I implemented it <img src="smileys/smiley2.gif" border="0" align="middle" />.

  • bjadams : I'm going to check the families problem. Does it happens when you have several Sprites in a Family, and one of them has the behavior, or all of them ?

    By the way, what kind of coloring book are you doing ? I don't know if you saw it, but I gave some code to R0j0Hound to integrate the "floodfill" ('paintbucket') in the Canvas plugin. With that, you can colorize black & white images with color where you put your finger.

    (My question : your "anxious little kid", is it your inner child, or your real child ? <img src="smileys/smiley2.gif" border="0" align="middle" />)

  • bjadams : I tested it on Safari :

    BUT there is a problem on Safari!

    1. Press save

    2. Press colorize Red. Works ok

    3. Press restore. Works ok.

    4. Press colorise Blue. IT DOES NOT WORK

    and you are right, there's a problem. It seems that when you restore an image with it's initial value, you can't apply effects anymore on Safari. I need to dig deeper inside Safari inner working to understand how they handle security policies regarding base64 images.

  • bjadams : I'm sorry, I tried to reproduce your bug, and everything was working. What build of Chrome are you using ? Canary ?

    I have updated the first post with a new build. Can you check if you still have the bug ?

    If it's still not working for your case, you can also extract the image with my "Extract as base64" plugin, save it in a var, do all you want to do with the effects, and reinject the saved string if you want to revert everything. It's not straightforward, but it works.

    All : I have updated the first post with a new build : new effects !

    Kyatric : is it possible to change the name of this plugin in the plugin list to reflect the new function (it's now doing Text & Effects, and not only Text as before). Thanks !

  • puoidirloatutti : I don't really understand what you want. Can you reformulate it ?

  • Val : any mic connected to the machine will be picked by the Flash code.

  • Metal_X : I made the two plugin Kyatric kindly mentionned.

    The base64 string thing is really old, as old as the web (older, in fact, since it was made to allow people exchange binary files over mail, which allowed only text at that time...).

    The idea is very simple : every byte of a file on a computer is a number between 0 and 255. However, when you want to represent a character in a text files, there are less letters in the alphabet and the punctuation thatn 255. In fact, the characters are numbered from 33 to 126 ('M' is 77 for example).

    So the base64 algorithm is simple : when you encounter a byte from the file, you represent it with one or more character (i.e. the byte '34' would be 'AG', the byte 201 would be '=/' and so on. It's not the real mapping, it's there to illustrate <img src="smileys/smiley2.gif" border="0" align="middle" />).

    If you do that for the whole image file, you have the whole sequence of byte (each one ranging from 0 to 255) converted in a printable character sequence (each one covering 32 to 126 hence the 64 in base64).

    You are going to object "Hey, if for each byte, you convert it to two or more letters, the representation in base64 is longer than in bytes !". That's true. base64 add around 33% overhead to the file size. That's the price to pay to be sure that the base64 string is always going to be readable, no matter what language the user is using on is machine (old 7 bits english ASCII, 8 bits european with '�','�','�', letters, complex tables with ideographic characters in Asia, etc...). At least you are sure that those 64 characters are the same everywhere.

    Since it's so old, browser can naturally handle those base64 string. You can specify directly a base64 string as an image source, and the browser will display it happily (that's what my behaviors are doing).

    Since it's a string, you can easily store it as text directly in localStorage, WebDB, send it over WebSocket and all...

    With one of my behavior, you can extract the base64 string of an image. Since a few builds, you can enter that string directly as an URL in a Sprite, Ashley added the code to the Sprite object.

    Everything you store in localStorage is going to be cached forever (at least for a long time, the decay is different for each browser, but at least 9999 days or the like <img src="smileys/smiley2.gif" border="0" align="middle" />). It's not true on mobile (oh, surprise !), because the system can decide that "the phone is full, I need to do some space !" (especially true on iOS).

    If you want to lighten the download for your client, you can store the images in localStorage. You need however to have a system to check the image version when you are going to add new card to your game ("is the card I'm introducing newer thatn the one cached in localStorage ?")

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 2. My business relies on games and app made with C2.

  • Updated first post, with the possibility of a base64 string dump for the SVG canvas. (Nudge chrisbrobs <img src="smileys/smiley2.gif" border="0" align="middle" />).

  • The "noise/grain" is intrinsic to Path Tracing. The way it works also means its really great for static images, for print (as an example), but it's non-usable for realtime graphics like a game (too taxing for the GPU, and furthermore, the image is never 'finished').

  • Sheepy : I'm on holidays, so I can't post it this week, but when I'm home I'll post it here.

  • Fimbul : not for the moment, since you need to do an Ajax get/post to a TCP socket, and browser can't open them.

    However, you can send the base64 string via WebSockets.

    (I'm also planning to do something with Flash P2P).