DruggedBunny

Forum Replies Created

Viewing 15 posts - 121 through 135 (of 347 total)
  • Author
    Posts
  • in reply to: mojo3d: Entity in view? #14469

    DruggedBunny
    Participant

    Cool, works here. It looks correct — guessing the constraints have a little ‘flex’ in them at first glance, rather than being set to a fixed distance? Will dig in…

    EDIT: Hmm, see what you mean…

    in reply to: Inside access #14464

    DruggedBunny
    Participant

    You want somearray2[3].position.x

    Oh, wait, you also need to init the vector, so somearray2[3].position = New vector, follow by somearray2[3].positionx = whatever

    Or, in your loop…

    [/crayon]
    in reply to: mojo3d: Entity in view? #14447

    DruggedBunny
    Participant

    No, they’re not in yet, just got to wait until Mark fancies playing with that stuff, hopefully soon!

    in reply to: Ted2Go IDE #14445

    DruggedBunny
    Participant

    That’s working great, thanks nerobot! Will really help my workflow.

    in reply to: Ted2Go IDE #14439

    DruggedBunny
    Participant

    it’s easy, will add

    Thanks! This will be used a lot by me!

    in reply to: Fragment shader fails with additional uniform #14437

    DruggedBunny
    Participant

    I don’t generally use Debug because it usually crashes Ted to desktop on ‘7, depending on what you click. (I admit I’m a Print debugger that uses Debug rarely anyway.)

    I’ll try remember to use it before posting bug reports!

    Will give SetInt a whirl today, many thanks.

    By the way, the debug crash error was traced by Ferdi to some degree (but see later comment from same):

    Is your Ted2Go crashing in Window 7 when debugging?

    I’d come to a similar conclusion on an epic 6-hour debugger-debug session, but it seemed to be failing in the underlying C++ call for WriteStdIn, and as far as I could tell was being called correctly, so sort of lost the trail at that, and I knew you didn’t have 7 to be able to follow it up.

    in reply to: Ted2Go IDE #14425

    DruggedBunny
    Participant

    Small feature request — could we have an option in the right-click tab menu* to open the current file’s location on desktop? I know we can do that in projects, but I rarely create projects myself, I just start a new file and go!

    * See attached image.

    Attachments:
    in reply to: Fragment shader fails with additional uniform #14421

    DruggedBunny
    Participant

    I’m still stuck on this — trying to set an int in the shader, in the existing uniform block, it’s always 0 on the GLSL side. (Have tried checking for both m_Mode and i_Mode!)

    I’ve been trying to add another UniformBlock, but I get the impression that’s not the way to handle it. (Am I right in thinking you just have to set the largest data type that’s going to be passed?)

    Tried a new UniformBlock using both types 1 (scalar) and 9 (int), but scalar causes textures not to be found (think because it effectively replaces the existing block ?), while int just crashes when I try to call SetInt.

    (Assume scalar is same as float?)

    So I’m back to what I posted above (see code), which just passes 0 all the time!

    in reply to: Fragment shader fails with additional uniform #14392

    DruggedBunny
    Participant

    I don’t think that’s an error, I get that too, it’s just mojo3d printing out version info while WIP, I believe.

    in reply to: Fragment shader fails with additional uniform #14385

    DruggedBunny
    Participant

    EDIT: To see that fail more clearly, amend the shader check to:

    [/crayon]

    … which results in magenta, even though m_Mode should be 1, it is in fact 0.

    I assume I’m doing something stupid!

    in reply to: Fragment shader fails with additional uniform #14383

    DruggedBunny
    Participant

    It seems my m_Mode value isn’t being received by the shader… what am I doing wrong here?

    Even explicitly calling…

    [/crayon]

    … results in m_Mode apparently being zero. This still produces a black screen instead of the magenta I’d expect:

    [/crayon]

    Runnable version attached…

    Attachments:
    1. uniformzero.zip
    in reply to: What means := ? #14382

    DruggedBunny
    Participant

    That automatically assigns a type to a new variable, eg.

    [/crayon]

    … the type being taken from the result of the calculation or call after the = sign.

    in reply to: Fragment shader fails with additional uniform #14375

    DruggedBunny
    Participant

    EDIT: Skip this and cut to the chase, below!

    This appears to be a general GLSL query, rather than MX2-specific, so anyone with some background welcome, doesn’t have to be Mark!

    I’m trying to get an old greyscale shader working, whereby an integer Mode uniform is passed to set the greyscale algorithm used.

    This used to work (in OpenB3D):

    [/crayon]

    Note the break lines.

    … but now it seems as if it always exits the switch at the first break, regardless of the value of m_Mode!

    For example, this always exits at case 0 (no greyscale applied) if I enable the break within that case, even if m_Mode is set to 1 or above (ie. it shouldn’t even hit case 0):

    [/crayon]

    Yet without the break, it seems to end up at the last breaking case (the final case if there is no earlier break). So with no breaks enabled, the screen always ends up red (per the last line there), even if m_Mode is < 3.

    Example is attached — anyone got any idea what’s going wrong here? Is it some later GLSL spec that works differently?? How do I get it to just select a path based on m_Mode?

    Note that m_Mode is set by this line (0-3, where 0 is normal RGB), and it can then be changed via -/+ on the main keyboard:

    [/crayon]

    Help!

    Attachments:
    1. greyscale.zip
    in reply to: Fragment shader fails with additional uniform #14374

    DruggedBunny
    Participant

    That’s what I was after! Working nicely.

    [/crayon] [/crayon]
    in reply to: Fragment shader fails with additional uniform #14373

    DruggedBunny
    Participant

    Hi Mark, I was kinda guessing that it related to the number of uniforms in the block! As in, for each SetFloat, SetVec3f, etc, I’d need another entry in the ‘block’. Obviously misunderstood this!

    Number 3 happened to tie in with:

    [/crayon]

    Setting to 3 does indeed work! (Yes, dodgy green cube/no mouse position is expected at this point.)

    Thanks for the explanation.

Viewing 15 posts - 121 through 135 (of 347 total)