Halfgeek's Forum Posts

  • Correct me if I am wrong, but the you can't just compare a a range of products like 6300M with a single product like the Mobility 5430 in such a case.

    It would be like if I would compare the GTX 900 series with the GTX 770.

    So it would be usefull to know which of the 6300M models have been used.

    Since a 6370M is better than a 6330M which you both would compare (and set equal) to the 5430 in your case.

    I'm sorry but this had to be

    The 6300 and 5400 series of mobility radeon (entry, lowest performance) all have 80 shaders, the difference is clock speed but the performance scaling on those older parts aren't linear. At best, you have 20% performance gap. Even the fastest 6300 series is slower than newer iGPU from Intel (when it works).

    On desktop, entry dGPU typically have 500+ shaders, so they are many orders of magnitude faster, and indeed is much faster than Intel iGPU.

  • Thanks for the info! Did not know that was possible, glad to hear that.

    I just tested the game out on my laptop which is a bit slower then my workstation. The game does not run at 60 fps on the auto res option but the fps is around 46. But its still playable and don't notice any jank. Lowering the res gets the fps to 60 again.

    This is on a Intel i7 Q740

    Ati Radeon Mobile 6300 which is by far a good videocard.

    If I have the time I might be able to test it tonight on a Mac Air which has a intel hd4000 vid card.

    This is definitely an Intel driver problem because the mobility 6300 is a re-named HD 5430 Radeon, which itself is barely faster than the iGPU in Sandy Bridge!

    http://www.notebookcheck.net/ATI-Mobili ... 702.0.html

    A newer iGPU found in Ivy Bridge (HD4000) or Haswell (HD4400+) is actually a LOT faster (33/70% faster) than that Radeon.

  • Nice job on the parallax forest!

    I have constant 60 fps no stutter on Chrome. ~18% cpu usage.

    i5-3570K

    Radeon 7950

  • You'll need to collaborate with Scirra on this, let them test the capx examples on Intel graphics and see whats going on.. if its really an Intel problem, perhaps they can submit bug reports to Intel's driver team.

    If its a C2 problem, then they can improve it.

  • Is there no way to make this an option in-game like at an options menu?

    Once in-game I don't think there's a way to change the renderer.

    Would be good if we can toggle at runtime with WebGL on or off, like a -command line. That would be great for these situations.

    Is there a way?

  • It is true, Intel iGPU cannot render simple WebGL shaders (like water, warp, glows etc) without major performance loss. I've tested this a long time ago to find what shaders work well on iGPU & mobiles and what does not (most of them). This is definitely a case of Intel graphics drivers having zero optimizations for this kind of workload. In general its a hit or miss with gaming on Intel iGPU (some of the games I play on my Intel notebook have horrible texturing bugs or flickering).

    You may have to make 2 versions for Steam, 1 with WebGL + shaders for people with dGPU and one without for those on notebooks on iGPU.

    Note that this is actually an Intel driver issue, because even crap low-end discrete GPU from NV or AMD have no issues and actually running with WebGL on results in much faster performance as it should.

  • See my earlier explanation, it explains why this happens. It is expected behavior and by-design.

    Bottom-line:

    "On Overlap + Trigger Once" keeps track at a per-Object Type/Family Level.

    "On Collision" keeps track at a per-UID level.

    Yes, its good to now know the pros & cons of both approach, where possible, use Is Overlap with Trigger Once, or without it with bullets that destroy themselves etc, since On Col has added overhead and should be used where required.

    I had not considered using Is Overlap because I've always went with On Col, but definitely in future, where Is Overlap works fine, that should be used to optimize the game. With lots of col checks, such optimizations leads to major performance gains.

  • This is definitely a case of poor implementation with Intel graphics. I noticed my own beefy PC 3770K w HD4400 struggles with WebGL on but off, its fine, the CPU handles it like a beast that it is.

    Most gamers do have a discrete GPU, NV or AMD and even the crapper ones are miles ahead of Intel.

  • Thanks for the clarification, think that was greatly needed

    However in what circumstances is the extra functionality of "On collision" a benefit or where is it intended to be used? At least in my experience I mostly used it with bullets hitting an enemy and then the bullet is destroyed. However you say that it needs to keep track of when the separation happens and touch again. Where as "Is overlapping" doesn't do this and just checks for an overlap, which is really what you need when a bullet hits an enemy for instant as the bullet most likely is destroyed.

    Im a bit uncertain how to formulate the question , but can you give an example where "On collision" would outshine "Is overlapping" meaning where the extra functionality is obvious or what to say? or if anyone else can? I would appreciate it, because im happy with the clarification, but sadly I still don't see the reason to use "On collision" over "Is overlapping", so an example would help me?

    A beam weapon that expands and hits an enemy, then keeps going and hits more enemies.

    If you use Is Overlap, it will trigger many times on each enemy hit. If you add Trigger Once to it, it sometimes does not trigger on the subsequent enemy hits so the AoE is not reliable.

    On Col works and trigger once for each instance and it will hit as many instance as it needs, but once only, very reliable.

    The same applies for other AoE weapons, like an expanding nova or EMP circle, shockwaves, etc. On Col is 100% reliable.

  • Thanks, that makes a lot of sense now. There's definitely places where Is Overlap is a better way and again, other situations where On Col is better.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Looks great man!

    Thanks, I had a few feedback so far in that line of thought.

    The BG and planet sprites are actually place holders. Lots of things need to be improved yet!

    I had a friend point out my Beams end abruptly and they were right, so I fixed it with a gradient and it looks heaps better in action.

  • More screenshots, of two major factions (Empire vs Starborn) in a fleet battle:

    In a typical engagements, individual AI have priorities that best suit their weapons or speed/agility, ships with anti-fighter or drone weapons will disperse and chase those targets. Likewise, bigger ships will prioritize engaging other big ships where their guns can penetrate high armor better than smaller weapons.

    There's a few different damage types, ie. Energy (bonus vs shields, penalty vs armor), Kinetic (neutral) and Plasma (penalty vs shields, bonus vs armor). Armor has innate Armor Ratings that reduces incoming damage by a flat amount (as in Starcraft), so smaller fast firing weapons barely scratch heavy ship armor.

    I plan to have ships leave behind a wreck after destruction, player will able to loot it for cargo, credits or rare modified modules (to reverse engineer for a blueprint to craft).

    Also, as any experienced gamer knows in these sort of games, a major balance issue is thus:

    One of the problems with smaller ship classes is they fail hard in a blob fest engagement, often instant death due to the mass incoming fire. I’ve balanced this by giving ship classes an innate evasion, with a big bonus for fast Corvettes (smallest pilot-able ships), whilst drones have a very high evasion.

    This evasion only triggers against weapons which are not designed to engage these targets, so an all-rounder fleet is required, else a few big ships with massive guns might face a bunch of smaller threats which they a) can't track the fast moving ships as they weave & orbit and b) even when they fire, the target has a high evade chance to take zero damage!

  • - I had about the same - the On-Collision has a massive and surprising overhead to it. I would certainly use Overlap / Trigger Once if the situation allows; however, if you need to know whenever a collision happens to a new object, while another similar object is overlapping, the On Collision trigger seems to be the simple way to go (although I'm sure that you could use Overlap with an array for a much better result in situations like this). I'm pretty sure that Ashley said in another thread that the two methods in that example are essentially identical - but that clearly isn't the case!

    In my context, most of the col occur with bullets or lasers and such so I can do Is Overlap -> disable collision of bullet & spawn various effects then destroy bullet. So it only triggers once.

    On Col seem to have a very high overhead and its limiting the CPU in other ways, because even in situations where its 40% CPU usage, the fps isn't 60, its down to ~40.

  • Colludium

    I tested your capx, On Col was using 94% CPU versus around 10% of Is Overlap with Trigger Once.

  • What's interesting is I took your capx, and did the On Col check AFTER a "Every 0.1 seconds" trigger.

    [attachment=0:2zy7tnfp][/attachment:2zy7tnfp]

    The Col per tick drop as expected as well as CPU usage went down to ~40%. BUT, fps is capped at much lower than 60 fps.

    This does not occur for Is Overlap under the same scenario, CPU usage also went down but fps is 60.

    There is something fundamentally bottlenecking On Col, causing a higher overhead that is limiting the rendering.

    This needs an official input from Scirra. There is a large performance penalty associated with On Col vs Is Overlap.