@Brucey - what are you doing?
BlitzMax Forums/BlitzMax Programming/@Brucey - what are you doing?
| ||
| Given my current plight I don't know why I didn't ask this sooner. I see you're basically rummaging around in the innards of Blitzmax quite a lot... and I got to wondering what your intentions are. Are you planning on doing stuff to Blitzmax as and when you need it yourself, or is there a long-term aim to keep flying the Blitzmax flag for as long as possible and turn it into a more modern, mature product? |
| ||
| My initial intention was to be able to make 64-bit native BlitzMax apps, which I can do now. I'd like to try to "future-proof" it, by giving it a bit of a leg-up. Then I must have banged my head or something as I'm now very keen in pushing BlitzMax onto other platforms too, such as the Raspberry Pi, iOS and Android. The main stumbling block here is the graphics - I can pump out wrappers til the cows come home, but all this GL and shaders stuff just makes my head spin. So I've hit a bit of a wall currently. Otherwise, the translator/compiler is working very well. There are a few niggles and some cases where it still falls down, but it generally copes fine with your average BlitzMax code. The new SDL backend also appears to be working well. For example, I dropped it in place of GLMax2D for Wiebo's Asteroid framework demo, and it *just worked*. It basically replaces GLGraphics (which sets up the window/fullscreen/context) and System (which processes input events). The SDL backend also happens to be natively supported on iOS, Android and the Pi - thereby making it a no-brainer to use as a backend on those platforms, rather than trying to figure out how to do it myself. I'm also looking at some different audio drivers - like SDL_mixer - which is also working in some basic tests. It supports multiple channels + 1 streaming channel (like for music). Then there is ALmixer, which is a similar API but using OpenAL - the difference with ALmixer is that it supports many streaming channels (where a stream is something you play from disk, rather than from memory) And in other news, I've been trying to keep other libs/modules reasonably up-to-date, like libpng and friends. Basically, I like BlitzMax as a language, and just want to make it useful in the long-term. |
| ||
| ..this GL and shaders stuff just makes my head spin. So I've hit a bit of a wall currently. How so? What kinds of issues are you running into? |
| ||
| Interesting... does any of this come with BRL's support/endorsement etc? Would you be happy taking over the helm if that's what it came down to, or don't you want that level of commitment/responsibility? |
| ||
| How so? What kinds of issues are you running into? Well, for starters, I just haven't the time to invest in learning OpenGL and shaders. That's why we have modules which take care of all the low level stuff for us (things that I'm sure GfK appreciates too). Of course, when the time comes that one actually wants to change those modules, then one is a bit stuck with not having much of an idea what's going on :-p I have a half-complete BRL.GL2Max2D module, which attempts to use shaders as a replacement for the direct pipeline. It's based on zzz's example. Currently it supports lines and rects thru the shader. Textures however I've completely failed to get working. I would certainly appreciate any help to get it running :-) |
| ||
| If GL and DX are available using SDL and it's "a no-brainer to use as a backend," then would it be easier to get the Max2D stuff working that way? |
| ||
| does any of this come with BRL's support/endorsement etc? I've never discussed anything with Mark, although if he does at least browse the forum on occasion one might have expected him to notice what's going on. Perhaps he's having too much fun with his Oculus Rift to wander here these days? However, Skid appears to be enjoying playing with BlitzMax on his Raspberry Pi ;-) As for taking over, I can't really see my "port" becoming an official replacement for BlitzMax. Ideally, I suppose, one would base everything on the original parser, rather than my hack of Monkey's. Back-fitting all of BlitzMax's extra functionality has been a job and a half. I'm also up for community involvement where its useful - like for instance, with help getting the graphics engine more up-to-date. There are some people who are good at certain things, and others who are good at other things. This is how other projects work - you get Joe Blogs fixing section X, and John Smith upgrading section Y. In the end we have a better product and everyone is happy. My only concern there - from experience here on the forums - is that the community here tends to be a lot of talk and not so much doing. Which is really sad. With various individuals help, I believe we could do a lot for BlitzMax. |
| ||
| If GL and DX are available using SDL ... would it be easier to get the Max2D stuff working that way? I have a working GLSDLMax2D module. It is a drop-in replacement for GLMax2D. It works in exactly the same way as GLMax2D - but sits on top of the SDL window/fullscreen/input handling code, rather than BRL.GLGraphics and BRL.System. Using SDL in this way only provides a GL context, and our GLMax2D is based on OpenGL 1.x. It won'r work on mobile platforms. There is a specific SDL Renderer which handles textures through shaders, but it's abstracted in such a way that I doubt we can use it in a Max2D way. i.e. you'd probably have to rework your code a bit to use it - which is something I'm trying to avoid. The other option is to create a Max2D module which implements all the drawing using modes that are compatible with OpenGLES 2.x. (I think this would be OpenGL 2+ as a minimum?) This means a move to shaders. GLES 2.x doesn't have things like glBegin, so you have to throw away that whole pipeline and come at it from vertex arrays, vbos, and shaders, and so on. You don't necessarily need SDL for this either, as you will only be using the GL Context that is supplied by whatever backend you are sitting on (SDL or GLGraphics, for example). |
| ||
| ..the community here tends to be a lot of talk and not so much doing.. Yes, but not everyone can devote that much time to what is essentially a hobby. I guess you have a pretty good day job. :)I use GLGraphics and the only reason I'm using GLMax2D is because I need an easy way to draw lines for debugging purposes. Is your GLSDLMax2D module working in Windows? I could take a look at it, but I've had problems with bmax_ng before. I switched it out a while back and my engine compiled fine, except for one issue with FreeImage. The odd thing was that none of the samples would compile for me. However, I'm using regular MinGW, not TDM. Could that one factor make that much of a difference? |
| ||
| @Brucey Hows skids attempt going? I havent forgotten about this, but I dont have much free time to put towards coding, and I kind of put it on hold completely when I saw he'd have a go at it. Him being a more knowledgeable and seasoned coder and all that :) |
| ||
| I'm also up for community involvement where its useful I would love to help. But I'm windows only. Unless you have a binary package to download or detailed instructions on how to build/setup the environment, I'm a bit lost on where to start. |
| ||
| I would love to help as well, but I'm a fairly high level kinda programmer. That's why I love Blitzmax :) But I'm game. |
| ||
| My only concern there - from experience here on the forums - is that the community here tends to be a lot of talk and not so much doing. You find that everywhere. Blitz, Monkey, Gideros, etc. etc. It always comes down to the individual and if she/he has the motivation to do it on their own. Or you get a huge group starting which falls apart within' a blink. I have experienced this quite a number of times. Very rarely it will work. I was also looking forward to a BlitzMax replacement and your posts looked very promising. But this topic here sounds to me like you are more fiddling for yourself, you don't really have the time to go for it completely and some parts are more hacks than something solid. Maybe I got it wrong. |
| ||
| This is just missing self-confidence. Until everything works it is always "hackish" or "fiddling/tinkering" around. I like that words, as they explain what happens here: people use their sparetime to create something - without the crowd yelling and crying that something has to get fixed "asap" or that they "never buy something again from company X". Brucey needs things to "tinker around" - see his modules. But of course it is no "full time job" so he asked for support by others. Nobody said that Mark hasn't done a great (in the sense of "huge") job - redoing only parts of it already would take ages to do. This is why there is the request for help in specific areas. I know there are many here already having published COMMERCIAL applications written in BlitzMax - so they wont be people just throwing in some copy-pasted code from elsewhere + assets, no they are people who tinkered with their own games too. They might not have the time to do hours of work for the "NG"-project, but they might give it a blink of their time to test some things, narrow down what exactly does create an error - or segfault, and report that to the issue tracker of the project on github. But hey... better fiddle around here and there and wait until something gets finished (or not). Such projects also allow people to "re-engage" for something - to reactivate old blitzmax-frenzy. I know that "open source" projects do not rocket on their own - so give it a chance and see if you can help it in some parts, even if at the end of the day the project might be dead. So for "non-tinker-coders": if you are on linux/mac it is easy to setup. Download it - check if your custom code compiles and file in some bug reports - or have a look at the compiler and maybe you are brave enough to play with it a bit. Of course you wont be able to recognize the functionality of every piece of code but here and there ...you might find a little bug to squish. bye Ron |
| ||
| BlitzMax-NG could also be detrimental to the health of BlitzMax. BlitzMax isn't broken, but if BlitzMax-NG becomes a distribution the namespace pollution with BlitzMax (which isn't broken) becomes an issue worth considering. I am not stating that BlitzMax-NG is broken, I am just worried that people don't understand how polished/complete/finished BlitzMax is from majority of end users point of view. BlitzMax did begin it's life on the Mac and that platform is perhaps not so far away from going 64 bit only in which case I suppose end of life issues for the original distro become a lot more real. |
| ||
| It would be nice to see it rolled into something official and supported. The only way I can see that happening is if it had some commercial interest. |
| ||
| BlitzMax isn't broken It certainly isn't, and 32-bit desktop apps will run faster with BlitzMax than with BlitzMax-NG. It's an excellent language. The job it does, it does very well. With NG, I'm just trying to extend it onto targets/architectures that it doesn't support. Sure, Monkey is already there, but it's missing a lot of the functionality I'm used to with BlitzMax. A BlitzMax-compatible compiler means I can use my modules across many different targets/architectures - rather than rewrite everything to support Monkey instead. A little choice can't hurt too much? |
| ||
| @broken blitzmax: You know about the situation of the "ide", fltk-maxgui, sound problems on linux (eg. with pulseaudio and other sound sources playing simultaneously), faulty window handling on extended desktops (destroys it and sets to cloned - which force-resizes apps on the extended screen), ... . Of course most of them are not connected to "NG"-works - but some of them are tackled "along the way". Also without the "revitalizing" portion the NG might bring along it might revive interest of other users. With the future surely passing by the next time, more and more bugs will "appear". There will be a time with "BlitzMax" (in its current state) can get called "broken" (for specific target platforms, for all, for specific areas ...). @Pollution: For now NG aims to be "compatible" - but this is only valid for the compiler itself. Every new target platform cannot be "compatible" with vanilla, every module Brucey wraps for "NG" must not be compatible with vanilla (dunno why it shouldnt, compiler-wise). For "people" this does not change the view they have on "a polished/completed/finished BlitzMax". They just might recognize: ok, BlitzMax has everything onboard, but there are additional modules covering problems the vanilla ones have - and hey, there is another compiler (trying to do/)doing the same thing than the original one. So when leaving out "bcc-ng/bmk-ng" you end up with saying that new modules will taint the opinion people might have about BlitzMax. Think that is not true - or from another pov - it is true, that the opinion about "polished/complete/finished" should get some cracklings as it is not 100% perfect in all situations. But hey, you are more likely in the position to know how many active users BlitzMax has - and how many new it attracts per month (squinting at the affiliate-promotion-thread). If there are up to 0, nobody should really worry about a potential "pollution" as it just virtually replaces the "old product" (it does not replace, but "build upon it"). In Short: like stated "BCC-NG" tries to be compatible with "vanilla BCC" (yesterday we even had to build in "limitations" to make things like "if bla then do endif" not possible) . This means: when replacing "vanilla BCC" with "new BCC" you should not loose functionality - you might get newer target platforms (and therefore conditional-flags) but thats all. Then there are changes to base modules, but the needs and whys are surely better explained by brucey. Every "3rd party module" will work in both "worlds" as soon as you take care of pointers correctly (byte ptr -> int). Sorry if this now sounded like a rant, I just tried to defend the "NG"-project as I like it very much (especially the "Open Source" aspect, as it really might help attracting people to help at my OSS game - also for now bigger Linux distros only allow OSS-games if the compiler is freely available too - they asked for inclusion of our game multiple times but hmmpf... ). Although "detrimental" to my sentences above: I would like an "extended" BlitzMax-language (some more OOP features like "overloading" - handled similar to the monkey2blitzmax-code). This would remove "compatibility" in one direction (ng->vanilla) but until this functionality comes, other more prioritized aspects should get tackled first. bye Ron |
| ||
| ATM mac osx can run both 32bit and 64bit bit being now 64bit only as the latest osx maverick version states how long is this going to be the case. Tbh I think 64bit support is the number one niggle for desktops these days, updated graphics and mobile targets are under that. With windows one day moving to 64bit only one day it will have to be updated or die, its in this instance that bruceys projects will keep blitzmax alive. |
| ||
| One question I have about this is, what licensing is involved with ng? I presume people are not free to use it without purchasing a copy of BlitzMax...? |
| ||
| NG is zlib/libpng-licenced (open source). All BRL modules got licenced by Mark Sibly similary. All Pub modules were already Open Source (that's why the "pub"). Modules by 3rd parties have their own licence - but were not shipped with the BlitzMax downloads. Within the lib-folder are other files: All lib files came from other OSS software - eg like MinGW when on Windows Within the bin folder are other files: ar.exe/ld.exe (or ar/ld on mac/linux) came from the compiler suite too bmk.exe - blitz "make" is OSS too, there is also an "bmk enhanced" or "bmk ng" The only "proprietary" thing is "bcc[.exe" - this is the BlitzMax compiler. Brucey started a replacement based on the "open source monkey compiler" published by Mark Sibly. Conclusion: Everything (maybe except the "samples") is available as Open Source variant. That is why everything to make it "run" is available at: https://github.com/bmx-ng It should even compile itself, but for now you need someone providing you a "bcc[ng]" build - or you compile it with the demoversion of BlitzMax. This means: you do not need to purchase a copy of BlitzMax to be allowed to compile things with "bcc-ng" and the officially provided modules of BlitzMax -but you better use the "bmxng"-modules as they contain patches making them compatible to generate eg. 64bit builds. bye Ron |
| ||
| trans (the Monkey language translator), from which the new bcc is derived, was released as Public Domain by Mark. The new bcc will not work with the default modules shipped with BlitzMax - you need to use those specific to bmx-ng. (due to different GC, code generation changes, etc) As Derron says, you'd need a copy of BlitzMax to be able to compile bcc-ng in the first instance - before you can use the new bcc to compile itself. It is otherwise self-hosting. The only bcc binaries I've released are for the Raspberry Pi :-) |
| ||
| But that does not mean that all need "a copy of BlitzMax". You just need one who provides a binary for your platform - maybe later this is done in "prebuild packages" (containing all needed things - except gcc/mingw ? - to compile something in your beloved "bmx"-language). gcc/mingw: this is the difference between "bcc" and "bcc[ng]" - the first one translates blitzmax-code to "assembler" which is then converted into a binary using "fasm" (flat assembler). The second one translates to "c", so it needs a c-compiler doing the final work. This is in our case mingw (windows) or gcc (rest). Dunno if you can "include" mingw in a "ready to go package". Else it needs a "installPrerequisites.exe" or so, which assists you in installing everything needed. bye Ron |
| ||
| I am very interested in working on some future BlitzMax product, or incorporating it into Leadwerks. I think the underlying idea of BMX has huge potential to be much bigger than anything its achieved in the past. |
| ||
| I hate to see Mark out of the loop on this, but I'm in the same boat. It occurs to me that if it were possible to build on all major platforms, a BlitzMax engine could give Unity some serious competition (and for a much lower price). |
| ||
| Why limit it to just being one 3D engine? There's a fundamental problem that almost all programming languages are really badly designed, and people are starting to realize it. That's why you see things like Swift and Jonathan Blow's talk about a new language for games. The language and module structure are what make BMX valuable. The actual implementation of different functionality is just a detail anyone can do. Make BMX friendlier for use with C++ and the implementations are already done, as Brucey is discovering with SDL. There's a ton of functionality already out there, but it's unattainable for all but expert programmers. BMX is the bridge that makes all of that accessible. |
| ||
| One will lead to more, I'm sure. But one thing that Unity has going for it is that it appears to be one singular product/solution. In reality, people are buying plug-ins to fill in the gaps, but all of that falls under one apparent brand. |
| ||
| +1 Just saying. |
| ||
| I hate to see Mark out of the loop on this, but I'm in the same boat. Me too, but that's Mark's prerogative. Brucey and I'm sure most of us would love to see some official BRL involvement in this. Make BMX friendlier for use with C++ and the implementations are already done Totally agree- one of the biggest headaches I experienced with Blitz.Blitz needs a simple, officially supported 3D engine to bring the community together and lower the bar for beginners, but the more the merrier. A new BlitzMax, pre-bundled with the power of the Brucey modules, a supported 3D engine and bindings and support for Leadwerks is a very alluring proposition. |
| ||
| Blitz needs a simple, officially supported 3D engine to bring the community together and lower the bar for beginners, but the more the merrier. Ehm, wasn't MiniB3D that simple 3D engine? |
| ||
| So technically BmaxNG is something 'free', and as OSS there could be derivative works, with many (too many?) variations (and incompatibilities). Something I don't like at all. I prefer 'one word' solution. (and Mark meanwhile is playing with his new Oculus toy? Nothing to say?) |
| ||
| There's a fundamental problem that almost all programming languages are really badly designed, and people are starting to realize it. That's why you see things like Swift and Jonathan Blow's talk about a new language for games Most programming languages are rather well-designed, but nobody uses them and then treats the state of C++ as the state of the art. Even Swift - which is a great leap forward for the mainstream and people moving to it is awesome - is still basically state-of-the-1980s. To quote some other folks on this subject: the video unfortunately reinforced my stereotype of game programmers being 10 years behind the rest of the industry and in general full of cargo cult like optimization tips If he writes C++ like that, he needs to put down his compiler, step back from the keyboard and then pick up a C++ book Jonathan lacks some insight/experience with how useful, and low-friction, type-systems can be Wrt programming languages, the problem is not that the tools don't exist or that the state of the art isn't advanced enough. We already know how to solve the vast majority of language-related difficulties. The problem is social: people ignore the tools because they're "hard to understand", then they get annoyed by the fact that the problem isn't solved so they try to patch a fix over C++, then declare it impossible to solve because patching over C++ didn't work. (The truth is that the tools aren't hard, so much as the problems themselves are. You can't escape from type theory. It's like a highschooler insisting they'd understand physics if only you didn't keep using all that math...) e.g. Did you know that the GC/malloc "debate" was solved twenty years ago? The bleeding-edge language folks have understood perfect zero-overhead compile-time GC since the 90s. Absolutely nobody uses it, because practically nobody in the industry can be bothered to understand what they're doing enough to recognise that it even exists (or think that "can't be done in C" == "can't be done", rather than considering that the C family is inherently defective). You can't see solutions to problems you can't articulate. (Sorry, that was wildly off-topic...) |
| ||
| Ehm, wasn't MiniB3D that simple 3D engine? Was it officially supported? Did it offer collision functions to at least the level of B3D? |
| ||
| Did it offer collision functions to at least the level of B3D? v0.5 - Updated collision and picking system - now uses the Blitz3D C++ source code, and is the same as Blitz3D in all respects Apparently so? |
| ||
| In that case it would make a good standard 3D solution for Brucey's distribution, IMO. |
| ||
| A pre-packaged 3D module like MiniB3D would be a good addition. The trick is to keep it simple and ignore feature requests. BlitzMax 2 should not try to have the best most advanced 3D engine in the world. The main value of "BlitzMax 2" is not the 3D module. The main value of BlitzMax 2 is the language. Relying on third party libraries like RakNet, FreeImage, etc. will eliminate all the problems of implementing this functionality, and allow BMX2 to leech off the popularity of these libraries, without being committed to them. Why try to make the best 3D engine when you can rely on Leadwerks, Godot, JME, etc., so you win no matter which is the most popular? When some new hot library comes along, BMX2 can leech off its popularity right away (in a good way). BMX2 does not need to be all things to everyone, it just needs to allow easy access to C++ libraries. -Cost of implementing functionality goes down. -Brand name association goes up. -Compatibility with existing technologies goes up. -Switching cost goes down. I can build a store into Steam that allows everyone to publish their own modules and sell them on Steam. If I knew how to write compilers, and I wasn't already doing Leadwerks, I would spend my time on this. |
| ||
| -Brand name association goes up. How do you figure that? People don't associate Language X with Engine Y unless they're bundled.I suppose engine makers could create their own distribution packages - I'd love to do that with my engine! However, I don't think the Blitz brand would flourish. |
| ||
| How do you figure that? People don't associate Language X with Engine Y unless they're bundled. 90% of my users program with Lua rather than C++. The thing that tempts them to use C++ is access to third-party libraries. However, the complicated nature of C++ and its library import system makes this out of reach for most people. Once a Lua programmer goes to C++, they are usually never heard from again. BlitzMax 2 could allow non-experts to access things like the OculusVR SDK, RakNet, Newton, etc. whereas they really wouldn't be able to otherwise, realistically. So when you have bindings come out for some new library that's cool, you make a press release about it and capitalize off the popularity of whatever's cool at the moment, i.e. "BlitzMax Makes OculusVR Accessible for Everyone". Instead of just being accessible to a lot of C++ wizards (who tend to be bad at finishing anything because they just want to endlessly tinker around with details) it's suddenly something everyone can play with. This also helps the library author because you can increase their audience by ten times. So I would expect to get some help from their side, i.e. a logo of Blitz on their website. Anyways, if anyone is serious about something like this, I would love to help with the business and marketing stuff. |
| ||
| Unless it all flies under one banner, like Unity does, I just can't agree that this form of branding will work on a large scale and give Unity real competition. Perhaps I'm misunderstanding something, but it sounds fractured. Sure, it's a more flexible system and reasonably technical users will get that more choices are better for them. But I don't think non-technical users will make that connection. They like all-in-one solutions and will not necessarily want to explore all of the options. |
| ||
| Why are you even talking about unity? That's like saying Photoshop won't offer much competition to Microsoft Excel. If you're talking about seriously entering the 3D engine market, I would stay away. The value of game engines has been driven to zero thanks to Unity's operate-at-a-loss-until-someone-buys-us approach. Unless you can carve out your own niche it's tough to sell anything. Historically, Blitz has always been stronger in 2D games. Here's where stuff like Box2D and SDL can pick up the slack. |
| ||
| That's like saying Photoshop won't offer much competition to Microsoft Excel. Except that it's not. I am very interested in working on some future BlitzMax product, or incorporating it into Leadwerks. The premise with which you started and I responded. If you incorporate it into Leadwerks, and it's cross-platform, then it starts to look more like direct competition for Unity. If you're talking about seriously entering the 3D engine market, I would stay away. Heh, I seem to remember this coming up a few months ago - right after the UE4 price reduction. Your attitude at the time seemed more positive. I admit I was pretty concerned (still am), but I've come to think that it's like deciding against opening a hamburger franchise because, y'know, there's already McDonald's. Unless you can carve out your own niche... Well, I'd be foolish not to do that. My engine has been in full-time development for almost five years. Unity has exploded in that time and you can bet I've been watching the entire market with much interest. The great thing about building something flexible is that it can be taken in a lot of different directions and even more so if it can be made cross-platform.Anyway, we have pretty much hijacked this thread. |
| ||
| The premise with which you started and I responded. What I mean is I would provide bindings for it and encourage my users to try it. Leadwerks would be just another library it supports. Heh, I seem to remember this coming up a few months ago - right after the UE4 price reduction. Your attitude at the time seemed more positive. Rather than fight over scraps of a dying market, I've moved on to a new one. The great thing about building something flexible is that it can be taken in a lot of different directions Yes, this is very smart. This will mostly be a matter of choosing the right features to eliminate/not pursue. |
| ||
| Looks like a win-win to me. A B3D equivalent engine bundled satisfies the old B3D crowd- if someone adds a few bells and whistles, all well and good. Leadwerks bindings would be a big plus for a bunch of people, so it's all good. I don't see this splintering the community, but bringing it back together behind the Blitz language. |
| ||
| For MiniB3D to be taken seriously it would need a DirectX backbend. |
| ||
| Tbh if you talking about blitzmax 2 it would be a huge benefit if it could access external modules much like for example SDL, racknet, unreal engine. The externals could be via a wrapper or imported directly, one thing much like max does and does well is expose the OpenGL internals making it easier for all. I think the main problem with things like monkey is its a completely different product that tries to do more than max but everyone over here in max land is waiting for the features to be added. Also I don't think that s direct x back end for minib3d would be a good idea tbh. |
| ||
| I agree with Kryzon. Unless the situation has changed in the last few years, OpenGL drivers can be outdated and a lot of the casual gaming crowd refuse to update them. |
| ||
| The problem arises when ya write for cross platform with directx being a windows only system it defeats the purpose when you have to use OpenGL on Linux and osx anyways |
| ||
| That raises an interesting idea... ...@anyone who knows about this, would it make sense/be possible to steal a WebGL implementation (from like WebKit or something) and use that as the default low-level Max graphics API? That way people who want OpenGL-style control (access to shaders and so on) can write the same medium-level code on Windows, *nix, and ES devices, while letting the hidden translation layer convert it to DirectX, ES, or whatever. It pushes the modules a level away from the hardware and would make Max itself that little bit more inherently cross-platform. People like Josh who actually need the performance of the real thing could always still use OpenGL directly, but it'd be made available as a non-core, potentially third-party, "wrapper" type module. |
| ||
| Kryzon is right - MiniB3D really should have gone with DirectX, even though anyone developing for OSX would be kinda stuck with the GL incarnation anyway - which is probably why GL was chosen in the first place. |
| ||
| Kryzon is right - MiniB3D really should have gone with DirectX, even though anyone developing for OSX would be kinda stuck with the GL incarnation anyway - which is probably why GL was chosen in the first place. MiniB3D was written purely for myself, so I could port Super Gerball to the Mac in the absence of any 3D module from Mark. So DirectX was never a consideration. |
| ||
| MiniB3D was written purely for myself Really? I never realised that. Mind you, I wasn't paying 3D much attention at the time. |
| ||
| The Windows-only nature of DX makes it a non-starter for me. steal a WebGL implementation (from like WebKit or something) and use that as the default low-level Max graphics API A while back I was looking into Chromium, partly for that reason. I think it's possible and would be a great addition, but not necessarily for the default graphics API. |
| ||
| A possible solution can be seen in Max2D, as it already offers a DirectX renderer (which it calls a "driver"). The driver is set automatically based on the platform that you're building your program on. It uses those ?MacOS etc. compiler directives to set the default driver, and Max2D is then presented to you in an API-agnostic way. On Windows it defaults to one of the DirectX drivers (I think it's version 9), but you can still manually set the OpenGL driver if you wish so (or even better, expose it as an optional driver for the user to choose), and it works if your GPU supports it (you need to install the driver from your GPU vendor, which is something some people don't care about). DirectX support already comes with Windows through system updates. On the other platforms the default driver is OpenGL obviously. If you don't really care about the driver, this method works seamlessly: go to a certain platform, build your BlitzMax program and it works. The native details are handled in the background. So to do the same with MiniB3D, you have to abstract the API parts under a "driver" paradigm like Max2D does, and code in two drivers for it, one with OpenGL 2.1, one with Direct3D 9. With just these two you support a broad range of systems since they're older versions but still support shaders, and the latest APIs are backwards-compatible with them. This driver system also leaves room for expansion in the form of additional drivers for MiniB3D, like for OpenGL ES (for mobile devices like Raspberry Pi), for Direct3D 11 (for the latest Windows desktops and notebooks etc.). Of course this all takes a lot of work. @anyone who knows about this, would it make sense/be possible to steal a WebGL implementation (from like WebKit or something) and use that as the default low-level Max graphics API? That way people who want OpenGL-style control (access to shaders and so on) can write the same medium-level code on Windows, *nix, and ES devices, while letting the hidden translation layer convert it to DirectX, ES, or whatever. It pushes the modules a level away from the hardware and would make Max itself that little bit more inherently cross-platform. That sounds like what the ANGLE project is for: https://code.google.com/p/angleproject/ The Qt framework documentation recommends that developers use ANGLE if they don't want to use OpenGL for rendering on Windows systems: http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL |
| ||
| That sounds like what the ANGLE project is for: It's pretty close. ANGLE takes care of the most difficult bit - it can convert OpenGL ES 2 to DirectX 9 - and is used as the backend for I think all WebGL browsers on Windows. But it doesn't provide a single 1:all layer by itself. I think it can provide most of the heavy lifting though. Since it seems that carefully-written OpenGL ES can be compatible with desktop OpenGL (API call wise), you don't actually need a translation layer between those two drivers; one piece of code can do both jobs. So a native-code driver only needs to provide WebGL->ES wrappers (which I'm thinking can afford to be lighter-weight than the WebGL spec mandates in terms of safety features, because Max is a statically-typed offline-compiled language), then let ANGLE decide whether to convert the API calls to DirectX or not. It can also recompile the shaders from ESSL to GLSL in the event that you're not using DirectX but are using Desktop GL, taking care of the biggest incompatibility within the GL family. There's a relatively-standalone MIT-licensed WebGL->ES wrapper here (and a C++ translation here, don't know if it's complete), which should be stealable. I'm'a give this a go and see how it turns out. EDIT: I gave this a go. It's not technically demanding at all once you know what to do, but the more I looked at it the more it seemed like a pointless exercise with no clear use case guiding the API. |
| ||
| Why not make a wrapper for Chromium? Then you get WebGL and web page rendering. |
| ||
| I was playing around with gdb from the command line, and it's pretty simple. It would take me just a few days to implement a visual debugger. It works similarly to the debugging stuff I did in Lua. |
| ||
| @Brucey I don't know if this should be the thread to post this, but I am willing to work on an OpenGL 2.0 programmable pipeline alternative to GLMax2D (should be easy to move from there to OpenGL ES 2) which It seems to be the biggest missing feature on your project. I just need someone to point me in the right direction on getting and setting up bmk-ng development environment. Info on getting bmk-ng seems to be scattered and difficult to follow (I'm not as familiar with github as I would like) Regards, |
| ||
| - install a gui tool like "smartgithg", it really helps downloading things - clone the github repos you need (or fork them, if you want to work on your online copy and sending "pull requests" later on. Then clone your fork): - - cloning means, creating a local copy of the repository - - "git clone https://github.com/bmx-ng/bmk.git LOCAL/DRIVE/PATH/DIR" Another option (if you just want to play around) is to go into the various projects on github, and on the right side of the file list you will have a button "Download ZIP" - this will archive the current project state and give it to you in a nice download package. Ok ... so what does that mean for you (I assume you want to have everything packaged in one folder): - create a directory, eg "BlitzMax-ng" - create a subdirectory "BlitzMax" there - go into "BlitzMax-ng" - "git clone https://github.com/bmx-ng/bmk.git bmk-ng" - "git clone https://github.com/bmx-ng/bcc.git bcc-ng" - "git clone https://github.com/bmx-ng/brl.mod.git brl.mod-ng" - "git clone https://github.com/bmx-ng/pub.mod.git pub.mod-ng" now you have this structure: /BlitzMax-ng /BlitzMax-ng/bmk-ng /BlitzMax-ng/bcc-ng /BlitzMax-ng/brl.mod-ng /BlitzMax-ng/pub.mod-ng If you do not want to compile MaxIDE yourself you just copy "MaxIDE" and the folder "cfg" from your original BlitzMax installation to "BlitzMax-ng/BlitzMax". - create a subdirectory "mod" within "BlitzMax-ng/BlitzMax" - now copy "brl.mod-ng" as "brl.mod" into the newly created mod directory (or symlink it, if your OS likes that more - so you keep it up to date then automatically) - do the same for "pub.mod-ng" You now have copied the new mod code into the new BlitzMax-ng. It is up to you to directly "git clone" into BlitzMax-ng/BlitzMax/mod/brl.mod | pub.mod - so you can just pull recent changes from github into your BlitzMax project. For the sake of easyness we use the copy-approach. Ok ... now lets compile bcc/bmk. - create a subdirectory "bin" within "BlitzMax-ng/BlitzMax" - open "BlitzMax-ng/bcc-ng/bcc.bmx" in the MaxIDE of the original BlitzMax, compile it (console build!) - open "BlitzMax-ng/bmk-ng/bmk.bmx" in the same MaxIDE and compile that too (also console build!) - copy "bcc[.exe]" from bcc-ng to "BlitzMax-NG/BlitzMax/bin" - do the same for "bmk.[exe]" from bmk-ng, but also copy "make.bmk", "core.bmk" and "custom.bmk" to the bin directory Now start BlitzMax-ng/BlitzMax/MaxIDE[.exe] and recompile all modules. If this is not available at the IDE, you will have to do it per commandline: "BlitzMax-ng/BlitzMax/bin/bmk[.exe] makemods -a" It then should compile modules - and you should be able to play with NG. EDIT: if really needed, I think we could provide a windows/linux-base-package which just needs the brl.mod/pub.mod-ng downloads (to keep filesize small). bye Ron |
| ||
| Ok I think I have enough information to play for a while. I will post my findings and issues later. Thanks |
| ||
| What version of MinGw should be used for building this? gcc 4.6.1 seems to be the one with the most compatability with vanilla Bmax. |
| ||
| I'm using TDM gcc-4.7.1, which can compile pretty much all of Brucey's libraries -- some of them don't work with older MinGW versions. |
| ||
| So, I tried compiling the modules. Everything except for appstub compiled succesfuly. The error I get is the following: Compile Error: Expecting expression but encountered 'ptr' [C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/mod/brl.mod/appstub.mod/debugger_mt.stdio.bmx;363;0] gcc.exe: error: C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/mod/brl.mod/appstub.mod/.bmx/debugger_mt.stdio.bmx.debug.win32.x86.c: No such file or directory gcc.exe: fatal error: no input files compilation terminated. Build Error: failed to compile (1) C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/mod/brl.mod/appstub.mod/.bmx/debugger_mt.stdio.bmx.debug.win32.x86.c ►►►►brl.appstub was not built. See error information on latest attempt. Not sure how to work around that. |
| ||
| I would like to move Leadwerks over to this system, but I need to wait until it is tested and stable. |
| ||
| Think this is your chance to be one of the testers... instead of waiting for everything being done nicely. @juankprada Maybe you should consider using a previous revision (before the commits for the debugger were added). Just click on a previous commit and you get the url of it - for a solo download - or use your git tool to pull a previous release. bye Ron |
| ||
| Ok thanks Derron. With a precious revision I was able to build all modules. No testing one of the samples throws the following error: In file included from C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/mod/pub.mod/glew.mod/.bmx/glew.bmx.release.win32.x86.h:5:0, from C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/samples/breakout/.bmx/breakout.bmx.gui.release.win32.x86.c:1: C:/Users/Juan Camilo Prada/Documents/Proyectos/BlitzMax-ng/BlitzMax/mod/pub.mod/glew.mod/.bmx/../GL/glew.h:90:2: error: #error gl.h included before glew.h #error gl.h included before glew.h Im not as familiar of blitzmax modules as I would like to be, so I cant really find where is that include that is causing the error. |
| ||
| I cannot help you with such issues - as OpenGL is the thing you wanted to care for - and "glew" is surely a part of it :p. bye Ron |
| ||
| There is a dependency now that Glew is imported before OpenGL - because of the way the headers work. I thought I'd found all the imports to fix that. |
| ||
| @Brucey Ani hints on where should I start looking at? I've been all day trying to find out where is the include being made but haven't found the answer. Thanks |
| ||
| I've just updated some of the modules - pub.glew, brl.glgraphics. Hopefully it will be okay now. Certainly if you use Framework you shouldn't have any problems. Non-Framework currently relies on the order the folders are retrieved - so perhaps I should sort that list before handling them - just to be sure O comes after G. |
| ||
| Just to make sure I've read this correctly. Mark = the god of blitzmax Brucey = the jesus of blitzmax |
| ||
| So who would be the holy ghost of Blitzmax? I like my trinities complete. |
| ||
| I am having a really hard time trying to get NG to work, so I am wondering if in order to provide an OpenGL ES 2 compatible GLMax2D implementation I could just use the official BlitzMax compiler and modules? As I understand correctly the modules should work in both official bmk and ng (please correct me if I am wrong) So that way, I could write a programmable pipeline for both So when I am done with the GLESMax2D it could be tweaked as needed for NG, or is it a waste of time and I should just stick to NG? |
| ||
| Ideally it should work for both versions. But "vanilla" uses things which are not compatible to 64bit NG then (byte ptr, ints .... just check what brucey commits with "64bit" in the description). Why do you have a hard time? Thought you got it compiled and just stuck with some GL stuff. If you use Brucey newer brl.mod/pub.mod you will have that changes in too - which might also create the trouble you see. As everything else (simple samples) seem to work, it is not "NG" itself but maybe a portion of it (gl stuff). bye Ron |
| ||
| Well, it is compiled but cant run any of the samples due to the GL error. And as I am also writing a game and I would like to use a programmable pipeline for it (performance reasons) I thought I could start by making it "just work" for the official bmk and once I have something working in OpenGL 2 I could just tweak here and there for the GL ES 2 |
| ||
| So who would be the holy ghost of Blitzmax? I like my trinities complete. Jayenkai. He's the holy ghost of all blitz products ;) Sorry for being off topic don't know where my head was in that one. |
| ||
| I think an " ----- SuperStrict print 1+1 ----- What especially does not work with glew/opengl now : I cannot answer you this question. Thought Brucey updated in his latest brl.mod-commit. bye Ron |
| ||
| @Derron executing that actually results in the same error as before. I updated and built the brl.mod and pub.mod after brucey commited pushed his changes. Still same error as before |
| ||
| Brucey updated something for "glew" but as long as you cannot compile a simple "calculation sample", the problem is something else. ---- SuperStrict Framework BRL.StandardIO print 1+1 ---- Using the framework, skips the inclusion of all modules. bye Ron |
| ||
| I've been re-working a lot of the code recently, so apologies for the lack of stability. It's still very much in "beta", so one should expect the occasional problem from time to time. One could call it bad-timing, as it was working fine last week ;-) |
| ||
| then I will just checkout a last week commit :) Regards |
| ||
| It should actually be okay at this point in time. I was testing against all three core platforms last night. |
| ||
| I just compiled all modules (except sdl.mod :D). I had a problem compiling "freeprocess.mod" because it misses two changes: < Method Read( buf:Byte Ptr,count ) > Method Read:Long( buf:Byte Ptr,count:Long ) < Method Write( buf:Byte Ptr,count ) > Method Write:Long( buf:Byte Ptr,count:Long ) bye Ron |
| ||
At the current commit, i get this error when trying to build modules:Compiling:blitz.bmx Compile Error: Can't find interface for module 'brl.classes' [C:/Blitzmax-ng/blitzmax/mod/brl.mod/blitz.mod/blitz.bmx;2;0] Edit: edited bcc.config and rebuilt, compile error disappeared but module building just stops right after compiling blitz debug and release: Compiling:blitz.bmx Archiving:blitz.release.win32.x86.a c:\testsdks\mingw/bin/ar.exe: creating C:/Blitzmax-ng/blitzmax/mod/brl.mod/blitz.mod/blitz.release.win32.x86.a Process complete |
| ||
| You only need bcc.conf for debugging bcc. You should probably remove it otherwise. I only have these files in bin : bcc.exe bmk.exe core.bmk custom.bmk make.bmk From bin, you should see something like the following : C:\BlitzMax_NG\bin>bmk makemods -a brl.blitz Compiling:blitz_app.c Compiling:blitz_types.c Compiling:blitz_cclib.c Compiling:blitz_memory.c Compiling:blitz_module.c Compiling:blitz_object.c Compiling:blitz_string.c Compiling:blitz_array.c ... |
| ||
| I also use bcc.conf to make bmx-ng work from a shared network mapped path (windows and linux share the same "directory" then). Also I do not have the environment variables set (blitzmax doesnt do this during installation) - so this avoids ambiguity when having multiple blitzmax installed. But to keep it "easy" it is better to remove unneeded files. bye Ron |
| ||
| Ok :) Is it possible (at the moment) to build/rebuilt all modules in one go? (that's what didn't work here) :) |
| ||
| You can rebuild all modules - I only had trouble with "debug" build ... so "bmk makemods -r -a" will eg. only rebuild all modules in release build. Maybe the latest changes allow a debug-build of all modules. bye Ron |
| ||
| I only had trouble with "debug" build Still a problem? I got the debug build on the Pi to go right through after a couple more tweaks to the debug generation. |
| ||
| Ok - downloaded new bcc sources, bmk sources, pub.mod sources, brl.mod sources ...recompiled BCC, BMK again I have the fun of "MINGW" not being an "environment variable" (this is not a default ... none of my windows systems has this variable set "by default" ... this) -> maybe add to "readme" / make it configurable in a "blitzmax.conf" containing some setup paths. (after removing "config.bmk" I keep having them in my NG-folder :p) ...recompiled brl.mod .. C:\BlitzMaxNG\bin>bmk makemods Compiling:freetype.bmx Archiving:freetype.debug.win32.x86.a C:\MinGW/bin/ar.exe: creating C:/BlitzMaxNG/mod/pub.mod/freetype.mod/freetype.debug.win32.x86.a Compiling:freetypefont.bmx Compile Error: Can't find interface for module 'pub.freetype' [C:/BlitzMaxNG/mod/brl.mod/freetypefont.mod/freetypefont.bmx;29;0] gcc.exe: error: C:/BlitzMaxNG/mod/brl.mod/freetypefont.mod/.bmx/freetypefont.bmx.debug.win32.x86.c: No such file or directory gcc.exe: fatal error: no input files compilation terminated. Build Error: failed to compile C:/BlitzMaxNG/mod/brl.mod/freetypefont.mod/.bmx/freetypefont.bmx.debug.win32.x86.c And when explicitely compiling "-r": C:\BlitzMaxNG\bin>bmk makemods -r Compiling:audio.bmx Archiving:audio.release.win32.x86.a C:\MinGW/bin/ar.exe: creating C:/BlitzMaxNG/mod/brl.mod/audio.mod/audio.release.win32.x86.a Compiling:bank.bmx Archiving:bank.release.win32.x86.a C:\MinGW/bin/ar.exe: creating C:/BlitzMaxNG/mod/brl.mod/bank.mod/bank.release.win32.x86.a Compiling:bankstream.bmx Compile Error: Can't find interface for module 'brl.bank' [C:/BlitzMaxNG/mod/brl.mod/bankstream.mod/bankstream.bmx;18;0] gcc.exe: error: C:/BlitzMaxNG/mod/brl.mod/bankstream.mod/.bmx/bankstream.bmx.release.win32.x86.c: No such file or directory gcc.exe: fatal error: no input files compilation terminated. Build Error: failed to compile C:/BlitzMaxNG/mod/brl.mod/bankstream.mod/.bmx/bankstream.bmx.release.win32.x86.c C:\BlitzMaxNG\bin> EDIT: "brl.bank" itself is compiling well ... so I dont know what makes "bankstream" not find the interface file. PS: All files are "real files" this time (you know I like symlinks, but I this time copied everything to "C:\BlitzMaxNG"). EDIT 2: it compiled after I removed bcc.conf #code of my bcc.conf BMXPATH=/home/ronny/Arbeit/Programmieren/BlitzMaxNG BMXPATH_WIN32=C:\BlitzMaxNG #BMXPATH_LINUX=YOUR/PATH #BMXPATH_MACOS=YOUR/PATH Oddly it compiled many of the files even with the conf file in the directory. Removing / Renaming it, removed the problem. EDIT3: ok ... seems we have to replace "\" with "/" in the BMXPATH-configuration ... "C:/BlitzMaxNG" and it works... - stays "odd", why it partially compiles. bye Ron |
| ||
| The majority of people (perhaps everyone except you :-p) won't be using bcc.conf, so their experience will probably be less complex than yours appears to be. |
| ||
| I managed to build all modules (both x86 and x64), but I had to build every module manually i.e. "bmk makemods -a brl.blitz". Whenever I try "bmk makemods", "bmk makemods -a", or "bmk makemods -r -a", building modules just stops unexpectedly after building the first module, like this: I'm using TDM mingw 4.8.1 x86/x64... |
| ||
| @brucey Taking life easy ... why should I if we can do it the hard way :D @build probs You may try a "verbose" build (-v) ... so you see which commands get executed. Now take the last command - run it yourself and see what errors it spits out. bye Ron |
| ||
| Ok: tried with verbose: Seems ok, there are no errors... The first module is being built. It's just that it stops unexpectedly after the first module has been built! (Seems like a bug to me) |
| ||
No errors? what happens if you execute the last lineyourself?ar.exe -r "C:/Blitzmax-ng/blitzmax/mod/brl.mod/blitz.mod/blitz.release.win32.x86.a" "C:/Blitzmax-ng/blitzmax/mod/brl.mod/blitz.mod/.bmx/blitz_app.c.release.win32.x86.o" bye Ron |
| ||
| Maybe there aren't any other modules? :-) |
| ||
| @Derron: No output :) And "blitz.release.win32.x86.a" and "blitz.release.win32.x86.i" has been created, wich means the module has been built correctly, if I'm not totally mistaken? :) @Brucey: Ofcourse there are, I've downloaded your brl.mod and pub.mod and the directories are placed where they are supposed to be and they are populated :) I'm using Windows 8.1 x64 |
| ||
| Did you use the most current BMK and BCC sources? Maybe you should try to add some debug prints within "BMK" when it traverses through the list of modules ... bmk_make.bmx: Function MakeMod:TFile( mod_name$, isRequired:Int = False ) you could add some prints there to check if it fails in this method... Another option is to do this: copy the BMK *.bmx-files to your BlitzMaxNG/bin ... open "bmk.bmx" in your vanilla MaxIDE (take care not to copy the *.bmk files). In the menu "Program" there is "Command line" - you could write "makemods -a" there. When you now compile "bmk.bmx" it will overwrite the existing bmk[.exe]. If you "compile and run" - it will also start your bmk[.exe] with the commandline params we just set. So if you compile in Debug mode ... you will even be able to debug the bmk itself (if it eg. crashes during doing the "makemods"). The easier thing is of course using "print" and checking if step 1 is printed, but step 2 not. bye Ron |
| ||
| Strange thing, but now it suddenly works after all... I copied all the files from bmk master to the bin directory, and the only thing I did after compiling bmk.exe with vanilla, was to delete the config.bmk file.... Now "bmk makemods -a" builds all modules as expected :) |
| ||
| that bunch of bmk-files is really able to create some trouble. But in some cases you will need them so yeah... misconfiguration will happen from time to time. Glad it works now - and there is no flaw in bmk/bcc. bye Ron |
| ||
| It works so good now, that I tried to compile my own modules, and they all compiled ok :) So I tried to compile some BaH modules aswell, some of them compiled, and some not. However, the same error occured on different BaH modules: Just wanted to let you know :) |
| ||
| This is a nifty error Imagine you have this Type MyType Function MyFunc:INT() End Function End Type Type ExtType extends MyType 'override and forget :int in definition Function MyFunc() End Function End Type above will lead to your error. It means: you have a method/function overriden in an extending type - but did change the "definition". I had this very often with "Render:Int()" and "Render()" or "Update:Int()" ... just depending whether I needed to distinguish between "successful or not". In Short: check if your definition is different (it will be). EDIT: "libarchive.mod" can get compiled here ... so it might be another issue (is everything of "maxmod" up to date?). Did you use "github.com/maxmods/bah.mod" or something else/older ? bye Ron |
| ||
| I used maxmods via svn.. But it's over 6 months old, I'll try to update it. EDIT: It was the google code repository... Is github more up to date or? EDIT2: It appears I made some changes to libarchive myself, because of this bug: http://www.blitzmax.com/Community/posts.php?topic=102527 might be it. |
| ||
| If you want to use "the new compiler", you will use the modules from github.com/bmx-ng/brl.mod and bmx-ng/pub.mod "maxmods/brl.mod" etc contain fixes to "vanilla blitzmax". bye Ron |
| ||
| A lot of BaH mods probably won't work without some tweaking, generally due to the low-level nature of the libraries they are wrapping. So at the moment, YMMV ;-) |
| ||
| <retracted> |
   |