Forum Replies Created
-
Posts
-
Oh no, yet another ‘blockchain’ thing I just don’t get…
My tokens are on Mark
On the other hand, sounds like a great idea – thanks!
Ok, the main problem here would appear to be that “rw” does not create a file if none exists. Using “w” instead of “rw” fixes all above path problems for me, ie: I can use “asset::text.txt” etc.
On the other hand, “w” will always create a new file, even if it means deleting an existing file.
This is std C behaviour and all seems sensible to me, but perhaps “rw” should be tweaked so it behaves like “w” if no file exists?
[edit]Updated docs to describe “w” vs “rw”
Windows mojo/mojo3d apps can now use ‘real’ opengl drivers, instead of the angle opengl->direct3d wrapper.
This will make them a little less ‘compatible’, but will give them access to more opengl extensions and improved performance (esp. instancing) in mojo3d. Mojo 2d performance seems to be about the same. Unfortunately, you currently still need to ship with angle dlls. I will fix this ASAP, hopefully upgrading to latest SDL2 will be enough which I plan to do soon.
To use real opengl drivers, add this before creating AppInstance object: SetConfig( “MOJO_OPENGL_PROFILE”,”compatibility” ). This is now the default for any app that #imports mojo3d.
You should be able to do this with any mojo/mojo3d app and everything should just work, assuming gl drivers are up to it. It also means you can now use ALL of opengl (well, up to 2.1 anyway, but it should be easy to add more as it’s all autogenerated) so if you’re writing something in pure opengl using GLWindow or something there is now much more of opengl available to you.
SetConfig/GetConfig are new, and behave pretty much the same as SetEnv/GetEnv, only they use an internal variable table instead of process env vars. I also removed the ‘appconfig’ map system altogether, you should SetConfig for setting app config vars now. See SetConfig help for more config vars. Need to fix some underscores in the docs there too…
I’ve also moved to opengl as the primary API. The gles20 module has been deprecated, people should import opengl now instead. You have access to the same functions as before (and much more) except glClearDepthf is now glClearDepth. If you were using the ‘Ex’ functions in gles20 (eg: glShaderSourceEx etc) please copy these into your own project code somewhere. I have not copied them to the new opengl module.
Will the mobile target will take advantage of that too?
Eventually sort of, as the opengl module is based on glew, which effectively supports gles3.0 so if/when mobile moves to gles3.0 I’ll be all set to go.
But in general, mobile only does GLES so having ‘desktop’ opengl available isn’t really helpful there. So this is much more of a desktop tweak.
Sorry, but you guys’ll likely have to live with fun little site quirks like this until I can afford to get a ‘real’ web developer involved.
Hmmm, I could possibly add a ‘GradientColors’ array or similar to canvas for this?
Again though, note that “assets/” will probably NOT work unless there happens to be an assets dir in the current dir!
I could probably set up a basic server (HTTP and/or WS), but will definitely be occupied the rest of this week, and probably most of the weekend, with a house move (not mine!).
No problem, whenever’s good. It’s just I suspect you know much more about this websocket server stuff than I do and I could really do with some help here.
If Stream.Open returns null, then file probably could not be found/created.
Try using “asset::levels.txt” (although you’re not really meant to write to assets), or change to a directory that contains an “assets” subdirectory.
Stream.Open returns a new stream so you need to use:
sr=Stream.Open( blah.. )
I’ve had a look into this and I am basically WAY out of my depth here! Network stuff is not my strong point in the first place, and I find 73% of all this utterly confusing…
Concering the ‘connect’ error:
There is apparently no way to test a normal ‘connect’, because emscripten sockets must run in non-blocking mode, which means connect always fails with “in progress” errors, which is apparently ‘success’ according to some sample emscripten code I’ve seen! So I can ‘sort of’ fix connect errors (by just ignoring certain errors) but of course that doesn’t mean I’m not getting an actual error. But then what? I really have no idea what will work or, more importantly, what even should work, eg: how/where do I send data now that I have a connection?
Concerning websocket ‘servers’:
What exactly does your websocket server do James?
My knowledge of websockets is that they provide a ‘mesage based’ protocol on top on TCP, ie: a SendMsg, SendReply, RecvReply style API, and I can see how emscripten could potentially convert a plain socket stream to this using 2 message ports and ’empty’ replies. But I don’t see how your server code achieves the message protocol (although I haven’t looked that closely TBH). Does it? And if it does, how is it supposed to be used? When does the server ‘app logic’ get to process the SendMsg data (that was sent by a client) and provide a ReplyMsg reply? And if an emscripten app writes to a socket which emscripten converts to a SendMsg which gets sent to your server what happens? Or am I just way off here WRT how this all works? Ok, thinking about it more, it’ll be the websocket connection ‘peer’ that processes msgs/send replies? So does the sever code then just transfer msgs/replies between peers?
Concerning websockify:
Everyone in the emscripten discussion group who has successfuly used sockets (both of them!) recommends using something called ‘websockify’ which, AFAICT, converts websockets<->TCP sockets and allows us to treat emscripten sockets as much like ‘real’ sockets as possible. I have no idea what’s involved with setting it up, although I gather it also involves having access to a ‘real’ server.
https://linux.die.net/man/1/websockify
I’m not sure if this is 100% required, but it apparently makes things a whole lot easier.
Concerning next steps:
I’m willing to continue looking into this but I’ll definitely need help, ideas for things to try, perhaps someone to set up a websocket server, or even websockify and a plain server. I just don’t have the skills to do this alone.
Yeah, reading up a bit more on this I think websockets should probably be able to connect to port 80, but are unlikely to be able to perform a GET.
For now, I have asked some pertinent questions about emscripten sockets in the emscripten discussion group and will look into it further when I get some time.
Anyway, off to buy a rubber ducky.
Thanks for the sample code, it at least gives me a starting point.
I guess you should be able to at least connect with http, but I doubt you’ll be able to do a full http GET. But I don’t honestly know how any of this stuff really works as yet so who knows?
Will have a closer look when I get some free time, although I don’t quite know that’ll be right now.
Copy the example code from above: http://monkeycoder.co.nz/forums/topic/simple-http-1-1-web-page-download/
But that doesn’t even connect to websocket server so I’m not surprised it doesn’t work! Is it supposed to?
Can you show an example of a js or other app successfully connecting to this (or any!) websocket server?
Can you then show an example of an monkey2 app unsuccessfully attempting to do the same thing?
But what exactly do you expect me to do with ‘it spits out -1’?!?
Please post a test app, explain what it *should* do, explain how to reproduce results, prove it’s not a server issue because of xyz etc (eg: ‘it works with this little js app’) and so on.
In general, please provide as much information as possible – just going ‘it doesn’t work’ is no help at all!
Possible starting point:
http://demos.kaazing.com/echo/
There should be a bunch of similar ‘test’ servers around on the internet too…
