nobuyuki

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 54 total)
  • Author
    Posts
  • in reply to: Ted2Go IDE #8824

    nobuyuki
    Participant

    @hezkore

    IRC color codes work by using control code 0003 (ETX) to signify the start and end of a block of colored text.  it then expects one or two arguments specifying the color code from a preset table.

    https://en.wikichip.org/wiki/irc/colors

    http://www.mirc.com/colors.html

     

    Some other control codes are used to create text formatting.  See the first link for more details.

    in reply to: Unable to load certain WAV files #7971

    nobuyuki
    Participant

    ah, fair enough.  I was under the assumption that the fmt block was incomplete or had bad data.

    in reply to: Unable to load certain WAV files #7962

    nobuyuki
    Participant

    a game engine isn’t an audio editor, so I’d argue it’s still your responsibility to fix wave files with bad headers if you want them to play in your project.  Without a proper header, the entire file needs to be read and the length and format guessed.

    in reply to: Monkey2 3rd party IDE #7793

    nobuyuki
    Participant

    ++++++++.  Can’t live without Jungle currently  :c

    in reply to: Nintendo Switch devkit price announced: $500 #7792

    nobuyuki
    Participant

    That would be awesome.  I really want to get in on the hype for this system…

    in reply to: Playniax news #7791

    nobuyuki
    Participant

    Ace, Tony!  Pyro2 is shaping up to be the comprehensive framework for mx2.  Keep up the good work

    in reply to: Ported particle System "Memory access violation" [SOLVED] #7668

    nobuyuki
    Participant

    [EDIT] Thinking about this, maybe TimeFunc() should just be replacable, where the default just gets TimeManager.DefaultTime (that in turn returns a mainloop updated Millisecs() ) That would mean no passing of nowtime + a simple way to pause/scale the system, with out sacrificing special timescales if needed

    Yes!  One upgrade I was thinking of making in my monkey 1 framework was to give every system which relied on time a field for a timeIndex reference.  One of the reasons I never got around to it was that it meant wrapping Millisecs() globally (to more easily support pausing) and probably keeping a seperate frame timer too, and as you said probably even going a step further if I needed support for time stretching/compression in my games.  In mx2 this can be a simple Func type and ppl who don’t need that complexity can just keep the default timeIndex of a pointer to Millisecs().

    in reply to: Ported particle System "Memory access violation" [SOLVED] #7658

    nobuyuki
    Participant

    I’d rather you keep your version available for the time being, since I don’t plan to do an authoritative version for mx2 anytime soon.  I’m waiting for Jungle to get some mx2 support before diving into that, and still have a few incomplete projects that aren’t even using mojo2 so I’ll be stuck there for at least a while.

    The other system is very simple and actually written less with public use in mind, but I’ll think about it!  It follows a “god particle” baseclass pattern which I didn’t favor for argyne, and doesn’t have intrinsic support for frame-based timing or second-order spawning.  What it does have is Easing curve functions and an allocator.  Here’s a code snippet of the main class, it won’t work without the nscreen framework (unreleased) but it should be fairly simple to understand.

    You can see an example of it working here.  The example extends Particle with a subclass that puts it on a rail, using Particle.RotMulDest() to spin back towards its destination.  Since the system was made specifically for this game, it’s a lot less elegant (especially to extend or if you need frame timing) but also a lot more compact and “to the point”.  The allocator here is also sloppy and just kills particles regardless of how close they are to expiring, which argyne would’ve done instead as a property of the Particle interface (which would’ve fetched a resource based on time-to-live, iirc).

    I would like to release something eventually for monkey/mx2 that is a “best of both worlds” of both of these systems.  Perhaps if mx2-only, have particles accept functions which define their behavior and reduce the number of classes/interfaces…

    in reply to: Ported particle System "Memory access violation" [SOLVED] #7650

    nobuyuki
    Participant

    Hi!

    Yes, it seems that bit of code from the original was a bit janky.  At some point in the design of argyne, I ran into a problem where I couldn’t make interfaces generic (a limitation of Monkey at the time) and ended up having to rewrite a large portion of the system.  This bug may have been an artifact of sloppy refactoring.

    One of the reasons I abandoned argyne was because it creates a lot of object initializations and does nothing to track or pool particle resources, making the entire system very resource-intensive compared to the (as of yet still unreleased) system I wrote to replace it.  Thrash was inevitable as the GC would have to sweep these eventually and that would cause big hiccups on Android (and eventually in glfw too if the example was anything to go by).

    Thanks for updating argyne for mx2.  If I were to rewrite it myself, it would probably handle a few things differently!  The general way to set it up would probably stay similar, though…… and there’d also be a way to delay its startTime, and an easing curve option in ParticleValues.Set()…..

    in reply to: How to init array? #7342

    nobuyuki
    Participant

    yay slices.  Best of luck

    in reply to: Canvas memory saturation (Bug?) #7341

    nobuyuki
    Participant

    check this thread out, it may be helpful even though it’s old:  http://www.monkey-x.com/Community/posts.php?topic=9473&post=98448&view=all#98448

     

    It relates to Images rather than Canvas but the notes on how the GC works near the end are probably still useful.

    in reply to: Ted2Go IDE #7227

    nobuyuki
    Participant

    hezkore:  Ctrl/Cmd+W is a typical way to close windows on non-Windows systems, but in Windows the typical shortcut is Ctrl+F4  🙂

    in reply to: gles3.0 vs gles2.0 for mx23d #7215

    nobuyuki
    Participant

    Most people probably won’t take advantage of GLES3-specific features but it’s definitely not going to “cut your userbase in half” like some people are saying.  If you’re targeting 3d for a new project then you’re probably not targeting a legacy userbase.  If you are, why not backport it yourself?  This seems like a special case scenario considering the circumstances.   Usage of GLES2-only devices is on the decline.

    Also, one thing that hasn’t been mentioned yet is that GLES3 guarantees availability of ETC2 texture compression, whereas on GLES2 you maybe got ETC1 but it wasn’t guaranteed to be available, and it didn’t support alpha channels anyway which often necessitated figuring out what type of hardware compression the device did support (cludge around or have a table of GPUs lying about) and creating duped assets for each of these, then specifying it in the manifest to reach the widest audience.

    It could be a mess;  PowerVR, nVidia, and AMD all had their own standard, and in AMD’s case, they had two(!).  Part of the convenience of GLES3 is you don’t have to mess with any of these; you just use Ericsson 2 compression and you’re good to go.

    in reply to: A Raspberry Pi Synth #7214

    nobuyuki
    Participant

    neat project!  Where from and how much was the controller?  And, how’s the latency?  I know there are more dedicated kits for rolling your own MIDI controllers and synths but I’m curious if this would be a good starter to patch in a daughterboard (with a dedicated synth chip on it) via GPIO or if rpi is not suitable for this task.  Tons of fun possibilities though 🙂

    in reply to: Continue Line #7193

    nobuyuki
    Participant

    I don’t like line continuation characters at all.  If there’d be only one change to make, I’d request that “+” qualify as a continuation character, or make all operators qualify.  Don’t know how messy that would be, but I’d presume that using “..” will be unfun for parsers and/or preclude using it in the monkey1 way for slicing (is that even a thing anymore?)

Viewing 15 posts - 1 through 15 (of 54 total)