Great work and insight to the complications and performance benefit of workers in C3. In my C3 plug-in 3DObject, I am also spawning a number of workers to do heavy work (like vertex and skin animations). I also looked at the shared-array buffer route for communicating between runtime and workers, but as you noted, discovered the restrictions (and preview would not work). I found I would have to export and use a local webserver w/ the appropriate restrictions, but that was cumbersome. Also it would restrict any final game webserver in terms of other server accesses (e.g. for CDN or database.) I did use ArrayBuffers though (transferables) as a way to quickly exchange large amounts of data between workers and that has been useful. It is a one way transfer, but perhaps with appropriate meta data along with the paths, other pathfinding workers could determine how to incorporate other pathfinding workers paths into its local map. Looking forward to the pathfinding updates.
bug posted
Regarding webglcontext, it looks like HandleWebGLContextLoss() has been removed from construct.net/en/make-games/manuals/addon-sdk/runtime-reference/base-classes/sdkworldinstancebase
Is there a new way to enable the custom options for handling webgl context loss / restore (the spine addon may need this)?
I took at look at this, but don't see an obvious answer, I imagine there is an issue with the transformation when the UVs transition at the border and the bilinear tries to blend across the boundary.
Hi, sure upload a link to the project (I use sendgb.com to share files, but whatever works for you.)
In general I use 3DShape or 3DObject to do what I used to want to do with this effect these days.
I am glad you also saw the need for extending the glsl version and extension support, very handy for creation of new effects. I hope you continue this project a lot of good has definitely come out of it for C3 and its users. One suggestion I have is take it all the way through to delivering on another platform (e.g. Steam, iOS App store or Google Playstore), so you also get the experience of what is required for that for a C3 export.
Thank you so much for the webgl effects options, this is very much appreciated. dfDy and dfDx can be so useful and performant for certain shaders! With these features, a useful new addition for effect uniforms would be arrays. For example for sending in a lot of light positions or a matrix.
Ah, too bad, but I don't have the C2 project anymore.
Give credit to this author: casual-effects.blogspot.com/2013/08/starfield-shader.html
Hi, this is all pretty old, so probably does not follow the latest updates to C3. I don't have plans on doing an update, since this was just an experiment for me. I am open to discuss a commission to update the plugin though if you that is interesting to you. Do note that this is very CPU/GPU intensive, it does not seem to work well on mobile, etc. Even on desktop you need a reasonable configuration for it to work well. If you need to contact me, you can connect with me on twitter: —
Thank you for new uniforms for effects! Would it be possible to add a couple more varying, like world_position (which would help a lot with a 3D fragment lighting shader see: construct3-21h2.ideas.aha.io/ideas/C321H2-I-197 )
Thanks for all the scripting updates and git updates. These are very useful for us (our project uses Typescript to access the C3 scripting interfaces). We have a 4 person team collaborating on the C3 client for our MMO and we use git for our version control. Minimizing unnecessary project files changes due to project saving is very much appreciated! As you do this, if you see any other areas where collaborators might clash due to adding objects, images, etc. I hope that they are addressed (currently we don't have open issues here, since the internal random object/image/instance IDs have been updated a while back.)
Nice work, I really like the fire and forget style of bullet, which greatly reduces the network traffic of many bullets moving around at once (just sending start x,y,vector of bullet vs send x,y of bullet every server tick) - Have you ever seen it go 'out of sync' between server expectation and client expectation (e.g. with subtle timing differences between CPU time on server vs client). I imagine there could be drift, but the time frame is short (bullet life) and both sides use pix/dt instead of pix/frame.
It's not exposed in this addon.
I also don't see it in the underlying greenworks library (which you could access through scripting.) You can see more here: github.com/greenheartgames/greenworks/blob/master/docs/friends.md
Sorry, no I do not have a tutorial for this.
I think you would want to use:
JSON object in C3 to store data and load data, see the C3 documentation on JSON object for more details.
Save text to file {0} {1}
Save text to file.
Use the JSON expression ToCompactString as the text to save to the Steam file.
Read text from file {0}
Read text from file.
On save text to file success -> let the user know that save was successful
On save text to file error -> use the expression: SaveTextToFileLastErr to indicate error
On read text from file success -> use the expression: ReadTextFromFileLastData to get the data. I suggest using a JSON object load and store data to/from. For example use JSON Parse action to load the JSON object from the ReadTextFromFileLastData and use the JSON expression ToCompactString as the text to save to the Steam file.
On read text from file error -> use expression: ReadTextFromFileLastErr to show the error to the user.
Member since 22 Apr, 2016