Programming in Blitz with an Eye to Monkey Port?
BlitzMax Forums/BlitzMax Programming/Programming in Blitz with an Eye to Monkey Port?
| ||
| I want to write something in Blitz that will be as easy as possible to port to Monkey. Anybody have any thoughts about this? The engine will be pretty simple without much graphical glitz. Should I just write concurrently in both, in other words once I get something worked out in Blitzmax, write it in Monkey? |
| ||
| I assumed you could copy much of "basic code" to monkey without much hassle (it allows for "end if" instead of just "end"). As long as you do not use more advanced things (manipulating images, adjusting the dx/gl matrix, ...) it should work. Give it a try ... before doing work twice. bye Ron |
| ||
| Well, that's exactly what I would do. Believe me, duplication of effort is NOT my problem :) Chronic laziness is my problem and it's serious. Anything else you can think of making porting easier? A lot of it does obviously work and for things that don't I can make some sort of abstraction layer. |
| ||
| I wrote this little 'framework'... not sure how much practical use it is, but might give some ideas, at least in terms of basic layout: Monkey-style game framework |
| ||
| Wow, thanks very much. Strangely enough I was thinking of doing exactly this. Just so you know I think your new StudioX pack is really on the right track. Now I can get working on my roguelike shooter Assault Philosophers... |
| ||
| The easiest way would be to WRITE IT IN MONKEY. I may be wrong, but there is a free version of monkey to write in is, (Before you get a full lenience), and I think there is a Bmax target compiler for Monkey to make it Bmax. |
| ||
| I have the full license. The problem is, I prefer writing in Blitzmax, but Monkey has all those juicy targets. Mark is right, I can just write it in a similar framework and port it as I go. I think that'll be pretty easy to do. Tons easier doing it that way than trying to remember how you wrote something ten months ago. |
| ||
| i did this and converted a project to monkey, it really didn't take much effort at all. the scale and rotates are on the image itself instead of calling it globally. which i believe you still can do that but you have to be mindful with it by popping and pushing the matrices around. |
| ||
| I have the full license. The problem is, I prefer writing in Blitzmax, but Monkey has all those juicy targets Just in case you were unaware, Blitzmax is getting more and more targets too. I don't know if they're all fully functional at this point in time yet, but here are the output formats listed by Brucey's (experimental) tweaked BMK as of right now: MacOS : x86, x64 Win32 : x86, x64 Linux : x86, x64 Android : x86, x64, arm, armeabi, armeabiv7a, arm64v8a RaspberryPi : arm Emscripten : js (javascript) Unlike the official Blitzmax bmk/bcc which builds and compiles ASM code, Brucey's version translates blitzmax to C first and compiles that, making it much easier to adjust for other platforms. This was made possible in part by some of the open-sourced components of Monkey |
| ||
| I was indeed not aware of that. Brucey is really a monster. What next? |
| ||
| What next? Bug squashing ... trying my (a bit bigger and "unconventional coded") game with Bruceys compiler uncovers some bugs here and there... so top priority is fixing bugs instead of adding targets. If your game is a "done once, later only support" thing (instead of continuosly evolving) I would do the monkey route. Exception is if the game will get very comples and is targeting "desktop", in that case stay with BlitzMax and "hope for NG". bye Ron |
| ||
| Derron +1 I would say monkey isn't ready for massive projects unlike max. Tbh I was writing Star Rogue in monkey but I've moved development to another platform with an eye to multiple targets due to an issue I was having with monkey. |
| ||
| ...but I've moved development to another platform... You can never switch platforms too many times for a single project, huh? ;-) |
| ||
| Nah I have a working version on this platform so I'm continuing with that, tbh I should have done it years ago but wanted to see if its capable. Unfortunately I don't think its ready for huge projects. |
| ||
| I think I'm just going to stay with blitzmax. You can never switch platforms too many times for a single project, huh? ;-) What platform you should develop for is a hard question. Some new product might come up that might cut your effort in half, but usually such migration efforts seem like false starts. They very rarely pan out. |
| ||
| Zoqfotpik: unless you intend to do mobile I would stick with max its MUCH more capable than monkey |
| ||
| I also can't decide if I want to do a simpler roguelike shooter game to build an audience or a more fully featured large project. The shooter concept could easily stand tablet and phone ports. But how much money do those really make? Whereas with desktop there's much better noise filtering and an actual real community as opposed to just a storefront overrun with marketing people. I guess I could do what some others do which is to work on two projects at once. |
| ||
| TBH I have a nice system to fly around now already and im modelling the stations and jumpgates, after that I will be adding the nebulas too :D |
| ||
| Porting to Monkey-X is no problem if you write the BlitzMax code to be friendly for such a port. The trick is not to use pointers, use Monkey-X compatible commands and define all variables aka myvar:Int. You must resist using any BlitzMax exclusive commands or structure. Phoenix USC (my project) is developed in BlitzMAx but will port to Monkey-X with few problems as I developed the project to be able to be ported to Monkey-X. Here is an example. This is the window framework for Phoenix USC's GUI system written in BlitzMax and ported to Monkey-X as a Flash demo. The port of this framework was fairly easy and required only a few modifications. http://www.phoenixusc.com/board/misc.php?page=PUSC_GUI Thread here: http://www.monkey-x.com/Community/posts.php?topic=9566 I will be porting the GUI components framework shortly and before you know it I will have the entire Phoenix USC's GUI system ported. My point is that it is fairly easy to port from BlitzMax to Monkey-X as long as you use the simple tips listed above. |
| ||
| Another thing is if your gonna target mobiles don't have functions that hog the main loop otherwise it will get killed by android after a second or so. |
| ||
| Is there a list of Blitzmax functions that don't exist in Monkey? |
| ||
| Everything coming from modules different to "brl.mod/Blitz.mod" is questionable: either does not exist or exists with same name - or exists with a different name. So some of the things "MaxIDE" colorizes as "known function" are not known to Monkey. The more basic your blitzmax code is, the bigger the chances that it runs without many changes. bye Ron |
| ||
| There is also loads of variable types gone as well, there no Byte, Long etc you only have int, string, bool etc. Pixmaps are out, time hogging functions are out. There's no DefData system, file Io is only supported on some targets. Not all targets have everything. Networking is VERY basic and once again not always in all targets. Tbh monkey does come across as Very limited. But if you game is very basic on the max command set then you should be ok, if your planning on the HTML5 target then its waaay more restricting as there's just basic drawing and sound for that one and little much else. |
| ||
| ... there no Byte, Long etc you only have int, string, bool etc ... People appear to be managing to write games in Monkey without all those "extra" types, so presumably you don't really need 8-bit or 64-bit numbers. |
| ||
| You should also think about the usage of "SetScale" or rotation ... seems you need to pop and push the matrix openly available in Monkey. So like said: the less of the Blitzmax-featureset you used, the easier it gets. Next to the "added functionality" most of your "logic" will just work fine (your ifs, elses, local, global). bye Ron |
| ||
| @Brucey: I agree the thing is porting from max to monkey ya need to know about its changes :) I'm not saying its impossible but you have to know the changes and the things that are not in monkey. |
| ||
| Monkey-X has it's limitations but that's the cost of doing business as a translator. Once you are famillar with Monkey-X writing code in BlitzMax and porting to Monkey-X is really not too difficult at all. There are really are only a handful of Monkey-X commands that are exclusive and require you to modify the codes structure. Some commands like SetScale and ViewPort() (BlitzMax) have compatible counterparts in Monkey-X like Scale() and SetSissors() Darron brings up a good point about Scale() and Matrices. Perhaps a better option (the one I used in window framework) then Scale() is to use Transform() which allows you to set the scale of the Matrix. All in all I see no real barriers to originating code in BlitzMax and then porting to Monkey-X based on practice and my experiences in doing so. In fact your code takes on a more portable disposition which is proving to be valuable in getting my project working with bmx-ng. |
   |