pirx's Recent Forum Activity

  • Yes, I have done that and published multiple times.

    That said, I really hope C3 gets more features related to user interfaces in the future. Currently it's somewhat cumbersome to achieve simple things like scrollable menus or popup windows and it's not going to be responsive in the way a native app can be (changing layout shape and distributing objects on a grid accordingly). But still apps are absolutely possible and tutorials and examples are all out there in the forums!

  • Yeah I ended up dividing by relation between DrawingCanvas width and Snapshot width which gets the proportions in order (got that from your capx)... but that's such a random problem to have o_O.

    Thanks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks dop2000, that seems to be working.

    It still however only reads pixels in a fragment of the canvas. Upon logging things to the console it seems that for some reason the snapshot has different dimensions than the DrawingCanvas?

    //dimensions of sprite and canvas after pasting sprite (x and y)
    Dimensions of picture:768 511
    dimensions of DrawingCanvas: 768 511
    //dimensions of snapshot (inside "on snapshot")
    snapshot width: 339 snapshot height:226
    
    

    Any idea why would that happen?

  • I'm making a rgb color eyedropper tool.

    The workflow is as follows:

    1. Have a picture in the form of a sprite.
    2. Set DrawingCanvas size and position to that of the sprite.
    3. Paste picture into the DrawingCanvas.
    4. Save snapshot of the DrawingCanvas.
    5. When ready, on mouse click I do "snapshotRedAt(mouse.x,mouse.y)

    That returns nothing when I click on the canvas, yet gives some readings when clicking outside the canvas which probably means that the coordinates for snapshotRedAt need to be relative?

    How do I then provide mouse coordinates for snapshotRedAt correctly in order to read pixel at that precise spot (independently of where the canvas is located in the layout?)

    thanks!

  • I'm looking to make a loop and spawn objects in a couple of rows and columns in that loop with a system->create object action. I'd like to avoid using a counter variable when I already have loopindex to work with.

    So this successfully increases the Y coordinate every 3 spawns:

    190*(round((loopindex-1)/3))

    Now how do I make X to increase 3 times and then go back to zero or 1?

    It should be different than the one for Y because Y stays the same for every 3 spawns, then increases. X should increase every spawn and then go back.

    Thanks!

  • dop2000

    Not sure if it would work in your project but another way to avoid the problem would be to ditch functions completely in this case. You could store layout specific actions in an event and trigger this event when needed ("on TriggerPixel created" or something). Passing parameters could also be accomplished via a couple temp variables. This way you could have this same exact setup in as many layouts/sheets as needed.

    Of course if there's a need to call stuff inline; recursion or other function-specific mechanics this wouldn't work but for simple scripting or just firing off actions/conditions it should be enough.

  • I'm currently making a game based almost entirely on non-linear dialogue with no plugins or addons.

    Using a pure text parser and a made up scripting language for that. I already had this game published twice using other frameworks (Corona SDK, Unity) and now remaking in C3 due to the fact that it is just faster and easier to develop; and WAY less error-prone due to how Construct does not allow for programming errors/typos to be made instead of hitting you with warnings after the fact.

    So you should be fine.

    If you want to use JSON or even an online database that's also well within Construct's capabilities.

  • no other programming languages support this

    Ashley I think what we mean is something like this

    function layout1() 
    {
    	 /* local */ function dostuff() {
    		 console.log("This is scene1!");
    	}
    	dostuff();
    }
    
    function layout2()
    {
    	 /* local */ function dostuff() {
     		console.log("This is scene2!");
     		console.log("Dostuff does something different here!");
     	}
    	dostuff();
    }
    
    

    This is a valid way to declare the same function twice (dostuff). The misunderstanding, I think, is in the fact that Layouts are not scopes in the traditional sense.

  • WackyToaster Games written in classic programming languages probably DO use same named functions that way.

    That is only possible, however, if you can make them local.

    You could, for example, easily have scene-handler functions called scene_1(), scene_2(), scene_3() ... scene_456() and if each of these had a local sub-function called identically item_arrive() that would be pretty normal.

    You would probably also twist your brain trying to make this more efficient by using things like inheritance, classes, scene instancing etc. but thankfully the reason C3 exists is to free you of all these :)

  • So expressions like rgb() and ColorValue return an integer number that can then be used to color something via an action.

    That is useful for me as my game has a parser that uses pure text to generate various items on screen. The source text contains colors in hex so I'd like to write a function that would convert these to the C3 format and then the other way around. But how is this number calculated from rgb values? The C3's color format does not seem compatible with any color-to-whatever calculator I found.

    Thanks!

  • dop2000

    Indeed in this use case it's hard not to see the utility of duplicating function names.

    I think the problem here comes down to scoping: there are no local functions in C3 whereas global ones cause problems mentioned by Ashley above. If you could make a function local to a layout this problem would be non-existent. Good that this was mentioned; I'd rather not discover this limitation in the middle of creating something important!

    Other than that I think the new function system is way more elegant and easier to work with for most purposes.

  • In general you will need backend mechanics. There are three routes to achieve this:

    1. Get a hosting server and write your own backend in php, mysql etc.

    2. Get a hosting server and a self-hosted backend system (such as Parse Server).

    2. Get a backend-as-a-service thing that handles all technicalities and lets you send/receive data using Construct's actions. Google Construct Firebase.

    Route 1 can easily amount to more work than the game itself, and it will be very hard to to make it secure, reliable, scalable etc. so you can skip it upfront. Route 2 will also require skill and then you will need to use third party plugins or JS. So the best option is to use route 3 to create an online database for storing users and then create a system of sign-up/sign-in within your game.

    Just a heads up: this is an undertaking that still can prove more cumbersome than coding the actual game.

pirx's avatar

pirx

Early Adopter

Member since 20 Aug, 2013

Twitter
pirx has 2 followers

Trophy Case

  • 11-Year Club
  • x3
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • RTFM Read the fabulous manual
  • Email Verified

Progress

15/44
How to earn trophies