impixi

Forum Replies Created

Viewing 15 posts - 46 through 60 (of 100 total)
  • Author
    Posts
  • in reply to: Hiding Button Background Color #7094

    impixi
    Participant

    *Very* basic example:

    [/crayon]
    in reply to: gles3.0 vs gles2.0 for mx23d #7044

    impixi
    Participant

    There’s no denying we *are* limiting mx23d’s potential user base by going with gles3, but IMO it’s worth it. It’ll make my life a ton easier, and the new features are likely to allow entirely new approaches to terrains, sprites, environmental effects and a bunch of other stuff.

    I agree. An emphatic vote for GLES3 from me…

    Then there are new features such as geometry shaders (which I *really* want to play with!), transform feedback (eg: render to ‘vertex buffer’), and a bunch of other features that just plain make stuff ‘go faster’ such as uniform buffers, geometry instancing (draw a bunch of models in one hit), vertex arrays and so on.

    ..Though geometry shaders are a capability of GLES3.2 (released 2015), so support for that particular feature might be very limited?

    https://en.wikipedia.org/wiki/OpenGL_ES

    in reply to: 3d engine roadmap #6916

    impixi
    Participant

    Utilising a graphics subsystem higher than gles2 would kill off the emscripten (i.e. browser) target in the near term because gles3 (via WebGl 2.0) isn’t supported yet by most browsers.

    http://caniuse.com/#feat=webgl2

    Also, gles2 underlies the current mojo incarnation so mixing 2d with 3d might not be possible if Mark uses gles3 for 3d.

    My personal ideal would be a Vulkan/Metal/DX12-based engine, ditching support for all the old stuff and incapable target platforms, but that would probably take ten times longer and alienate most of monkey2’s potential user-base.

    So, I see Mark’s current plan as “realistic” and something to look forward to, as, like with everything, there are positives as well as negatives.

    in reply to: Patreon $1000 Goal #6874

    impixi
    Participant

    Nice. Looks like a realistic plan. Can’t wait to see the results. 🙂

    in reply to: Miscellaneous Procedural Generation Code #6788

    impixi
    Participant

    @nerobot

    I can’t find a way to do it so I’m going to paste only the pertinent function(s) in each post body and “attach” the complete runnable example as a zip file…

    EDIT: Still a “wall of code” but not quite as bad. 😉

    in reply to: Miscellaneous Procedural Generation Code #6770

    impixi
    Participant

    Relevant theory links for the previous two examples…

    Particle Deposition:
    Generating heightmaps using particle deposition

    Fault Algorithm:
    http://www.lighthouse3d.com/opengl/terrain/index.php?fault

    in reply to: Miscellaneous Procedural Generation Code #6769

    impixi
    Participant

    Fault Algorithm:

    (See attachment for runnable example)

    [/crayon]
    Attachments:
    1. fault.monkey2.zip
    in reply to: Miscellaneous Procedural Generation Code #6767

    impixi
    Participant

    Particle deposition:

    (See attachment for runnable example)

    [/crayon]
    in reply to: Miscellaneous Procedural Generation Code #6763

    impixi
    Participant

    @codifies

    That’s good enough, no improvement necessary.

    For simple proof of concept code I usually don’t bother seeding with a unique number per run but I should. So I’m going to incorporate your code snippet, though slightly simplified. 🙂

    Another way to do it, if you’re not generating something right at the start, is to seed with Microsecs at the point of first user interaction. That’s what I do for my game projects and simulations.

    in reply to: Miscellaneous Procedural Generation Code #6752

    impixi
    Participant

    @codifies

    Yes, if you seed the RNG with the same number you should see the same results regardless of platform, since Monkey 2’s RNG algorithm is platform agnostic.

    EDIT. Sorry, I misunderstood your statement. Yes, I realise Millisecs and Microsecs are derived from the application start time so the results are likely to be the same…

    in reply to: Miscellaneous Procedural Generation Code #6751

    impixi
    Participant

    @pakz

    Here are some links that explain, in depth, the algorithms that the above code is inspired/based on:

    Perlin
    http://devmag.org.za/2009/04/25/perlin-noise/

    Hill algorithm.
    http://www.stuffwithstuff.com/robot-frog/3d/hills/hill.html

    Midpoint displacement (aka Diamond Square algorithm)
    https://en.wikipedia.org/wiki/Diamond-square_algorithm

    Your technique sounds similar to the “hill algorithm”, except you use rectangles instead of circles/ovals. I’d be interested in seeing your code!

    in reply to: Miscellaneous Procedural Generation Code #6746

    impixi
    Participant

    Midpoint Displacement

    (See attachment for runnable example)

    [/crayon]
    Attachments:
    1. mpd.monkey2.zip
    in reply to: Miscellaneous Procedural Generation Code #6745

    impixi
    Participant

    Hill algorithm:

    (See attachment for runnable example)

    [/crayon]
    in reply to: DPI independent GUI system #6719

    impixi
    Participant

    @danilo. Very interesting, thanks for the info… Don’t you just love all the complexity and “edge cases” associated with software development? 😉

    in reply to: DPI independent GUI system #6715

    impixi
    Participant

    Do you need to double the font sizes?

    I’d assume it depends on the amount of DPI. Higher amounts would require higher multiples font size. IIRC, Ted2 fonts are really small by default. I have to use the “zoom” functionality of the “View” menu item – but only on the first run.

    Not sure about your problem above. Would have to see the relevant code… You might need an additional RequestRender call somewhere or to manually adjust View rects, etc…

Viewing 15 posts - 46 through 60 (of 100 total)