Forum Replies Created
-
Posts
-
Yes, translator bug!
‘blah=blah mod etc’ works, but ‘blah mod=etc’ doesn’t, possibly only when blah is non-int type. Will fix.
Welcome to monkey2, and hello from New Zealand!
I’ll have a think about this lot – could you post it to github issues?
is there a README for the new build?
No, it’s really just a snapshot of the github repository. I’ll try to work out some way to attach a github changelog to future releases.
This release at least is mainly just bugfixes, but there’s a lot in there so I’d recommend ‘upgrading’ anyway.
Can someone provide steps to install emscripten target?
…this might be a bit more recent…
https://github.com/juj/emsdk/blob/master/README.md
What browser? OS version? Googling suggests it may be a chrome thang.
I can’t actually get emscripten working here at home on a windows 10 laptop, guess there’s still some magic files missing from the emscripten-1.37.9.exe package so probably not worth trying if you haven’t got emscripten going already.
Module has been updated and is now available via module manager!
This may in fact be fixed in develop branch – someone had a similar problem with image:Image=Null in a struct and I seem to remember fixing it.
If you post a runnable example I can test it…generally, it’s always best to post something runnable if something is acting up.
That’s why I made that statement.
No problem and thanks for the input – hope you don’t think I was hassling, just responded with ‘problems as I see it’ etc and threw some ideas around. I actually don’t remember how monkey1 did it, must have another look!
…works well here with soon-to-be-released 1.0.04, will add it to bananas thanks!
The only real issue is that asteroids/rocks flying around seem to have a fringe/border. However, this seems to be built into the image (aliens3.png) not just a ‘GrabImage’ problem!
Ok, this one’s a bit fun as I’m finding it hard to reproduce here, but it does happen every now and then. What OS are you on? Windows 10 here.
Anyway, this code looks a bit dodgy to me, one of the ParticleEmitter ctors:
12345Method New(factory:ParticleFactory, interval:Int, ttl:Int = 500, LockParticlesToEmitter:Bool = False)Super.New(ttl, Self.initial, Self.last)...End MethodThis is invoking Super.New using ‘unconstructed’ fields of the super class as parameters, ie: Self.initial and Self.last (which are really members of BaseParticle). This is IMO kind of nonsense code, like Local k:=k or something.
These are *usually* null before super.Ctor is called, but apparently not always. Changing the ctor to:
12345Method New(factory:ParticleFactory, interval:Int, ttl:Int = 500, LockParticlesToEmitter:Bool = False)Super.New(ttl, Null, Null )...End Method…appears to fix it for me, although like I say it’s hard to reproduce here so I’m not 100% sure.
The ‘big fix’ is probably to (at least) disallow use of any base class members when evaluating parameters for use with Super.New calls, as it doesn’t make sense to allow use of yet-to-be-constructed members.
Ok, The ‘asset::’ prefix (and other such ‘::’ prefixs) should only be used with Stream.Open, eg:
Loadl dataIn:=Stream.Open( “asset::table.data”,”r” )
Assets are not always stored in filesystem directories, so an ‘asset stream’ is not always a FileStream.
Personally, I think games should just default to the assets dir but what do I know.
The problem with that then becomes how do specify ‘current dir’, eg: if “table.data” means a file in assets storage (not necessarily a dir) then you’d need a different way to specify a file in the current dir – perhaps force people to prefix files in current dir with CurrentDir()+blah, which is gonna annoying a differet set of people! Or perhaps even ‘cd::’ – dunno, if you’ve got any ideas go ahead and let me know…!
So far, every mx2 target is little endian so there is currently no need to check – although you could if you wanted to ultra-future proof stuff I guess.
Yes, some reliable steps to reproduce would be most useful.
Had a quick go at building angelscript and it worked first time, results are here:
http://www.monkey-x.com/mak/angelscript.zip
That said, I’m not sure how much use it’ll be – from the looks of things, it uses c++ types to interact with the host, so you’ll need to wrap all that stuff.
Yes, mx2 does use -std=c++11.
The dxmath problems looks like a calling convention issue – there might be some #defines in dxmath somewhere that you can tweak to fix this.
As for the angelscript module not building, can you post angelscript.monkey2? Looks like you may have a dodgy #Import in there. I’ve never heard of angelscript before, but looking at the web page now I think it should be relatively easy to port to mx2.
