MonkeyMax - Part 4

Monkey Targets Forums/User Targets/MonkeyMax - Part 4

therevills(Posted 2013) [#1]
Thread continued from here...
MonkeyMax is a BlitzMax target for Monkey, it allows you to code in Monkey and it outputs BlitzMax code so you can run it on Windows, Mac OS and Linux

Instructions can be found here:
http://code.google.com/p/monkey-max/wiki/MonkeyMax


Skn3 has updated MonkeyMax to work with v69!!


Skn3(Posted 2013) [#2]
w00t, I did this in one long coding session from about 5pm to 5am (and then a bit more the next day) so there are likely to be some errors. Post here if you spot any and I am sure someone will be able to assist!

It was an incredibly satisfying moment getting the first compile working after 12+ hours of coding!


Skn3(Posted 2013) [#3]
I retweaked LoadString() because if it was not working meant the other openfile stuff internally was broken too.

Turns out I had the fopen modes wrong and reading a file was overriting it... to top it off it wasn't returning the open stream either. DOH!

fixed to this:



Why0Why(Posted 2013) [#4]
One of the reasons I love and have supported Blitz products for the last 10 years is the community. I really appreciate all of the effort that guys like therevills, Samah, skn3, AdamRedwoods, et all continue to put into Monkey.

Thanks again!


Skn3(Posted 2013) [#5]
:D We do have a strong community spirit here, its nice!

I updated the repo and added a "BMAX_GRAPHICS_DRIVER" config var that can be set for a project.

options are: dx7,directx7,dx9,directx9,gl,opengl. I added various duplicate options just because its one less thing for the user to lookup in the future.

On mac/linux it will always use gl. On windows it will default to dx9 unless specified.


therevills(Posted 2013) [#6]
one long coding session from about 5pm to 5am

Wow! I remember doing those at Uni... but if I did that today, my wife would kill me - lol!

On mac/linux it will always use gl. On windows it will default to dx9 unless specified.

I've added a note to the code, not sure if you can see it.
What would happen if DX9 isnt installed?
I remember that BMax uses DX9 by default these days.... but does it fall back to DX7?


Also whats with the ".blah" syntax you are using in BlitzMax, I've never seen that before!? It looks like it sometimes calls Self. and others a global version?!?


Skn3(Posted 2013) [#7]
Wow! I remember doing those at Uni... but if I did that today, my wife would kill me - lol!


I like staying up, she likes tends to fall asleep. it balances out.. haha!

What would happen if DX9 isnt installed?
I remember that BMax uses DX9 by default these days.... but does it fall back to DX7?


Not entirely sure tbh I had some code to check dx version somewhere, maybe I should add that in... Although I would say dx9 is quite a safe bet really? Just checked wikipedia and dx9 was released 10 years ago.. CRIKEY!

The "dot" ah I missunderstood your exclamation about it in other thread, lol... well simply it allows you to call the globally scoped function. So if your class has SetColor method then use .SetColor to override the internal method and call the global function.


therevills(Posted 2013) [#8]
Although I would say dx9 is quite a safe bet really?

It should be safe, but if you state your game is DX7 compatible and its not - it doesn't look good!
Just checked wikipedia and dx9 was released 10 years ago.. CRIKEY!

I know... feeling old :(

well simply it allows you to call the globally scoped function. So if your class has SetColor method then .SetColor to call the global function.

Thanks for that - As I've said never seen it before, thats why I wrapped a lot of the BlitzMax functions!

Well I've put MonkeyMax v69 thru most of the Diddy examples and Spriter Importer and it looks good :)

The only thing which fails is the bmaxTest.monkey when printing "~".


Skn3(Posted 2013) [#9]
haha yeah I remember much lower directx flavours being "new" and exciting. Times change bloody fast!

I will have a look at why its not printing ~'s I did notice something along my way I think I changed it, I also noticed that audio samples were repeating if played too closely together so will check that out.


Skn3(Posted 2013) [#10]
Ok it should be fixed now. The old example file seemed to be broken.. it was trying to print "blah ~" which basically was an unclosed quote. Ontop of that I had tweaked the:


When I shouldn't have ;) lol Code OCD!

I reworked the sound looping mechanism. I can't believe there is no way in max to modify a sound looping without having to reload it?

Instead of reloading each time based on when you call PlaySample, I made it so internally it keeps two copies of the sound. If you play a looping sound this will now get stored in sample.soundLooping and the non looping version will remain as a duplicate but without looping. I guess it will be rare for two copies to be in memory, but it beats constnatly reloading the sample if you switch back and forth between loop and non-loop.


therevills(Posted 2013) [#11]
Jon I think you need to take a break... you are a coding machine!!

Re: LoadString - I've just checked the repo and it is still using my "fixed" version

Re: Enquotes - So the example was dodgy and you reformatted the Enquotes method, as I cant see any code change apart from spaces...

Re: Music looping - Its great isnt it that we have to reload the sound to set the loop flag!


Samah(Posted 2013) [#12]
Just pushed an .hgignore file to ignore commercial Mojo, and merged it with v69. Make sure nothing gets ignored when you rebase.


Skn3(Posted 2013) [#13]
haha CODING REOBOT REPORTING FOR DUTY *beep bop*... or maybe I can be like marvin the paranoid android. *ohhhhh i'll code if I have too.. ohhhhh*

*ahem*

To be honest I have only just started working on some repo's with more than 1 major contributor so a bit of learning is going on ATM :). Up until now its been me, maybe on two machines and at most one/two other with minor commits.

So I notice that you merged default and v69, but the default branch doesn't show any of the changes of v69 yet or is something else going on here?

therevills, do you not have these changes when you update branch v69?

This is where the sound/enquote stuff came in:
https://code.google.com/p/monkey-max/source/detail?r=6bed8e420ad12dc9fa791abc0b4f9930fa99c0d2&name=v69

I just noticed that the LoadString stuff wasn't there though, I must have accidently deleted it when testing. The Sound + enquote stuff is though?

Just committed a modification to v69 to reintroduce the LoadString changes.


therevills(Posted 2013) [#14]
So I notice that you merged default and v69, but the default branch doesn't show any of the changes of v69 yet or is something else going on here?

Samah merged the .hgignore into v69.

This is where the sound/enquote stuff came in:

Yeah thats what I'm talking about, if you do a diff with bmxtranslator I can only see formatting spaces:
https://code.google.com/p/monkey-max/source/diff?spec=svn6bed8e420ad12dc9fa791abc0b4f9930fa99c0d2&old=66bc797d93e23030c5ae2e8113be318110df3a04&r=6bed8e420ad12dc9fa791abc0b4f9930fa99c0d2&format=unidiff&path=%2Fmodules%2Ftrans%2Fbmxtranslator.monkey

Just committed a modification to v69 to reintroduce the LoadString changes.

Cool, I'll check them out tonight :)


Samah(Posted 2013) [#15]
@Skn3: So I notice that you merged default and v69, but the default branch doesn't show any of the changes of v69 yet or is something else going on here?

The difference is that I merged default into v69 rather than the other way around. Any changes in the default branch (in this case only the .hgignore) are brought into the v69 branch, but the default branch is left untouched.


Skn3(Posted 2013) [#16]
Yeah thats what I'm talking about, if you do a diff with bmxtranslator I can only see formatting spaces:


Weirdness, not sure what happened there then. I must have changed it back and forgotten at 4am in the morning.. lol.

The difference is that I merged default into v69 rather than the other way around. Any changes in the default branch (in this case only the .hgignore) are brought into the v69 branch, but the default branch is left untouched.


Ah cool didn't know you could do that, very handy :D


Skn3(Posted 2013) [#17]
Added a small update.

There is now a BMAX_IMAGE_MIPMAPPED_ENABLED preprocess/config var to specify if images should be mipmapped. Its currently set to default to on for bmax compiles. Is this correct behaviour or should it default to off?


therevills(Posted 2013) [#18]
Its nice being able to add these extra configs :)

With the mipmapped one though, I would have only used it for a few images, not the entire game.

And going by the doco in BlitzMax, I think it should be defaulted to off:

Note MIPMAPPEDIMAGE images consume extra video memory, so this flag should only be used when really necessary.



therevills(Posted 2013) [#19]
Samah found an issue with MonkeyMax and he's got a fix for it, something to do with casting...

He found it whilst testing his editor using JungleGUI, so I thought I'll have a look and found another issue... maybe with reflection and a combination of properties/extending and abstracts - I tried reproducing it, but having a hard time with a small piece of code.

If you run one of the samples from JungleGUI you can see the issue.

[Edit]
I've managed to reproduce it:


Parsing...
Resolving types...
Resolving decls...
Resolving const decls...
Resolving fun decls...
Compile Error: Overriding method differs by type


And a shorter version:


So the issue is with Interfaces!!!


Skn3(Posted 2013) [#20]
Hmm I don't get any errors when compiling the second example?

What do you get?


therevills(Posted 2013) [#21]
Did you save your monkey file as testmm?


Skn3(Posted 2013) [#22]
Ah ha... very weird! Ok I'll take a look.

Just to make things slightly easier to debug I reduced teh example down and changed some naming. Just incase anyone else wants to have a look at this.



Skn3(Posted 2013) [#23]
Ok I have a possible fix, could anyone tell me if this is ok?

I created it on a new temp branch to avoid confusion.

https://code.google.com/p/monkey-max/source/detail?r=d1370fb316e6e67c6d3a0482971a0f1254206dfa&name=v69_interfacefix


therevills(Posted 2013) [#24]
Just to make things slightly easier to debug I reduced teh example down

LOL! Wasn't my second example short enough - ;)

Ok I have a possible fix

Cool! I'll have a look when I get back from holidays :)


Samah(Posted 2013) [#25]
@Skn3: I created it on a new temp branch to avoid confusion.

The problem with "temp" branches is that they never are. Once you push something into the wild, it exists forever unless it's stripped from the repository and everyone reclones it. If you decide to accept and merge the change into the mainline, you get this ugly named branch floating there.

Given that there are very few people with push access, it might still be feasible to strip it. It just means that in the future if someone who has already cloned this repo gains push access, the bad branch may come back.

I think a better solution would be to export your change as a patch and submit it as an attachment on a code review.

As for the actual change, does it work? If so, just merge it and close the "temp" branch. If it ends up breaking something you can commit a backout changeset.


Skn3(Posted 2013) [#26]
LOL! Wasn't my second example short enough - ;)

Haha! It was confusing my brain looking at the compiled code with two slight variants of method.

The problem with "temp" branches is that they never are. Once you push something into the wild, it exists forever unless it's stripped from the repository and everyone reclones it. If you decide to accept and merge the change into the mainline, you get this ugly named branch floating there.

I think a better solution would be to export your change as a patch and submit it as an attachment on a code review.

Ok cheers for the advice, will look into doing this tomorrow. Not done it before :)


therevills(Posted 2013) [#27]
To me a branch is to allow test code to be shared (with other reasons too)... Samah is pretty obsessed with a clean repo (he likes to rebase!!) :P


Samah(Posted 2013) [#28]
@therevills: To me a branch is to allow test code to be shared (with other reasons too)

Sure, but not if your test code is a minor bugfix. That's just silly. If you're working on a new feature or something that could potentially have huge repercussions, named branches are the way to go.

@therevills: Samah is pretty obsessed with a clean repo

You'll find that most of the big projects are.

@therevills: (he likes to rebase!!)

Rebase is fantastic. It's much cleaner than merging.


therevills(Posted 2013) [#29]
Hook, line and sinker :D


Samah(Posted 2013) [#30]
You know I like fishing. ;)


Skn3(Posted 2013) [#31]
[J][J] I smell fish hooks.

lols ok time to look into creating a patch!


Skn3(Posted 2013) [#32]
Ok I see what you mean... cant get rid of the remote branch! How annoying!

Are we stuck with the pesky branch now or is there a way to clean it up?


Samah(Posted 2013) [#33]
@Skn3: Are we stuck with the pesky branch now or is there a way to clean it up?

These are the steps for Google Code:
1) Everyone who has ever cloned the repository needs to delete their clone.
2) Exactly one of the repository owners clones it.
3) One of the owners resets the repository.
4) Strip the bad branch from the local clone (requires mercurial queues extension to be enabled).
5) Push the clone back to the empty repository.

These are the steps for Bitbucket:
1) Everyone who has ever cloned the repository needs to delete their clone.
2) One of the owners strips the bad branch from the remote repository (can't modify the master repository on Google Code).

So now the bad branch has been cleaned from the master repository, but it's likely that someone somewhere still has an old clone with that changeset. You just need to hope that an owner never gets it back from them and accidentally pushes it again.

Edit:
Regarding closing branches: Update to the branch you want to close, then do an empty commit and when selecting which branch to commit as, choose "Close current branch". You should get a changeset with a little horizontal bar in the graph. Then you can update back to another branch.
Note: I've already done this!!!

Edit 2:
I can strip out that branch if you want; the repository is still young enough that it's not a huge deal. I want an OK from both you and therevills first.


therevills(Posted 2013) [#34]
I wouldn't worry about it... Skn3 has closed the branch - that's good enough.

(Although I don't think Jon has committed the fix to the v69 branch?)


Samah(Posted 2013) [#35]
Skn3 has closed the branch

Actually I closed it. Skn3 committed an (essentially) empty changeset on the default branch.

I've done this locally, let me know if you guys are ok with me resetting the repository. It's pretty simple really. I just imported Skn3's change to MQ, unapplied it, stripped the extra commit and reapplied. It even kept the original comment and author. :)



therevills(Posted 2013) [#36]
Actually I closed it.

Strange - it looks like Skn3 did it on the v69 branch, but on the v69_interfacefix branch I can see you closed it?!?!

if you guys are ok with me resetting the repository

Just leave it as is... I've merged Skn3 changes to the v69 branch - makes the graph looks a bit crazy, due to the branch being closed!


Samah(Posted 2013) [#37]
Strange - it looks like Skn3 did it on the v69 branch, but on the v69_interfacefix branch I can see you closed it?!?!

Yeah, but he didn't actually "close" it in Hg terms, he just committed an empty change. Sorry dude, you can't merge a closed branch, it looks awful. I'm going to reset it. I wouldn't have minded so much, but that merge is horrific.


therevills(Posted 2013) [#38]
LOL! Its a good thing we don't use Hg at work - I think it would drive you crazy!

Its just the graph... who cares if it looks awful!! :D


Samah(Posted 2013) [#39]
Its a good thing we don't use Hg at work - I think it would drive you crazy!

That's why people do "pull-only" repositories where one person maintains what the graph will look like per clone. Linus does it this way, I believe.
Also, done.


therevills(Posted 2013) [#40]
Linus does it this way

But Linus is crazy :P

Also, done.

Fair enough... maybe next time merge to the "master" (v69 in this case) and then close the branch.

So I guess we now have to re-clone the repo from scratch?


Samah(Posted 2013) [#41]
So I guess we now have to re-clone the repo from scratch?

Yes. Please don't push those bad changesets! That means you too, Skn3!
Delete your entire local clone.


therevills(Posted 2013) [#42]
Done on my local repo... but from now on don't worry to much about stuff like this. Its not the end of the world and if we get more people on-board it'll be a nightmare to control.

Just commit and push like normal.


Samah(Posted 2013) [#43]
but from now on don't worry to much about stuff like this

Yeah agreed. If the repository was any bigger I wouldn't have bothered, but I figured it was small enough that it wouldn't be too big of a deal.

if we get more people on-board it'll be a nightmare to control.

If we get more than three people on-board, we should look at doing proper patch reviews for dangerous changes.

Just commit and push like normal.

Commit often, rebase when it makes sense, and push when you're 100% happy you want to share it in its current state. Don't just push after every commit.


Skn3(Posted 2013) [#44]
Back from Easter!

Yeah, but he didn't actually "close" it in Hg terms, he just committed an empty change. Sorry dude, you can't merge a closed branch, it looks awful. I'm going to reset it. I wouldn't have minded so much, but that merge is horrific.


Haha well its weird because I am used to using git, bitbucket/github and not a tortoise client; it was a bit baffling how to do it in merc and tortoise. So with googlecode what is the proper way to close a remote merc branch?

Nice one for sorting it. The little "experiment" has helped progress my repo knowledge/experience anyways so thumbs up for that!


Samah(Posted 2013) [#45]
So with googlecode what is the proper way to close a remote merc branch?

Mercurial doesn't really have the same terminology of "remote branches". Branch names are optional. To close a named branch, you update to that branch, then close it. I can't remember the command line syntax for it, but in TortoiseHg you basically make an empty changeset (with a clean working directory) and change the target branch to "close current branch". It will actually flag that branch as closed, and you should see a special icon on the graph for it (usually a horizontal bar). Note that the branch is only closed in your clone. You need to actually push the "close" changeset to the main repo before everyone else will see it as closed.


Skn3(Posted 2013) [#46]
Hmmm that's odd, I pretty much did exactly that. Does the close changeset only push through to remote the next time there is an actual change on source files then? I pushed the blank commit you noticed through, only after having failed to successfully close the branch using the steps you described.


Neuro(Posted 2013) [#47]
Alright, so how do we go about installing this new monkeymax? Do i have to add it to transcc and rebuild/etc?


Skn3(Posted 2013) [#48]
As per normal:
https://code.google.com/p/monkey-max/wiki/MonkeyMax


Neuro(Posted 2013) [#49]
Ah thanks, thought the process changed.


Samah(Posted 2013) [#50]
I pushed the blank commit you noticed through

The changeset you pushed wasn't actually empty though. You'd changed the whitespace in one file (can't remember which) and left the target branch as default. You can't make an empty changeset in Mercurial unless it's something special like closing a branch.

remote

Mercurial doesn't really work that way. There's nothing special about the central repository other than its nice web interface. You're not closing a remote branch, you're giving it a changeset that marks a named branch as closed. Technically you can still commit to a closed branch if you update to a changeset before it was closed. This is what therevills did, and it's naughty. :)


Skn3(Posted 2013) [#51]
Mercurial doesn't really work that way. There's nothing special about the central repository other than its nice web interface. You're not closing a remote branch, you're giving it a changeset that marks a named branch as closed. Technically you can still commit to a closed branch if you update to a changeset before it was closed. This is what therevills did, and it's naughty. :)


Norty norty! Ok I thanks for clearing it up, I should probably practice some more on a private repo. Perhaps there could be a dev branch and then a stable branch? It would avoid trying to juggle untested micro branches.


Skn3(Posted 2013) [#52]
Found a bug with static function overrides.



This produces an error (blitzmax error):
Compile Error: Overriding method differs by type


I don't currently have time to fix it but have posted it here and on the repo for future reference. Anyone else got some free time to fix this?

https://code.google.com/p/monkey-max/issues/detail?id=2


therevills(Posted 2013) [#53]
I had a quick look at that error Skn3 and its due that Monkey doesn't like to override Functions or Methods like that... I guess we would need to kludge it so that the extend class has a slightly different name, but would that mess up some OO along the way?!

In other news I've updated MonkeyMax to v70.


Skn3(Posted 2013) [#54]
Hurrah team monkeymax!

I did take a quick look too at a kludge fix, but stopped as I was a bit busy. Probably needs some serious head scratching to make sure it doesn't kill the OOP.


ziggy(Posted 2013) [#55]
I don't see how it makes sense to override a function into a class... ?? --> I was begin stupid and thinking on Overriding instead of Overloading (My english, you know...).

That said, Monkey does not allow derived classes to add new overloads. This is by design. So it does not look like a bug at MonkeyMax, but more like the way Trans works-

EDIT: In fact, if you try to force it, you'll see you're not overriding it:
Function Main()
	Local b:Base = New Base2
	b.DoThis(10)
End
Class Base
	Function DoThis:Int(x:Int)
		Print "Base"
	End
End

Class Base2 Extends Base
	Function DoThis:Int(x:Int)
		Print "Base 2"
	End	
End

On C++ target this outpus "Base" instead of "Base 2". So it seems both functions are just different functions, not any kind of overriding implementation.
Not sure if this brings any clarity or adds confussion...

EDIT3: This adds more confussion to the party!
Function Main()
	Local b:Base = New Base2
	b.DoThis(10)
	Base2(b).DoThis(10)	'--> How can this be solved??? It's a clash!
	Base2(b).DoThis(10, 20)
End
Class Base
	Function DoThis:Int(x:Int)
		Print "Base"
	End
End

Class Base2 Extends Base
	Function DoThis:Int(x:Int, j:Int = 5)
		Print "Base 2"
	End	
End



It seems that Monkey is using the class in a variable declaration to solve function calls binding, instead of using the actual variable instance class kind. That's somehow expected as you should be able to call functions without any instance as they're shared and instanceless.

So... mmm... back on topic....

Yes, you can't add overloads on derived classes. In my opinion, it looks like something that could be added for functions very securely.


BlitzProg(Posted 2013) [#56]
Hi, I've followed the instructions to install BMAX target over V69 (made a duplicate folder, downloaded the files, copied over the duplicate, edited the file config.winnt.txt)

But I can't get the BMAX target to appear on monkey. How am I supposed to install it?

Thanks if you can help.

Edit: Got the BlitzMax target to work after doing the following

What I did in additions to the instructions
Installed MinGW
Copied bin and target folder from V69MAX to V69MAX\src\transcc\transcc.build
Opened transcc.monkey and ran it with c++ tool target
Moved V69MAX\src\transcc\transcc.build\binmain_winnt.exe to V69MAX\bin\transcc_winnt.exe

Blitzmax target: Not working (missing files) - Copied the files that were in the wrong location over to where they were required. Yes, copy, not move, since their original location was required as well (???)
The code worked but failed to launch since several classes were in double. So I manually edited it and it worked.

Generated graphics do not appear to work, I'll go and check what's wrong.

Edit: Re-did the process, doesn't work anymore, the application repeatedly send "Attempt to index element beyond array range" exception until i kill the process. :/

Looks like i'll stick to V63 for a while...


Karja(Posted 2013) [#57]
I've updated the repository to work with v74a. There wasn't much to change - but just wanted to let you know!


therevills(Posted 2014) [#58]
Looks like Karja has been busy with this :)

* Added rudimentary support for HttpRequest. Encoding and error handling not yet added beyond the bare basics. Jan 26, 2014
* SaveState() and LoadState() now saves and loads to the user's data dir on Windows and Mac instead of directly to the app folder. Jan 27, 2014
* Updated MonkeyMax to work with Monkey v76d and added some experimental things for databuffers and filestreams. Feb 1, 2014
* Corrected the GetDate function. Feb 1, 2014
* Made it possible to build Mac builds of MonkeyMax projects. Feb 17, 2014

Top stuff Karja!


Karja(Posted 2014) [#59]
As you can tell I'm not too fond of the normal desktop target, and I'm nearing release of my game - so I'll probably be adding and updating small things now and then to this one :)


MikeHart(Posted 2014) [#60]
Cool stuff. Is this target compatible with the sandboxing requirements of the apple appstore?


Karja(Posted 2014) [#61]
I haven't looked into the appstore yet, but I can't imagine that being any problem. BlitzMax compiles native code, so if there are any issues I'd imagine that it could be with regards to the experience in general (i.e. has to have intuitive controls, perform like normal Mac apps, etc).


Playniax(Posted 2014) [#62]
Hi,

I wanted to give MonkeyMax another try but I can't get it to work with 79e.

Is it supposed to work with 79e or am I missing something?

Target is not showing.

Bye,

Tony


Raz(Posted 2014) [#63]
Same with me Playniax as far as I can tell I followed the instructions but no sign of the BMAX target. I remember the install process being pretty easy about a year ago, so maybe something has changed?


Playniax(Posted 2014) [#64]
Yeah, I have tried it a couple of times and even with different monkey versions.

I don't have the time right now to go into it further :( but it's a shame I can't get it to work.


Karja(Posted 2014) [#65]
I can see if I can write up a new installation instruction, as I'm actively using it myself. It definitely works for v79e at least.


Playniax(Posted 2014) [#66]
That would be great!


therevills(Posted 2016) [#67]
Moved the project over to GitHub:

https://github.com/therevills/monkey-max