Mark Sibly

Forum Replies Created

Viewing 15 posts - 481 through 495 (of 1,431 total)
  • Author
    Posts
  • in reply to: MacOS Audio not fit for purpose! #10497

    Mark Sibly
    Keymaster

    But you can still hear something? I’m stuck with crappy monitor HDMI audio (through a KVM!) and with 64 samples I can hear a noticeable ‘click’ here, which I don’t find particularly surprising as the sound is only playing for 1/11025*64, ie: ~6ms!

    Not quite sure what everyone’s expecting here…

    in reply to: MacOS Audio not fit for purpose! #10493

    Mark Sibly
    Keymaster

    …also works fine with 44100hz, even short sample data lengths such as 32.

    I had assumed this was a macos openal bug, looks like I was wrong.

    in reply to: MacOS Audio not fit for purpose! #10492

    Mark Sibly
    Keymaster

    Can you post a sample you are having problems with?

    This is playing something that sounds a lot like a sine wave, which would suggest it’s not actually a playback problem:

    in reply to: Links point to old domain in files part of the site. #10432

    Mark Sibly
    Keymaster

    Thank you!

    in reply to: Projecting vectors #10427

    Mark Sibly
    Keymaster

    Yes, camera’ll eventually support orthographic, and hopefully stero one day!

    This is the nice thing about the 4×4 projection matrix – it supports both perspective and orthographic projections so the project/unproject code wont have to change.

    in reply to: Making MSVC portable #10416

    Mark Sibly
    Keymaster

    This has been fixed in more recent versions of monkey2. There’s a new binary build on its way – this week sometime for sure!

    in reply to: Projecting vectors #10414

    Mark Sibly
    Keymaster

    Ok, I think these camera methods are basically what you’re after? Adding to repos soon…

    You can added these as extensoin methods if you want, or butcher them for your own evil purposes.

    in reply to: Making MSVC portable #10411

    Mark Sibly
    Keymaster

    Turns out I forgot ;${PATH} at the very end!

    Aha!

    in reply to: Making MSVC portable #10409

    Mark Sibly
    Keymaster

    Is your bin/env_windows.txt file correct, or have you set system PATH to mingw binaries?

    Can you dump bin/env_windows.txt file here, along with full path to devtools.

    in reply to: Making MSVC portable #10407

    Mark Sibly
    Keymaster

    The MSVC version still needs g++ to generate dependancies, so you’ll need this in devtools too.

    in reply to: Projecting vectors #10405

    Mark Sibly
    Keymaster

    Dividing a 3d point by it’s ‘z’ component will give you a 2d point at z=1.

    in reply to: sqlite does not buld for android #10392

    Mark Sibly
    Keymaster

    You’re right, the latest version of the NDK (v15.2.4203891) breaks the sqlite module.

    A fix for this has just been pushed to the develop branch, plus I updated to the latest version of sqlite.

    in reply to: Bug: Light sprite with Virtual Resolution #10385

    Mark Sibly
    Keymaster

    Woah, had to dig deep to find that one, but once I did the fix was surprisingly simple and halved the length of the light vertex shader in the process.

    Fix push to develop branch, but you should really only need to update this file:

    https://github.com/blitz-research/monkey2/blob/develop/modules/mojo/graphics/shaders/light.glsl

    in reply to: Extending Mojo3D #10376

    Mark Sibly
    Keymaster

    And just to confuse things a bit more, here’s another approach!

    This is a bit of a compromise in that it doesn’t store entities in components, but stores a single entity per gameobject (which is effectively its ‘transform’ too) that you can access directly. This means a gameobject can’t have both a camera and a light component – it must have one or the other. You can think of a gameobject’s entity as a sort of special case component.

    It doesn’t bother managing a hierarchy – gameobjects are just stored in a linear stack. You can of course parent gameobject entities to each other though, much like Transform above.

    Again, the implementation of components here isn’t really important, I’m more trying to think out how mojo3d can be interfaced with.

    in reply to: Extending Mojo3D #10372

    Mark Sibly
    Keymaster

    One thing I dislike here – using component string name. In my code above I achived this by Typeof().Name, because you can take a mistake in string but not in type name.

    I didn’t put much thought into how the actual component system should work, and that ‘s sort of the point – having ‘clean’ GameObject and Component classes means you can do whatever you want, however you want.

    But doesn’t the GameObject approach mean you have to wrap all the functionality in the Entity subclasses?

    Yes it does, and it’s up to you to decide if that’s an acceptable amount of work. But it *does* give you 100% control over access to entities, so you can fire off callbacks and invoke signals etc whenever you want etc. You can also mess with parameters, or even prevent properties being modified or methods being called at all. It’s a form of Proxy object I guess, and is really the only way I can think of to gain 100% control over an object.

    A ‘halfway’ solution to this would be to add Entity:Camera, Entity:Light, Entity:Model properties to components to return underlying entities, so people could access component entities directly. This would save you writing all the ‘wrapper’ properties/methods, but again, you lose a degree  of control over things this way, as you have NO IDEA how the entity could potential be modified. But its really up to you how big a deal that is. The above is just an example of IMO a 100% safe/clean approach.

Viewing 15 posts - 481 through 495 (of 1,431 total)