Overriding mojo functions
Monkey Forums/Monkey Programming/Overriding mojo functions
| ||
Is this possible and how?! I can create for example a Cls(r,g,b) function on my main build file which overrides the mojo Cls, which is great. But when I do the same as an import in a seperate file it does not work "error duplicate function" |
| ||
Alias Cls=myImportedFileName.Cls Alternatively you could just write it manually... myImportedFileName.Cls(0,0,0) |
| ||
I was hoping there would be a more user friendly way if the imported file was to be a public module. I.e if I Could use alias in the imported file instead of the Main build file, but alias dont work like that :( |
| ||
you can extend the GraphicsDevice backend. look at how i did this for minib3d, but i had to replace Surface as well, which results in some ugly hacks: https://github.com/adamredwoods/minib3d-monkey/blob/master/mojographics.monkey |
| ||
Thats great, thank you! the graphics side is working now :) Still one more issue though I need to do the same with the InputDevice. I can successfully set a new one with 'SetInputDevice()' but there is no GetInputDevice()? For example I need this to do: User calls MouseX() - which currently gets redirected to my MouseX() function I then need to access the real MouseX in order to times it by a scale factor and then return that. There is no GetInputDevice() funtion and _mouseX is private Any ideas? (there is a GetGraphicsDevice() and a GetAudioDevice() funtion, was the input left out on purpose?) |
| ||
Do you think Mark would consider adding the following to mojo's input.monkey ?Function GetInputDevice:InputDevice() Return device End |
| ||
It's a little bit clunky in some ways, but when I'd prefer a Mojo function to do something different I write one that's prefixed with 'My', e.g. MyDrawCircle() etc. and just start using that. |
| ||
Yeah I know, I wouldnt normally mess with the mojo functions, but this time its for an autofit module, I always make a game and then have to go through it all changing mouseX to VMouseX etc etc I have nearly finished an autofit module that, when imported, essentialy overrides (for example) the mojo's Cls() function to handle all of the boarder drawing and scaling etc, and calling functions like MouseX, SetScale etc return the scaled values instead, so you dont need to remember to use Vthis and VThat. I want to do it without changing mojo (apart from the above which I hope mark might see!). So basically all you type is 'Import autofit' and 'SetVResolution()' in OnCreate' and bingo everything else takes care of itself. Its nearly finished and working, but does require post#6 in mojo.input.monkey |
| ||
In my honest opinion, if a function is going to do anything different from Cls, it should not be called Cls. why don't you create an additional function? You could have compatibility issues and maintenance problems in the long run if functions do more than they should, and if they do silently, is not nice! |
| ||
I do understand where your coming from, but the pull of having a 'one command' virtual resolution is too strong for me :) It only overrides the std functions if you import the module AND use SetVResolution() function. You should try it and see :) |
| ||
Main program [Codebox]Import mojo Import autofit Function Main() New Game End Function Class Game Extends App Method OnCreate() SetUpdateRate(60) SetVResolution(600, 300) End Method Method OnUpdate() End Method Method OnRender() Cls(200, 200, 200) DrawText("Mouse: " + TouchX() + "," + TouchY(), 300, 150) DrawText("Device: " + DeviceWidth() + "x" + DeviceHeight(), 300, 165) End Method End Class[/codebox] autofit.monkey Add this to mojo's input.monkey (in a public area like underneath SetInputDevice()) Function GetInputDevice:InputDevice() Return device End p.s. The above function exists for mojo's GraphicsDevice and AudioDevice, so why not its InputDevice? |
| ||
How whould it play with any module that resets the transformation layer as part of its rendering? |
| ||
I think it would have the same effect as it would when using any other virtual resolution module? They all require use of a matrix scale. I think... but I have a very limited understanding of matrix and transforms :s I pretty much used the principles of an existing autofit module and made it integrate with mojo more. |
| ||
Ive found it not to work on Android anyway, so umm sorry for wasting time :s |
| ||
If.it's pure Mojo it should work for Android |
| ||
Comples ok, but get an unexpectadly quit when run on decice. The cls function works, but as soon as I add a drawtext it dont work, which is odd as I diddnt alter that function. I may try resolve it as it will bug me otherwise :) But other than that I think the general oppinion is dont mess with mojo lol so I will conceed it may not be a great idea |
| ||
I think it would have the same effect as it would when using any other virtual resolution module? They all require use of a matrix scale. Simply, wrong! Mine doesn't touch any matrix command at all. |
| ||
@ mike Oh... Apologies. I wouldnt have the faintention idea on how to autosize between decices without using scale :s beyond my abilities :) |
| ||
I *Think* Mike means he's not pushing popping matrixes, but I guess he's using Scale commands (so using the transformation matrix too, but not the matrix stack) |
| ||
Oh in that case Neither did I :) no pop or push |
| ||
I got around the need for a GetInputDevice() function in mojo as I just discovered 'Super' which of course lets me call the unmodified version of the function from my extended class :) But Ive had no luck on Android issue. Desktop release works, but Desktop debug doesnt, leading me to belive that it is because android is also in debug (until signed etc). The Desktop error points to where it sets the 'renderdevice' blend mode. So, maybe when I Use Setgraphicsdevice( new myExtendedClass) it sets mojo.graphics global 'device' but not its 'renderdevice'. (both of those are private) but looking though mojo.graphics code the 'renderdevice' is set to equal the 'device' at the start of rendering anyway Im completly stumped and confused! |
| ||
Just in case, notice that most graphic operations will fail outside the OnRender |