README FIRST!!!!!
Community Forums/Monkey2 Talk/README FIRST!!!!!
| ||
| http://marksibly.blogspot.co.nz/ |
| ||
| Looking forward to supporting you when you get your Patreon up! Monkey 2 sounds great! Would using something like asm.js be helpful? I think we will still use Monkey for majority of our projects. For us there might not be a real reason to upgrade, but maybe we can take advantage of some unique features which Monkey 2 facilitates better. |
| ||
| Thanks Soap! Unfortunately, I don't think asm.js or emscripten etc will help all that much with what I'm trying to do, as the problem is not so much with generating js code, but the js APIs. A lot of the feature requests for monkey are entirely possible on the c++ targets, but not others, and I'm kind of sick of having to either reject requests because they wont work everywhere, or watch in horror as monkey slowly forks itself into 'glfw' and 'others' flavors. |
| ||
| I will support this new endeavor on patreon and hopefully this will bring the Blitzmax crowd on board if the feature set is rich enough... they could treat this as a BlitzMax 2. |
| ||
| Looks like a decent plan, especially in restricting yourself to C++ targets with a "posix-ish api". Sure, I'll support that. |
| ||
| This makes me very happy. I'm glad to help in any way I can, even if it's just some $. The Blitzmax and Monkey languages have put food on my table for years and I'm excited to see the tools I use every day get new life. Thanks Mark! |
| ||
| Well, it seems I was not alone when the 'blitzmax2' bubble popped out onto my head. ;) Good work, Mr. Sibly. ^_^ |
| ||
| Nice to hear this Mark. I will definately contribute towards this. Cya |
| ||
| This sounds really interesting! Keep us informed, Mark! |
| ||
| Am I right in thinking that Patreon = Subscription?. For the record I am indeed interested in contributing. I for one hope that Monkey1 code will at least run in Monkey2 with the minimum of tweaking! |
| ||
| I'll definitely sign up! About time I paid for a BRL product... |
| ||
| Can we please call it BlitzMax 2 not Monkey 2. Blitz has a much longer richer history than monkey and monkey although a good product in its own right is woefully inadequate to even blitz2d. |
| ||
| Ohh! Great news! The creative mood is back! I really don't understand the 'patreon'-thing (It tooks me a while to understand the real meanings... 'maeceas') - what's bad with 'selling' / 'renting' it? In any case I *really* hope you call it BLIZ-something (and drop any reference to Monkey!) ps: a little prayer... make the language case INsensitive :D |
| ||
| HI Mark. I bought blitzmax and then monkey. And I like them. But let me be a little bit "iconoclast"... :-) If the target of this new project is platform and mobile only, so C++ or one of his avatar, what's the interest of this project ? I mean: instead of creating a new language, why not to develop a new QT game framework, maybe the best ? The targets of QT are the same isn't it ? And so you can concentrate yourself on the game framework itself... again, thanks for all your work ! Pit |
| ||
| Coolness! Very good news :D |
| ||
| Gee... I'm sad with this. So we have no hope of a proper admob module for Windows Phone, Monkey updates will be far and far apart, no more html5 (at least on *that* part I'm partially covered with my own engine :P). As for features on the html5 side... wouldn't WebGL solve most of the problems? That's the way Unity is going to, so I can't think as its being *that* bad as plain canvas2D... And on top of this going on the subscription route...? Definitively Monkey2 isn't for me - and now I'm afraid Monkey1 will have the same future as Blitzmax :( |
| ||
| Could you give some more details about the patreon project, please? Or is it too early? Just asking about the details after reading such comments in BlitzMax forum: Mark will be funding it through patreon. That means those of us who can afford it (and are willing) will pay a "subscription" to support his efforts. Everyone else can use Monkey 2 for free, because it will be open source. Seems like a win/win IMO. It's possible many people are not willing to pay then (it's open and free and free of charge anyway), and only a few guys pay (a monthly subscription, forever?). Would there be any benefits/extras with the subscription, or is it just good will of some good guys? ;) (With Kickstarter, you usually get benefits/gifts the more you spend/donate - that's what I mean...) EDIT: Example monthly subscription projects 1 2 shows also rewards the more you pay. Looks like "If 1000 guys spend $5 each per month, all is fine"... first time I see something like this. :D |
| ||
| Great news. Looking forward to funding on patreon. |
| ||
| Looks like "If 1000 guys spend $5 each per month, all is fine"... Hopefully that happens, or any combination of the above #s to make it work for Mark... |
| ||
| Awesome news! The loss of HTML5 is a blow definitely, what are you thoughts that HTML5 support could be feasibly added at a later date? Are there any language features you plan that are definitely impossible? I am not so fussed that HTML5 is gone personally, but more that it basically slices a large part of the market/ecosystem away in one swipe! That said, hell yeah to hackability! P.S. I will be supporting! Do we need some kind of tshirt "I am a BlitzMonkeyX2Plus supporter"? |
| ||
| @Skn3: The loss of HTML5 is a blow definitely... I don't understand this mentality from everyone. If you want to use HTML5 with all of its shortcomings, use Monkey 1. If you want to use potentially awesome features that HTML5 never had any chance of supporting anyway, use Monkey 2. Too many people seem to be of the mindset "Monkey 2 is coming so I won't be able to use Monkey 1 any more". |
| ||
| Well I know someone who works in the gambling game development business and they are in the process of heavily switching over to html5. This is a long running company who had previous relied solely on c++. If you have companies staking their future on html5, it strikes me as a blow to monkey2 longevity. I wouldn't say that it is a "I won't be able to use monkey 1" mindset, but more that it's a shame such a good feature has to be cut from the lineup. It was a bit like moving from blitz max to monkey and losing maxgui. Yes it was still possible to use blitz max, but you sure as hell miss all the new programming flexibility. |
| ||
| Plus there are concerns that Monkey 2 will mean the end of Monkey 1's development. I know Mark has said he will continue to update Monkey 1 but that won't alleviate the fears. |
| ||
| There are concerns that Monkey 2 will mean the end of Monkey 1's development. I know Mark has said he will continue to update Monkey 1 but that won't alleviate the fears. Well, I think monkey 1 is still very relevant and as long as it doesn't get broken and Mark stays tweaking it here and there you still have your html5 target. |
| ||
| I was answering on the blogger but then reread the Monkey2 forum to monkey-x.com line and decide to drop it here. Hi Mark That's what I was searching for with "Monkey 1" back in 2010 when most yelled at me that the future was HTML5. And it was right, HTML5 is a good thing... mostly for website. I would never been able to write the game that I want even with the current performance of HTML5 (especially now that I've done a few mobile games and get disappointed by the general performances :). Unfortunately, back in the day, I had a few Linux users asking me to support drivers I couldn't use in BlitzMax. A few general users asking for modern features and I was stuck... So I had to learn another language to continue my learning and choose C# so I could eventually run into IT on bad days. After looking at how Monkey X turns out (and how many times I really used it) I think I it was a good choice. Now about Monkey 2... or "BlitzMax 3" ? :-D To me (read IMO), since it's an open source project, it's quite simple : just keep going on the nice Monkey X language, support a good IDE (e.g. Eclipe, better : Atom.io) and port a robust game engine (e.g. LibGDX). There's no way I could go back to a brand new language without a top notch IDE and a huge range of basic needs. You create excellent languages : give them excellent IDE and engine ! Think about the time needed to reach this at a decent level and see what's best ;-) Ps: I also like the idea of using Qt as a game UI. Most in-game UI today are bad. The best would be supporting something like CoherentUI. All the best things of the web instantly available in your game or app. |
| ||
| I'll definitely kick into a Patreon. |
| ||
| Well, I didn't read it first - I was looking at other threads more in terms of an upgrade to original Monkey. My attitude: there are a million languages, but there is only one Monkey / mojo. As far as I am concerned, the loss of HTML5 (and Flash too, although that will probably fade away in the future) takes away a big chunk of Monkey magic. I am here for the multiple targets, not the language (even though I quite like the language). That doesn't mean I wouldn't use Monkey 2 - but the stronger HTML5 becomes, the less incentive for me to do so. |
| ||
| Mark, i see you start again from "zero"... why? creating new language, ide, docs, libs ... that need a lot of time - you should spend this time to monkey instead (with that patreon, if you like) Monkey is a very good language for games. I like to have many targets as possible... including HTML5+FLASH !!! today, the game language market is "DEAD" it is no more possible to create again new language for games... here are many languages, libs, gamemaker today... |
| ||
| Mark, i see you start again from "zero"... why? I am not sure he is starting from zero. He is taking with him tons of experience and can probably do a lot of copy / paste, make the required changes/additions and voilà, Monkey 2 is born. That may be a over simplified explanation but I am guessing this is the case. |
| ||
| My mobiles are windows phones so looks like im up a creek with moneky2. |
| ||
| Perhaps you could try this: https://code.google.com/p/angleproject/ |
| ||
| Oh my god please make it happen! |
| ||
| I like Blitz3D because of it entity engine and its 3D interface, not because of its language. I like BlitzMax because it gives me immediate access to put a 2D software together real fast. I like Monkey X 1 because it can generate js when performance is not needed and too much ugly js is involved. I still don't know why I need Monkey 2. Thus, I won't pledge or buy it, I will wait. If I see 3D functionality like in Blitz3D in Monkey X 2, not through third party developer, I may become interested. Having sense of community is the best of humanity, but needs need to be satisfied, otherwise, individuals will feel betrayed and a community will become isolated and cult-like. |
| ||
| Please add Direct X support and I'll make it my no.1 commercial dev language and will spend accordingly. |
| ||
| We released (Anawiki Games) more than 10 quality games on iOS using Monkey. We'd love to have: - iOS - Android (that handles games larger than 50MB*) - Desktop targets similar in functions to BlitzMax At the moment we develop our games in BlitzMax first, then recode them in Monkey, but we could work much more efficient if we could use just Monkey. No Desktop target (with DX for Windows) or no iOS target is a no go for us. * We know you can use multiple APK on Android for Google Play, but for some reason when we do that and load assets from another APK our app runs out of memory, while it works perfectly fine when it's just one APK. That's the reason we did not release our games on Android yet. |
| ||
| @Anawiki, Mark has stated that Monkey2 will support iOS... we have to wait have see if we get DX support. To this end, monkey2 will initially only support c++ targets that have a posix-ish api, which effectively means that only the desktop, ios and android targets will be supported. BTW congrats on your successful release of Avalon Legends Solitaire 2! |
| ||
| Hi, I'm the develloper of the Jewel Match serie. I just wanted to say that I am very interrested in this project but as Grey Alien and Anawiki said, DirectX support is very important for the casual market. Without that, Monkey2 would only be one more possible tool to port our games to Android/IOS. With Dx support it could become *the* tool :-) |
| ||
| I want to keep using Blitz products forever. I've just signed up to the Patreon. Please consider DirectX support. Thanks! |
| ||
| I'm halfway done with a Direct-X 9 target for Monkey. The only problem I'm having so far to finish it, is with SetScissor - using SetClipPlane isn't working for some reason. Other than that I still have to implement CreateSurface, DrawPoly, DrawPoly2, ReadPixels and WritePixels2 in mojo/dx9 - and then do something with audio/joystick. The rest is done, and working quite nicely... |
| ||
| That's pretty rad news SLotman! |
| ||
| Thanks :) And I solved yesterday the SetScissor problem :) I already have DrawPoly/DrawPoly2 implemented (need to test it to be sure its working properly), so now I just have to implement CreateSurface / ReadPixels / WritePixels2 - and then see what I'm missing from newer Monkey versions (I'm still using 77b) |
| ||
| I also think it should be called BlitzMax instead of Monkey. I have never understood why it was called Monkey and I think it may have hindered sales as every time I have mentioned it to work colleagues they just laugh at the name. The Monkey and bananas approach just doesn't seem very professional. |
| ||
| Every time I see the name Monkey I think GORILLAS.BAS. |
| ||
| BEST GAME EVERRRRR!!!!! |
| ||
| Regarding the current 'block' use of public/private vs the more verbose 'per decl' version - how about we allow both? I'm thinking that anything that can be public/private/etc can have public/private/etc appended to the end of it's decl, eg: method OnDraw:void() protected This wont affect the 'block' state of public/private, it'll only apply to the one decl. The other place this could go is at the front of the decl, but I think this has the potential to be confusing if we're allowing both styles. Also, it's more monkey-ish to have modifiers at the end. Decent enough compromise? |
| ||
| I'm fine with both methods, choice is good. However, what about conflicts where an end-line-declaration scope conflicts with it's block scope? I think prefer the scope it at the end of the declaration too rather than in front. Kind of like how Bmax reflection tags looked natural. |
| ||
| So that's where that post went... > what about conflicts where an end-line-declaration scope conflicts with it's block scope? The end-line-decl access modifier only applies to the current decl, doesn't affect block/default access, eg: class C method Draw:void() method OnDraw:void() protected method Update:void() method OnUpdate:void() protected end Draw and Update will be public because that's the current 'block' access when they're encountered. |
| ||
| Looks good. |
| ||
| I would prefer to have only one method as it adds unnecessary complexity. If there's nothing in the declaration of a memeber, I don't know it's visibility unless I try to find if it has been defined before in the class declaration which adds ambiguity. I would choose one or the other, but not both! Method DoSomething:MyClass(param1:Int) It's impossible to know if it's private or public or protected unless I search for the visibility modifier being set before. Depending on the complexity of the code, it can be a waste of time. In fact, while IMHO having public or protected defined a la Monkey 1 is not the best option, making the same for Protected seems a lot more weird to me, and I see no benefits unless you love the mouse scrollwheel. I would go for defining a default visibility behavior and requiring an identifier in every class member that does not have the default defined visibility. Make "Public" the default one, and expect people to mark as Private or Protected only encapsulated members. This is usually less typing too, but much more consistent and less disperse. That said, I think putting the visibility identifier before the member allows for motr natural read of the code as it will resemble much more natural English. EDIT: Also, what about classes? Are their going to be pubic or private depending of something defined several lines before and maybe several classes and functions before? And what would be the default visibility for their members if they do not have a visibility identifier, inherited from class visibility? At the end, not easy to know if something is public or not unless you start searching in the code. Not the nicest thing on earth if you ask me! EDIT2: I've read in your other post that you'll be leaving the "block" mode as you're too used to it. I respect and understand this, but it's a very poor argument! Lots of people were used to GOTO and GOSUB statements XD (No offense intended, just that what one's used to is not a valid argument). And there are usability reasons to choose one over the other. Whatever you choose to do, remember that if you try to please everybody, you can end with something completely inconsistent. |
| ||
| I thinking that having both is fine, but if only one is chosen, I'm leaning toward the 'block' method. Syntax consistency of Monkey2 with Blitzmax and Monkey1 are near the top of my wishlist. |
| ||
| Although having choice is good, and I'd like to find a compromise that both camps are ok with, I think I'm going to have to go with ziggy. However... @ziggy: That said, I think putting the visibility identifier before the member allows for motr natural read of the code as it will resemble much more natural English. I agree that it makes for easier reading, but it's not very "blitz-ish". Historically, modifier keywords go at the end of the initial declaration (in BlitzMax and Monkey 1, at least). If I had the choice I'd probably put them at the front as you suggest, but it might be harder to convince some of the old school BRL users (and Mark). |
| ||
| I'm also in favor of visibility identifiers before the method name. It gives you context and it's better to understand the context as soon as possibile when reading. In general I think putting all the modifiers at the beginning is better than at the end for the same reason. At a glance you know what we are talking about when scrolling vertically through the modifiers. |
| ||
| I agree that it makes for easier reading, but it's not very "blitz-ish". Historically, modifier keywords go at the end of the initial declaration (in BlitzMax and Monkey 1, at least). I see, but isn't this very very weird and confusing? Field myField:Int, another:String, oneMore:MyClass Private It seems that only last element is private, and maybe it is, maybe ALL the elements are private. It adds ambiguity to the syntax, so not a good idea for fields and globals. then, different syntax for fields and globals? not nice! In the other hand: Private Field myField:Int, another:String, oneMore:MyClass It's sort of obvious that all fields are private here. |
| ||
| I would go for defining a default visibility behavior and requiring an identifier in every class member that does not have the default defined visibility. Make "Public" the default one, and expect people to mark as Private or Protected only encapsulated members. This is usually less typing too, but much more consistent and less disperse. I agree with this. I can see programmers being easily frustrated by the different organizational methods that will emerge from a mix of the two... (though a good ide should help them with that) |
| ||
| I'm fine with a compromise on scope syntax, but if other people aren't, then keep it the way it is now ;) further thoughts were posted on the other thread and I'll repeat one here: Having both will leave it up to personal style, with most people coming from other languages likely to tack it on to everything even though it looks way uglier than the "Monkey way". Let them have it their way, and make any further arguments about this issue a moot squabble |
| ||
And this?Field myField:Int, another:String, oneMore:MyClass,x1:int,x2;int SetPrivate oneMore,x1 |
| ||
| @degac: Nah, before or after the declarations works best, that looks fiddly and not immediately identifiable. I would be in favour of the Blitz-like Private goes after declaration, but in fairness ziggy's before example looks pretty sensible too. |
| ||
| "Make "Public" the default one, and expect people to mark as Private or Protected only encapsulated members. This is usually less typing too, but much more consistent and less disperse." For me it would be more typing. I try to have relatively few public functions. But some would say my classes are too big. In fact, 'Protected' would be my default for class members if I could choose one, though it may be an eccentric view. Anyhow, I'm very pleased to see that 'Protected' is coming! I don't think this is going to be a make or break issue with regard to language usability anyway. We all have our ways of organising the layout or using IDEs to make things more comprehensible, even if the way of declaring access qualifiers doesn't suit our workflow. (By the way, PowerBasic used to have - maybe still has - GoSub available along with standard procedure calls as in modern basics. I found it useful once or twice to be able to run a procedure with access to the local variables of the current procedure. GoSub is not all bad!) |
| ||
| REMOVED - wrong thread :D |
| ||
| @Gerry Quinn: Anyhow, I'm very pleased to see that 'Protected' is coming! Protected has been in Monkey for a few months now. |
| ||
| Hi. I just heard about Monkey 2. Why are you making another version of it? Were there some glitches or something in the first one? I am still a bit new to monkey so i do not know much about it. Still playing around so to speak and learning from the forum here and the youtube videos. So right now i think Monkey is a bit complex. So when i heard about Monkey 2, I was kinda freaking out due to fact that this language has just been out for such a short time. Personally though, I found the easiest language to learn was Blitz3D. I guess i am what you would like to call an "old school" programmer. Anyway back to Monkey2. I just hope some stuff gets a bit more simplified like blitz was. But that is just me. One thing i have noticed over the years: it seems like people can't enjoy anything for very long anymore due to everything changing. I think that is kinda sad. |
| ||
| Species: Think of Monkey2 as a partial rewrite, intended to "improve" upon decisions made early on in the original Monkey's development, that will allow certain new features to be implemented more easily than they would be in Monkey1. This includes some changes to the syntax which would break existing Monkey1 code, so as a result, the language has been split into an intended predecessor and successor. Which one you go with depends on when you decide to get "into" the language, and what your intents are. Until MX2 reaches a more mature state of development, there's really no way to know whether MX2 will take off. Some people will stick with Monkey for practical reasons, and others won't migrate until they're able to have certain frameworks available. Mark's doing what he can to make sure that external libraries are easy to access and work with in MX2, which is supposedly far superior to the way it's currently done in Monkey. This might encourage faster adoption of the language. But most of the syntax and feature improvements I've been reading about are ones that probably aren't of much interest to you if you're an "oldschool" programmer. Many new functionalities cover new-ish programming concepts that you would never see in any older BASIC syntax, so any simplification will boil down to the libraries available to you at the time you adopt the language. |
   |