Monkey V61 now available! [MONKEY NEWS]

Monkey Forums/Monkey Programming/Monkey V61 now available! [MONKEY NEWS]

marksibly

(Posted 2012) [#1]

Hi,

[edit]
V61b now up - fixes an issue with the new GC + a nasty debug mode bug in html5/flash with arrays and +=, -= etc..

Also includes a version of Ted that stores settings in bin/ted_blah.ini dir and hopefully handles unicode better!
[/edit]

Ok, V61 is now up!

This is sort of a 'half' release. I've removed some unfinished editor/doc stuff I was hoping to have in by now in order to get fixes out for Vita/XCode4.4 ASAP.

The highlights:

* The package is considerably bigger now, about 30Meg-ish, thanks to Ted/Qt. However, this does include EVERYTHING for both Mac and Windows, not to mention a fully html5 capable WebBrowser control that hasn't been made use of yet! I considered splitting things up, but decided to keep things simple.

* The xcode projects (ie: ios and glfw) have been convert to xcode 4.4 projects, so you'll need to update xcode if you haven't done so already.

* A new psm target has been added to support Play Station Mobile (I guess that means no ps3 then?!?), which is the fancy new name for the Play Station Suite (I prefer suite!). The pss target will eventually be removed.

* The package now only includes Ted - feel free to copy in Monk if you want.

* Ted has been moved to bin/ and is now launched via a Monkey.exe stub app in the root dir. The stub app does some 'housekeeping' like registering itself and the .monkey filetype (if not already registered). It also helps hide the ugly Qt dlls. This stuff COULD be done via a setup.exe app, but I like how Monkey is installation free and dropbox/removable storage friendly and would like to keep it that way.

* Also note that Ted still stores it preferences in the registry. This is probably wrong - I think a local ini file makes much more sense. This is something I wanted to tidy up along with new docs, but it'll have to wait...

* The C++ GC alogorithm has changed. It now collects CPP_GC_MARK_RATE objects per update/render (defaults to 2500 - about 1ms on an iPad 1), and sweeps when CPP_GC_TRIGGER bytes have been allocated (defaults to 4M). You can set the TRIGGER to 0, in which case a sweep will occur as soon as all objects have been marked. This is theoretically harder on the CPU, but in a way, this also represents the 'sweet spot' of realtime GC, where you are marking *just* enough to require a sweep once you are finished. Anyway, that's probably all a bit heavy. More to come GC-wise, but hopefully I haven't borked anything in the process...

Modules:

pss/psm mojo - added discard to surface.

flash mojo - fixed stream of mousehits bug when app lost/regained focus.

glfw mojo - added KEY_TILDE and KEY_QUOTES support.

lang.cpp - tweaked GC, added CPP_GC_MARK_RATE and CPP_GC_TRIGGER config vars.

Targets:

Upgared Mac ios and glfw target projects to xcode4.4.

Added psm target - will replace pss target in next release so upgrade NOW! Check your PSM_PATH in bin/config.winnt.txt is set correctly before use.

glfw - Updated GLFW lib to 2.7.5

Trans (V1.37):

Fixed debug array index check bugs on js/as.

Fixed bug with reflection filter and mixed cased module names.

Fixed comment at end of preprocessor line parsing bug.

Neuro

(Posted 2012) [#2]

Awesome stuff Mark! Can get to work on PSS...er i mean PSM stuff again :)!

Samah

(Posted 2012) [#3]

No MODULE_PATH config variable yet? I'm a sad panda. :(

Amon	(Posted 2012) [#4]

Thanks, Mark!

Shinkiro1

(Posted 2012) [#5]

Thanks.
Especially the GC stuff seems interesting. Has anybody tested this already (muddy_shoes? ^^)?

muddy_shoes

(Posted 2012) [#6]

No, I haven't looked at it. It takes me a while to get around to taking new versions as I have to merge with my altered monkey/mojo code. Seeing as it's common to get a bug-fix increment within the first week I normally wait unless there's something I really want. As I've already added the equivalent of the CPP_GC_TRIGGER value I'm in no rush to get this.

Looks like it's bound to be an improvement though. I'd definitely like to see more control over the GC in the long-term. Being able to trigger collections when the user is less likely to see a hiccup would be good.

Kalakian

(Posted 2012) [#7]

Great Stuff. Updated with almost no problem this time (remembered to delete the build folder and everything).

I'm getting a lot of "ERROR:p=013CCFD0" errors when running GLFW in debug mode now. I assume this is some nasty memory leaking to do with my code (which I expected was there anyway), or is it something else?

Kalakian

(Posted 2012) [#8]

Not sure exactly what the error means, but I've reduced the amount it occurs in my game. It seems to be linked to rapid object creation and destruction.

I created a quick and nasty collision system where all game objects were checked for collisions against each other. This was obviously going to cause problems, so it was to be optimised later. The scope of the issue was a lot larger than I had thought, as there were hundreds of thousands of collision rectangles and circles being created per second, plus the walls were colliding with each other.

Anyway, lots of temporary objects were being created during the collision detection phase, and this seems to have caused the GLFW "ERROR:p=013CCFD0" error. I still have some left, but I'm quite sure now that they can be fixed in my code if I just stop being silly :D

Skn3	(Posted 2012) [#9]

Great work there Mark, keep em coming :D

Nobuyuki

(Posted 2012) [#10]

good work on the GC -- it's always nice to hear progress being made in that arena :)

time-killer-games

(Posted 2012) [#11]

It is very amazing how quick you guys make such awesome updates! :D

marksibly

(Posted 2012) [#12]

Hi,

> I'm getting a lot of "ERROR:p=013CCFD0" errors

That's definitely a 'should never happen' thing - any chance you can reproduce the problem with a small sample, or send me the entire project?

Kalakian

(Posted 2012) [#13]

You want me to break things deliberately? Sounds fun, I'll get on that :D

I'll try replicate the problem in a small sample and get back to you

Grey Alien

(Posted 2012) [#14]

Thanks Mark! I've been looking forward to this just for the Flash mousehit fix but the other stuff sounds cool. Now I can release Flash games with confidence (sent the last one to some press then they found the mousehit bug, oops!)

Kalakian

(Posted 2012) [#15]

Oops, totally forgot to write that code yesterday. I've now created some test code that shows the "ERROR:p=013CCFD0" error (for me anyway) in 2 of the 4 test cases.

Strict

Import mojo

Class MyApp Extends App
	Field objects:List<GameObject>
	Field testCase:Int = 0 ' 0 to 3
	
	Method OnCreate:Int()
		SetUpdateRate(60)
		objects = New List<GameObject>
		For Local i:Int = 0 Until 100
			objects.AddLast(New GameObject())
		Next
		Return 0
	End
	
	Method OnUpdate:Int()
		Select(testCase)
			Case 0 ' ToArray and New Rects, causes ERROR:p=003FCFC8
				Local objArray:GameObject[] = objects.ToArray()
			
				For Local i:Int = 0 Until objArray.Length
					Local obj1:GameObject = objArray[i]
					For Local j:Int = i + 1 Until objArray.Length
						Local obj2:GameObject = objArray[j]
						If (RectsIntersect(obj1.Bounds, obj2.Bounds))
							' Collision response goes here
						EndIf
					Next
				Next
			Case 1 ' Iterator and New Rects, doesn't cause ERROR:p=003FCFC8
				For Local obj1:GameObject = EachIn objects
					For Local obj2:GameObject = EachIn objects.Backwards()
						If (obj1 = obj2)
							Exit
						EndIf
						If (RectsIntersect(obj1.Bounds, obj2.Bounds))
							' Collision response goes here
						EndIf
					Next
				Next
			Case 2 ' ToArray (unused), Iterator, and New Rects, causes ERROR:p=003FCFC8
				Local objArray:GameObject[] = objects.ToArray() ' not actually used
				
				For Local obj1:GameObject = EachIn objects
					For Local obj2:GameObject = EachIn objects.Backwards()
						If (obj1 = obj2)
							Exit
						EndIf
						If (RectsIntersect(obj1.Bounds, obj2.Bounds))
							' Collision response goes here
						EndIf
					Next
				Next
			Case 3 ' ToArray without New Rects, doesn't cause ERROR:p=003FCFC8
				Local objArray:GameObject[] = objects.ToArray()
			
				For Local i:Int = 0 Until objArray.Length
					Local obj1:GameObject = objArray[i]
					For Local j:Int = i + 1 Until objArray.Length
						Local obj2:GameObject = objArray[j]
						If (RectsIntersect(obj1.Bounds2, obj2.Bounds2))
							' Collision response goes here
						EndIf
					Next
				Next
		End
		Return 0
	End
	
	Method OnRender:Int()
		Return 0
	End
End

Class GameObject
	Field bounds:Rectangle
	
	Method New()
		bounds = New Rectangle()
	End
	
	Method Bounds:Rectangle() Property
		Return New Rectangle()
	End
	
	Method Bounds2:Rectangle() Property
		Return bounds
	End
End

Class Rectangle	
	Method New()
	End
End

Function RectsIntersect:Bool(_rect1:Rectangle, _rect2:Rectangle)
	Return False
End

Function Main:Int()
	New MyApp()
	Return 0
End

What these tests seem to indicate is that the error happens when using a List's ToArray() method followed by creating and destroying many temporary objects, regardless of whether you actually use the array or not.

JaviCervera

(Posted 2012) [#16]

Great release, Mark. And in fact it doesn't require Xcode 4.4. I am running it successfully on Snow Leopard and Xcode 2.2. The only thing I needed to do was to rebuild Ted using Qt Creator (maybe the version you're shipping is 64 bits only? My Mac is a 32 bits white MacBook from 2006).

Raz	(Posted 2012) [#17]

Getting an error when trying to run Monkey.exe

Ted.exe - Unable to Locate Component
This application has failed to start because MSVCP100.dll was not found. Re-installing the application may fix this problem.

It is fixed by installing the Visual C++ 2010 redist - http://www.microsoft.com/en-us/download/confirmation.aspx?id=5555

I'm running a fresh install of XP hence the missing C++ stuff Not a big issue, but it might be worth noting for new users of Monkey

AdamRedwoods

(Posted 2012) [#18]

minib3d v0.30 + MonkeyV61 + GLFW + animation_test.monkey
The code runs but I get:

ERROR:p=006C0DA8 gc_free_bytes=-858941496
ERROR:p=006C0DA8 gc_free_bytes=-285706032

Is this debugger info that I can only trace in Ted?

marksibly

(Posted 2012) [#19]

Hi,

> I've now created some test code that shows the "ERROR:p=013CCFD0" error (for me anyway) in 2 of the 4 test cases.

Thanks!

V61b is now up and should fix this problem - GC was using memory after a free()...duh!

Kalakian

(Posted 2012) [#20]

Great work Mark!

Cheers for the update, it resolves the issues in my test code and those issues in my main project ... now I just have to fix my own code so it doesn't perform so badly :)

golomp

(Posted 2012) [#21]

Thank you Mark and thank for your reactivity,
i did'nt have the time to download the v0.61
and the v0.61b is already there.
Great!

DruggedBunny

(Posted 2012) [#22]

Just in case anyone hasn't noticed, you can toggle Ted's output console on and off using ESC, which is great because I was finding it a little cramped vertically before!

Sledge

(Posted 2012) [#23]

a fully html5 capable WebBrowser control

Away from my dev machine ATM -- what is this exactly?

DruggedBunny

(Posted 2012) [#24]

It means (in theory) we should at some point be able to run HTML5 apps within the IDE if Mark figures it out, which would be pretty cool!

ziggy

(Posted 2012) [#25]

Just to let everybidy know that HTML5 i also available on the default JungleIde browsers tabs, so if Mark provides a way to comunicate the compiler with the IDE browser, Jungle Ide could beneffit from it too.

Nobuyuki

(Posted 2012) [#26]

Is Jungle still using Trident as its HTML engine?

Tibit

(Posted 2012) [#27]

@ziggy, can you not just open the browser on the selected html file when user press F5, instead of using the default browser?

I did that in my IDE, worked great. If I remember correctly then in my IDE made it so a html5 "build" (not build & run) switched to the browser tab, set the url to the current locked-build file's html5 directory and refreshed.

Do you need to do more?

slenkar

(Posted 2012) [#28]

thanks for the update,

a little Ted request:

y'know when you search for a word? The line goes yellow,

its a small thing but to get the line back to normal I have to press the mouse and then press a key, in monk, you only have to press the mouse.

When I double click on the name of a class on the right panel the line goes yellow too, so every time I have to dismiss it.

DruggedBunny

(Posted 2012) [#29]

One little thing I'm missing in Ted is the ability to middle-click in the source view and then move the mouse up and down to scroll -- all previous Blitz editors let you do this (and Ted's Help view does it). I find this much nicer than constantly working the scroll wheel through a large source file or trying to drag fiddly scroll bars. Hope this can find its way in!

Sledge

(Posted 2012) [#30]

It means (in theory) we should at some point be able to run HTML5 apps within the IDE

Aha. Cheers!

ziggy

(Posted 2012) [#31]

@Tibit:

Do you need to do more?

Yes. We would need to know somehow the port that is going to be used by the mini server as Monkey games are not run localy (well, they are, but using a local server). And I see no way to make trans call the miniserver, then the miniserver providing information of wich port it'll be using and then allowing the IDE to open the corresponding URL. In my opinion this should be accesible using trans, a parameter that just returns the URL to be opened by any external tool using trans, so it can embed HTML5 documents on any IDE or in any other tool that compiles anything using Monkey.

Tibit

(Posted 2012) [#32]

Ah I think I understand now. So I assume what I missed was that it seemed to work, however if I'd tried to Save/Load data it would have failed I guess?

ziggy

(Posted 2012) [#33]

however if I'd tried to Save/Load data it would have failed I guess?

Yes, and it would fail also on local flash storage. Also, the security settings of the internaly used browser would be different from local use than for server use, and this would make debugging things a bit unreliable, as you would always have to add a final remote testing phase wich you can pretty much avoid now

Corum

(Posted 2012) [#34]

Awesome! It's all fantastic, except this...

The xcode projects (ie: ios and glfw) have been convert to xcode 4.4 projects, so you'll need to update xcode if you haven't done so already.

To update xcode I'd need to firstly upgrade to Lion, while my old Macbook Core Duo is not supposed to be compatible with it.
4.2 is the max possible version available.
This is a bit disappointing to me. :(

[Edit]
It compiles without hassles with my old version of Xcode (latest 3.x).
The only problem is after iOS build: it ends and doesn't go further. This requires to manually open the project inside XCode and build'n run the app from the ide itself; that leads to a correct execution of the simulator.
No problems with Android and HTML5.
The GLES examples can't compile with my present configuration, whatever target I pick.
Any chance to include a couple of configuration parameters to choose the XCode version?
[/Edit]

Landon

(Posted 2012) [#35]

if i remember any macbook with a processor of like 900mhrz and up can at least upgrade their macbook to 5.6