Fundamental problems with Monkey (As of V71)
Monkey Archive Forums/Monkey Discussion/Fundamental problems with Monkey (As of V71)
| ||
| For those who want it, I've reimplemented the GLFW window/screen-mode changing for V70e+, you can find it here. SKN3 has also rewritten his old code, which you can find here. Mark, if you end up reading this, please take this into consideration. Monkey and Mojo are basically standing still (When it comes to realistic development), because they don't have a stable and fully functional foundation behind them. I've been using Monkey for about six months now, and honestly, I both love and hate it. I love it because: It generally produces accurate source code, It gives me easy access to the main technologies I need for creating games, And Monkey's essentially BlitzMax with more language related features. However, for a long while now, Monkey has seemed unfocused to me. Some things that I think should be community driven aren't, and some things that I think should be left to Mark are done by the community. These days Monkey's pretty huge in terms of source code, and with pretty much one guy handling it, that's got to be a challenging task. However, that doesn't change the fact that Monkey has a ton of issues. These range from horrible development 'prioritization' to features we still don't have, but should have had months ago. GLFW has been neglected for a while (Until V71 at least, but those features aren't 100% necessary), and it still doesn't have the features it desperately needs. We're just now getting basic socket support, but we STILL need an official method to change the screen-mode. Mark, stop storing things in the "CONFIG.MONKEY" file; when it comes to GLFW and XNA(Windows), that should only be used when absolutely necessary, or for actual preprocessor stuff. The desktop version of my game should not have its resolution set in stone, that's the stupidest thing I've ever heard! My game should set the resolution similarly to the way Blitz 3D & Max did. Having the resolution handled by the preprocessor just feels wrong for desktop targets. I payed for Monkey, I shouldn't have to do a bunch of editing and managing, just to have basic features that should be there already. Having to edit code constantly isn't the answer; especially when all we want is a basic feature that we could write ourselves, but then would need to update somewhat regularly. Sure, Git fixes this to some extent, but this shouldn't be on us. Even if you think it should be our job, something like screen-mode/resolution changing could be a big change, and I don't think that should be our job entirely. On another note, if Monkey's supposed to be as mobile-friendly as advertised, why do we still have dozens of small bugs? Not being able to properly close the on-screen keyboard being one of many (Which should be handled by the user using an optional argument). It's not like we haven't brought these issues up before, so what's the deal with that? I love Monkey, but Mark really needs to get the smaller and older issues dealt with; especially before we get even more major features like sockets. (Which adds to the pile of bugs) Other than its overall image, I don't think many people use Monkey because it's just so unpolished. (Unlike the Blitz languages) Realistically working with Monkey isn't user friendly on all of its targets, only some of them. Though I love the "Extern" functionality in Monkey, making it practically necessary on half the targets is not the answer. I admit, Monkey's "Extern" system opened my eyes to the C languages, and now I love C++. And I'm not talking about higher level functionality (std::string, automatic memory management, garbage collection, etc), I'm mainly talking about pointers, and managing memory myself. (Something I had mixed feelings about with BlitzBasic) For me, if I'm using a high level language, Monkey's generally the answer, and C++ fills most of the gaps. I've tried C# and Java, but I'm against Microsoft's ideals, and Java just runs terribly on Windows; plus, you never have any control. This is why I'd love to have the best of both worlds (GLFW and STDCPP), without having serious issues about the target(s). |
| ||
| GLFW has been neglected for a while the GLFW target is dependent on GLFW3 being released, which was yesterday! hooray! http://www.glfw.org/ |
| ||
| the change resolution and window/fullscreen issues are very important for who want to publish his casual games on BFG or other portals. i am still suing blitzmax for desktop games because of that :) |
| ||
| Raul: The change-resolution and window/fullscreen issues are very important for those who want to publish their casual games on BFG, or other portals. I'm still using BlitzMax for desktop games because of that. :) Sure, BlitzMax is nice for desktop applications, but I'd rather stick with native C++. Plus, BlitzMax would add $80 onto the price for newcomers who want to make native PC games. And switching to it completely would stop your game from running on non-desktop platforms (Android, iOS, Xbox 360, etc). I've already ported my game from BlitzMax to Monkey, I'm not porting it back. Even if I end up going to MonkeyMax temporarily, the fact that I have to consider it as an option (Just for some basic features) really sucks. And if I end up doing that, I'd have to rewrite/replace most of my external code. |
| ||
| AdamRedwoods: The GLFW target is dependent on GLFW3 being released, which was yesterday! Hooray! I guess my timing with this post was really spot-on. I'll cross my fingers and hope that Mark will make a new/modified GLFW/GLFW3 target. If we don't end up getting a new/modified GLFW target, then we'll need some serious bug fixes and features to be added. (Resolution changing being one of many) |
| ||
| Hrrm, Monkey is already too cheap. The original price point of $120 was better, but $180 would be fine also. Up the price, and if BlitzMax can give a better performance on PC, make a translator and include it for free. |
| ||
| I wouldn't go that far, $120 I could see, but $180? I'd rather just use the languages it converts to at that point. I think Monkey (When we get these issues sorted out) should be worth about $20-40 more than BlitzMax's current price ($80), so $100-120 would be fine. |
| ||
| I agree that it would be nice to get some desktop attention, but you can't ignore the fact that Mark is adding stuff that the community wants. We just got a module manager and sockets recently!? Now that glfw3 is out woooo! it makes more sense for monkey to utilize their hard work instead of Mark having to hack in a ton of functionality on top of it. It wasn't all that difficult to hack in screen resolution changing (albeit hacky) so with enough determination and reading/experimenting you could probably do the same? I would revisit my glfw code snippet but unfortunately I have to pay the bills so cant just keep doing free things. |
| ||
| I would like to see a big-ass monumental push to get desktop targets up to spec. As it stands, Monkey falls way short of what Blitzmax is capable of. (Not to belittle everything Mark has done with Monkey, because doing something on this scale is an epic challenge for a team, let alone a single Kiwi - just feels like desktop targets are more of an afterthought) |
| ||
| MonkeyMax IS a very good option for this. Need any additional Max API? Extern it and you're done! (no need to change the generated code). |
| ||
| SKN3: I agree that it would be nice to get some desktop attention, but you can't ignore the fact that Mark is adding stuff that the community wants. We just got a module manager and sockets recently!? Now that glfw3 is out woooo! it makes more sense for monkey to utilize their hard work instead of Mark having to hack in a ton of functionality on top of it. It wasn't all that difficult to hack in screen resolution changing (albeit hacky) so with enough determination and reading/experimenting you could probably do the same? I would revisit my glfw code snippet but unfortunately I have to pay the bills so cant just keep doing free things. I didn't realize GLFW3 was out and stable when I made my first post, so I'd say moving to that would be a far better option. As for changing the resolution using clever hacks, I've done it a couple of times, but editing targets and using workarounds just feels wrong to me, and it can cause a large number of issues. I'm by no means trying to belittle Mark's work, but I think the community has better ideals for networking. Sure, standardization and collaboration between forum members would be ideal, but a lot of these modules work very similar (Especially ANet and my own module/library). Maybe this is just me loving how much control I get with things like BSD-sockets, and to a lesser extent WinSock, but networking just seems to be a bit too platform-dependent for it to be managed by Mark. That issue of stability and control is why I never thought Mark would do anything past a TCP server class. And on the topic of features like sockets, it doesn't matter what our thoughts are about it being a good addition; the fact of the matter is that we still need existing features to be more stable, and we need smaller features to support the bigger features. (Resolution changing is one of the best examples of this) One thing to note is that the module manager is unnecessary, but still something we've been wanting for a long time, and it's simple. The module manager makes Monkey look better and more manageable, that could definitely help bring in more customers. This isn't at all like sockets, where there are too many dead ends, and far more that could go wrong. Not to mention how the community has been doing an okay job about networking, but a module manager hasn't realistically been built by the community. I'm not ignoring Mark's efforts, and I'm not strictly against them, but stability, structure, and finishing what you're already doing should always go before fancy new features that will cause similar issues. And if the community's saying that Monkey should have unstable sockets over fundamental features, and getting things done, then you've gotten to the point where you need to look at your priorities. Pleasing everyone (Without thinking about things first) is just going to cause more of the same kind of problems. |
| ||
| I have been using Max for years and when I got Monkey I really had some analysis paralysis on which language to use because of things like resolution switching. I am not a high level coder so doing all kinds of hacky external things aren't even really an option for me. Resolution switching needs to be a feature that is built in. We should have all of the features to write a BFG style game out of the box. I have decided to just use Monkey and if I have problems getting the desktop version the way I want then I am going to use MonkeyMax. I love Monkey and have gotten very comfortable with it. I believe what I am working on will work equally well on a desktop or tablet and I don't want to give up that flexibility by using Max. |
| ||
| You say foundations, I say dressed-up feature requests. These things are all very nice, but as far as I'm aware, the main features being added right now are focused on platforms which are expanding, where there's good money to be made, and where there isn't already a niche. I'd imagine that BlitzMax (or Unity) fills the PC niche for now, and while better GLFW support would be nice (I've hacked the target, too, to have features I wanted), the lack of certain features are only "fundamental problems" insomuch that some people would prefer to use Monkey and Monkey alone for PC-game development. Monkey's a multi-platform tool, though, and development priorities should reflect both its original purpose, and its niche. Let's approach these things for what they are -- feature requests. I'll throw in my support towards seeing GLFW3 migration. A GLFW-specific module for things that can't be fully leveraged through preprocessor directives like resolution-changing would be nice too, and perhaps other GL-specific features like access to surface handles / extra blends / shaders / stencil / etc. But to me, I see them all as "could be nice" features which are platform-specific. |
| ||
| Nobuyuki, instead of just saying that they're "dressed up feature requests", how about you actually say why you think that way? Saying that you shouldn't use Monkey isn't a good enough answer. The BlitzMax target is unofficial, not so reliable, and it requires people to pay an extra $80. And using it on its own would remove portability. As for Unity, I hate it, I hate most high-level engines. If you ask me, they just don't understand how game development should work, and they try to spoil you. And expanding the targets? All we've seen lately are things that could cause more problems that'll take forever to be solved (Due to "lack of communication" apparently). Mark needs to hold off on new features for a little bit, so he can actually finish what he started; if that happens, we'll actually have stability, and Monkey will be a lot more of a finished project. You know, stability; where you don't have ridiculous limitations that wouldn't be there if you did it yourself, but you can't because Monkey can change drastically (As it should). At this point, we still have bugs like on-screen keyboards not closing when people want them closed, these things could be fixed by us, but why should we be the people to do it? Mark started it, so he should at least try to iron out the problems. But, I haven't even seen him attempt this. These are fundamental problems, which just keep getting added to a queue when we get more features that haven't been refined/polished. Mark used to be a lot better about this with the Blitz languages, where he implements something, and then tries to actually work with it. Mark's essentially been adding features (And even targets), and ignoring them after. This makes no sense, because you just end up with a backlog of problems. (Which he'll need to look into eventually) The community's been finding bugs and problems with Monkey for a very long time. The fact that we really need to push Mark to even look at them is disappointing. I'm not looking for shader support, that may be something we should handle as a community. I'm just waiting for Mark to actually tackle long running bugs and problems with his project. But these days he seems to have no patience for looking things over. There's no "good money to be made" when you don't listen to people when they tell you about fundamental issues. This is one of many reasons why people don't think Monkey is worth buying; it's way too experimental, even on its "stable" builds. There are so many people who were either turned off by Monkey, or are waiting for it to actually become stable. Well, if you want those people to use Monkey, then you need to fix the problems they have with it. Cubic zirconium isn't diamond, it may look like a diamond at first glance, but it isn't. The difference here is that Monkey can actually be a diamond with the right work put into it. In other words, Monkey needs a lot of work, and Mark isn't working on the right things. The mind set of "If it looks good on the surface, then it's good enough for me." really pisses me off. |
| ||
| Are there so many bugs and problems? Please give examples. Personally I would like to see some changes, in particular I think we really need a Protected access qualifier above all else. But I certainly would not agree that monkey/mojo are bug-ridden. Are on-screen keyboards part of monkey/mojo? I think not. |
| ||
| The problem is not so much about bugs as it is about unfinished functionality, and lack of basic features we've been needing for the longest time. In terms of existing bugs, here's a decent number of them: * GLFW analog support has been buggy for a while. * GLFW doesn't see all of the buttons on some controllers. * XNA's trigger functionality works completely different from GLFW. * XNA has had issues with capping the framerate. (It sometimes sets it to 50 instead of 60) * Mojo has had plenty of performance issues on HTML5. (This isn't really a bug, but I think it's worth noting) * I've had the colors of some images be completely broken and washed out if I use SetColor() with Flash (And sometimes HTML5) * EnableKeyboard doesn't disable when hitting the keyboard close button. I know this is an issue on Android at least. (I think this should be a toggle-able feature) * DrawText has horrible performance on half of the targets (Not really a bug, but worth looking into) * Using HideCursor() with GLFW makes things break, and it thinks your desktop goes on forever. * HideCursor() has similar, but less annoying issues with XNA (Windows). * Clicking anywhere on a GLFW window makes it lock your cursor, so you can't move the window properly. * I've seen some small floating point issues while rendering on some targets. * Sometimes I wonder if GLFW's garbage collector even works. * For some reason when I use MouseHit/TouchHit on mobile devices (Android), it counts as a click, then moves. * DataBuffer.Load() has been known to have issues with files around 2KB for me. * Filtered mode on some of the targets can screw up entirely. * Some devices can't change the orientation to be upside-down portrait. (This one isn't such a big deal) * Just about anything in the bug reports section that hasn't been answered. And then there's the features we really can't live without, but there aren't too many of those, just enough to be worth noting. These are by no means all of them, but here's a decent few: * Resolution/Screen-mode changing (Desktop targets mainly) * We still don't have a simple way to make our own image loaders (Without doing it from scratch, or having to maintain it constantly) And if we do, I certainly haven't heard about it. * Simple shader support, but I honestly think we should handle that. * Support for Millisecs() in the OS module for STDCPP (Which I have done, and it takes two seconds to add) * Bluetooth controller support for Android and/or iOS (Not sure if this is available yet.) * A better way to debug Android programs. (Not exactly necessary, but useful) * Multi-platform sockets. This is something I think the community should do. And technically we already have them via PushButton. But come on guys, do you hate UDP that much? My library and ANet are the only unofficial UDP-capable libraries/modules for Monkey. * An optional console like what BlitzMax did with "GUI build". * An 'inlining' pass for Monkey itself before 'Trans' compiles/converts everything. * Some kind of proper pointer access. (I know this isn't going to happen, but a guy can dream, right?) * A proper GUI library, so Ted can be done completely via Monkey. (I doubt this will happen, and I honestly wouldn't want it for a while, but Mark is trying to move a lot of his old code to Monkey.) * Supposedly there were some Windows 8 multi-touch issues, but I'm not sure if Mark fixed them yet. * The ability to properly disable V-SYNC on most of the targets. * Better documentation about threads with Monkey (Especially with how it works under the hood). * Other kinds of integer data types. (Byte, Short, Long) This may be possible with a bit of work. (For example, you could use bitwise AND for capping smaller integers on targets that don't support them natively) * The ability to make integers unsigned. * We need Sleep/Delay to be added to the OS module, or even Mojo. C# has this functionality as well, and it can be done via System.Threading.Thread.Sleep(MS), I've added this to my own projects before. * A few things here and there that I've heard about on the forums. * And of course, GLFW3 support just got added to the backlog. Half of these are feature requests, however, they are relatively basic. Most of these are crucial for Monkey games to be realistically developed. Unlike something like sockets, where it's more of an afterthought. |
| ||
| There was a guy who made a game in qbasic. Black Annex. Check it out. If somebody is hating unity to me that tells quite a bit... :) In a way I understand you. To me it feels like Monkey does many things well for you but you are frustrated (?) Because the way its developed. My suggestion: use whats available and stick to that. Develop games that dont rely on Monkey being developed... use bmax for desktop. Rethink if you really want mokey to do everything. Currently it doesnt. Focus is more on mobile side. |
| ||
| I'm not so much frustrated as I am disappointed. Monkey has needed a lot of things, and jumping to new features instead of looking at the problems is not the answer. Monkey is marketed as a cross-platform development tool, and I expect Mark to hold up his end of the bargain. Ignoring GLFW, and forcing people to use an unofficial target like MonkeyMax (BlitzMax) is just a bad thing, and you can't deny that. And by the way, if Monkey is really as mobile-oriented as some people say, why is GLFW the only target with a decent debugger? Sure, I'll say this, it's generally modeled after a lot of mobile oriented code, but if Mark works on GLFW, it could easily hold its own as a desktop development tool. In conclusion, read some of my other posts if you're going to reply to me, because it looks like you didn't. People gave me responses, and some even asked for a response, so I gave them responses; that itself doesn't make me mad at all, but I'm not exactly happy with Mark's methods. And how is being mad even a bad thing? Venting anger tends to be really healthy for people, and I'm no exception. As for the whole Unity thing, I dislike it for a large number of reasons, but getting into that would mean a new topic, and I just can't be bothered. And I'd say you'd dislike Unity about as much as I do if you fell in love with the capabilities of lower-level languages. |
| ||
| seeing this list, have you tried Haxe + NME? http://www.nme.io/ I'm not exactly happy with Mark's methods we all have had our rants somewhere here. in the end, it's one person trying to support an extremely large product. i think he reigns in his ambition in order to keep up support. supporting a project for over a year, two years, is not easy. |
| ||
| Some of the features you have requested to replace missing functionality (perhaps things someone coming from blitzmax would expect?) go against the multiplatform philosophy that monkey has adopted early on and would be better implemented when the language is in a more mature phase. This could also be said about some of the features added to the mobile platform, but mobile is where Monkey has found its niche -- not XNA or GLFW. Several of your feature requests would only be able to be incorporated consistently on a single target, like glfw, or would require a serious undertaking that would take away precious time better served fixing bugs or improving the multiplatform functionality. If you insisted, I'm sure I could pick through the list one-by-one to elaborate on this. Furthermore, things like floating-point roundoff error are left undefined by monkey and are implemented by the target -- that, much of Monkey's "lack of functionality" on desktop, etc. are some of the side-effects of cross-platform compiling, and come with the territory if one is to maintain a consistent standard library. This is especially true for languages hoping to avoid the mess that is C/C++ standard includes by the time it reaches maturity. To answer your question about GLFW debugging -- this was simply the most convenient target to add debugging. Development takes place on the desktop, so it would make sense that debugging can be achieved the easiest there. Debugging is still pretty good on mobile, especially Android, where developers have access to DDMS and can use it to retrieve debug messages and profile memory usage. The way I see it, Mark's priorities when adding features to Monkey appear to first go towards functionality that can be applied to (nearly) all targets, and then after that towards functionality which would monetize projects quickest for the majority of Monkey's core userbase. I can't speak for him, though, so this is only a presumption. There's no reason you can't use the right tool for the job if you don't think Monkey's that tool, though. |
| ||
| If mark (or someone else) can create a fully functional GLFW or DirectX target for monkey, that does things pretty much as BlitzMax does where you can set resolution at run time, switch to windowed/full screen, access the OS API to find out where files should be saved and read / write files to there then I think monkey would be the perfect choice for mobile, web AND desktop. As it is right now it's perfect for mobile and web but BlitzMax is the best choice for desktop apps. At the moment I am writing a game in monke and BlitzMax at the same time because I want the desktop version to be 'Casual Portal Ready' Luckily the logic code between both versions is pretty identical, but monkey does a lot of things much nicer than BlitzMax does, it would be great to use monkey for everything. |
| ||
| Mark Sibly is trying to do to much at the same time.Finish one target,then the next,so on,so on. |
| ||
| I can't say I agree with the idea that desktop resolution and window handling is legitimately ignored because it's not a multi-platform thing. To support a target you need to support the expected basic features regardless of whether they are common to all. This is why, for example, we have joypad, physical keyboard and touch support even though any one of them may not be present on a given target. Resolution switching and windowed mode are expected basics in desktop games. What most of these threads have in common is that everyone has to speculate if a feature is in progress, on a todo list, in a "never" bin or is even something that Mark has considered. There's no visible roadmap, priority list or even a stated philosophy to refer to. In the past Mark has brushed off feature requests as low priority and then turned around and implemented them shortly after (you have to imagine that these things magically move from low to high value when he works out how to do them). If there was a publicly visible feature request tracker to refer to people would at least be able to see that a given desire was represented. Votes could be cast, priorities and intended delivery cycles presented, discussions about merit and implementation details organised usefully. Perhaps it might serve to reduce angst from those waiting for Monkey to support something they need and avoid these sorts of threads popping up on a regular basis. |
| ||
| one can create milestones and post bugs on monkey's github. |
| ||
| +1 on muddy_shoes' post. Some sort of officially-sanctioned thing like this would make me feel a lot more connected to the pulse of this very-much alive language. |
| ||
| +1 for muddy, have to agree having a feature request, and tracking page would be mint. would also give people a little feeling of future security when they see their missing feature on a list , at least they know it should be looked at in time. |
| ||
| It would could be very easily adopted in the API design if we add: SupportedResolutions() Which could return just the one actual resolution on phones and tablets, and a list of available resolutions and pixel depth on desktop Then SetResolution (or the like) could be added based on the result of SupportedResolutions. This could make the thing work on devices with an arbitrary number of resolutions, then it could use the appropriate internal BlitzMax APIs in MonkeyMax, and also, if resolution changes is anytime adopted on GLFW, it could be added there too. Just my two cents. I suppose this is quite obvious, but it could work in a cross-device basis. |
| ||
| "you have to imagine that these things magically move from low to high value when he works out how to do them". Maybe he works on the basis of desirability divided by difficulty! So when he figures out how to do something the desirability doesn't increase, but the D/D ratio does. |
| ||
| +1 as well mainly because the mode switching and fullscreen to window switch is a requirement for any game released on portals, if you dont have that option quite often it will get rejected. Desktop stuff this is a must and will bring the whole thing nicely in line with blitzmax, being able to set resolution and flicking to and from fullscreen using code would be a godsend :) I am looking at monkey for another title im working on and it would be a nice feature, at the moment I dont need it but when the game is complete I would like it in there :D |
| ||
| +1 for windows/fullscreen and resolution controls. I've just started considering this now and it really is a necessity for desktop/laptop targeted dev |
| ||
| Please go here :) http://www.monkeycoder.co.nz/Community/posts.php?topic=5448 GLFW screen mode changing :D |
| ||
| Alternative solution: http://www.monkeycoder.co.nz/Community/posts.php?topic=5439 After you install check out the banana screenmode.monkey. The nice thing about this target it has a software renderer, so the compatibility with old machines should be really good. |
| ||
| For those who want it, I've also reimplemented the GLFW window/screen-mode changing for V70e+, you can find it here. |
| ||
| Yeah there are third party solutions but it would be nice to have an official one as well that is added to the monkey download :-) |
| ||
| I keep reading that MonkeyMax is the solution to many desktop problems. If it's the case, then why stopping updating BlitzMax ? The BM community is asking for a few things which could ensure its future for a few more years. Personally, I don't care cause I found a free replacement solution that is both useful for my project and for my working experience. I just feel sad I don't have that "quick'n'easy alternative" I found at the BM time. |
| ||
| I think the thing is bm is getting dated now, with the lack of updates its got dated. Don't get me wrong its not past it its still very usable but I do think with some adjustments monkey will surpass it. I don't think that monkeymax is an option as always with this its created and supported by a third party, its that its a third party that creates the issue where if they move on the the project gets retired and no longer is available. As an example look at the links for some of the tools on the blitzmax forum some are no longer there. Also some of the code examples aren't there either that are in the code archives. On then whole I do think that monkey can be a good replacement for blitzmax but its not there yet. |
| ||
| that its a third party that creates the issue where if they move on the project gets retired and no longer is available. That's one of the reaons why MonkeyMax was OpenSourced from the start and hosted on a reliable repo (Google isn't going anywhere for a long time). Over the time there has been 6 people (7 if you include Mark himself) from these forums contributed to directly to MonkeyMax and more in threads. IMO Monkey is a long way off BlitzMax for the desktop target... |
| ||
| I didnt know it was a open source thing :) I agree though that monkey's desktop target (glfw) needs serious work to bring it inline with max :) |
| ||
| When I was trying to decide whether to stick with Max or move completely to Monkey I spent some time going back through the Max forums. A lot of examples and threads are years old and have dead links. I agree that Monkey can and should be the answer for everything. Hopefully with the new glfw out we can move it where it needs to be. |
| ||
| Another thing that comes to mind which is a pain for newcomers is that some of the examples in the code archives don't work with the up to date 1.48 version of blitzmax mainly because of the changes that have taken place over the years. I do know this will happen with monkey over the time especially if its out as long as blitzmax but let's hope its fixed more less noticeable. |
| ||
| I would love to see Monkey overcome BlitzMax for Desktop experience. Currently it's a bit messy, goes in every directions and while the essential is there I still miss many extra libs to get things done and enjoyable. I'm looking at it since 2 years now but the version log is mainly about mobile. How many mobile devices do we have to buy until we finally understand that games require buttons :D |
| ||
| For me desktop targets are good and quite handy but atm without it being brought into line its blitzmax that reigns supreme, yeah there are other options code wise to help but its the out of the box monkey that it should be judged on not the out of the box monkey and a million other websites to fix its shortcomings. |
| ||
| What list of features would monkey require for people to consider it inline with blitzmax? (for game creation) This comment from Mark seems positive! http://www.monkeycoder.co.nz/Community/post.php?topic=5448&post=60998 |
| ||
| Question: what about GLFW3? would this fix the screen switching problem? it uses shared contexts, offers undecorated windows, and clipboard pasting. seems it would add a few nice features to the glfw target. |
| ||
| For me its: 1) fullscreen/ windowed switching inside game or app 2) resolution selection inside game or app 3) uniformed media for targets 3 isn't a major biggie but when your whacking out games on all targets why do we need to keep changing formats? Why not PNG for graphics and ogg or some other format for audio? 1 is a MAJOR requirement for portals as they require that be in there if they are to release your game. 2 is a nice to have feature for application or game. Shared contexts are a must if your doing multiscreen editing as well. |
| ||
| As EdzUp[GD] says with the addition of allowing you to get the location of "My Documents" like you can with BlitzMax so you can save the game in the correct location. |
| ||
| It seems 1 and 2 are comming |
| ||
| Yes, 1 and 2 from EdzUp[GD]'s list, and as CyBeRGoth mentions, ability to get the proper "My Documents" directory for Win and OS X, so the operating system will be happy with where you're writing files with your app. And yes, Mark's comment on skn3's thread is encouraging! |
| ||
| What list of features would monkey require for people to consider it inline with blitzmax? * A DirectX target - since I market to the casual market you just need to look on Big Fish Games and most (all?) of the Windows games have DirectX listed. * Switching between full-screen and window * Resolution control * File location control * Capturing window events Maybe more... |
| ||
| Yeah file location control is another biggie, I would like the media formats to be standard across ALL targets though and not the miss mash it is now at the moment its a different format for each target which is a pain tbh |
| ||
| Given that you still need different formats for the HTML5 target alone, I doubt whether 3 is coming any time soon. |
| ||
| That's a pity but not a deal breaker, but 1 and 2 are however. The direct x target is also a issue for some portals, it appears they reject opengl based games on some of them :-\ |
| ||
| Looks like v72a takes on 1 and 2! And maybe the os module can allow us to save to the proper user directories? |
| ||
| Yeah all cool news, as for the single standard for media, that's less on Mark and more on the platforms themselves all having a single format that they all share which at the moment they don't. Would be nice if they all used mp3 and png rather than wav or ogg. |
   |