Forum Replies Created
-
Posts
-
but really this should be part of the app process.
I agree, but you guys will have to work around it for a while yet sorry.
supported since Android 4.3
…sort of:
Caution: Support of the OpenGL ES 3.0 API on a device requires an implementation of this graphics pipeline provided by the device manufacturer. A device running Android 4.3 or higher may not supportthe OpenGL ES 3.0 API. For information on checking what version of OpenGL ES is supported at run time, see Checking OpenGL ES Version.
If you can come up with any figures re: gles2/3 etc adoption in general I’d love to see them! On PC, gles2.0==d3d9 and gles3.0==d3d11.
And, just curious, but what ‘gles3.0’ specific features would you want to use the most?
Gles 3 is supposed to be 100% retro-compatible with gles 2 so it’s a kind of non-issue to me..
Yes, this does make adding’ gles3.0 support at a future date much easier!
He’ll wake up this morning and it will hit him like a stone that gles2.0 is shit.
I’m not big on the swearing, please tone it down.
For people who aren’t into 3d tech or facts: gles2 = Trump, gles3 = Hillary/Sanders/some Kennedy clone/your favourite local clown/whatever. It’s not Buddha, it’s not perfect but way more interesting to deal with in the future. gles3 is 3d on a whole different level, even if you only cherry pick certain features. The boys using gles3 get the hot girls.
That’s not an argument, it’s just a bunch of garbage metaphors.
No, i’m emotional on this one because i know what it means.
Well, I don’t have a clue what you mean so far.
I’m not *against* gles3.0, but it *will* cut down the number of targets and devices it will run on and that *has* to be taken into account.
Yes, I know you don’t care about mobile or emscripten, but I am not writing this to suit your requirements.
In favour of gles2.0 is that fact it is very cool API that is capable of way more than people realize – quite possibly more than the majority of users here will eventually do anything with (no offense intended – I include myself here!).
But gles3.0 does have a few very cool features that are impossible to emulate in gles2.0 and would be very fun to play with – IMO, feedback buffers and geometry shaders in particular. So I am *tentatively* hoping that mx23d will one day provide both gles2.0 AND gles3.0 backends, but my priority WILL initially be gles2.0.
Anyone watch Johnathon Blow’s streams?
I used to, esp. his game language vids on youtube, they were way cool! Will definitely check out his GL extensions ideas though.
For the love of all that is sweet and holy, no roadmap.
Ah man, can I work for you?!?
I will likely put together a little roadmap in an upcoming blog post, but it wont be anything too surprising and of course will be subject to change!
Hopefully people more or less get what I’m trying to achieve here, but I will go into more detail soon.
I don’t want to be involved into your simplifications and ‘style’ of discussion where people who disagree with you are mostly negative, stupid or get silenced.
As far as I can see, you’re the only one here with a problematic style of discussion – all you’ve contributed is an entirely ‘fact free’ rant about how much you don’t like gles2.0. Good for you, I hope you feel better etc, but what am I meant to do with that? How does it help the development of mx23d?
Tested with tinyxml2_test and onemegs.xml file on Windows and it worked fine…
Are you loading the xml file properly? Check it’s not loading a null string is a good idea.
1920,1080 is supposed to be ‘worse’ case buffer size – not as elegant as it could be but it should still work. The idea here is that I want to share a single offscreen ‘gbuffer’ texture between potentially many canvases. This should probably default to device size and have a user modifiable ‘max’ size (and there are probably better was to try and computer it automagically).
But it does work here with simplelight etc. which use 640,480 windows and can be resizable (here anyway).
Can you email me a zip of your example project (blitzmunter at gmail dot com)? I can’t see any source code here…
Not yet, but it’d be nice to add!
Yes, looks like a const thing. Your initial solution is probably as good as it gets without resorting to native glue code, which would be cleaner but a little trickier.
Hey everyone,
Woohoo, looks like we made it!
Sorry I haven’t replied to this earlier – I keep noticing it at home (on the couch with ipad) but seem to forget it when I get to work (where I try to actually work as much as possible).
Anyway, hitting the 1000 Patron goal means I’m going to be mainly working on a 3d engine/module for monkey2 from now on, which is both exciting and a little scary.
My main mission is to provide something that has an easy to use API, and that can produce attractive results and runs at a decent speed. In other words, something hopefully in the ‘spirit’ of blitz3d.
I am also planning to include VR support from an early stage, mainly because I have become really fascinated with it (largely thanks to PSVR + rez + area X) and also because I have a DK2 (oculus rift dev kit) anyway which I’ve had going in the past and should be easy to get going again.
My plans for an API are to stick with gles2.0 + some extensions for starters, while keeping gles3.0 in the back of my mind. This doesn’t mean you’ll be using gles2.0 any more than you do in mojo 2d, but it’s what I’ll use behind the scenes, mainly because it works everywhere.
This does mean you wont be able to use ‘bleeding edge’ d3d12 etc features, but I’m cool with that. There is still a ton of amazing stuff that can be done in gles2.0+ (more in gles3.0 which is kind of sort of d3d11 to gles2.0’s d3d9) purely with vertex/fragment shaders and render targets.
My plans for file format support are to include support for gltf ONLY in the actual 3d module. gltf is a new format, but it has a lot going for it: it’s backed by khronos, very well documented, obviously written with gaming in mind, lightewight, available in binary/text flavors and completely open (unlike several other potential uber-formats). I think it has a very bright future. More info here:
Support for other formats can be provided via an ‘assimp’ module (still lovin’ that name!) – more info on assimp here:
And you will of course be able to combine mojo3d with 2d/mojox rendering.
One thing that WILL be a problem for me is test/demo models. I somehow managed to end up with a ton of cool models for the original b3d and I’m convinced that helped a lot both with development and marketing.
So if anyone has any test/demo models they would like to contribute to the project, please contact me.
Finally, this would indeed not be happening as quickly as it is – if at all! – without the major help of Impixi, who has not only helped get the patron up to 1000, but who has also chipped in some very generous amounts every now and then over the years to help keep monkey2 going and my spirits up – thanks a ton Impixi, I’m very happy I get to concentrate on monkey2 for at least a bit longer!
And of course, thanks also to anyone who joined as a patron or upped their contributions a bit.
Fixed now in develop branch. I forget that assigning a struct actually also involves a bunch of member assignments.
This is a hard one to get 100% right though, as there’s a tension (in c++) between not wanting to #include too much, which can cause forward referencing issues, and having to #include enough to keep compiler happy. And fixing one always affects the other…
I think a new approach may be in order and have some ideas but for now I’ll just keep dealing with these on a case by case basis.
I’d quite like to have a play with this and see how it works out. Abakobo, if you’re OK with being in charge of making ‘pull requests’ (containing *only* docs edits please!) I’ll have a go at merging them into the official develop branch. Is this what the general idea is?
If it works, perhaps we can move the wiki+branch to official monkey2 github, but in case it doesn’t probably best to just leave it where it is for now.
One thing that may not be working yet docs-wise is linking to sample code. I think this is better than bloating out source code with samples but I’m not sure if works so for now no examples in source files please! Will look into this ASAP – it was going at one point so shouldn’t be a biggy.
Not sure why you’re bothering with the cfloat struct at all there…
mx2 floats *are* just c floats (ie: 32bit) and mx2 doubles are just c doubles (ie: 64bit) – in fact, your code already depends on this as it’s casting cfloat ptr to float ptr – so the cfloat struct is redundant as far as I can see.
You probably only need xcode command line tools, and it may be possible to install them without xcode according to this:
http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/
I wont be closing bb.com as its its own thing now, with skidracer in charge for extra thrills and spills! In fact, the site’s probably still only there ‘coz of skid (it only costs me money) so please don’t hassle him too much.
Yes, there’s probably a certain ‘anti-monkey’ element there, but that’s kind of natural because it’s a blitz site and ‘my language is better than your language’ etc – and monkey is quite different from blitz! In fact, they represent 2 quite different aspects of programming, so I’m not that surprised that someone who digs blitz is not so keen on monkey.
I wouldn’t worry about the effect this is having on mx2 though. I think anyone who was gonna do the blitz->monkey2 thing will have done so by now, and anyone left who is still grumpy about mx2 is by now just preaching to the choir.
Besides, IMO the future of monkey2 is really going to depend on whether or not we can make an impact on the *current* generation of indie game coders (and whatever blitz may be, current it is not), many of whom have c#/java etc backgrounds and I think will ‘get’ monkey2 a whole lot better.
Think I’ll lock this too as it seems to be getting a little heated in places…
Using github for adding/improving docs by external people?
This is worth a shot I reckon, although it might be an idea for someone else apart from me to handle docs merges as I suspect I’d be ultra-picky about it! Any volunteers (with suitable experience preferably)?
Also, each module should have a ‘samples’ dir with a sample-per-identifier that’s linked to from the docs (so it can open in Ted2 etc). This would be a pretty easy way for people to contribute.
Will have a think about these, but I’m semi-inspired!
I try to prioritize docs, so language/std/mojo have precendence right now as I believe these will be the most commonly used. After that will likely come mojox (which as Danilo points out I haven’t even started yet), other ‘pure mx2’ modules, then finally ‘native’ modules (as much as is sensible here).
I’m happy for now with the quality of docs for std/mojo – I consider them to be ‘pass 1’ complete, eg: I think most people can make sense of the DrawPoly docs just fine. Yeah, more docs is always better, but there is still a LOT of stuff that isn’t even at ‘pass 0’ level and that has priority right now. Things will then be further refined in pass 2 etc.
And finally, please, enough with the “Mark! You must do *THIS* or mx2 is boned!” threads. It’s great you have such strong opinions, but please try to understand that maybe not everyone shares them?
