The Future of monkey

Monkey Forums/Monkey Programming/The Future of monkey

hardcoal(Posted 2011) [#1]
will monkey is aiming to replace blitz3d and blitzmax one day
or is this not the plan..


AdamRedwoods(Posted 2011) [#2]
monkey will replace me one day...


Amon(Posted 2011) [#3]
It's Elvis.


Samah(Posted 2011) [#4]
Short answer: No.
Long answer: Nope.

Until Monkey can create a standalone executable with embedded data, Blitzmax will always have the dominant position. If Mark creates an official Monkey/Mojo to Blitzmax target, then yes, I can see Monkey taking over somewhat. It won't really "replace" Blitz3d/Blitzmax, as I'm sure there will be things that don't translate well.


hardcoal(Posted 2011) [#5]
Thanks for the diginfied answer samah
I guess ill continue learning blitzmax as well :)


Samah(Posted 2011) [#6]
I guess ill continue learning blitzmax as well :)

It's good to know multiple tools. :)
But no, I don't think Mark ever intended Monkey as a replacement.


slenkar(Posted 2011) [#7]
A new version will be released, called Sapiens:The Next Evolution


Gerry Quinn(Posted 2011) [#8]
I guess it will replace Blitz3D and BlitzMax a bit later than it replaces C++, Java and Javascript ;-)


Dabz(Posted 2011) [#9]
The future of monkey is all depended of BRL.. We cannot predict or otherwise dictate what the future outlook should be, it's all out of our hands...

Though, going off past form, BRL do the job... And do it well, though, in regards to this, I'm pretty much miffed at the fact that they seem to disregard file operations (LoadString) to the point they drummed down a customer/forum member in a thread for suggesting a workable solution only to be told it'll be technically fixed when its fixed... File operations, taking a back seat, erm, WTF?

Also, the SetColor command in HTML5 is cack, it's fixable, but, again, it's been left... My worry is that all this iffy stuff has been left and as such, the "write once and build for all" slogan is pure bollocks, because you cannot actually write once, and confidently build for all the advertised platforms, because, things are broken all over, false advertising... I'd go as far as say it is (Loadstring works in HTML5 in the demo.. foobarred in Flash, which, is only available in the full version)

The quicker BRL address these cross platform ball ups. the better, otherwise, what is the actual point of monkey?

Dabz


GfK(Posted 2011) [#10]
Apart from that it needs a debugger of some description before it can be taken really seriously. I've seen people in the past tell me to build the project then debug the C/C++ output. If I understood all that why the hell would I be using Monkey?

As for LoadString, it's horrid as the *only* method of loading raw data since it fails in many circumstances.


impixi(Posted 2011) [#11]

...the SetColor command in HTML5 is cack, it's fixable, but, again, it's been left



I looked into this recently and did not find a *decent* solution - 'decent' meaning good-performing and resource-friendly. The consensus among native HTML-developers is that the lack of a straightforward method to 'tint' canvas images is an annoying oversight in the current HTML5 canvas specification. So it's not really Mark's (or Monkey's) fault per se that SetColor is cack in HTML5.


TheRedFox(Posted 2011) [#12]
@Gfk: debugging with GLFW C-code is fine enough for me.

The code is full of references to the monkey code lines and the mapping is straightforward. Just a lot of bb_ prefixes.

And it allows me to code on one Windows box, move to the Mac and build for the iPad every once in a while.

All the code of Monkey is available, so, why not make patches available?


therevills(Posted 2011) [#13]
Re: SetColor

JL235 recommends doing this way:
http://www.playmycode.com/blog/2011/06/realtime-image-tinting-on-html5-canvas/

@RedFox - you shouldnt need to debug the c++ code, you should debug the monkey code though!


Gerry Quinn(Posted 2011) [#14]
There are things to do, but IMO Monkey does what it is supposed to do, i.e. generate working cross-platform programs out of the box. Sure, it's not perfect and your going to have to tweak some things when you first compile a large project for a target you didn't test on periodically during development. But I defy anyone to point to any compiler that doesn't give you a few nasty surprises when you compile a large program that hasn't been done before.

Absence of a debugger... well, it brings back the old days ;-) You young whippersnappers don't know what it was like to code in a quasi-assembler typed in from a book, loading and saving to cassette, like we did on the Spectrum way back when. Compared to that, Monkey is a luxurious programming environment! I haven't even got Jungle yet.

All joking aside, I hope Mark will before too long produce a debugger, a preprocessor, and targets that you can build outside Monkey. In the meantime, though, I'd suggest treating the basic IDE and absence of a debugger as an incentive to develop good programming practices.


TheRedFox(Posted 2011) [#15]
@Gerry Quinn: About 42y old here, so guess I know a bit about cassette recorders :-)

@therevills: sure. Thing is as of today GLFW is the best thing on my hands to find out what goes weird and why. It saved me hours already.
A translator is no compiler anyway. And I do not expect it to be.

Know what? The best thing about monkey is that I really positively like the BASIC-like syntax. I have done my share of C++ and Java but it brings back the "old days feeling". With tablets and mobile, the fun is back again!!! #indypower


impixi(Posted 2011) [#16]
@therevills

Funny you should mention that site. I've created a TintedImage class based on that code and technique. Now I'm in the process of coding a simple particle system to test the performance of that compared to Monkey's SetColor command.

However, and this goes back to my definition of 'decent', I'm not sure using multiple canvas objects to achieve such an end is 'resource-friendly', especially when running in mobile browsers.

Will be interesting to see the results anyway.

EDIT:

Here's the Javascript class if you want a crack at it yourself. You'll need to pass a valid target canvas context to the Render method.

tintedimage.js




Samah(Posted 2011) [#17]
@impixi: Now I'm in the process of coding a simple particle system to test the performance of that compared to Monkey's SetColor command.

Try out the particle system example in Diddy.


impixi(Posted 2011) [#18]
My test results are disappointing. I coded a simple 100 particle test that wrapped the TintedImage class I posted above and hacked into my 'canvaswrapper' code. The mojo test simply used SetColor for tinting prior to rendering. (The image was a 64x48 PNG). Both tests used the same 'particle system' code.

IE9 performed 5-8fps better. Chrome16 actually performed 5-8fps worse.

(If anyone is interested I can post the test code, but it hardly seems worth the effort.)


impixi(Posted 2011) [#19]
Heh. I'm looking at mojo's JavaScript source code and it looks like Mark uses the same principle to draw a tinted image. Could have saved myself a lot of time by checking there first. Ah well.


hardcoal(Posted 2011) [#20]
3D in monkey. another step towords domination.


TeaBoy(Posted 2011) [#21]
3D for Monkey is definately a very good move from Mr Sibly, very smart decision.

I would like to see a network module in the near future, that would be an uber smart move.