Experimental v82b now up! [MONKEYNEWS]
Monkey Forums/Monkey Programming/Experimental v82b now up! [MONKEYNEWS]
| ||
| Hi, [edit] v82b now up! See below for latest tweaks... [/edit] Experimental v82a is now available! The main tweak with this version is a change to the preprocessor that means import statements are now processed while a source file is preprocessed, not after. So this code: [code] Import something 'where module something defines #BLAH... #If BLAH #EndIf [code] Will now work as expected. ***** v82b ***** Fixed glfw3 windows/linux gcc builds dumping obj files in same dir. Fixed val decls can have void type. Upped max debugger array elements dumped from 10 to 100. Fixed issue with alias statements confusing/crashing new import handling. ***** v82a ***** Fixed some typos in brl.datastream. Imports now happen while preprocessing, not after. Fixed c++ issue with reflection and recent extends null fixes. Fixed html5 webaudio panning issue - panningModel now set to "equalpower". |
| ||
| This is fantastic, thank you, Mark. The preprocessor works exactly how I wanted it to. Even the test files I made work now. Now I just need to fix up a few of my modules, so there's consistency for the preprocessor checks. EDIT: See below for my detailed post on an issue I found (And unless I'm missing something, I fixed it) with this update to the compiler. My previous comments still apply though, good work, Mark. |
| ||
| Thanks, Mark. |
| ||
| awesome! |
| ||
| Imports now happen while preprocessing, not after. :) |
| ||
| Great, thanks. A note about the defines: I have just tested GLFW_WINDOW_SAMPLES from the earlier version and it works great, just what I needed. It is however very strange to have these kind of options as defines, in a real game the user should of course be able to change them in an options window or an ini file, so the following defines should imho be changed to functions: GLFW_WINDOW_SAMPLES GLFW_WINDOW_WIDTH GLFW_WINDOW_HEIGHT GLFW_WINDOW_FULLSCREEN GLFW_WINDOW_DECORATED If it's to much work to be able to set them at runtime, perhaps we could have a #ENGINE_INI_FILE defined instead and have the options read from that ini file at startup. As it is right now it's impossible to write a real desktop game without shipping a myriad of exe files for different configurations. What every game for desktop need that is missing right now is: - Some defines in an ini file or functions as above. - SetWindowPosition, GLFW_WINDOW_DECORATED is also very commonly used for borderless fullscreen so we need to set the position to 0,0 - SetMousePosition, or MouseDeltaX, for any game where you steer something with the mouse, like an fps camera. - MouseZ, for the scrollwheel. - SetMouseVisible(True/False) I could of course write it myself but I think it would be a good idea to implement the few missing functions needed for a complete desktop solution in the main release. Some functions are very easy to add, here is what I use right now:
static void SetMousePos(int x, int y){
GLFWwindow *window=BBGlfwGame::GlfwGame()->GetGLFWwindow();
if( window ) glfwSetCursorPos(window,x,y);
}
static void SetMouseVisible(bool visible){
GLFWwindow *window=BBGlfwGame::GlfwGame()->GetGLFWwindow();
if( window ) glfwSetInputMode(window, GLFW_CURSOR, visible ? GLFW_CURSOR_NORMAL:GLFW_CURSOR_HIDDEN);
}
|
| ||
| Excellent Mark Thanks for your continued dedication and hard work! |
| ||
| In hindsight, I have actually found one somewhat small problem with the new version of 'trans'. It would seem that the 'Alias' keyword can cause the compiler to crash with this version. It seems to be related to this line, and especially this line. After a not so quick look at this, I realized the effect you were looking for might be better handled with 'PushEnv' and 'PopEnv'. After testing this, I can confirm that this fixed the problem in the situation I tested. From what I understand, the crash was from a chain of events, which begin at lines 1633 and 1644 of 'trans.parser' (The 'ParseMain' method's 'Alias' code). Basically, the entire issue is that '_env' is being set to 'Null', instead of being restored. So, when '_env' is used later (By the preprocessor), you get a memory access violation. Weirdly enough, this problem can only be seen from the preprocessor of the module doing the importing of the module which has the aliases in question. If the first module / build file has aliases, there's no issue (For that module, I'm pretty sure this will still happen anyway). The fix would be something like this (This may require more testing): Basically, I just restore the old version of '_env', so we don't have any issues. Here's an example which will cause this issue: "module01.monkey": "module02.monkey": Assuming I understood the point of all of that, my fix should work just fine. It doesn't have any issues with the above example. I had a hell of a time debugging this (And not in a good way), so here's hoping this is the last of that for now. |
| ||
| Thank you Mark. Good job! |
| ||
| Hi Mark, I'm not certain if this the correct place, but I have a change to the core mojo for Android which I think would be beneficial for everyone - I discuss it in the 2nd post here: http://www.monkey-x.com/Community/posts.php?topic=9153. In short it makes games on android devices massively more response when loading textures. The work I did was based upon 79, but I would be happy to port it to any version you nominate. Is there any way for me to contribute this as (understandably) the mojo implementation for android etc are not on github. By the way thank you for such a fantastic tool. I am really enjoying working with Monkey. Keep up the good work! |
| ||
| Thank you Mark ! I use preprocessor commands and import a lot. This evolution give me some ideas. Best regards Golomp P.S. : +1 for SGEM advice, Monkey is really fabulous. |
| ||
| Dear mark, thanks for your work and upkeeping efford with monkey =) |
| ||
| Thanks :) |
| ||
| @SGEM I think it would be best if you create a zip and post it at the bug forums. |
| ||
| @SGEM: DO NOT do what Pharmhaus just said. If you upload any source code or related software from Mojo's Android backend (Excluding the actual target), you will be illegally distributing it. Uploading it to the forums doesn't change it from potentially being illegal distribution. You should probably email Mark about integrating your changes. That's a lot less shady. |
| ||
| > Assuming I understood the point of all of that, my fix should work just fine. Yes, this fix looks good to me. The alias code in the parser was overwriting the _env pushed by the preprocessor, which wasn't an issue when preprocessing occured before parsing. Ideally, I think I'd like to see the preprocessor merged with the parser, but that's a job for another day... Regarding the android fixes, feel free to email them to me, or to post 'snippets' to the bug reports or programming forum. But please don't just post an entire modified android mojo somewhere! Regarding the glfw functions, perhaps the best solution is to just expose all of glfw3, eg: Module brl.glfw3 Extern Function glfwSetWindowPos( window:GLFWwindow,x:Int,y:Int )...or whatever it's called. ...etc... There's a fair bit in glfw that I don't know about that someone's likely to want sooner or later, so perhaps it's better to throw it all in (or at least make a start). Or, the internal glfw game target class could be exposed, extended eg: GlfwGame.GetGlfwGame().SetWindowPos 10,20 But I think I prefer the first way - a wee bit messier but you can do whatever you want with it. |
| ||
| Well when the gflw adjustments are made so we can make desktop window changes from one exe then we will be a big step nearer to max's functionality. Personally i would love a external tool to setup the icons for targets etc this would be brilliant. If it could also be merged in Ted that would make it more nearer a complete solution instead of where we are atm where we have to manually setup everything. By rights if the language is perfect we should never need to delve into any part of the files to reconfigure anything it should ALL be done via the IDE or language. |
| ||
| Regarding the glfw functions, perhaps the best solution is to just expose all of glfw3, eg: Sure, perhaps something similar to the opengl modules. Btw, it would be great with an opengl es 3 module so we can use texture arrays. Since the makeglxx program is done perhaps it's not that much work? |
| ||
| Regarding the android fixes, feel free to email them to me, or to post 'snippets' to the bug reports or programming forum. But please don't just post an entire modified android mojo somewhere! Thanks Mark. I am in the final stages of releasing my latest app. Once I have seen how this change performs in the wild over the Christmas period I'll be confident to submit it to you. |
| ||
| hi did you take a look at this bug yet? http://www.monkey-x.com/Community/posts.php?topic=9152 thanks |
| ||
| Hi all. something I don't understand: when i look at the "product updates" I still see as last version 0.77A (since month now) and here we spoke about an experimental 0.82A there was no 78, 79 80 or 81 version ? Pit |
| ||
| Hi Pit, they are all there. Have you registerd your product? Someone else with the same problem wrote: "I'm goob, i forgot to register monkey x pro when i bought it ... now to find my reg code...." |
| ||
| @pit: You should be able to go to the "Product Updates" section where the other versions were. On the bottom right, there should be an "Experimental Versions" thing. That's where the main releases have been. Assuming you don't have that option (I'm not sure if experimental builds are available to free users), you could always clone/download from the official GitHub repository. Just note that if you do have the full version of Monkey, you'll want to move over your target-specific Mojo implementations to your "modules/mojo/native" folder. There may be version conflicts. You really should have that experimental builds option, so you shouldn't need to do anything manually. If this is about owning the full version, and not having it registered to your account, please enter your product key on this page (Monkey's product registration page). |
| ||
| H iguys, and thanks for your answer. :-) I don't see the link to the experimental version. But, indeed, I have the FREE version. So, it's probably only available for the PRO version ? does it means that 77a version is the only last official version ? Or is there another offcial new version but only for PRO version ? Cheers Pit |
| ||
| if you want the newest version or the experimental version you need to pay. :) otherwise what you are using is the newest. |
| ||
| ok thanks ! I understand ! and what's the newest version (not hte experimental) of the PRO version ? Pit |
| ||
| 81b |
| ||
| Ok So I think I should upgrade to verison PRO Thanks Pit |
| ||
| @pit: You go make that purchase, you'll be glad ya' did. ;) |
| ||
| Mark I know its been asked for before but could we have '#MONKEY_IMAGEDIRECTORY' and '#MONKEY_SOUNDDIRECTORY' compiler directive so we dont have to have the 'mygame.data' folder we could do things like: MyGame and have Graphics, Sound, LevelData in there and have a #MONKEY_IMAGEDIRECTORY = "Graphics" #MONKEY_SOUNDDIRECTORY = "Sound" #MONKEY_DATADIRECTORY = "LevelData" this basically would allow us to use whatever directory structure we wanted and with the platform directives we could then have different media for any particular platform not only that we could also have demonstration versions in the same directory etc just with different data. This feature would also bring it closer to max which would be another BIG plus for people migrating from max/blitz3d etc. |
| ||
| Why? You can as well do /data/graphics /data/sound /data/levelData At least, It's what I do here. no need for new flags. |
| ||
| What I meant is the mygame.data directory being got rid of and allowing us to use our own directory structure |
| ||
| v82b is now up... |
| ||
| Hi guys, following your advices, I did it :-) I'm now in pro version, 81b. Long life to Monkey ! Pit |
| ||
| Thank you very much for continuing the free bug fixes and small improvements! Happy new year to Mark and the Monkey-X community! :) |
| ||
| Thank you for these improvements. It gets better and better. Is there any roadmap / plans / decissions for V83? |
| ||
| ... |
| ||
I don't understand. Just downloaded 82b, and now I'm getting "Type 'App' not found" onClass Game Extends App What is going on....? This code compiles fine in 0.80b...?! (And it happens on all targets, even HTML5!) Edit: Strange, after I imported mojo, it compiled. But on earlier versions, I have mojo imported in the first lib I import into this code, and didn't need to import it again. Something like Import mylib Class Game Extends App End Class mylib: Import mojo function myfunction() End function |
| ||
| Did you "Import mojo"? Thats where the App definition is. Never mind I see you figured it out. |
| ||
| @SLotman: If 'mojo' is imported publicly by any of the modules you import, you will have its functionality. However, if you only import a specific part of Mojo, you might end up not having all of the functionality delegated to you. If you're unsure in a situation like this, just import the modules you need from the original module. Or, you could always use a "common imports" module, but I'm generally against that for less dependent projects like standalone modules. Games shouldn't have too much of a problem with this. The 'Import' functionality has not changed its behavior, but the newest versions of Monkey do have a new implementation (Which allows better integration of the preprocessor). But, I've done extensive testing with this, and I can confirm that this change performs as expected. The 'App' class is found in 'mojo.app', and you should probably be importing 'mojo' or its sub-modules from the modules which are using Mojo as a crucial portion. Since we're talking about your main 'Game' class, you should definitely have an import for Mojo at the top of that class's module (file). And assuming you want to do more advanced things than just setup an application, you should probably just import 'mojo' to be safe. |
| ||
| Thing is, the same code compiles at earlier versions of Monkey, and on .82b doesn't until I set "import mojo" in the main code. What I have is exactly this: Import iglib Class Game extends App End Class Function Main() New Game() End Function And iglib: Import mojo.app Import mojo.graphics Import mojo.input (bunch of functions below) That doesn't compile on .82b - but it does on .80 and before. If I add "Import mojo" in the first code, then it compiles. So, it's not 100% compatible with previous code, for sure. |
| ||
| Assuming those imports were public (Which is the default), then it should work without a problem. In fact, this code compiles just fine for me (As expected): "Main.monkey" (This is the build file; it doesn't matter what you call it): "test.monkey": The above program simply exits and displays "Hello, world." in the console. That compiles without any errors; I have no idea what's causing your problem. I'm running V82(B) myself, and I'm having no issues compiling this. You're not using a non-game target (Basically just C++ Tool (STDCPP)), are you? Because, the only other explanation I can think of is that you're missing the Mojo implementation for the target you're building for. |
| ||
| Nope, that happened to me for *all* targets. HTML5, Android, desktop... I wasn't using "strict" at the top of the code, maybe that's the difference? Edit: The strange thing is that now it is working. Go figure. |
| ||
| it works fine here! have you tried reinstalling Monkey? |
| ||
| Can we have 32bit binaries for Linux, before everyone jumps in saying about recompiling the binaries this netbook only has limited space so I don't want to install Qt creator etc just so I can use one system. I need the 32bit binaries as the netbook is 32bit there isn't a 64bit cpu in the netbook and due to time constraints and limited coding time I use a netbook. If there isn't gonna be 32bit binaries in future versions of monkey I will have to look to using something else for development like code::blocks and use c++ |
   |