Mark. how close are we to being complete
Monkey Forums/Monkey Programming/Mark. how close are we to being complete
| ||
| I want to ask this question before I ask my next as the answer to this might nullify my next question. So as Mojo targets all platforms almost equally with the exception of the OS module, I want to know just how much more can be added to mojo so that its complete and nothing more can be added that can be supported on all platforms. Has to be getting close I think ? |
| ||
| Definitely need game multiplayer networking as part of mojo before you could count it as being "complete". |
| ||
| All official targets need to be able to support HTTP POST/GET requests. |
| ||
| What I am wondering really, is if Mark is going to, once Mojo is sorta done, start working on more target specific updates that start to fill in the stuff that specific platforms are missing. I had a thought, that if and when mark gets to this stage, what he could do is compile the targets into groups with the most similarities in terms of what they can do, and then treat them like he does mojo now, and give them updates that all in that group can use. assuming that for a second html5 and flash are very close, those could be grouped, xna,glfw,metro could probably all be grouped, android, and ios could be grouped. he would probably have to compile a list, that compare's each platform to find the ones that deserve to be grouped with each other. |
| ||
| All official targets need to be able to support HTTP POST/GET requests. Yes definitely. |
| ||
| Whats complete? Mark could aways add new features to Mojo and Monkey... When Monkey was first released it didnt have interfaces, reflection or exceptions, it does now. And if Mark wanted to he could add even more features. I don't think Mark will be added specific features to each platform as it kindof defeats the purpose of Monkey. (BTW I feel terrible, been at the hospital all night and found out I've got gallstones :() |
| ||
| @therevills Aw man, sorry to hear that. My mum and sister had them (and had gallbladder removed) and said it was really horrible and agonising having gallstones. I recently passed a kidney stone and that was extreme, so I sympathise. Get well soon! |
| ||
| it may be more prurient that mojo sticks to doing the basic sorts of tasks it does now, and to have networking be its own standard library. The tricky thing about including all of that stuff standard is that the further away you get from the most basic of functions, the harder it is to keep them up with the times. Rather than depreciate parts of mojo or all of mojo in the future, it would be easy, for example, to depreciate a networking library if it later ends up being that the paradigm for the library is too confusing or wacky, or is made obsolete by a newer, more streamlined paradigm, library, or whatever. Mojo itself is supposed to be there to give you the boilerplate code to get a simple game running; images, sounds, input, and basic I/O. I'd be lying if I didn't want more stuff in there to help make a game, like per-pixel collision routines, more containers, simple objects like vectors and the like, but all of that stuff adds to the complexity of the lib. Take Diddy for example; why not add all of this extra stuff to it? There's certainly a case to be made for it, though the more stuff the lib gets thrown on top, the more cumbersome the library is to keep up to date. |
| ||
| it may be more prurient that mojo sticks to doing the basic sorts of tasks it does now I think you mean "prudent". Prurient means having an excessive focus on sex. Is mojo complete? It depends what you think it's meant to do. At the moment it doesn't include anything to do with networking but there's equally no real argument for saying that it should. What does "networking" support mean anyway? It's a pretty broad area. Is there an example of a library in another language that would be considered to offer complete networking support? In terms of some features not being available on some platforms, that's already true. See ChannelState, for example. In the long run it seems more sensible to figure out how to make such variations easier to handle rather than fixate on not providing anything that can't be supported on every single possible platform. |
| ||
| @muddy_shoes: I think you mean "prudent". Prurient means having an excessive focus on sex. ....you learn a new word every day. ;) |
| ||
| I think Monkey if a more important focus than mojo atm, however mojo is the module that sells :) Making it easier to add new targets, make new targets more modular and easy to share, make it easier to modify targets, make it easier to write target-specific modules and make it easier to extend Monkey and Monkey modules (like mojo) is probably more worth to the community long-term. |
| ||
| not that I will ever write a target but yeah that would really help those who do, as for my idea of creating new group/target specific modules like their own little mojo's I think that covers the bloated code and things getting messy for maintenance really nicely. By splitting them into small groups, it will make each group a lot easier to manage and upkeep, keeping them all as part of mojo would make it a lot harder specifically when he starts to add things only some targets can do and others cant. I can see a day when we import mojo, and then something like mojo_xna for the xna specific stuff that mojo does not cover. at least thats what I hope he's working toward. |
| ||
| Im taking the side that MOJO needs some loving too. There are a few peeps on here that have "hacked" mojo to get it todo what "we" all want it todo, they then told they cant share their work. Which is fair enough but then we hear that mojo isnt being updated officially. StuC |
| ||
| wait mojo is NOT being updated? |
| ||
| I can see a day when we import mojo, and then something like mojo_xna for the xna specific stuff that mojo does not cover. I totally agree, with the only difference that I think is more probable that mojo_xna will be made by someone in the community, not by Mark. Since I would guess there will never be an official *mojo_xna* module, unless Mark hires more programmers to the dev team, or make such project a community project. Right now people hack mojo, we build our own Monkey trans, we build our own target languages to fix certain things. This is possible because monkey is open - which is beyond awesome. However what would be even more awesome would be if those additions could be shared with others. So that someone actually could do a mojo_xna that others could import, update and use easily. |
| ||
| Tibit, that's only a valid point if the majority of the community are fluent in all target languages, I know I am not, it's the reason I paid for monkey because I dont want to have to learn java. So I really hope your wrong, I really hope that mark gets mojo to a stable state and then starts working on the finer points for each target. Look at blitzmax, whats that now 10 years old, unless you think Mark will get mojo stable and updated and then sit back for 7 or 8 years releasing the odd mojo update. GOD I HOPE NOT!. |
| ||
| Mojo not being updated is more of an observation and reading between the lines :( Ive held off about hacking Mojo for 1) not having time 2) not having a clue about some of the targets 3) in hope mojo is updated by others :) Saying that there isn't much in Mojo that personally I'm missing :) The main thing for me is writing to textures/ creating textures. Mark has previously said it ain't going to happen.... I don't want to seem I'm moaning - monkey is a joy to program with Stu |
| ||
| Another shout for POST/GET! |
| ||
| Hi, > Which is fair enough but then we hear that mojo isnt being updated officially. Who told you this? > Mojo not being updated is more of an observation and reading between the lines :( Oh, OK, no one! Anyway... Mojo is still under active development, but I've been busy with other stuff lately and will be for a wee while yet. My goal is still to keep Mojo as target neutral as possible though, although I do have some ideas for how to make it more 3rd party extensible. Stuff like POST/GET, sockets etc will eventually happen, but they'll probably go somewhere else, probably a new 'net' type module. Mojo is primarily concerned with being a lightweight app framework and I think it should stay that way. |
| ||
| I think you mean "prudent". Prurient means having an excessive focus on sex. Hahaha, oh man. My gutter brains at work. Thanks muddy, I should've caught that one sooner. |
| ||
| Mark. Stuff like POST/GET, sockets etc will eventually happen, but they'll probably go somewhere else, probably a new 'net' type module. Mojo is primarily concerned with being a lightweight app framework and I think it should stay that way. Is MUSIC to my ear's , can we be safe in assuming that net is not the only new module we can look forward to ? Don't really care how long it takes, just knowing you have it planned is good enough for me. I really hate messing with the core files and would rather have official support for stuff than having to mess with it. |
| ||
| I'm still hoping for off-screen surfaces. That's the one killer feature that (in my opinion) is holding Monkey back for me. It's been done by various people for all targets by hacking mojo, but obviously they can't release it. The point is, it can be done. It may not have been possible when Monkey was first released, but the various target platforms all seem to support it now. |
| ||
| It's great the hear from the man himself (Mr Sibly), I wish people would stop speculating and spreading rumours. Monkey is a great product, I wish I had more time to work on my apps with monkey, hopefully that will change in the future. It's great that POST/GET and sockets will eventually happen, can't wait for that. I also agree that mojo should stay as lightweight as possible. anyway, let the man work. [ Inappropriate comment - removed by TeaBoy himself :) ] |
| ||
| not sure I would call the mans FANS life blood suckers, we support his business by buying ALL of his products, if anything we ARE his life blood, keeping him in food, and a home. PS. I'v been a massive fan of Mark's work since Blitz3D's release and I say with PRIDE that I have not looked seriously at another language since. |
| ||
| Yeah, fair enough, I apologise for any misunderstanding. I mean the individuals who attempt to spread rumours that have no factual evidence, so perhaps I used the wrong wording, so again, I apologise. |
| ||
| Tibit, that's only a valid point if the majority of the community are fluent in all target languages I assume I did not get my message across the way I intended. The way I see it is that if people could share changes and additions, then no one would need to know more than one target language. Why would you need to know XNA to use someone else's XNA module? Or know java to use a Android networking module? I dont want to have to learn java. I never meant to apply that you or anyone else would have to learn a target language at all. But I did apply that atleast one person in the world (except Mark) might need to know a target language to develop a module for it that the rest can use. So I really hope your wrong, I really hope that mark gets mojo to a stable state and then starts working on the finer points for each target. I'm not sure why you want me to be wrong. But assume Mark does do a mojo_xna module, and someone in the community does too. And assume also the community module is better because more time was put into it, then why not use the community module? I see community extensions as a good thing, and I think it is important that they have a low barrier of entry both for creation, sharing & use.While I can only speak for myself, my intention is to find solutions that is for good of everyone in the whole community, otherwise I would not put any time into talking about it. I'm definitely a Mark fan too. BlitzBasic became my native language, my mother tongue, the first programming language I learnt. |
| ||
| Stuff like POST/GET, sockets etc will eventually happen, *does the moonwalk* then *does the splits* |
| ||
| I'm not sure why you want me to be wrong. But assume Mark does do a mojo_xna module, and someone in the community does too. And assume also the community module is better because more time was put into it, then why not use the community module? I see community extensions as a good thing, and I think it is important that they have a low barrier of entry both for creation, sharing & use. I would use the xna module from mark, because it comes with official support, bug fixes and updates, thats my choice, I do not want to go hacking mojo or trans to add an unofficial target, but do not mistake me and think that means I dont want them it simply means I want them made official, or for mark to make a way to plug targets into trans easier so its not the hack that it is right now. As for Community extensions, even though you quoted me you missed the fact that I never mentioned community extensions, I said I hope your wrong about mark, community additions, be they modules, targets , code snippets , projects they all advance the community, and thats something I can and have and always will get behind. I use diddy, I use the community CE ide for max, and over the years have started and taken part in community driven projects, so please dont think I want that to change in anyway, because I dont, I simply want mark to keep working on monkey, mojo and future updates, and I would love one of those updates to be an easier way to plug targets into trans without requiring us to hack the code. forum posting can be annoying at times its to easy to misunderstand each other. anyway. glad mark is planning new modules, so I am happy :) |
| ||
| Yeah I agree :) |
| ||
| it's good news to hear Mark! Personally can't wait for being able to write to textures ....... it's a killer using workarounds stuc |
| ||
| I already completed all targets CreateSurface and writepixel/getpixel and native TTF support code, but need hack lots of mojo's code (gxtkSurface class) and new target template. I do not know how to share my works, because the monkey is for sell, so I can't upload all code to googlecode, that is a problem. |
| ||
| @hsutuo Can you send it to Mark? With a bit of luck he can take a look at it, test it and then maybe add it officially? I guess that a lot of the time (like in this case) the problem lies not so much in monkey, but more in how to share an extension or modification of Mojo. |
| ||
| @hsutuo, can you not post a description of your changes to mojo (so you're not releasing a modified mojo, you're just describing the changes that a user would need to make), and then release all non-mojo code as a module? |
| ||
| you can probably distribute the changes as a patch file using diff, as long as the diff file can't be compiled as-is :v |
| ||
| A hidden forum that can only be seen by license holders could be a good place to post changes to Mojo. |
| ||
| As I understand it, the licence protects Marks code, not the code we write as we hack extra stuff into mojo. So we should be able to use the PHPBB system for adding new features. for anyone not familiar with it, it kind works like this. Open : SomeFile.h Find [monkeycode] 10 Print "Hello" + World 20 goto 10 [/monkeycode] Add After [monkeycode] 30 some new code [/monkeycode] with phpbb3 you have AddAfter AddBefore or Replace Simple Instructions followed simply, when it comes to Mojo and given its mark and not a massive team, you could change it to Goto Line Number, and then add after, add before or replace. Using this system does not expose ANY mojo code, and gives people an easy method step by step for adding new features. Its not ideal but it will allow for you to post your patch publicly because your not showing mojo code your only showing your own, your only referencing line numbers of mojo and im sure mark wont mind line numbers. |
| ||
| Unfortunately diffs don't resolve the problem of derived code. If it was easy to add major features like off-screen rendering without including such code I'm sure we'd have seen it already. Even if we have a BRL blessed area for sharing this sort of thing we're still left with the problem of mixing additions as well as keeping up-to-date with Monkey updates. It's a pain for me to do this for my own stuff never mind doing it for other people's code or fielding questions from the community at large about how to merge Monkey v67 with tweaks A, B, N and Z or whatever. It's certainly possible to create Monkey "Plus" feature bundles, but someone would have to be willing to maintain them. |
| ||
| yeah I agree its no where near an ideal solution and its the main reason I personally have not and will not install any mojo hacks. |
| ||
| What possibilities are there for making mojo more hackable? muddy_shoes, what needs to be possible in mojo for you to be able to easily share your changes? Some kind of "extension methods" or "friend classes"? So that one could write a method as-if it is part of the mojo core but it is still located in a file of it's own - and need to be imported to be used, or for that method/class/function to overload/override existing ones. What ideas do you guys have? I'm sure someone here can come up with some brilliant solutions that are doable, at least on Mark's side of things in the future when he works on mojo hackability. Handy Features for Extending Modules (not only mojo) * Replace Method in class from external file (replace method) * Add Method/Field/Global/Function to Class in external file (extention method - need to be imported before the target file in question) * Add extends/implements to class in external file (used to make module compatible with an interface of your own) * Target platform specific extendability - Should be made possible by the extension methods/replace methods Such hacks needs to be updated each time the interface to the module/file they operate on are changed - however should be an easy fix. And even those, like muddy_shoes that hack their own mojo will probably have an easier time at updates, and the code will be sharable. Actually such system could easily be created on the IDE side of things instead of being part of the Monkey language, quite similar to a batch file, only a bit smarter. |
| ||
| I don't believe that there are changes that would make mojo amenable to some of the additions we're talking about. Mojo is a high-level interface and if you want to make low level changes there's an inevitable need to mess with the internals. Off-screen rendering is an example where deep changes are unavoidable. My stuff pretty much takes mojo's graphics classes and allows you to create multiple render buffers that offer mojo's rendering api plus the ability to render buffers to buffers, e.g.: [monkeycode] 'create new buffer Local buffer:RenderBuffer = New OffScreenRenderBuffer(200, 200) buffer.BeginRender() buffer.Cls(64,64,255) buffer.SetColor(255,45,45) buffer.DrawRect(20,20,30,50) buffer.SetColor(255,255,255) typeface.DrawText(buffer,"Test Text",10,10) buffer.EndRender() 'draw buffer to screen buffer.DrawToScreen(0, 0, 50, 50, buffer.Width, buffer.Height) Local secondbuffer:RenderBuffer = New OffScreenRenderBuffer(200, 200) 'draw buffer to second buffer secondbuffer.DrawRenderBuffer(buffer, 0, 0, 10, 10, buffer.Width, buffer.Height) [/monkeycode] It's difficult to see how mojo could support that via a plugin system or similar as it is completely changing the way it works currently. Exposing some of those internals would avoid a bit of the merging work but wouldn't be desirable in general. At the moment Mark can legitimately change anything behind the interface and it's tough cheese if any of us have messed with it. If he makes it public then he's locked into maintaining those internals as is to a certain extent. |
   |