Forum Replies Created
-
Posts
-
Thank you all for your input so far. I guess it’s safe to use Monkey 2 for my purposes. Thanks DruggedBunny, I did miss the Back to the Future update, and going forward WebAssembly makes sense. So that’s an exciting path for Monkey 2.
Same as you, SekaiChi, I particularly love the Monkey 2 syntax. I also had a play with some of the Monkey 2 features such as glsl shaders and it worked pretty well for something I hadn’t really used before. That’s a year ago mind you, and I don’t think I’ll heavily rely on glsl for the game I have in mind. Good to hear your experience with the different platforms. I have a Pie and an older Nougat device, probably 7.1.
Amon, thanks for your comment as well. When I first started with Monkey 1 I wanted to write everything myself, including user interactive particle systems, etc., to have full control and to learn things. Back then I’d count it as my first step into game development because I got a bit bored of web development. Even though my first project was never completed or released, it was a good learning curve and helped me to get a great game dev job that I’m still in today. But by now I also like to have a more complete framework that takes care of common game basics. I’m just wondering, wouldn’t a lot of those helper functions be covered by modules? When I first used Monkey 2 I went straight with Pyro 2 and found it a really good addition. Not sure what happened in Pyro land since then, but I’m pretty sure I’ll use it again.
So, yes, from all the comments so far I’m quite confident that I can achieve a game in Monkey 2, even if Monkey still is a bit rough around the edges in a few areas. I guess I’ll see soon enough if I run into any insurmountable issues, but I just like the syntax, features and was a happy Monkey 1 user.
Sometimes it’s literally weeks until I find some more time for this, but for completeness’ sake and as I said I’ll share the result, I can simply send an offset value to the shader, e.g.
12CanvasLayer.Mask.Material.SetVec2f( "Resolution", New Vec2f( width, height ) ) ' app width/heightCanvasLayer.Mask.Material.SetVec2f( "Offset", New Vec2f( App.MouseLocation.x, App.MouseLocation.y ) )which the shader will pick up and apply like this (simplified):
12345678910111213uniform vec2 m_Resolution;uniform sampler2D m_ImageTexture0;uniform sampler2D m_MaskTexture;uniform vec4 m_HighlightColor;uniform vec2 m_Offset;void main(){vec2 maskCoord = v_TexCoord0 - m_Offset / m_Resolution;vec4 maskColor = texture2D( m_MaskTexture, maskCoord );vec4 imageColor = texture2D( m_ImageTexture0, v_TexCoord0 );gl_FragColor.rgba = imageColor.rgba * m_HighlightColor.rgba;gl_FragColor.rgba *= ( maskColor.r + maskColor.g + maskColor.b ) / 3.0;#endifFor a full working example see this test on Github with a mask that moves based on mouse coordinates.
Here’s the shader code.
It’s not perfect but it shows how it works in principle.
Oh, never mind. I got it! Mark once linked to this post about premultiplied alpha, and that had the clue I needed:
——————–
blend(source, dest) = source.rgb + (dest.rgb * (1 – source.a))
…
In this world, RGB and alpha are linked. To make an object transparent you must reduce both its RGB (to contribute less color) and also its alpha (to obscure less of whatever is behind it). Fully transparent objects no longer have any RGB color, so there is only one value that represents 100% transparency (RGB and alpha all zero).
…
To use premultiplied alpha, in addition to setting the appropriate renderstates, you must also convert your source graphics into premultiplied format. Drawing a non premultiplied color with premultiplied blending will not give sensible results!
To convert a non premultiplied color into premultiplied format:
color.rgb *= color.a
——————–
And that was the only thing that was missing. I needed to multiply the alpha value with rgb as well. So the fix in the glsl shader is:
1gl_FragColor.rgba *= ( maskColor.r + maskColor.g + maskColor.b ) / 3.0;instead of just
1gl_FragColor.a *= ( maskColor.r + maskColor.g + maskColor.b ) / 3.0;therevills, I had a similar error before
> Invalid uniform type 0 expecting 1
In my case I didn’t set the uniform from outside the shader. I thought I did but that piece of code never got executed and so the shader couldn’t find it.
Thanks Mark and nerobot. Both answers were really helpful, plus it’s a face palm situation for me. It’s true that the shader couldn’t find the uniform. I set it in a method that was never called, so naturally the shader was expecting a Vec4f but probably had a null, or 0 vector if that even exists. I’m still confused enough by shaders that I was looking in the wrong place.
Actually I base my shader and ImageExtend on your sprite-masked shader, nerobot. That post was incredibly helpful. I just need to add a few “features” to the shader mask and I’m getting there one step at a time. Next up is a way to move/translate and scale the shader mask. I’ll see how I go and will share it in the forum.
Hi Mark. In this case I’m thinking of “layers” (conceptually). So I have a number of things (shapes, possibly bitmaps, etc.) in a “layer” (i.e. somehow grouped), and I want to apply a shader to this layer/group. I’ll eventually end up with probably 3–4 “layers” total that each have a different (yet very simple) shader applied. I need to test if this is too expensive performance-wise, and what’s the best way to do this to avoid drawing everything onto the layer each frame. But that’s a different issue.
I think the way to just draw the shapes/bitmaps that I need to a canvas, render that canvas onto an image and apply a shader to that image is working well. It’s great to discover the flexibility that Monkey2 already provides.
If it works in practice for my game remains to be seen, but I’m on the right track.
Just a brief update, I actually got this to work and could apply a shader (a mask in this case) to a number of drawn shapes. This was possible in the current Monkey2 with a combination of the following:
- a glsl shader (sprite-masked) from this related thread (a mask glsl shader is linked there as part of the zip file)
- a MaskedImage Image extension, however with slightly modified code to the one in the link above to take a pixmap instead of an image path
- a new canvas that renders to that MaskedImage above (see also the rendertoimage banana)
- a bunch of randomly generated shapes that are drawn onto that new canvas
I can animate the shapes and the mask independently and it works very well. I’m not sure if this is very efficient performance wise but for now at least it works as intended.
I’ll see if I can write an isolated sample code to share here. So far I still don’t understand this 100% and it’s surrounded by a bit of convoluted work in progress, but I’m glad I got it working. Thanks to everyone who gave me the hints to get there. I’ll follow up.
Having said that, a way as suggested by Mark above would still be great.
Sorry, I’m just coming back to this. So it appears that at the moment shaders can only be used for images, is that right? I tried to apply a shader by looping through all shapes that I’ve drawn, but they don’t have a Shader property. I just thought I can use something like that as a temporary solution until (fingers crossed) Mark’s suggestion above would be implemented. But maybe I need to put shaders aside until a later version of Monkey2.
Mark, is it helpful to put this into Github as an “issue” (labelled as an enhancement)? Thank you!
Hi Mark, yes, that’s about what I had in mind. So one shader that applies to multiple things. If the usage would be as you’ve shown in your sample code that’d be nice and easy to apply.
Even better if, as you mentioned, it could be applied to drawn shapes, not just bitmaps.
Hi Mark, thanks for your reply and insight.
If this could be done relatively easily I’d appreciate a canvas shader override.
I still need to fully understand how this all works, but this is a really helpful reply. I think with the override it can get me there with some trial end error.
Oh, awesome! I was wondering about how to get around that limitation.
Nice. This looks really useful! Thanks for sharing.
OK, I’ve done a bit of research about the Kalman filter and there are quite some implementation samples out there, but for now I still put it in the too hard basket. The main reason is that pretty much all implementations use accelerometer and gyroscope combined. I’m not sure how to access gyroscope raw data, I could get the accelerometer data via JoystickDevice, but no idea if gyro is accessible in any way. I also read that when the Kalman filter is set to be very smooth, you also end up with a delay. How much, and how it compares to a low pass filter I don’t know.
Well, anyway, I’m still very interested in this and will probably come back to it at some point, but for now I think I’ll focus on other parts. I’m just very uncertain if it’s worth the effort in the end. Apparently the Kalman filter isn’t really a filter in that sense, but rather a predictor model with biases, sensibilities, noise, etc. Complex stuff. I also read that for simple noise filtering a low pass filter should be enough. There’s no knowing without trying and comparing, and that’ll bug me for sure, but maybe later.
If the delay of the low pass filter is too great for your taste I suggest to play with the dt and rc values of the filter.
Having said that, if anyone is a Kalman genius, please do post an implementation or possible approach in this forum. Or your opinion if it’s even the appropriate approach to reduce noise from the accelerometer.
I’m still in early stages on the first mini-project (oh someone give me more free time!), but I’m using Pyro2 for convenience. It comes with a lot of useful stuff for general use. Contrary to a comment further up I’m not looking for a too specific game engine, more for general modules and utils/helpers for development as I see Pyro 2. Anything that’s too specific I’d rather write myself, otherwise I think any framework that tries to cover too many specifics and game types out of the box will in the end be too limiting and require bandaids and workarounds to make things behave the way I want. The general approach works better for me.
So far I’m mainly using the scene graph “basics”: virtual resolution, layers, sprites, camera, etc. I’m not using much of the framework yet, but I’m sure this will come in handy sooner or later, i.e. object pool, collision, pathfinder, screen manager, and also TexturePacker support. I think it can save quite some time to have these modules available.
+1 for a Github repo, just for the ease of updating (and possibly customisation, but I’m hesitant about that). But (I guess) I understand why it’s on Itch.io, it just makes it more obvious that you can donate.
Oh, and btw, is there a reason why the Pyro framework is split up into smaller modules but GUI and Scenegraph each are one long file? Not that it makes a big difference, but I find it quicker to find the source when it’s split up.
Thanks for Pyro2, Playniax! I think it’s an awesome addition to Monkey2.
Thanks for the info Diffrenzy and DruggedBunny. I’ll have a look into the Kalman filter if I find the time. The delay with the low pass filter isn’t too bad for my needs, but no delay would be better. I have no idea about Kalman filters, so if anyone else knows more and wants to come up with a Monkey2 implementation that’d be nice, too. But yes, I’m keen to improve this further if I can make sense of Kalman.
