Experimental update V52 now available! [MONKEY NEWS]
Monkey Forums/Monkey Programming/Experimental update V52 now available! [MONKEY NEWS]
| ||
Hi, [edit]Ok, 52b up already![/edit] Ok, there are quite a few changes to targets and how data dirs are handled so this update is definitely experimental! Note: You WILL need to delete your .build dir... The first major change is the unification of 'config' file handling for each target. To date, this has been done via ad-hoc config.h or config.cs etc files in the .build target dir. Now, config files are still in the .build target dir, but they are all called CONFIG.TXT and are all parsed the same way, ie: simple KEY=VALUE pairs. I've also added ther ability to define 'data file filters' in CONFIG.TXT files. This is done via settings that control what sort of data gets copied into a target project's data dir, and what the data is used for. These settings are called TEXT_FILES, IMAGE_FILES, SOUND_FILES and MUSIC_FILES, and their entries in a CONFIG.TXT file will look something like this: TEXT_FILES=*.txt|*.xml|*.json IMAGE_FILES=*.png|*.jpg SOUND_FILES=*.wav MUSIC_FILES=*.mp3|*.wma (this example taken from the xna target). The values of these settings are simple file filters (not full on regexs) and are used when copying data from your projects '.data' dir to the actual target project - files that match are copied, files that don't, aren't. This should allow you to minimize what data is copied to what targets, and what preprocessors (in the case of xna) are used on the data. Not sure this is the best way of doing this, but it's simple yet reasonably flexible so let's give it a whirl. Some other 'hidden' features in this update that are pretty raw and I'm not totally sure about yet: * CONFIG.TXT settings are available for #If preprocessing. * You can also create CONFIG settings via trans using +key=value, eg: "trans -target=html5 +MY_CONFIG=1 myapp.monkey" Anyway... Modules android mojo.input - added blind kludge for EnableKeyboard. os - Changed CopyFile to use os copyfile/CopyFileW. html5 mojo - Removed cookie hack from LoadState/SaveState. opengl.gles11 - Added LoadImageData for use with glTexImage2D etc. android mojo.graphics - changed gl calls to use GLES11 class instead of GL11 object. mojo.audio - added PauseChannel, ResumeChannel, PauseMusic, ResumeMusic. mojo.graphics - added support for IMAGE_FILTERING_ENABLED to appropriate targets. See CONFIG.TXT files. Targets: xna - text files no longer embedded. xna - data dir now created directly to xna Content dir. ios, glfw - INCREMENTAL_GC now defaults to 1. html5 - loadString now uses XMLHttpRequest. flash - added type="..." to <embed> tag glfw, flash, android, xna, glfw, android - added IMAGE_FILTERING_ENABLED setting to config files. Trans (1.28) bin/makemeta app gone. Text files no longer embedded in html5. Added 'data file filters' to CONFIG.TXT files. Added support for per-target CONFIG.TXT config files. |
| ||
Thank you for the data file filters. :) |
| ||
Cool - just downloaded now :) Any chance that we could lose the "project.data" folder and just have a "data" folder in the future? |
| ||
Just testing Diddy's GUI example using v52: * HTML5 - Compiles and works * GLFW (Windows) - Compiles and works * Flash - Compiles and works * XNA - Fail: 2 errors - Cannot find importer "M3Importer" [edit] v52b: * XNA - Compiles and works [edit2] * Android - Failed due to the GLES11 changes in v52, I've committed a change to Diddy to fix this and it works fine now. |
| ||
Hi, > * XNA - Fail: 2 errors - Cannot find importer "M3Importer" Thanks - 52b on it's way up... |
| ||
Yep, that fixed it: XNA - Compiles and runs (4 warnings, but we don't care about those do we? ;)) |
| ||
nice update! |
| ||
Thanks! just a question.. I noticed 'loadString now uses XMLHttpRequest.'... what it means?? :) sorry if it's a silly question :P thanks in advance! best. |
| ||
thats just for the HTML5 target. |
| ||
Does the XMLHttpRequest update mean that we can now use something like LoadString("http://www.domain.com/myfile.php?querystring")? EDIT: Changed the wording of my question so not to cause confusion for others, but the answers below still make sense :) |
| ||
XMLHttpRequest means that we can now use LoadString("http://www.domain.com/myfile.php?querystring") for example, right? no, it's just another way to load external data. |
| ||
So if it's not as benmc says.. what's the difference? what do you mean saying that's just another way to load external daata, bruZard? :P |
| ||
Hi, > XMLHttpRequest means that we can now use LoadString("http://www.domain.com/myfile.php?querystring") for example, right? Nope. Text files used to be 'inlined', which could make the main document considerably larger. This is no longer the case, and text files are now stored in separate files and loaded using the XMLHttpRequest mechanism instead (which is really just a way to 'load a file from the server' in JavaScript). There should be no difference in terms of using text files in your apps though, so feel free to ignore this if you don't know anything about XMLHttpRequest. |
| ||
XMLHttpRequest... Monkey is officially "Web 2.0" :) |
| ||
This sounds like a great update, I already discovered that having to have .wav and .mp3 for HTML5 and Flash targets in my data folder was a pain. |
| ||
Thinking specifically from an XNA point of view, this is really great news :D Looks like there should be very few post monkey changes required for a proper release now. Might have to go back and recompile Ninjah just to see if it's actually much much quicker now too :) |
| ||
This is the best update that's come in ages. This is going to be extremely helpful for setting up a lite and full version of a game. As well as setting up the output's settings themselves, which is an unbelievably big step forward for Monkey. Excellent job, really. Keep it up. |
| ||
Fantastic update, thanks! Lots of much-requested features, particularly useful ones to me being the per-target CONFIG.TXT & data file filters. |
| ||
I'm wondering if instead of LoadImageData() you should leverage your DataBuffer class. I think it may be better if there's a function to return a DataBuffer from an Image. This way, people can Poke/Peek Images for pixel access, as well as sending data over to opengl. |
| ||
just wrap it ;) |
| ||
I probably would have to. I forgot that mojo dumps the image data after loading it, which is why LoadImageData() is needed. Looking at your S3D Texture Class this is what is basically needed. The key method being getData(), but I think you have a typo, shouldn't it read Return Self.textureData Looking at it more, if you created a method for uploadTexture() which would do the binding and moving the image data into video memory, then one could begin manipulating image data through peek/poke and displaying updates with uploadTexture(). EDIT: ugh No, we can't do this cleanly because mojo make 'int texture' private. If you manually make this public (or add method GetTextureID() ), then you can bind your texture upload with mojo's Image. |
| ||
Excelent, i really need PauseMusic for a game i'm developing, so pleeeeeaaaaaase launch the stable version "pronto" =D |
| ||
LoadImageData() just loads a DataBuffer(), you can use the Pokexxx Methods to manipulate it. |
| ||
LoadImageData() just loads a DataBuffer(), you can use the Pokexxx Methods to manipulate it. Right, but you can't use it with mojo's Image class-- unless you make some 'tweaks' to the Image Class such as: GetTextureID():Int '' returns opengl texture id for the image This would help people to upload an image databuffer to texture memory for the image created by mojo's Image Class. Otherwise, you can't. I think this is something Mark should investigate, since people are wanting various pixel access functions, at least it would be possible at the opengl level. |
| ||
awesome !!! |
| ||
If I compile the target "GLFW" lines # OPENGL_GLES20_ENABLED = "False" # MOJO_IMAGE_FILTERING_ENABLED = "True" # GLFW_WINDOW_TITLE = "Monkey Game" # GLFW_WINDOW_RESIZABLE = "False" # GLFW_WINDOW_FULLSCREEN = "False" get an error - such as "... error C2065: 'False' : undeclared identifier ..." |
| ||
@teremocheck - they need to be in uppercase... and without any spaces in them. Although I can't get GLFW_WINDOW_TITLE to work either... |
| ||
Hi, "True", "False" need to be lowercase. Yes, a little inconsistent, this stuff is a WIP... GLFW_WINDOW_TITLE will probably need quotes, eg: #GLFW_WINDOW_TITLE="~qMy Game!~q" See CONFIG.TXT files in targets/ for reference. |
| ||
Hi Mark, in 52e and under HTML5 I get this error: Uncaught TypeError: Cannot call method 'pause' of null The offending part is located in the main.js file here: gxtkAudio.prototype.OnSuspend=function(){ var i; for( i=0;i<33;++i ){ var chan=this.channels[i]; if( chan.state==1 ) chan.audio.pause(); '<<<<< crashes here } } Under 51 I don't get this error. Looks like you have done quite some changes ot the HTML5 audio section. Cheers Michael |
| ||
I've been get exactly the same error as @MikeHart. I wasn't sure if it is a bug in my code or not. I haven't had much chance to look into it, but I noticed that the problem goes away if I comment out all my code that plays sounds. It doesn't happen straight away, always happens at some point during the game but not always at the same place. My hunch is that it happens after playing a certain number of sound effects. To play sound, I am using the Diddy Play() method. |
| ||
thanks. |
| ||
Hi, Ok, think I've found/fixed the html5 audio issue. Will have yet another V52 up soon! Unfortunately, html5 audio still seems to be pretty dodgy on Chrome. Thrash it too much, and the audio system seems to get confused. Sounds start lagging badly and never finishing. Sometimes, you even need to restart the browser to fix it. Firefox and Opera are much better. There is minimal lag before a sound starts playing (Firefox esp.) and I haven't been able to unduly upset either browser. |
| ||
Hi Mark, that's great to hear. I get the crash on Chrome AND Firefox. |
| ||
Thanks Mark. Glad to hear it wasn't a bug in my code after all :-) FYI. I mainly use Chrome, but I tried IE9 and saw the same problem there as well. |