Forum Replies Created
-
Posts
-
The reason it takes a floating-point argument for color is because that is what the underlying opengl does. This has been the case since forever, after people moved from 8-bit channel rendering internally to whatever the native hardware is offering. Using a floating point value allows the underlying Hardware to quantize it to the level of accuracy it processes stuff internally.
The main time this would be a disadvantage is actually with image editors, since you can’t necessarily guarantee 100% color accuracy if the internal Hardware renders colors without perfect accuracy for speed reasons. In those cases where speed is a “bonus” and accuracy comes first, editors usually have their own separate internal image processing engine anyway, only using opengl to speed up the output (or noncritical tasks). But mojo wasn’t designed for that specifically, it was designed for games.
In the future when monkey2 has established itself as the canonical replacement for all of the previous BRL products, I would love to see a unified portal taking over all of the old sites, archiving all of the old sites and bringing all of the community under one tent.
Until that happens though, I would agree with the people who say that it’s a moot argument. I do somewhat lament the fact that the monkey forums have dried up in post quality and quantity lately as the community has been split up once again, however as I’ve learned the language I feel that I don’t need to for help that much anymore, I only miss the community itself which has mostly moved to over here. Since I’m still waiting for an IDE that gets me the same convenience level that jungle did for monkey X, I mostly lurk here, but there seems to be life in the mx2 forums waiting to blossom out when it’s “ready” for primetime.
P.s. all of you mx2-interested peeps should check out the monkey chatroom on Skype sometime..
Nice work Adam. Always love to see people experimenting with making painting or composing tools and associated code.
Looks like it works fairly similar to brl.json from MX1… Data members of JsonObject appear to be directly accessible through operator overloading of [] though. Using JsonObject.Load(path) should create the object. Then, you basically either work with the JsonValues directly, or unbox them / bus them to your game’s variables. Again sometimes in MX1 this required direct casting. I don’t know if that situation’s changed now, but if you need to cast, remember that the syntax has changed for MX2 and is now a kinda weird looking operator thing Cast<T>(expression).
Edit: Almost forgot. TMX map format by default uses XML (gross), the json format is an “export” format for Tiled, although its structure is nearly identical to standard TMX, save for changes in the syntax and one or two other things…
Texture size is limited by your graphics card. There is an attribute available in openGL called MAX_TEXTURE_SIZE which you can refer to using the glGet() function from gles20.See: https://www.khronos.org/opengles/sdk/docs/man/xhtml/glGet.xmlMisread the original post. Thought the size was extremely large….
For “http” they changed it also to plural, so
while “http” will stay for a while (compatibility),
the new and future-proof spelling is plural: “https”.lol
taumel: Sorry, I didn’t want to make it sound like your post was entirely unhelpful. However, focusing on the things that are “not what you want when you’re into music and after more control and precision” without talking about what it is you think people actually want, that just sounds like, well, a critique that lacks much substance if your intent was to help improve that situation.
I want to encourage your musing on what you think would be a better option, or barring that, at least explaining that the situation seems suboptimal but you’re not sure if there’s a clear and obvious way to improve it. I apologize for sounding a bit confrontational in my previous post.
BASS is a pretty good lib, I used to use it all the time back when I made mostly freeware stuff. It’s pretty straightforward and runs on a load of platforms. Its source license isn’t compatible with mx2 however, and costs money if you want to use it for commercial or shareware projects.
LibOpenMPT (not to be confused with libmodplug) is the core of OpenMPT — you could theoretically write an entire tracker with it. This probably isn’t what most people making games with Monkey are looking for, but it is a viable option. It also has the benefit of having a BSD license. It supports all formats OpenMPT does, with the same level of compatibility.
For basic stuff, it seems like OpenAL might be the way to go. The big missing feature in MonkeyX seemed to be audio streams, which theoretically would let us hook anything else up into it that wasn’t originally supported. Setting loop points in streamed audio (ogg) would’ve been nice, too, but I never really dug into whether that was nontrivial to implement.
There is actually limited/experimental support for this in now – see my blog update, but note there are issues with doing realtime stuff like audio in a single threaded app.
Glad to hear it’s there. I’m sure in the future there will be a straightforward way to handle more realtime stuff, either with a thread specific to the feature, or when threads start getting worked into the language, or whatever.
@taumel: If you wanted to be helpful, what would you suggest as far as audio libs go? If my focus were a music writing application specifically, I’d probably wrap bass.dll or libOpenMPT and skip the middleman. OpenAL has the advantage of being free, and OpenALsoft has a liberal license (and afaik is still being maintained). FMOD is old and has a rather expensive license, and FMOD Studio (while nice) would be a large undertaking to wrap, and might add a bit of heft to the runtime. It also has licensing which is incompatible with distribution with mx2, as far as I know.
[The only talk about multiple platforms so far I’ve has been about the Pi…]
and if anyone can come up with a better name than StaticIf…
I think PureBasic calls it CompilerIf. I don’t care that much what it’s called but if it’s not proceeded by a # then my brain automatically assumes it’s not processed any differently than the rest of the code in regular code blocks. Is there enough stuff that happens in the same phase of the compilation process to justify some kind of signifier and not be a mess of symbols?
VB.NET uses #If as a directive and no one seems to care, I guess because hashtags don’t strictly mean “precompiler”. For example the #Region directive is strictly for the IDE and has nothing to do with the compilation process whatsoever.
What I would really like to see is some kind of direct access to the audio buffer in mojo. Most of this extra stuff will take care of itself when there’s a standard/easy way to hook existing audio generation libs into an OpenAL stream without having to hack around in OpenAL directly or circumvent it entirely.
@gcmartijn : Git works by allowing multiple branches and forks to exist simultaneously. Any particular version can be x commits ahead of its last pull, and x commits behind the latest push. This branch exists separately from everyone else’s branch and working copies.
In a fork the branch systems exist separate starting from the point of forking and you need to make a pull request asking that the upstream maintainer pull your patched changes back into the mainline branches. As far as I know, nobody except Mark has access to the mainline, so everyone’s currently working off of forks. If he had other people working on the same project, they would be using merges instead — these can usually be automated. There’s a lot of magic involved.
This “Getting Started” guide to Git should help explain a lot of things. Check the Syncing and Using Branches sections for more details. https://www.atlassian.com/git/tutorials/making-a-pull-request
Heart plz
Woot! I sense a “Monkey Boy” rpi0 portable console project in the future…
Properties are a good way to expose class fields to other classes in an “encapsulated” manner. In practical usage (outside of theory or library design), they’re a useful way to sneak in some maintenance code when performing a get/set operation on a field variable. They’re also useful for creating fields that can’t be altered by certain classes.
For example, you can set your underlying field variable as Protected or Private, then only provide a Property getter to access it. If the field’s set to private, then only that class can change it directly — if it’s set to protected, then only that class and classes that inherit it can alter the field. That’s good for keeping people away from messing with variables where they’re not supposed to…
Interfaces are used in situations where you might want to simulate what multiple inheritance normally offers in a limited way. By specifying that a class conforms to an interface (classes can conform to multiple interfaces), then you can specify elsewhere that something takes an interface type and normally unrelated classes can use it.
This is useful when you want to create modular systems (like for example, a standard library) since interfaces decouple the definition from the implementation. Without interfaces, a lot more care and foresight must be taken in the design of a set of classes because a change to the implementation sometimes ends up needing a change in the definitions to remain straightforward.
A good example of the use of interfaces is when implementing containers. Another is for the sorting of containers — mx2 uses function calls for this, but .NET languages use generic interfaces to assume a safe definition of what the potential sorting and collating operations are for any particular implementation.
http://monkey2.monkey-x.com/mx2-docs/std-std-collections-icontainer/
Hoping that generic interfaces are implemented eventually, since their initial absence in monkeyX affected the design of a few base libraries from some users…
