Forum Replies Created
-
Posts
-
Ok, just pushed a new ‘theoraplayer’ module to the github master branch! See new theoratest banana…
It uses the ‘theora player’ library – see: http://libtheoraplayer.cateia.com/wiki/index.php/Main_Page although docs there are wildly out of date.
It’s kind of low level (you need to paste video frame data to a texture) but seems to work well and is very flexible this way. We can wrap it in something higher level later if necessary.
Should work on all targets except emscripten (it uses threads, which might be ‘fixable’).
And damn, that KDE anim is cute!
> This. The name is not really abstract
Well, strictly speaking no it’s not. Either is python, java, lua etc – they are nouns with specific meanings (and apparently cultural connotations). But they are all ‘meaningless’ in the context of ‘programming languages’ which I guess is what I really meant.
I must admit though I did not realize Europeans had such a crappy opinion of monkeys. Here, they’re generally regarded as fun, cute, playful, clever etc, all generally cool+laid-back+positive. Perhaps I would not have gone with monkey at the outset if I had known this.
Yet the name monkey for monkey1 seems to have ‘stuck’ OK. I don’t think it doomed the language or anything and monkey is sort of a known quantity in the indie game dev scene now as far as I can tell. I even catch the odd monkey t-shirt popping up on facebook now and then (OK, twice)!
Would more people be trying out monkey2 if it had a different name? I guess it’s possible, but I doubt it. What I do know is that rebranding now would be a MAJOR PITA and would throw away any/all goodwill the name ‘monkey’ has built-up over the last several years.
I think the difference with monkey compared to say ruby, lua, c, etc is that perhaps they target their audience a bit better.
Not sure what you mean here by ‘target their audience a little better’…these names are, IMO, just as meaningless as ‘monkey’, and these languages are not well known due to any slick marketing or because they have ‘Zap’ or an ‘X’ in the title, but because they are actually *good* at what they do. I think monkey1 has managed to make a little headway here too – ie: things like new star soccer, the necro dancer game etc, have all helped make monkey1 a more viable tool for game authors.
> Out of interest, is the name of version 2 final?
Never say never, but my current POV is that we’d be nuts to change the name. Whether you like it or loathe it, the name ‘monkey’ does have *some* visibility out there so it makes sense to me to leverage that with monkey2 (it *is* really a sequel after all). The alternative is to rework the site, IDE, docs, etc to…what exactly? Improve the appeal of monkey2 to a small and shrinking blitz user base (I’m assuming the suggested alternative has ‘blitz’ in the name, it always seems to…)? Many of whom wont/don’t like monkey no matter what I do anyway because it’s not blitzmax 2 – which is both entirely reasonable and (partly) why I didn’t want to mislead people in the first place by sticking blitz in the name when I decided to do monkey1.
I really, really want to move forward, not backwards here, ie: to start attracting coders outside the blitz-bubble, who understand the value of some of the new stuff in monkey2. But that wont really happen in earnest until some cool stuff gets written in monkey2 (and any delay here is really down to me…), at which point I have a hard time imagining the name will really matter much at all.
And at the end of the day, no matter how bad you may think ‘monkey’ is, at least it’s not ‘mingw’….
I really don’t get all the hate directed at the name ‘monkey’ – it has always seemed innocuous enough to me, as abstract/meaningless as C’ or python or lua (moon – cool!) or ruby or spider monkey or boo or whatever, and I find it kind of odd/sad that people appear to be so bent out of shape over this.
Surely, the success or otherwise of monkey2 will depend FAR more on what’s actually created in it than what it’s called? If someone writes the next great mobile app in mx2 (yes, I went there!) will people still refuse to use monkey2 because the name is….what exactly? I don’t get it…
I do vaguely suspect this hate may be coming mostly from people who wanted to see the name ‘blitz’ in there. But if not blitz (and it’s not) then what? Or perhaps it’s a cultural thing? Here in NZ, ‘monkey’ generally means ‘cute and clever’ which I think is kind of apt for what I’m trying to achieve (readable+powerful). But perhaps it has other undertones in other cultures I’m unaware off?
I don’t think the blitzbasic name carries water the way you guys think it does
I most definitely agree, and I think it’s reasonable to say that monkey2 will HAVE to appeal to more than just blitz users if it is to have any real chance of success.
The latest stuff at github WILL be more volatile as it’s what I’m actually working on *right now* and code does not alas fall perfectly formed from my fingertips.
If you want to play it safe, stick to the ‘tagged’ versions at github, or the prebuilt release versions.
But even these will not be perfect. If you find a bug and want me to take a look at it, please report it at github in the ‘issues’ section (and here at the forums if you’re really keen). If you don’t report it, I can’t fix it.
If all of this is just too much hassle and you’d rather wait for mx2 to mature a bit, I quite understand and hope you enjoy the break. If you’re not enjoying it, you definitely shouldn’t be here!
I’m quite impressed you’ve done ted2go without knowing that!
Stack is not a struct!
Stack, List, Map and Deque are all classes so instances are always passed by reference.
Also, I recently added a RemoveIf to stack (and list) which may be useful…
Uploaded a module for to the modules system
I didn’t publish this sorry because:
a) Module name ‘random’ is too generic, use ‘edzup-random’ or something.
b) Hows does it compare with current rnd? If it’s better, perhaps current rnd needs replacing/fixing. If it’s worse what’s the point having it there at all? Even if there’s a point to having multiple rnd number generators (is there?) I think it’s still worth having 1 really good one in std.
I have tweaked the current std.random generator a bit – it now uses an algorithm called xoroshiro128+ which sounds like one of the best out there for speed vs quality:
Mersenne generators sounds like they were superceded a couple of years backs, and the ‘C’ rand() function has terrible reputation in general…
But I don’t *really* know the above for sure. I’m not any kind of expert on random numbers and it’s a very complex field, so perhaps what we need to do at some point is some actual emperical testing?
Ok, definitely seems to be related to the stack ptr param for RemoveFromStack, just passing a plain stack works fine.
This should not of course cause a c++ error and I’ll check it out, but at the same time what’s up with the pointer?
Object Ptr’s (and array and function…well, ALL ptrs!) are dangerous. They can mean there’s nothing’s keeping an object alive so the object can be GC’d unexpectedly. They should only be used in extreme situations – generally dealing with extern libs or something.
I have kind of struggled with whether to or allow ptrs to GC-able objects at all or not but they’re in now so are staying, but be aware that if you use them needlessly in code posted here (without explanation) you will likely receive this lecture every time!
There are currently 2 product settings for the desktop target – app name + gui or console switch. If more are added, this is where they will go. You could of course have worked this out by actually looking at the json file…
The point of this is to stick *everything* that can affect the generation of *any* product into a single file, so if a team wants to share product build setups for a range of targets they only have to share a single file.
why can’t I just have a folder with the app and the assets + dlls?
You do – it’s called ‘Windows’ or ‘Macos’ or ‘Linux’ or ‘Emscripten’ inside the blah.products folder.
Sorry if you don’t approve of this approach but it’s staying.
One issue with ffmpeg is that you apparently need to statically link with fancier codecs via cmake switches (going by this page: https://ffmpeg.org/general.html).
This is a hassle with a LGPL product as it means a whole new dll needs to be generated for each combination of codecs, correct?
Also, it’s likely that, due to patent issues, (grrrr…) I wont be able to include all the codecs everyone may want or be legally able to use etc in the official release, but with ffmpeg there’s doesn’t seem to be an easy way to add them.
so not sure if that’s possible yet.
No, no yet.
However, there’s already a std.zipfile.ZipFile class (used by module manager) that could be tweaked to perform simple file extraction, eg:
123456789Class ZipFileMethod Extract:DataBuffer( file:String )...doesn't exist yet!...Function Open:ZipFile( path:String )EndLocal zip:=ZipFile.Open( "Somefile.zip" )Local str:=zip.Extract( "DATA.XML" ).PeekString( 0 )Would this be enough for now?
libVLC looks pretty good, except for the LGPL aspect. However, just checked and ffmpeg is also LGPL so I’m hosed-ish either way (well, it becomes a bit trickier anyway…).
Does libVLC do audio too?
Can you try and narrow it down?
Have no idea what it’s supposed to do and am feeling too lazy to try harder…
A quick google suggests ffmpeg might be a good place to start:
There’s also a tutorial for getting it working with SDL:
Any objections to starting with this?
Embedding VLC (which is only an app?) doesn’t sound very easy or ‘cross platformy’, esp. for straming stuff to textures etc but I’ve had no experience with this – any pointers?
