Mungo - Monkey fork
Monkey Archive Forums/Monkey Discussion/Mungo - Monkey fork
| ||
| 3rd of July 2014 First public version of Mungo Impress v1.0.0-rc.1 (Windows only, for now). Here is the list of new features and differences with Monkey. --- Website: mungo.io Source code source.mungo.io --- After thinking some time about the future of Monkey I’ve decided to try to evolve my own fork of Monkey called Mungo. I’ve created it shortly before Mark said that the Monkey development is on hold. Right now I have a plan of action and I decided to give it to the world in order to get some feedback from the community. Firstly I would like to say, that this isn’t Monkey’s competitor. Moreover, I hope that this fork will encourage Mark to continue to work on Monkey. All that will be created and opened under this project can be moved to Monkey later. So, a little bit about development plans. Project will have two parallel development branches. 1.x This branch will be a simple support and improvement of the current Monkey version. Development of this branch will contain: * Add WebGL support to mojo * Change Ted by another (advanced) IDE * Improvement documentation template * Rewrite bmx tools in Monkey * Create standard distributives (rejection from archives) * Small fixes and improvements of core modules 2.x This branch is the next stage of Monkey development. Development of this branch will contain: * Create Mungo language based on Monkey * Node.js and node-webkit integration to build new infrastructure * Create mungoscript and monkeyscript for more flexible targets building (builders, hooks, etc.) * Development of a modular IDE (written in Mungo) * Installer SDK development * Development of module registry and package manager * Development of internal player for running and debugging HTML5 games * Development of advanced mojo alternative (perhaps with backward compatibility) with shaders, atlases, tilemaps etc. These are preliminary plans so they may slightly change. I would like to hear any feedback from the community and maybe some suggestions. Right now branch 1.x is in active development stage, you can get the source code on GitHub. When it will be ready to use in production I will prepare binary builds. Changelog of the current version: * Added WebGL support for mojo. Use #HTML5_WEBGL_ENABLED=True to enable * Added TARGETS_PATH variable to Trans config file * Added CLOSURE_COMPILER variable to Trans config file for ability to use closure compiler. Use #HTML5_OPTIMIZE_OUTPUT=True and release mode to enable minification of js file * Added metadata for sound files in HTML5. So, LoadSound and PlayMusic return values similar to other targets * Added support of #MOJO_IMAGE_FILTERING_ENABLED to HTML5 target (not for all browsers). With #HTML5_WEBGL_ENABLED=True it works correctly in all browsers * Fixed TouchX/TouchY with scaled canvas * Fixed Web Audio support check in Android browsers * Fixed Web Audio activation in mobile browsers |
| ||
| Seems like it could be cool, though I really must question the wisdom in changing the syntax for the sake of changing the syntax. Monkey's arguably more readable than Python when using Strict styles and verbose block closure statements (End Method / End If / etc. instead of simply End). Python's also a dynamically-typed language, which doesn't translate very well at all to some targets, if that's a planned feature. (If it's not, again I must question changing the syntax.) Several of Python's other nice pieces of syntactic sugar can translate to Monkey without much trouble -- the one feature which I think could argue for such a change would be support for Generators / coroutines in a Python-like way. Honestly though from my limited understanding of the things, this can also be dealt with perhaps with a reworking of how ObjectEnumerators work in Monkey along with some extra keywords (Yield, From, etc) to step through an enumerator in a custom/lazy way. |
| ||
| have I missed something when did mark say development of monkey was on hold? |
| ||
| Pretty ambitious but good luck! Paul - see 'Monkey roadmap' thread: original post is three weeks ago on about page 3 or 4. |
| ||
| I could understand Mungo 1.x plan (WebGL supporto to mojo and various improvements). Doesnt' understand why in 2.x you want to 'add' a new syntax (as you stated Monkey-syntax will be still supported)... just to complicate things and write a new function/features 2 times? ps: 'Mungo', after a quick search on google... seems to have many meanings (and commercial names too). And the name of Tarzan's ape friend I think (so warning... ) |
| ||
| it is no problem to fork it... any time... ***Create Mungo language based on Monkey but more python-ish (full rejection from Basic). Monkey support will be still alive. monkey language is better (and cleaner) than python ***Development of a modular IDE (written in Mungo) why on hell? ***Development of advanced mojo alternative (perhaps with backward compatibility) with shaders, atlases, tilemaps etc. the most useful thing... in my eyes, the only things than need a massive improvements are: standard modules - they need a "STRUCTURE", codes should splittet from singe files to smaller pieces (video, audio, input.....) then... a simple preprocessor-command could append all splitted files to single temporary output file (automatically) at compile time if needed. then all modules need a clean code style... i do not like: If foo bar better: If foo = True Then bar() +More better documentations And then we could start to extend modules add new functions -AdMob for WinPhone -IAP for Amazon -Controller for Android -Social Modules -Vibration -Advanced GFX-Commands ...etc +More default, officially supported modules -3D -GUI ... On language side... I like to check also DEAD code for errors, because i do not like surprises if i enable unused codes later... Then more simplifications are needed.. i do not like to recover build structures on monkey updates (add icons, setup projects etc...) This is what we need, and not another IDE (use existing: Eclipse as plugin) |
| ||
| dragon wrote: : Eclipse as plugin) Does it exist? |
| ||
| For the new syntax, got any code snippet on how you would like it to look? |
| ||
| >>>Does it exist? i think here is nothing for monkey... but haxe have this - so it is doable... http://www.eclihx.org/ |
| ||
| Thanks for a great feedback! I would like to clarify a bit about the change of syntax. It seems I mislead everyone when I said that I’ll do syntax similar to python (it seems to me that Monkey syntax has something in common with Python). Actually, I don’t plan to change so many things, so let's just forget about python :) I would like to change: the comments (//, /**/ instead of ‘ and #rem), the select operator to the switch operator, and the comparison operators (!=, == ). Also (possibly) to refuse from End If, End For, Then, etc. All this is done to make it easier to switch between languages. I write a lot on js, so when I return to Monkey very often I do the same typos... Also this decision was made because of a huge amount of negative feedback about Basic syntax when I told about Monkey to other developers. For me it’s not insulting - to write on Basic, but for many developers it is like a red rag to a bull. So as you can see this is not a big issue to support two languages. At the moment I don’t plan to bring more changes. Regarding IDE. Actually I would like to write IDE in order to create UI module. So I could test the module in action. Right now I arranged with Jentos IDE author about including this IDE (after some stability fixes) in the distributive of 1.x branch About naming. Mungo comes from reducing genus Mungotictis. I tried to find a registered trademark, and it seems it was but right now it’s abandoned. So maybe there won’t be any issues with the name. I think at the moment it is not so important... But thanks for the warning. Regarding other modules. At the moment I don’t plan to create and refine modules like 3d, IAP, AdMob, etc. I hope that the community will continue to do modules for Monkey, so it won’t be an issue. Small mungo syntax snippet (just from my head. I should think more about that) /*It's block comment*/
//It's line comment
if (a == b and b != c) //brackets not required
switch b
case 0
//do something
default
//do something
end
end |
| ||
| Not sure if forking it and splitting the already small community is the best of ideas, but who knows what might happen. good luck. personally I will be using normal monkey until it breaks and then with no other options I will move to unity :( not a very happy guy at all. |
| ||
| All this is done to make it easier to switch between languages. I write a lot on js, so when I return to Monkey very often I do the same typos... Also this decision was made because of a huge amount of negative feedback about Basic syntax when I told about Monkey to other developers. For me it’s not insulting - to write on Basic, but for many developers it is like a red rag to a bull. So as you can see this is not a big issue to support two languages. At the moment I don’t plan to bring more changes. Don't mind me saying this, but it's pretty jacked up to waste such an inordinate amount of time catering to these people's old prejudices. They're upset over clearly more accessible syntax -- that must be it, because every other old critique of BASIC languages doesn't apply, and some of the ones that do seem to get a free pass with languages like Python that share those features (ahem, like dynamic typing), segue aside. Switch statements have fall-through in C-like languages, so you're not making it any easier for people there by removing that than you would forcing some level of verbosity for readibility's sake. Actually, Monkey lets you omit verbosity for block closures, which is a feature not present in many BASIC dialects -- Forcing people to use that, however, I find downright offensive, as a long-time vb.NET coder, I use verbose block closure statements to help find my way around the code and wouldn't be happy seeing that removed. I not sure what else to say, other than everyone has their own preferences for operator choice. I actually think Monkey got it right on Logic vs. Bitwise ops. Straight comparison is fine, though I imagine some people can take contention to <> vs. !=; that's an old BASIC thing. I find little use, however, for allowing assignment inside the eval part of a one-liner branch statement -- you can always do this on a separate line, and it improves readability. Maybe c-style For syntax would have more use for that, but then you start running into the Generator/Iterator thing again, and while Monkey has a quirky syntax to deal with that, that's one of the things that makes the language unique (for better or worse). In the hypothetical future, EachIn could support lazy generators and Step would work with variables when the a full generator isn't needed. So, yeah. People's objections to the syntax are mostly an excuse, I think. Everyone who has been around a while has encountered BASIC, and anyone who hasn't is either new or simply opinionated and have room to learn. The same arguments though I guess could be said if the language started off with more c-like syntax, but it didn't -- Mark chose BASIC-style syntax, so you're gonna be making an active decision whether devoting resources to changing that is a worthwhile tradeoff for your efforts. (IE: Do you gain much more than you lose, on top of the time spent?) I dunno. I think I might be with Taiphoz on this one, but then again if I thought Monkey were dead, I'd probably put in a fork, too. It would be an "with-intent to merge back into mainline" thing for me, though. |
| ||
| As long as Mark doesn't make the NON desktop and HTML5 part of mojo public domain, then Iwish you fun creating a replacements for mojo for all these targets. Which is doable but quite some work. Maybe SDL2 can help in this regard. That would also give you DirectX support for windows which a lot seem to want. Or do you want to concentrate on desktop and html5 alone, which is also a nice project!? |
| ||
| @Nobuyuki, I understand you and in many things I agree with you. But if it might help to attract new users why not try it? Perhaps I’m wrong, but if I don’t try to do it, I will never know it. If no one uses mungo as language in future I’ll just stop its support and will concentrate on other things. In any case, implementation of the new syntax will be the last thing I do for Mungo 2.x Also I would like to point out, that all core modules will be written in Monkey, so they still can be used with it. I don’t aim to split Monkey community, just right now I can’t put my energy into Monkey development, because I’m not its co-developer and the only thing I can is to go my own way. Even if I’m the only user of this fork I’m going to develop it until I need it in my work. @MikeHart Thanks! First of all I’ll focus on HTML5 and Desktop targets (since I'm familiar with them most of all). And yes, I’ll probably use SDL2. Later on I plan to add support of mobile targets, but total targets amount will be most likely less than Monkey and mojo have now. |
| ||
| I find this actually very interesting. I'll be watching the progress of this. I've thought also to rebuild the html5 translator to focus more on a modular output. I've been working for a long time as a full JS developer and using prototype hasn't been the best solution. Also having everything globally exposed a isn't a good idea too. From my perspective there is a lot that can be done for that target. I would love to focus html5 for mobile development. I believe the current target is more focused to desktop. |
| ||
| I've thought a few times about the possibility of creating an alternative syntax layer. The first job seemed to me to be refactoring the code to enable easy adding/swapping of lexer/parser modules. Mungo's changes sound relatively minor though, so it might possible to just work them into the existing code. I'm not sure if that would be a good thing. I'm also a bit concerned about treating the language and the tools as a monolithic project. While this might work for Mark as a solo coder, it makes it more difficult to work on at a group level. Perhaps we could open up a discussion about a structure for community development. Oh, and one other thing. I appreciate the concept of using a language to build the tools for that language but it really seems a masochistic endeavour to try to build an IDE in Monkey/Mungo right now. |
| ||
| I like some of the improvements but I feel this will splinter the community, especially if the syntax changes. The code will not be interchangeable with each other. |
| ||
| * Add WebGL support to mojo For the HTML/JavaScript target, take a look at: three.js - JavaScript 3D library - using WebGL Website: threejs.org Download: github.com/mrdoob/three.js/ Documentation: threejs.org/docs/ License: The MIT License Examples: - Examples - More Examples Demos: - TriggerRally - HexGL - Special.T - They will eat you - Gravity Movie Experience - Racer-S WebGL Demo (Google Chrome browser recommended) Another one is: Canvas 3D JS Library Website: c3dl.org Download: http://www.c3dl.org/index.php/download/ Documentation: http://www.c3dl.org/index.php/documentation/ License: MIT License Demos: - WebGL Demos |
| ||
| @verbose code blocks / functions function Stop:int(bla:int) function Drinking:int(bla:int=1) function Beer:int(predefined:Bool=True) if Stop Drinking Beer print "thirsty" So how should the compiler know, that 'print "thirsty"' is the evaluation to "true" and should be used as param for Beer(). So the compiler must do assumptions instead of clarifying things in code - using brackets or "expression"-splitters (if...x...then...y) The only (for me) valid option of an "if"-block without "then" is, if it is a multiline if-block. This is because Monkey/BlitzMax enforces you to use ".." to concat multiline expressions. Also leaving out braces for functions makes things really hard to read "logically". So this is not about "verbosity" but about "not flawless" interpretable without doing assumption (it is logic, not analysis and interpretation). bye Ron |
| ||
| So how should the compiler know, that 'print "thirsty"' is the evaluation to "true" and should be used as param for Beer(). So the compiler must do assumptions instead of clarifying things in code - using brackets or "expression"-splitters (if...x...then...y) that's because it's a deliberately contrived example (it's not even correct syntax). Stop(bla:Int) requires an argument, so it can't be called in the way you described. In Strict mode, all 3 eval functions would expect parenthesis, because they're functions. Only variables and Properties get that luxury typically. Single line parsing should expect Then as typical BASIC syntax; it may have been a mistake to allow omitting Then when there is no line break to separate the condition from the statements, but it's a minor point of contention with a scope of critique somewhere between allowing implicit type conversion and allowing type sigils. If you're using a single-line If block, be sure to use Then, and to also use good (not lazy) function arg syntax. Strict can help you here somewhat, but newbies wouldn't know that since a lot of bananas use the lazy old Blitz-style syntax and can teach some bad habits. |
| ||
| The example of mine was "BlitzMax"-code (and should be valid there) ... I am not really doing something with Monkey, so I just assumed that you still do not need brackets there. Also that "then" can be left out in BlitzMax. So I assumed that this language hmm "features" were kept in the language definition of Monkey. Sorry if this is NOT the case. My codes all use "SuperStrict" (BlitzMax) to avoid surprises. bye Ron |
| ||
| @ilovepixel thanks! I totally agree with you - current HTML5 target is more suitable for Desktop than for mobile devices. I think I will provide some work in this direction. I also agree that js translator doesn’t use the best practices. But as muddy_shoes said, it should be improved at a language level, and not at a tools level. But I would be interested to participate in translator improvement if community decides to do it. @muddy_shoes yes, in my case it will be enough for me just a few tweaks in the translator. But the syntax layer sounds interesting! I also share your concerns about treating the language and the tools. I think it will be the right thing to open a discussion about a structure for community development. Though it will be difficult to separate tools and language until builders and translators are rigidly connected together. Regarding the IDE. Yes, it maybe sounds a little bit masochistic - to develop IDE with Mungo/Monkey :) But it is not an idee fixe, so if it is too difficult or takes too much time I will hold it on for better times @Danilo thanks for the links! But I’ve already implemented it. I would like to say that I don’t want to make 3d version of mojo, only WebGL wrapper for 2d commands. |
| ||
| @dragon: monkey language is better (and cleaner) than python That's not hard. :) @dragon: I like to check also DEAD code for errors, because i do not like surprises if i enable unused codes later... Add the following at the top of your main source file and it will force trans to compile all your code: #REFLECTION_FILTER="*" Import reflection @Nobuyuki: Don't mind me saying this, but it's pretty jacked up to waste such an inordinate amount of time catering to these people's old prejudices. They're upset over clearly more accessible syntax -- that must be it, because every other old critique of BASIC languages doesn't apply, and some of the ones that do seem to get a free pass with languages like Python that share those features (ahem, like dynamic typing), segue aside....(snip) I agree with all of this. Changing existing syntax is just silly. You may as well add mandatory semicolons too. Adding syntax is another thing, and as long as it fits nicely with the rest of the keywords I don't see why not. @Nobuyuki: I actually think Monkey got it right on Logic vs. Bitwise ops. Agreed, except for the Shr/Sar bug that should have been picked up in beta versions. @devolonter: But if it might help to attract new users why not try it? Because it might also do the exact opposite. As much as I love my braces and semicolons, basic is a brilliant syntax for newbies to programming. I'd wager that BlitzMax/Monkey are a first foray into programming for a huge portion of the BRL community. Do you really want to scare away newbies? Over the years, I've seen the Monkey community as being extremely helpful to new people. @devolonter: So as you can see this is not a big issue to support two languages. That's what Microsoft said when they made VB.NET rather than letting it die the agonising death it should have many years ago. VB.NET exists solely for the migration of VB6 programmers. @devolonter: I don’t aim to split Monkey community... But it will. Any time a project is forked it's unavoidable. @devolonter: Regarding the IDE. Yes, it maybe sounds a little bit masochistic - to develop IDE with Mungo/Monkey :) But it is not an idee fixe, so if it is too difficult or takes too much time I will hold it on for better times So it will either never happen, or will be a dirty hack like Monk was. You need to dedicate one person to this. You can't do it all yourself. @devolonter: I would like to say that I don’t want to make 3d version of mojo... Unfortunately it seems that this is what people are asking for rather than language improvements. Summary: Features and bugfixes are more important than changing things "just because". |
| ||
| Have to agree with Samah, anything that has the potential(and this has a lot) to split this small community is a bad idea. All you will end up with is even fewer people using your fork and even fewer people using the main source so no one wins, I wonder why you don't simply push these changes toward the main distro I am sure if their actually good ideas mark will pull them in. either way.. good luck, I hope it all works out for everyone. |
| ||
| "I am sure if their actually good ideas mark will pull them in" There wouldn't be anything stopping him pulling changes from any given fork if he wished though, that's just how open source works. However, the evidence so far is that Mark is not particularly inclined to take changes or incorporate code from elsewhere. From what Devolonter wrote he has no intention of making "Mungo" anything more than an optional mode and it's just Monkey with some minor tweaks for his own tastes. I'd suggest that getting concerned about some hypothetical Monkey/Mungo rift is a bit premature. Mungo doesn't particularly interest me (if I were to create an alternative syntax it would be a much larger set of changes) but starting to build a structure for community development does. It would be a pity if people started to see Monkey forks as somehow inherently a problem. |
| ||
| It would be a pity if people started to see Monkey forks as somehow inherently a problem. if someone who is a positive influence in the community decides to create incompatible modules, i would think that would create problems. i remember the "D" language split for a while and it created rifts/ confusion as well (phobos vs. tango). i don't want to discourage this project, but i think this comes at a sensitive time. |
| ||
| @Samah I understand your point of view. Maybe you are right, but maybe not…Time will tell. Just wanted to say that many things were once made "just because". OK, I see that this fork raises many concerns. Though muddy_shoes wrote quite accurately the purpose of this fork and reasons of its creation. Let me provide a few examples why I decided to do it. Mojo HTML5 GL. This patch will never be included in the official repo. Also I haven’t heard of Mark’s plans to build his own. But the issue is that patching isn’t the best idea (it’s not very usable). Currently, I wrote a completely new implementation of it with full integration with mojo. It still needs some work, but it already works 10 times better than the patch and ~20 times faster than 2d canvas mojo. Meta data for audio. It was important to check sound file exists or not in my project. But in HTML5 target LoadSound doesn’t return Null. So, I had to write a fix. I offered it to Mark, but he wasn't sure that it will work with Web Audio and the fix was rejected. Though now I use it in my project and it works like a charm. Access to surface image field. It was asked to do a number of times, but every time it was rejected. In my fork I can make it public. So, it’s very difficult to contribute to Monkey. You can make hundreds useful stuff, but if Mark rejects it you can't do anything about it. I understand that Mark makes a commercial product and he doesn’t need magic bugs in someone else's code. Eventually I had a choice - keep these things for myself or open them to community. And I chose the second option. Once it is ready for release and is well tested I’ll send pull requests to Mark. But I can’t say for sure that they’ll be included. In any case I’ll provide some manuals about how to use it in Monkey. It doesn’t make sense to split this small community. I’ll continue to support my Monkey modules as well as to create the new ones. But with Mungo I can make something more. Syntax is my personally taste, so I’ll use it only for personal projects. All modules will still be written in Monkey. |
| ||
| "if someone who is a positive influence in the community decides to create incompatible modules, i would think that would create problems" It's certainly possible for someone to do this in an aggressive manner that would be problematic - if Devolonter made his syntax changes and then immediately altered Flixel to only work with his fork, for example. I don't see that sort of thing as an inevitable consequence though. To an extent I think it's an error to headline this project with the syntax variant label as it's really not the most interesting part of it. It would just be a shame if the baby went out with the bathwater and people shunned the whole idea of community forks of Monkey based on this one issue. As I said before I'm quite keen on the idea of getting some sort of loose organisation for community dev efforts moving forward. One part of that would be creating a general understanding of how we might structure projects so that people can still create things like Mungo's alternative syntax while maintaining clear separation from "core" Monkey. At the moment I'm struggling to find a site/web software that would allow discussions around things like proposals and design documents. I'm not entirely convinced there's enough motivation and commonality of viewpoint to make such a thing work but it's worth a try. |
| ||
| I hope this develops into something a lot of us will use. I'd hate to see your hard work on this go to waste. I hope you don't give up any time soon. |
| ||
| I appreciate your additions a lot, especially since I'm thinking about working more with html5. I do see why Mark might refuse a patch that he fears might cause magic problems ahead - however maybe I'm misunderstanding the nature of the changes but why not include them with monkey and have them require preprocessor directives to activate - make a clear note that the feature is 'unofficial'. For html5 GL this seems like a win-win. Once enough people have tested it out in a variety of apps then change the default of the directive to on. Or is that not possible? |
| ||
| Re:HTML5 webgl with an ugly hack, you can Extend Surface and Mojo to alter the behind-the-scenes. look at how i did this for minib3d: https://github.com/adamredwoods/minib3d-monkey/blob/master/mojographics.monkey i can try to streamline this and get Mark to allow us to extend Surfaces and GraphicsDevice. this way we can implement custom Mojo changes better. i agree Mark can be stubborn to add radical changes (like my PNG-4bit for GLFW), but sometimes if one can point out the benefits he will concede. |
| ||
| I like the idea of a more ecma style code option for monkey. I have one friend who should have migrated from action script to monkey but doesn't like the BASIC syntax one bit. I've just run into CoffeeScrtipt which also is a nice looking syntax. |
| ||
| Today was released the first public version of Mungo Impress v1.0.0-rc.1. Right now, build is only available for Windows. Builds for other platforms will be available after Mungo will become more stable. You can check the list of new features and differences with Monkey here. Also, for Mungo was opened simple website, where you can find download and source code links. Let me remind, that Mungo is fully compatible with Monkey. So, you can use only those Mungo features, that are not available in Monkey. Here is a small demo which presents main features of mungo - preloader and WebGL. Hope you’ll find it usefull! |
| ||
| Hi, Mungo looks great for HTML5, like the fact IE11 WebGL is working. Good work :) |
| ||
| Wow, the WebGL performance is really impressive! I had actually found that your older patch was no longer as performant as a plain old HTML5 build lately, I don't know why. But this blows it out of the water. I have to admit, though, I am very reluctant to switch off of the main Monkey development branch. All the concerns that exist about the level of support for Monkey proper are magnified for me for forks by individuals. On the other hand, some of these improvements are really great, and I wish they were in Monkey proper. |
| ||
| Actually, a question that is more general -- I currently use your GL patch, but rather than doing it as a patch, I just made it a custom target independent of the standard HTML target. That way it is very clean and easy to maintain between updates. How interwoven with mojo is your new GL implementation? Could it be a new target instead? Same comment goes for the preloader. |
| ||
| WebGL stuff can be implemented as a new target. How to use WebGL from mungo in Monkey 1. Create a new HTML5 target based on the standard HTML5 monkey target. 2. Rename directory of the new target. For example: html5_webgl 3. There, replace files in modules/native folder by files from mungo 4. Rename new target in TARGET.MONKEY file. For example: #TARGET_NAME="Html5 WebGL Game" 5. Copy-paste code from mojo.html5.webgl.js file into template/main.js file after //${TRANSCODE_END} line 6. Add #HTML5_WEBGL_ENABLED=True in template/CONFIG.MONKEY file That's all! Unfortunately, preloader requires some modifications in mojo files, so it can’t be implemented as a new target. |
| ||
| This is so impressive. I do understand some of Mark's concerns, but I wish he was more open to including things like this in native Monkey. |
| ||
| Hi, I have been playing with Mungo and tried my SVG renderer, it renders very broken if WebGL is enabled in both Chrome and IE? http://www.monkey-x.com/Community/posts.php?topic=7898 Thanks. |
| ||
| Awesome, thanks Devolonter! |
| ||
| If possible please add a precompiler const, something like #MUNGO=1 'impress so that library and module makers are able to compensate for the changes to things like input device coordinates. I'm presuming these are breaking changes |
| ||
| duplicate post, see above |
| ||
| Hi, I have been playing with Mungo and tried my SVG renderer, it renders very broken if WebGL is enabled in both Chrome and IE? Hi, Thanks for the test and report! I’ve made some changes, it’s still a little bit buggy but not totally broken as it was. You can find updated version in mojo repo. I’ll look at it in more detail next week. If possible please add a precompiler const, something like #MUNGO=1 I had some thoughts about it. Will be added in the next version. Thanks! |
| ||
| Wow, I can get 6000 objects to render in the webgl demo. Very impressive. |
| ||
| devolonter, I just tried out DrawPoly2 (textured DrawPoly) in Mungo, and it is giving very odd results -- verts exploding all over the screen, inconsistent with other targets. I haven't tried building a small test case yet, but wanted to give you a heads up. |
| ||
| Raph, what version of Mungo did you try? Version RC.1 doesn’t support DrawPoly2 function, I’ve added its implementation a few days ago, so it’s not released yet. I’ll provide new Mungo version this week. CopperCircle, regarding your svg module. I removed triangulation function from WebGL version of mojo, so now it works like any GL target. But you will need to modify your DrawTriangulatedPoly method in SVGObject class. Just modify your #IF TARGET="html5" condition by the following: #IF TARGET="html5" And Not HTML5_WEBGL_ENABLED |
| ||
| Hi, thanks for the update, are read/write pixels working correctly in webGL? I am getting some strange effects with the image being distorted when drawn after being grabbed with read pixels. |
| ||
| Yes, there was a bug in ReadPixels function, but it's fixed now. This fix will be included in RC.2 but you can update it manualy - just replace your local mojo.html5.webgl.js file by version from the repo. |
| ||
| Mungo Impress v1.0.0-rc.2 is out! This release contains bugfixes and small improvements. |
| ||
| I'm super looking forward to seeing how you handle pixel shaders with that Harmony module. |
| ||
| Small update about Harmony module development: http://blog.mungo.io/harmony-wip-update/ |
| ||
| Looking good :) |
| ||
| Reads good |
| ||
| Nice! I'd love to be able to play with shaders in Monkey. |
| ||
| Looks cool. Could you post the code for the shader example? |
| ||
| That looks awesome! |
| ||
| Looks cool. Could you post the code for the shader example? Slightly cleaned up copy of a working code: Import harmony.frontend.mojo
Class HarmonyApp Extends App
Field vertexBuffer:VertexBuffer
Field program:ShaderProgram
Method OnCreate()
SetUpdateRate(60)
program = LoadShaderProgram("plasma")
If Not program.IsCompiled() EndApp()
program.Bind()
program.SetUniformf("uProjection", DeviceWidth() / 2.0, DeviceHeight() / 2.0)
vertexBuffer = New VertexBuffer(4, 6, ["aVertexPosition"], [VERTEX_ATTR_FLOAT2])
vertexBuffer.SetVertices([0.0, 0.0, Float(DeviceWidth()), 0.0, Float(DeviceWidth()), Float(DeviceHeight()), 0.0, Float(DeviceHeight())])
vertexBuffer.SetIndices([0, 1, 2, 0, 2, 3])
vertexBuffer.Bind(program)
End
Method OnRender()
program.SetUniformf("uTime", Millisecs() / 500.0)
program.SetUniformf("uScale", 0.025, 0.025)
Cls 0, 0, 128
DrawArrays(DRAW_MODE_TRIANGLES, 0, 6)
End
End
Function Main()
New HarmonyApp()
EndIn the next blog post I’ll provide more info about API. |
| ||
| not as integrated or mojo-like as I would've hoped. It sounds like you have to draw triangles directly? Maybe it's just because the mojo bits aren't added yet? I was hoping we could bind shader programs to an image and have harmony automatically blit the surface, or have a single command to bind a shader to the global output buffer, but maybe I'm just thinking of it the wrong way. |
| ||
| Yep, mojo frontend isn’t ready yet. Actually you won’t need to use low level API. In mojo frontend this stuff will be wrapped in mojo-like functions. |
| ||
| How is it progressing? |
| ||
| Sorry for delay. Here is a short update post BTW. v1.0.0 is released! |
| ||
| Just to let you know, Mungo is not portable. It needs to have OpenAL installed on a system. Vanilla Monkey doesn't need that. |
| ||
| Well, if you refer to the desktop target, vanilla Monkey needs this installed as well, or it will silently crash as soon as you want to play a sound. ;) edit: Ok, I think in the newer versions the openal.dll is just distributed along the desktop target. |
| ||
| Well, if you refer to the desktop target, vanilla Monkey needs this installed as well, or it will silently crash as soon as you want to play a sound. I am using v79d here on a memory stick. Works out of the box and this machine definitely doesn't have OpenAL installed. The DLL is not inside the Monkey folder also! I think it is a dependency either from Mungo or Jentos which he bundles instead of Ted. I get the error message when I want to start Mungo. |
| ||
| Just to let you know, Mungo is not portable. It needs to have OpenAL installed on a system. Hi Mike, Thanks for report! Will be fixed in the next vesion |
| ||
| Is Harmony already available? |
| ||
| Unfortunately no. Current version of Harmony is rough and very unstable, so there is no sense to make it public at the moment. I don’t want to declare any date, but I think it won’t be ready as a public stuff till December |
| ||
| Ok cool. I was thinking that it was as 2dark seems to use it. i am looking forward to it. |
| ||
| Hey Arthur, what are your plans with Mungo/Harmony regarding supporting it, commercializing it and so on? I see you have no forum for it where a community could build up around it. If you would rather talk privately about it, contact me at monkey@... cheers Michael |
| ||
| As off yesterday, i am working with Arthur on parts of Mungo. He has done a great job so far and i can't wait till we can show everyone. |
| ||
| Cool. You two are not your average coders. Your skills excel especially at keeping large projects organized and maintained. Logic with reasoning is key to programming well and efficiently and delivering complete games/applications etc. Its like a personality; Logic and reasoning. We are all capable of eliciting generally accepted reasoning by applying how we define our logic to it. Some people cast logic, in programming, to their reasoning systems with the intention of getting back, when the Eureka moment allows, an efficient reasonable bluprint/answer to a current problem that needs solving. When both the Logic and Reasoning systems gel together harmoniously we get programmers like you two. When the Logic and Reasoning systems are even slightly misaligned, you get, again when the Eureka moment allows, programmers who struggle a little. The disaster is when your Logic casts to your Reasoning systems a question where the answer expected back is either a solution to a programming bug or just about a solution to it but instead you get back a recipe on how to make banana flavored ham. I don't suffer that at all...........cough.......anyway......... In brief, you two putting your programming heads together equals, when finished, something that will kick ass. Programming/Framework wise that is and not anything to do with bank managers...........err, I'm gonna stop typing now and hit reply. |
| ||
| I am sorry for bringing back an old thread but I would like to know the status of mungo. Its been over a year since I read the last update so I am wondering if this is still alive? |
   |