oosyrag's Recent Forum Activity

  • Agreed it isn't recommended, but it is possibly workable. Most MMO's were hardly truly real time anyway, there was a lot of fudging going on.

    You can still get 6 states out of a single byte character rather than 8 with little work. The overhead of messages will always be a problem though, so you still have to weigh what data to transfer carefully.

    Anyways it would basically be pretty far outside the scope of a beginner, considering a normal multiplayer game is difficult enough to make properly as it is. Just throwing some ideas out as possible workarounds in case anyone really wants to do this with the capabilities we currently have. The general feeling I got was that there would be no more work done in terms of the multiplayer plugin, regardless of a new runtime in C3, so I'm not holding my breath.

    I also had some crazy ideas involving separate zones/hosts with agents dedicated to popping in and out of each server in succession to pass low priority data.

  • Set variable to len(TextObject.Text)

  • Try 0 spacing?

  • Difficult to diagnose without seeing how tilemap is set up.

    Are you loading the right image? Are your tile sizes, offsets, and spacing set correctly? Are you changing anything at runtime that might make it look different than in the editor?

  • Straight lines are easier - just use a series of rectangles with fade behind the player.

    Curves are harder, but you can do something like to make it smooth , just add lines between the circles.

  • The on created trigger is probably running before your myEnemy sprite has any properties.

    Try a different method, such as using a container, adding the create myFont action to the event that created myEnemy in the first place. The "wait 0" trick might work here too, if you put that above the spawn action.

  • You could simply pick a random x/y, then check if the tile at my is valid and repeat. If valid, stop loop.

  • I modified it a bit to try to account for commas within cells, but I didn't really test extensively. Give it a shot and make sure to proofread.

    Note this will now completely not work for .csv files that don't encapsulate cell data in quotations.

    Edit: Also will break if you have any newline breaks in cell data.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can, but you'll have to build your own sync algorithm via messages rather than use the built in sync.

  • It depends if you're booting into the layout with the large sprites.

    Blank layout (fast load, no memory use) -> Layout with sprites (takes time to load sprites into memory)

    Is equivalent to

    Blank layout with empty sprites (fast load, no memory use) -> Load images via URL into sprites into same layout (takes time to load sprites into memory)

    The top setup will normally keep images in memory when moving to the next layout with the same sprites. Have you tried making the sprites global and/or using the persist behavior after loading from URL? That could possibly keep them in memory across layout changes.

    Generally speaking, it is advisable to design around a set peak graphics memory limit rather than try to fiddle with loading and unloading graphics into memory dynamically to try to get past memory limitations (Usually results in bugs and crashes and time spent with extra coding).

  • newt No actually it's not. Try making a blank project and put 20-50 1080p images in the files folder. Notice how previews boots instantly, and there's no increase in image memory use. Now place those same images in a sprite. Boom got yourself several seconds of loading, and that memory use's pretty big. Also done tests on HTML exports, and you can clearly tell the images from files needs to be loaded from the server. They're not loaded in the same way as sprites. Also if you have a text object print the image memory use, you will see it rise considerably once you use the "load from url" action. Restarting the layout makes it disappear, and the memory use is reset.

    This is the solution to making projects scaleble. This way you don't have load your entire game just to playtest that one level giving you trouble.

    You probably didn't understand what he meant... It actually is pretty much the same. Sprites aren't loaded into memory until they are required in the layout you load into. It is the same as On start layout, all sprites load from url. The benefit is that if those same sprites are used in the next layout after that, they are not unloaded from memory.

    Try putting all your large images in a sprite on an unused layout, you will notice if you preview an empty layout, those sprites are not loaded into memory.

    You use load from url on any given layout to spread out the loading process, so it doesn't necessarily have to complete all in one tick at the start of layout. This can give your users some heads up so it doesn't look frozen in the event of large amounts of sprites loaded.

    There are also advantages such as under the hood sprite sheeting that using the sprite object gives you. Regardless of which method you use, the sprites will need to be loaded in the end and your peak memory use will be the same regardless, so you still have to split up your image memory load across layouts anyway.

    Now if there were a specific action to UNLOAD a sprite from memory in a given layout at runtime, that would open up some possibilities in certain fringe cases.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies