Arima's Forum Posts

  • Oh, so webgl mode doesn't always dump textures immediately? In one of my projects I had a large object that caused a pause every time it was created after all its instances had been destroyed, so I assumed it did. Does that have something to do with the instance pooling?

  • I dunno, if you make the pieces you're creating and destroying small enough, like 256x256, make sure each piece is a entirely different object and not a different instance, and only create 1 each tick, I would think it should work fine, actually. That way it's basically 'streaming' textures to the graphics card and dumping them based on proximity, keeping memory usage down (as long as webgl is being used).

    The trick is definitely to try to not send too much image data in a single tick. As I hear the bandwidth for doing that isn't very high on most systems, which is what causes the pause.

  • Only the transparent pixels of the objects on the layer, unless you've set the layer to be rendered as a texture, in which case I'm not sure if the segment with objects is cropped or if the entire layer is drawn.

  • Use the system condition compare values, object.count=0.

  • Yeah, I design all my projects with the globals in their own event sheet from the start to make sure I don't have to. :/

  • If you cut the global variable, then paste it in the other event sheet, all the deleted references conditions and actions will reappear. I agree it's terrifying though, and would still prefer some other method like copying the variable then pasting it removes it from its previous location instead. Or maybe the method the windows file manager uses for cut and paste, where the file is still in it's original location with reduced opacity until it's pasted, basically resulting in a move function. If the user wants to delete the variable they can use delete instead of cut.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Allow me to disagree about the difficulty of a turn based game. The state of who's turn it is can be represented in a variable. Then use the variable compare condition in events to control when things happen. That is pretty much the main aspect that makes it turn based.

    After that you can tackle each other aspect individually. The computer AI will be the most difficult but is doable.

    Oh, the basics are simple. I had a basic version of the battle system of loot pursuit running very quickly when I first started on it years ago when I didn't know what I was doing that seemed to work just fine at the time. It's all the extra layers of the rest of the stuff that's not basic working with all the other tons of systems together smoothly that becomes a very complex problem if you don't know what you're doing from the start, one that I would not recommend for someone starting out with construct (though it did end up being quite an effective learning experience for learning how to use construct for me). RPG's in particular at first seem simple to make, but are extremely deceptive with how complex they end up being.

    Also, you are one of the top level programmers around here, so what's easy for you, as I'm sure you're aware, might not be easy for someone else. :)

    I'm inclined to agree with R0J0hound on the ease of developing a turn based game... for someone who knows how to work with Construct.

    I still maintain that even with experience, anything past the most basic of RPGs is going to be a much more complex task than it seems. I feel confident stating this objectively as I have read many other people agreeing to the same thing who have attempted making RPGs.

  • C2 is capable of making a turn-based strategy game, but it's one of the most difficult types of games to make. As far as I know, there are no tutorials for how to make one because of that fact. You should probably start with something simpler to learn how to use construct 2 well before attempting to make something so complex.

  • Yeah, I also want to be able to set what opacity it will fade to and such via events, like in CC.

  • That will result in overdraw where they overlap, yes. Option 3 is the most efficient for the rendering process. You could also use option 2 and try to reduce the amount they overlap as much as possible. Also remember to set 'clear background' in the project's properties to no, as that takes up draw time too.

  • mcdan - the landscape performance problem on ipad was fixed a while ago.

  • It might be downloading the new version as you play the old one. Try using the browser object's 'is downloading update' condition to see if that's the case, and the 'on update ready' trigger to reload.

  • Thanks for clearing that up, Ashley. Definitely a good idea to add it to the manual.

  • I suspected that was the reason you hadn't already. Glad to hear you still hope to at some point!

  • I've read up on it, as as far as I understand it, that's still incorrect, as I don't think C2 is blitting at all, I'm almost 100% positive it's billboarding instead (using flat texture mapped camera facing polygons). Even from the link you posted, it describes rendering being the process of having a scene file that is converted into a raster image, the drawing of the pixels themselves being a part of the process. I've rendered stuff in plenty of 3d packages, and none of them have ever wasted time rendering offscreen pixels, which would be a completely pointless waste of time, and I showed that C2 does not do that in my example above.

    It's my understanding that first, a scene 'file' is generated that contains all of the vertex information for all of the objects in the scene (Ashley reuses the data generated for collision polygons as an optimization). Then that data is used to draw the screen from, drawing the parts of each object that are on screen back to front. This can cause overdraw by drawing the same pixel multiple times if that pixel is overlapped by multiple objects. While the vertex information for offscreen objects is still there, it isn't used for the actual drawing of the image itself because the graphics card only draws what is inside the screen.

    I could easily believe that the graphics driver would cut down the undrawn vertex information to only what objects are on screen, which would make sense, but the drawn image itself? No. Cards have limits to their pixel fill rates and drawing offscreen pixels would be terribly wasteful. Also, the graphics driver or card having to check if the geometry is onscreen is a calculation that the driver can likely do far faster automatically than anything that could be done to try to optimize with JavaScript while still having the objects available to process in code/events.

    In practice, it doesn't matter even if either of our understanding is incorrect. Not even minecraft draws things out into infinity - it, like games all the way back to the nes and earlier, create/generate and destroy/store objects based upon distance because even writing the most optimized assembly possible wouldn't be enough to overcome the fact that computers have limits. If someone wants to have a million objects in a layout like Bobofet, then they should implement a dynamic system to load and destroy objects as they get close to/far from the screen, same way everybody else does it.

    Bobofet - if you're using a grid like minecraft, saving/loading the instances to/from an array would work great for that. Also, you might want to do a distance check for the tiles you're checking for collisions with to reduce the number of collision checks. Also, tiled objects render faster than lots of small sprites taking up the same space, or as Tokinsom suggested, paste the tiles to canvas then load the canvas image into a sprite.

    Rexrainbow was actually talking about possibly making a plugin that would load/create or save/destroy instances based on distance automatically - I reccommend bugging him for it, because I want that plugin too. :)