Forum Replies Created
-
Posts
-
Quite understand!
I am actually only aiming for ‘useful c++ support’. Full c++ support would be impossible without duplicating all of c++’s features (and quirks). But there’s enough in there to be able to use bullet, litehtml, libtheora etc. from monkey2 which is what I was aiming for.
Will update docs too to at least mention what you can’t do with extern.
Ok, there are some Print’s in modules/mojo/input.monkey2 that I’ll remove.
Just cursious, but do you have mobile going?
Not yet, preprocessor doesn’t handle ints, <, > etc yet so it’s probably not much use.
What banana can I run to reproduce?
What host/target?
type Self. and just as soon as you hit the ., the IDE closes.
I believe there’s a fix for this in the works, in the meantime try turning off autocomplete in the file->preferences page.
Is this the same problem though? The first post did not mention having to type anything.
This can happen when you post code that the server incorrectly identifies as malicious.
I need to contact support to get this fixed which I’ll get around to eventually.
There is no way to extern operators.
Monkey2 is not a cpp ‘translator’ or emulator, it is its own language that generates simplified c++ behind the scenes.
It does not support all c++ functionality and there are many things you can do in c++ that you cannot do in monkey2.
Why not just stick with c++? What are you hoping to gain by wrapping highly specialized c++ code in monkey2?
You will have to write a monkey ‘extern wrapper’ for it, or you could try using std.geom.Vec3f.
What platform, OS etc?
Anyone else?
I think I may have found it!
As far as I can tell, glGetError() is VERY slow on Chrome. Perhaps it’s doing an internal flush or something?
Anyway, you can verify this by sticking a ‘Return’ at the top of the glCheck function in modules/mojo/graphics/glutil.monkey2 and rebuilding modules for emscripten etc.
Plese let me know if this fixes it. This may be worth a 1.1.05b release as it’ll affect 3d stuff too…
(…that’ll teach me to ‘code defensively’!)
Unrelated, but another thing I recommend is using ‘TextureFlags.Dynamic’ when creating textures that are being constantly rendered to, eg: if you’re rendering frames off screen, eg: image=New Image( w,h,TextureFlags.Dynamic ).
This tells monkey2 not to bother ‘backing up’ the texture after you’ve modified it in case of a ‘lost device’ event, eg: Alt-Tab, display mode change etc. Backing up after modification is slow, and there’s no point backing it up if you’re just gonna redraw it again next frame.
Wont affect the above little demo, but could affect Civ.
Ok, I can reproduce now and it appears to be Chrome related.
Can you try ‘firefox nightly’ instead? The above little demo actually goes a bit faster in V1.1.05 with nightly for me (and using WASM) – but I can confirm very slow performance with Chrome.
Firefox nightly is my default browser of choice for dev work as it’s usually the first to support any fancy new fangled features and seems to offer the best performance with webgl, wasm etc. I should probably test more often with Chrome though, as it’s now the IE of the tenties…
Will keep looking into this though – could just be something I’m doing slightly differently is ‘trigerring’ crap performance on Chrome.
Strings in monkey2 are ‘immutable’: they cannot be modified. To do what you’re trying to do you’ll need to build a new string.
Just looking into this now…
The actually canvas drawing code hasn’t changed, but the ‘render to texture’ system has so I’ll start there…
