Arima's Forum Posts

  • I'm having difficulty finding a way to do this. I want the screen to scroll when the mouse is near the edge of the window, but stop if it goes past the edge of the window (the rendering area, technically). In all the tests I've done, it just keeps scrolling.

    Anyone know of a way to accomplish this? I've tried checking the mouse values but they stop updating outside the window. Checking if the mouse is over a fullscreen sprite doesn't work either for the same reason.

  • Tinimations - Glad it helped!

    newt - Bitrate and pixel fill rates really don't have anything to do with each other though. Bitrate is all about compressed video and the resulting accuracy of the compressed image in comparison to the original, and game engines don't compress their rendered frames when they're sent to the screen. Even having thousands of small sprites like the snow or confetti he showed might slam the draw calls, but the resulting number of pixels drawn would still probably be quite small compared to what the gpu can manage because of the empty space between them. With that many sprites on screen it's probably going to be a cpu bottleneck calculating their positions or telling the gpu to draw them instead of the actual process of drawing them, which is what we're talking about here. If you meant developers should avoid tons of objects to optimize though, that's correct but for different reasons than the pixel fill rate alone.

    Whiteclaws - A draw call is made for each on screen object, not once for the entire screen, so if you have 100 instances that's a hundred draw calls each frame, or 6000 per second.

    That's not exactly right about RAM/VRAM being cleared each frame - it would be a huge bottleneck to do so, as the process is so slow most games have to show you a loading screen. I suspect you meant the framebuffer is cleared (the RAM/VRAM allocated to the drawn image). Even if that is what you meant I thought I should clarify for anyone else reading. If you have 'clear background' set to yes it clears the framebuffer (which also takes more work, so disabling it can help performance if the background is covered anyway), but you can turn that off and watch objects smear around.

    As mentioned, the framebuffer is stored in memory, so the higher the resolution the more memory it uses.

    saiyadjin - At that resolution with no overdraw it's 124,416,000 drawn pixels per second. The Tegra 3 - which is an older chip - could draw 1.04 billion pixels per second, the Tegra 4 can draw 2.68 billion, and there are two generations of chips that have come out since then that are even faster. Mobile gpus have had the power to draw the entire screen multiple times per frame for quite a while.

    Also, C2 does not only draw moved pixels. I've never heard of the technique used anywhere except compressed video and even then it's not exactly the same thing as it's encoding the movement of pixels rather than just drawing the moved pixels, as far as I know. If anyone's using it for rendering it's unusual (aside from frame warping in VR to coverup missed frames, but that doesn't work properly for rendering new material). If there's any difference between the current frame and the previous one, C2 redraws everything (with the exception of any pixels that are not covered by an object if you tell it not to with the clear background setting). If everything is the same, it skips drawing completely.

  • Whiteclaws - it's not as simple as that. With C2's back to front renderer, if two objects overlap, those pixels are drawn twice.

    newt That's bitrate, pixel fill rate is the number of pixels a gpu can draw per second.

    Tinimations - I'm not sure how much knowing the exact number of pixels drawn each frame would help. There's such a wide variety of hardware out there any number that's fine for one device will be too much for another, unless you're targeting the Xbox one?

    There's also the issue that not all pixels require the same amount of work to draw. Even ignoring webGL effects which obviously add a varying amount of work, a transparent pixel requires more work from the gpu than a fully opaque one. Fully transparent ones still require work from the gpu as well, though only if an object is visible. So if you have an image with a lot of completely transparent pixels, that's work the gpu is doing for no effect. Rotated objects require more work, too.

    For any recent gpu though, those aren't really something to be concerned about as graphics cards are getting ridiculously powerful. Ashley tested his new 1070, and if I recall correctly from his tweet he was able to render a quarter million sprites at 30 fps, though I don't know how large they were.

    However, on a device like the iphone 4s, having UI panels be opaque instead of transparent makes a considerable difference. On some of those older devices the total pixel fill rate is only about three times the resolution of the screen - so if you have a single background image the size of the screen, that's a third of the pixel budget right there.

    I suppose you could calculate the size of the bounding boxes and crop them to the screen to determine a vague estimate of the number of pixels they contain, but again pixels alone aren't the only benchmark for performance because of various things like how it's more work for the gpu to use a larger texture than a smaller one and how it takes extra work to switch from one texture to another (so if you have a hundred of the same image to draw, sticking them all on the same layer can help).

    There are more performance tips in the manual, in case you haven't seen them already: https://www.scirra.com/manual/134/performance-tips

  • Thanks everyone, I'll put that money to better use by getting an i7 instead of an i5 then.

    saiyadjin My current specs? Vista, AMD Athlon 64 x2 4400+, mechanical hard drive, 3.5 GB DDR2, 512 MB Geforce 9800GT, so a new computer is going to be quite the upgrade.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • AFAIK PCI Express SSD can be even twice faster than SATA SSD. Haven't had a pleasure to play around with it so I can't confirm it, but if you will, please share your experience .

    Yeah, some of them are even faster than that at least for read speed. The normal SSD I'm looking at is 550 MB/s read, 520 MB/s write and the PCI one is 1400MB/s read, 600MB/s or 1000 MB/s write (the product page lists both write speeds in different places. I'm a little confused).

    If I do get one I won't have a way of properly comparing it though as it'll have to be part of a new computer, and my current computer has a mechanical drive.

    Hard to say. My laptop (PCIe SSD) boots in 3 seconds and takes 4 seconds to preview Copy Girl. My desktop (Samsung 850 Evo) boots in around 15 seconds and takes 5 seconds to preview Copy Girl...so the PCIe is much faster but only helps preview by about 1 second. That's not accounting for the rest of the machine though. My desktop's CPU is much faster so maybe that has something to do with it.

    Yeah, that's what I'm not sure of. If previewing is limited more by the CPU than the SSD, the extra speed would be unused at preview time.

    Also, that's a slightly older PCIe SSD. A brand new desktop PCI SSD could be faster but you're talking at least $400. Also I've heard they have some issues if used as a boot drive, but I don't remember the details. Last I looked into them was almost 2 years ago.

    I don't have a need for huge amounts of storage, so the one I'm looking at is actually quite a lot cheaper, at $145-160 for 240GB. $400 is out of my price range.

    Thanks for the heads up about possible problems using them as a boot drive - that's what I was planning on using it as so I'll look into it before deciding.

    I have a regular Kingston 60GB SSD and my game takes 10 seconds to preview - 5 to open up NW.js and 5 to load. Windows 10 opens up in about 7 seconds. Getting an SSD was a great decision, especially because the 60GB was at a really good price. I don't think upgrading to a PCI-E one would be worth it though, I mean, even if it's twice as fast it's just like 3 seconds faster...

    Yeah, I'm really on the fence about it. I'm just remembering how the CC version of loot pursuit would take 3-5 minutes to preview and am hesitant to make a decision because of it. I know C2's way faster than CC when previewing, but I don't know how long it'll actually take which just leaves me unsure. It might be worth it just for the piece of mind.

  • Anyone have one? I know normal SSDs are faster than mechanical drives, but has anyone noticed a significant improvement with a PCI SSD for preview times? I'm trying to determine if they're worth the cost.

  • Does C2 use code protection when exporting to nw.js? If so, that means there's an extra ~30% performance hit as mentioned on this page: https://github.com/nwjs/nw.js/wiki/prot ... 8-snapshot

    [quote:1i3vnw8n]The compiled code runs slower than normal JS: ~30% performance according to v8bench. Normal JS source code will not be affected. Again, if you have a real need against this limit, please file an issue and we'll find time to fix it.

    ~30% is quite a lot... if C2 does use it, maybe we should have an option to turn it off.

  • Aphrodite As I understand it, CS2 is free for everyone, but only for non-commercial use.

  • Jerementor Awesome! Thanks for the interest, I've got lots more stuff on the way!

  • — Yep! I've already started on it but my first attempt wasn't very clear. I'm redesigning it to be much more readable.

  • How I do it is by checking frequently for line of sight to the destination, and when the sprite has it I stop the pathfinding behavior and start the moveto plugin.

  • Got lotsa new features implemented!

    In this one I've consolidated all the individual HP numbers that appear with each hit - with the units moving around so much and so many of them appearing, it's too difficult to tell what's actually happened, so now with each hit it updates the one above them instead.There's also HP/SP bars and a ring shows the character's target. I'm going to improve upon that and make a line connecting the two as well to make it more easily readable.

  • Colludium Is it still happening? My only idea is my web host might have been down when you looked.

  • — Simple answer: the reaction time for most of the game is the player's own reaction time, and can be made easier by reducing the battle speed.

    Detailed answer: the basic gameplay loop is this:

    • Game auto-pauses when a character is ready
    • Player inputs command
    • Character immediately performs the command
    • Character pauses for a moment

    Early in the game, the player will get the ability to interrupt the pause after an action and enter a command before the game would normally auto-pause.

    The upside is getting to do the next action sooner, the downside is it increases the stamina use rate so abilities will use more SP than they normally do. All actions require stamina, so interrupting the pause repeatedly will quickly tire a character. Use too much, and they won't have any for when they need it to react to an incoming attack. Waiting for the full pause brings it back down again at a rate that I haven't decided yet and will likely be upgradeable.

    However, there are times where it would benefit the player to use a lot of SP quickly, so I've also got a combo system implemented so players can queue up commands and have the characters do them one immediately after the other.

    Another benefit of doing it this way is instead of just selecting a combo from a list, it means the player gets to be creative and come up with their own combos from the abilities they already have.

    The game is also going to have the ability to easily change the battle speed for people to choose what they're comfortable with - people with better reaction times can crank it up, but they can put the game into slow-motion when things get crazy like when fighting against a swarm.

    I've already got most of what I've described working, and I'll be posting some gifs of the combo system in action after I show some of the other things I've got implemented too.

  • But if you use groups then there's a different story. Unlike triggering the function, toggling a group takes one tick. So if you activate a particular group, code which is under this group will be triggered next tick.

    That's not exactly correct. Toggling a group is instant, so if you activate a group before the group in the event sheet it will run the same tick, but if you activate it after the group in the event sheet the group won't run until the next tick.