Question for Brucey
BlitzMax Forums/BlitzMax Programming/Question for Brucey
| ||
| Hi I saw in the past weeks some 'strange' (for me at least...) post, about compiling basic example and so on. http://www.blitzbasic.com/logs/userlog.php?user=8077&log=1889 I suppose you are testing on a BMK-NG-2 (the last post is about 64bit under OS X); in another one I read 'ARM'. So the question... are you working on 'more' than a BMK, like a 'BCC-NG' version or my imagination is gone too far away? Just to know! |
| ||
| Hallo :-) Your imagination appears no too far away in this case. |
| ||
| http://www.youtube.com/watch?v=t925JwYXhVA |
| ||
| Still a long way till your sound might be useful @ xlsior. bye Ron |
| ||
| Not too far, I think. |
| ||
| Oh! Nice, very nice. Waiting for seeing this future (I cant' imagine how you can do this 'magic'... but I'm very interested in it!) |
| ||
| +1 for being very interested! Thanks Brucey for all your work on Blitzmax. |
| ||
| definitely interested in 64bit osx :) |
| ||
| 64bit linux is also running fine. I hope there are some enthusiasts around willed to port the gl-modules to something compatible with ARM ... raspi and android would be a nifty addition. bye Ron |
| ||
| So, just out of curiosity: Is a 64-bit windows version also on the horizon, or...? |
| ||
| I don't have a 64-bit Windows box, so I wouldn't even know where to start with it. At the moment, I'm focussing on stuff that I can work with (OS X, Linux, Pi). |
| ||
| That's too bad... :-? |
| ||
| Does not work on win xp 64 yet (needs changes within blitz.mod to adjust how 64bit variables get stored in memory registers - this should already be done for the "other" platforms). bye Ron |
| ||
| That's too bad... :-? Well, one thing at a time. The generated code is going to be the same regardless of the platform - since it's just C. It's more about the implementation of core stuff that may need tweaked, which can be tackled when the time comes. Apparently WIN32 is valid for x64, so there may not be too much to change in the modules. bmk may need some changes to support different linkages and whatnot. But I've plenty to do for now without worrying about the minor platforms :-p |
| ||
| Anyone got a PS4 dev kit they can lend me for a month so that I can add support for that? |
| ||
| aha, sounds like you're doing a monkey? translate bmx code into c and then compile native? |
| ||
| Except of course that Monkey is not modular like BlitzMax and doesn't have low-level support, which makes it rather difficult to do interesting things. And Monkey is only for games. |
| ||
| Brucey have you thought about starting a kickstarter project for this? I don't know much about them but people make them for everything. This might help you get a PS4 devkit. I am sure people here will support you. |
| ||
| one thing that immediately springs to mind is you can use max for development and then this method for final compile. so you would have no looong wait for compile (like monkey) :) |
| ||
| Please keep in mind that "translating bmx to c" also means: including platform pitfalls in bmx. So you cannot compile "oldschool bmx" to ARM without trouble. While things work which blitzmax does not handle in its modules you have to adjust the modules itself (opengl, audio, ...). But hey... 64bit on the desktop is also something useful. Maybe it strives enough interest to bring some improvements to the brl/pub modules. @adamStrange: There is no need to use "max for development and then this method for final compile". It would replace that step (100% compatibility aimed I think). So you code your ".bmx"-files, press compile and voila... binary file. bye Ron |
| ||
| you can use max for development Or just use this for development and final compile. That's what I'm doing. The last thing you want is multiple different steps to make something. Better just to work like normal and not even care what intermediate source is generated. so you would have no looong wait for compile (like monkey) :) It's a problem with Monkey in that it does a monolithic build - hence the time to compile anything reasonable in size. Sure, you can't make html5 apps with BlitzMax, but I don't need it to. have you thought about starting a kickstarter project for this? No, because it's just for fun. :o) |
| ||
| are you looking for testers? I've got a heavily modified audio core which would be good to see in 64bit :) (it adds a lot of synth stuff like adsr, lfo's, effects) |
| ||
| I guess compiling via c means you are using a new garbage collector? If so, how does it compare to the default one in BMax? Does it handle circular references? Does 64 bit compiling also means BMax will support pointers to 8 bytes values? |
| ||
| testing is currently done with sct -> there is to-test-sourcecode and the output of a binary is compared to a desired result. Freeaudio (this is the one you are refering to ?) is compiling but not tested yet. Lazy people tend to skip writing tests if things do not throw errors. Hmm how to write a "tool recognizeable" sound test... sound loading (and reading information about a music file) is something different. Hmmm. bye Ron |
| ||
| Lazy people tend to skip writing tests if things do not throw errors Thanks :-) ...you are using a new garbage collector? We're using Boehm. If so, how does it compare to the default one in BMax? Given that the default one does not work with x64 or ARM, it compares very well. Does it handle circular references? Possibly not. You need to use some amount of common sense when writing your code. Does 64 bit compiling also means BMax will support pointers to 8 bytes values? That's a bit of a given really. And is a problem when it comes to porting the modules - since there are many places where Int is used instead of Byte Ptr. Getting through them though, and stuff isn't crashing so much now ;-) |
| ||
| Possibly not. You need to use some amount of common sense when writing your code. Boehm supports circular references - it's half of the entire point of its development (for the record basically every GC outside of Max's original supports this: it would be a bit weird to bother offering something as a third-party plugin that didn't fix this problem). Boehm is a tracing GC, not a refcounting GC; only refcounting GCs (of which there are now very few because it's a bit of a dead-end technology in a concurrent world) have the circular-reference problem at all. (It does have some impact on finalizers, but in theory you're not supposed to rely on those ever running anyway.) So who's "we"? Are you looking for help? :) Also what's Mark/BRL's opinion of and involvement in this? I know Mark often takes a "well I guess I can't stop you" attitude, but ...that was still always the real sticking point in the past. |
| ||
| Also what's Mark/BRL's opinion of and involvement in this? Everything is based on all the open-source code Mark has kindly provided the community - Monkey's trans program, and the BRL and PUB modules. Trans was ported to BlitzMax then modified accordingly to add support for all the things that BlitzMax has that Monkey doesn't (pointers, function pointers, byte, short, double, long, etc)- a new translator was written which generates source in a brl.blitz compatible format (i.e. object-oriented C) There's been no involvement with Mark/BRL concerning this project. I doubt it is something he'll be largely happy with, but I want to use BlitzMax on x64/ARM/iOS, etc. and I can't as it stands at the moment. |
| ||
| @Yasha If you have a closer look at [removed hint where to find the project - leaving it to brucey if he wants to "promote it"], maybe you find the projects files. @involvement Albeit it may be morally not the most perfect approach but using "open source"-code (think most is "zlib/libpng"-alike) the only think that "we" has (sic!) to care for is naming the original author and stating that it is a modification (if it is one). As Brucey decided for zlib/libpng-licence too, it is even possible for MS (not the Redmond ones :D) to sell the binary of the open source project. So this isn't a dead end for the BlitzMax product itself. @Sound Just created a sound example - but as Brucey modified freeaudio - and I use a modified freeaudio for normal BlitzMax (Pulseaudio etc.) it kept silent on my pc. Maybe Brucey can validate a succesful output on his machine. bye Ron |
| ||
| So you are working on a BlitzMax64 version (iOS, Linux at least) running on x86/ARM hardware!?!! And maybe compiling for different OS/hardware on the same machine? I know you are doing this for personal fun. But I hope Mark is looking at this thread with a 'positive' way: I'm not an expert, but I suppose something good for BlitzMax, Monkey-X and BRL (and users old and new) will be raise from this thing. |
| ||
| So you are working on a BlitzMax64 version... ? Not really. Just something that happens to compile for 64-bit architecture. It's basically just a bit more portable because it isn't relying on architecture-specific assembler. |
| ||
| Would it be possible to build an app (game) from Bmax for the Pi ? That would be great ! |
| ||
| Think that depends on things like opengl-module compatibility (which might have to get "build" first ... by extending the module code with some "?ARMx blacode ?" like it is done for ?win32 or ?linux) bye Ron |
| ||
| OpenGL ES is not the same as Open GL. So BRL.GLMax2D will need some effort to make it work with EGL. |
| ||
If you just add this line at the top of the shaders:precision highp float; Then OpenGLES 2 and OpenGL are pretty much identical. At least for simple stuff. Note that GLES 2.0+ always requires a shader while rendering and completely does away with the FFP stuff. |
| ||
| "pretty much" If that thing sees the light of the day ... you could patch the module to run with GLES 2.0 :D. Somehow I think there is a "bit" more to do ... but maybe we have luck and things start to work automatically. Compiled Breakout 64bit yesterday ...  improving every day. bye Ron |
| ||
| I found where this is and I'm very much looking forward to a finished version. |
| ||
| GAAAH WHERE IS EVERYONE ELSE FINDING THIS C'mon guys, at least give this poor fool a hint. |
| ||
| maybe someone has hidden that software egg on a code hosting platform. bye Ron |
| ||
| OpenGL ES is not the same as Open GL. So BRL.GLMax2D will need some effort to make it work with EGL. A bit late maybe, but did anyone do anything related to this? |
| ||
| A bit late maybe, but did anyone do anything related to this? Not yet. I'd like to go with OpenGL ES 2, rather than 1, since it's "better", but 1 is more like your standard OpenGL, whereas 2 moves a lot of the API into shaders. I'm sure we'll get there at some point. Then of there's concept of building native on NDK too... oooh. That would be a bit interesting, me thinks. Still, focus is on the core stuff at the moment. |
| ||
| [qoute] but 1 is more like your standard OpenGL, whereas 2 moves a lot of the API into shaders.[/quote] I think opengl es 2 is much closer to current standard of opengl (3.2+) than opengl es 1 ever was to previous standard (1.0-2.1). 1.0-2.1 should be ignored in new apps/games. |
| ||
| Well... I dont' have stats but based on Android OS diffusion a. OpenGL ES 1.0 and 1.1 - This API specification is supported by Android 1.0 and higher. b. OpenGL ES 2.0 - This API specification is supported by Android 2.2 (API level 8) and higher. c. OpenGL ES 3.0 - This API specification is supported by Android 4.3 (API level 18) and higher. Considering (a) market is very restricted today OpenGL ES1.x could be dropped without problems. |
| ||
| BRL.Reflection Oh, dear... I've just started to work on this. Whomever thought it was a good idea to use Int as a Byte Ptr, needs a good talking to! Most of the rest of the modules are working now. Although we are self-hosting (able to compile ourself - bcc that is), my bmk requires reflection and lua support - neither of which are working yet. Well, you know... save the best til last? I've acquired 64-bit Windows 7 Pro, and stuck it on a VM here, so at some point I'll be looking to try something with MinGW64. That should be lots of fun too, hey? Oh, and then there's MaxGUI. I will probably host a version of that with the rest of the revised modules. I hope there won't be too many "ints" there too - although I know of at least one. As for my modules, I've been working through them. Many are compiling straight off with no tweaks required. Some, that call back into BlitzMax, required some small changes because the naming generation for functions has changed a bit in places - in order to make things more unique. ;-) |
| ||
| I've acquired 64-bit Windows 7 Pro, and stuck it on a VM here, so at some point I'll be looking to try something with MinGW64. That should be lots of fun too, hey? Nice! |
| ||
| What about pub.glew/pub.opengl? You are porting those without many changes? There is code in bmax archives, that will upgrade opengl module to newest version, it would be nice to know if it works. http://www.blitzmax.com/Community/posts.php?topic=90520 |
| ||
| Not yet. I'd like to go with OpenGL ES 2, rather than 1, since it's "better", but 1 is more like your standard OpenGL, whereas 2 moves a lot of the API into shaders. I'm sure we'll get there at some point. Well, I have some incentives to contribute here but I thought Id have more free time available then I do. Ill give you a shout if I get anything done. :) |
   |