brent_hamel's Recent Forum Activity

  • I haven't had the chance to explore this much the last few days, however it appears that adding a script to "-On Start of Layout" that simply has "window.open( "","_blank" );" does seem to open a second window that can be moved around and repositioned within multiple monitors.

    However, as ROJO mentioned, I haven't begun to look at how to either control what is displayed in the new window, or read user input FROM the new window... so there's a lot of testing and experimenting to do. If anyone has any experience with this or some ideas to try out, please let me know.

  • Hi All,

    Happy New Year, here's to everyone making great stuff with C3 for 2024!!

    Just wondering if there's a way, either through Event Sheets or JS to create UI elements that can either be fixed or floating, and if floating, can be repositioned across multiple monitors.

    I'm looking to make a desktop based asset creation app, so being able to rearrange UI elements across multiple monitors for users is a highly sought after feature in my eyes.

    I know how to do resizeable but docked, I'm just not sure how to do floating that can exceed the bounds of the primary window (as floating is pointless imo if you can't move it out of the way of the primary screen.

    Thanks in advance,

    Brent

  • This is running at a solid 60 fps on my PC. Thanks so much for this!! I'll keep everyone posted as to how this project comes along!!

    This is actually a potential component of a larger project that I've already started that also happens to involve:

    - a graphics editor

    - a text editor

    - a sound editor using the third party WebMIDI plugin (which is excellent and would love to see bundled as a standard plugin someday)

    I won't say more yet, though this may have already given it away... Either way, I'll keep everyone posted!

  • If you share your capx with me, I can more quickly identify what's going on for you, if you're comfortable sharing it that is. I'm on Discord if that'd be better for you.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I can do a mockup for you tomorrow and post it here, sound ok?

  • So if its the specific math you need, then the way to calculate it is:

    Object1.yMin = -1800

    Object1.yRange = 2110 ( -1800 + 2110 = 310 )

    Object2.yMin = 410

    Object2.yRange = 840 ( 410 + 840 = 1250 )

    Object1.Y = -1272.5 ( this is where the player has placed Object1 )

    Object2.Y = ???

    // yOffset uses the values of yMin, Y, and yRange to end up with a value

    // between 0 and 1... this decimal is our percentage 0.25 = 25%, etc

    - Object1.yOffset = abs( abs( Object1.yMin - Object1.Y ) / Object1.yRange )

    // we can then use that percentage to easily place Object2, as it'll take the

    // yOffset percentage, and multiply it by object2.yRange, giving the same

    // percentage between Object2.yMin, and Object2.yRange

    - Object2.Y = Object2.yMin + ( Object2.yRange * Object1.yOffset )

    // By putting the actual values in:

    - Object2.Y = 410 + ( 840 * 0.25 ) // which equals...

    - Object2.Y = 410 + ( 210 ) // which equals...

    - Object2.Y = 620

    I'm sorry if this comes across as patronizing, its not meant to be, I'm just not sure at what level you're at with all this... does this help?

  • Are these moves supposed to happen smoothly over time? Or instantly, like once the player releases placement of object1, then object2 jumps to the appropriate place as a result?

    I ask about "over time" as you mentioned using lerp in your original post

    Either way, it leads me to think about these as percentages between their clamp values, determine the percentage that player one has selected, and then move object2 the same percentage between 1250 and 410

    If you're looking for the position change to move smoothly over time, then using lerp can help:

    lerp( a, b, x )

    lerp( starting value, target value, percentage of the distance to move each tick )

    so if you have:

    Set object2.Y to lerp( object2.Y, object1.yOffset, 1 )

    yOffset is the percentage between 310 and -1800 that the player has placed object1. object2.Y will then be set to the same percentage from 1250 to 410 immediately, as its travelled 100% of the way from where it is to where it should be this tick.

    If instead you have:

    Set object2.Y to lerp( object2.Y, object1.yOffset, 0.25 )

    Then object2 will only move 25% of the way there this tick, and now that its moved, the pixel distance between the two is shorter, so the next tick that 25% will be smaller. Lerp runs the risk of never reaching its destination and only moving smaller and smaller increments, so its good practice to check for a position that's really close to the target, and if its passed that position, set it to the target. Otherwise, it'll be lerping forever but essentially invisible to the eye.

    Is this close to what you're looking for?

  • If I understand correctly, you want the following to happen:

    object1.Y starts at 310 and then moves over time to -1800 (a difference of -2110 pixels)

    and at the same time:

    object2.Y starts at 1250 and then moves over time to 410 (a difference of -840 pixels)

    and you want object1 to trigger object2, and for both to reach their end positions at the same time?

  • Best performance so far appears to be using 256x240 single pixel TiledBackground objects, with the palette as the image, using X and Y offset to change the displayed pixel, however that's ~35 fps on my PC and ~45 on my phone when using remote preview... still not viable I'm afraid :(

  • Oh, and I also tried the SetColor shader on the sprites (without changing their frames) and that was the slowest at about 10 fps (For some reason I thought the shader might be faster, but alas)

  • So here's the thing... I've recently been learning 6502 Assembly for NES programming, which then led me to learning about how emulators work, which has NOW led me to wondering if its possible to make a bare bones NES emulator using C3... I can load a rom just fine. I can parse it and disassemble it just fine. I can read and interpret the CHR data just fine. However... There doesn't seem to be any way I can emulate the creation of a frame of graphics, 60 times a second.

    I've tried the DrawingCanvas, but its too slow... I've tried 256x240 stationary single pixel sprites pre-loaded with the NES palettes colors as frames... also too slow... I've also tried using the TileMap plugin (which is comparable in performance to the sprites) and the best FPS I can manage is ~30 fps, which is 50% of what I need to have a playable emulator...

    Is this simply an impossible task for C3? I know emulators tend to be more resource hoggy than they'd seem given all the work they need to do, but if C3 can natively draw entire screen's worth of graphics at 60 fps, at a much higher screen res... then why can't I?

    Also... if I can't even do randomized noise at 60 fps, then there's no way I can evaluate the NES's 3 graphics layers to determine which pixel to show (or to show the BG color instead)

    Any input would be greatly appreciated

    Thanks

brent_hamel's avatar

brent_hamel

Member since 31 Dec, 2009

None one is following brent_hamel yet!

Trophy Case

  • 14-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies