Forum Replies Created
-
Posts
-
Some kind of ‘player object’ is the next thing I need to attempt physics-wise.
You can currently create static, dynamic or kinematic rigid bodies – see the ‘shapes’ test: The ground is static, the objects are dynamic and the camera is kinematic. But none of these really suit game style player objects – dynamic bodies need to be moved using ‘impulse’ forces which is pretty nasty (basically like poking an object with a stick to make it move! I will add support for impulse forces though), and kinematic bodies don’t respond to collisions with other bodies at all, they are more suitable for things like platforms etc.
Player objects really need to be hacked in using raycasting or something similar as they generally break all the laws of physics!
Have you rebuilt all modules with MX2_USE_MSVC=1?
I donate regularly since last year and I got no heart yet.
Crap, sorry, fixed now.
i send some Money .
What name did you send money as?
Not sure what the default will be yet. Float textures are strictly speaking an extension under GLES2.0 so I initially just wanted to play it safe.
I can add support for #version in future, but if you want shaders that will work everywhere you should just stick with the lowest common denominator glsl features of GL and GLES20, which is AFAICT gles2.0 shaders version 1.00:
https://www.khronos.org/files/opengles_shading_language.pdf
This is what’s used by webgl, gles2.0, and I am 99% sure will work with all desktop gl drivers.
No, it doesn’t have inverse(), transpose() or mod() etc, but that’s the point – not all targets/drivers support these. Stick to this though (and you shouldn’t need to use #version to do this) and your shaders should run everywhere.
In future, a lot of this can be made more flexible, eg: if you don’t want/need to support moble/wasm you should be able to use desktop gl (or alternately, use gles3.0 on mobile/wasm) which will give you better shader support, and you can really start going nuts with #version – but you’re also on your own when it comes to compatibility!
But for now anyway, I just want to get everything going as well as possible on as many targets as possible, and I think stick with gles2.0 shader v1.00 is the best way to achieve that.
Can the GC be disabled?
Not really, although you can do the Java thing of trying to prevent it going off by never using ‘new’ etc.
Sweet!
Also, I added an extra set of texture coords to Vertex3f (now in develop branch). Still not sure how different vertex formats will work, but don’t want to let it hold up any cool stuff either.
Yes, structs are copied ‘by value’ and classes are copied ‘by reference’.
Struct cannot extend other structs or declare virtual methods etc.
Structs have no GC overhead while classes do.
Try again now – there’s a filename case issue in there I just fixed.
If that doesn’t work, you’ll have to use the release version or plain ted2.
canvas.Color.R = .5
This will *not* work. Since Color is a struct, the canvas.Color property returns a copy of the current color so you will only be modifying a copy.
Just use New Color(…). It’s plenty fast since (also because Color is a struct) no heap allocation occurs.
This is actually looking more like a precision issue than anything to do with cubemap seams (ignoring ClearColor for now). As far as I can tell, angle lib always does seamless cubemaps if you use linear filtering on cubemaps. I may have to turn them on on apple/linux though, which explains a few other glitches.
Try changing this in deferredrenderer.monkey2…
Const MRT_COLOR_FORMAT:=PixelFormat.RGBA8
…to…
Const MRT_COLOR_FORMAT:=PixelFormat.RGBA32F
Here, this vastly improves the quality of the image, so the math must just be running out of bits somewhere. Will have a closer look at this later.
ClearColor being in ‘linear color space’ and stuff like canvas color etc being in ‘monitor color space’ is indeed an issue, but I’ll tackle this a bit later. For now, if you need to set any mojo3d color like ClearColor to an sRGB (ie: ‘photoshop’) color, you’ll need to convert it to a linear color first, eg:
1234Function ToLinearColor:Color( color:Color )Return New Color( Pow( color.r,2.2 ),Pow( color.g,2.2 ),Pow( color.b,2.2 ) )EndThere’s this:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_seamless_cube_map.txt
This would I think affect cube map sampling at high roughness levels, as without it (ie: current situation) samples at the coarsest mip levels (ie: 1×1 cubemap faces) will not be filtered in anyway, you’ll just get a single color per cube face sample, ie: one of 6 colors giving a crappy ‘toon shading’ effect. This looks to me a bit like what might be going on, hard to tell though!
Texel colors are assumed to be ‘sRGB’, so they are raised to the power of 2.2 (ie: converted to linear RGB) immediately after being sampled from textures in shaders (see: material.glsl). Color constants (like ClearColor) however are assumed to already be linear RGB.
All shader/rendering math is performed in linear RGB, and converted back to sRGB by a final ‘copy’ blit (see: copy.glsl). In theory anyway, I could have very easily messed something up here!
ClearColor of 0.2 is actually the same as drawing a 2d rect in Pow( 0.2,1.0/2.2 ) as it gets converted from linear->sRGB by the final copy blit. Just tried this in mojo2d and it looks similar to what you’ve posted above, ie:
Local t:=Pow( 0.2,1.0/2.2 ) ‘about 0.48!
canvas.Color=New Color( t,t,t )
canvas.DrawRect( Rect )Linear color are much lighter than what we’re used to I think, so the ‘minimum specular factor’ of .04 is actually quite a bit lighter than we’d instinctively think, ie: everything is *very* shiny! I could be wrong (I only vaguely know what I’m doing here!) but I still think the problem is mainly to do with the env texture.
Why are you using Wine? Why not just build a linux app? Or is this some other use of Wine I don’t know about?
