i'm just gonna drop this here...

i think there's a lot of jquery vs javascript jsperf examples that show pure javascripts speed over 10-1000 times faster depending on the use case.

anyway my point was that c2runtime could be optimized even more (i've found a couple examples and i intend to post a list of changes with all data / old vs new testing, code, 10 runs, average etc..)

i know that mostly problems for people who export are in crosswalk and xdk, but i'm pretty sure there's much to be done here too.

jayderyu - thnx

also i didn't check how much jquery does c2 use, but i thought it was a small amount since i didn't find much of it anyway.

i've noticed that jQuery is being used by construct and i've read that its performance it not so huge, it's okay for web sites, but i think it slows down games.

also i've seen some performance comparisons here:

http://vanilla-js.com/

where you can see massive difference in OPS/s between vanilla JS and jquery.

what i'm mostly concerned about is getting DOM elements - if they're handled every tick for drawing/redrawing/etc., using vanilla would improve performance pretty

much, don't you think Ashley?

anyone?

yes, i know particles are my huge slowdown and some other stuff i'm working on to make it faster, the game is just in alpha phase, but soon it will be beta (approx 2-3 weeks)

and then stuff should work much much faster and better.

also the gameplay should be complete by then

random (1,3) if 0 rustles your jimmies.

check my example on last page.

each tick my event is hit in this order:

1. if any enemy that is in family Enemies has a line of sight towards boatPlayer (your boat that you controll)

a) what is important here is that engine already checks on ALL of them on screen! (no need for foreaches)

b) if one has no line of sight - there's no need to check other conditions so it moves on to next

c) when all enemies are iterated and checked in that TICK - those who have all conditions met will shoot, others won't

2. check if FiringDisabled = 0 (it's a instance var which describes if some enemy can shoot at that moment, used it to set up timer) - if it's 0 - firing is not disabled - therefore you can shoot. if(1) - can't shoot - will SKIP that enemy again! and internal foreach will move on to the next enemy (in that tick)

3. check if kamikaze = 0 (another instance var which describes if my boat shoots or doesn't shoot) - kamikazes (where kamikaze = 1) rush into you, other boats shoot. if that condition is not met next - again in that tick it skips all the enemies that are kamikazes.

4. if animation death is not playing (checking if enemy is dead)

now what happens next?

in that same tick if all 4 conditions are met - has line of sight + firingDisabled = 0 + kamikaze = 0 + is NOT playing "death" animation

THEN - that one enemy that met all those conditions - spawns a cannonball, sets it's angle towards me, bullet speed, and runs a timer that says "Enable firing" for some time..

now what is important here is - THIS TIMER IS LIKE A LOCAL VARIABLE. it's bound to the instance it's called from.

internally an ENEMY that has timer has only his local timer.

now another important part here - i SET FiringDisabled = 1 FOR THAT INSTANCE (which is automatically selected internally) - right after timer kicks in. now as i watch this code i come to a conclusion - timer kicks in, but my event moves on - therefore timer works on another thread waiting for some time to end.

anyway setting firingdisabled to 1 i've disabled this instances shooting, because in the NEXT TICK when this instance is selected again and it's conditions are checked - it will FAIL on condition 2. (CHECK UP in the post) - because it can shoot only when firingDisabled =0. now the timer is counting and that boat isnt' shooting, but once the time has passed, internal TIMER of that single instance (let's say for example it was set to 1SEC and we have 60FPS whole time), will call a function and set THAT INSTANCES variable firingDisabled back to 0. once it does, IN NEXT TICK - when your enemy is selected again and all 4 conditions up there are met - he will shoot again, set the variables and call timer again.

now you probably wonder why i metioned 60FPS and 1SEC. if your timer is let's say 1 SEC for something and you have 60FPS ingame, that means 60 TICKS per second when everything is recalculated. that means that THAT INSTANCE OF BOAT is selected 60 times in a sec and it's conditions for shooting are evaluated 60 times, AND THEY MUST BE written really good - because one condition is false - SKIP, all are true - enter into event!

and selection is already done internally by engine.

X is on screen - destroy

sorry i haven't even read the first post.

anyway it's not bugged as much as i know, but it's 99% that you've made a mistake somewhere and it's hardly reachable / understandable where. that happens because we have events based engine which is sometimes hard to decrypt what happens.

anyway this could also happen if timers use threading. using many threads (each minion owning a thread) could cause issues if undelayin' performance is bad or optimization is not perfect. i've had my share of playin' with threading in c# where lots of stuff is perfectly declared what you can do and can't do, and trust me, it becomes a pain in the ass over some time to sync events.

using wait probably pauses that single picked instance and blocks that thread until time runs out and continues the thread then. using timer probably creates a new thread for counting down the time and stuff gets easily bugged. if wait works for you, then use it. if you really really really want to use timer, at least supply the part of code where we could see what happens and direct you into fixing stuff (or waste another day finding why it happens).

(it's the same as when i optimized 6 events shooting into 1 event (works like a charm ) )

also why would you use "timer.time - 1 sec" thing?

i'm a show you a part of my code how i set how often my enemies shoot. (Timers)

behold:

oh yeah, difficulty - easy, medium and hard are described by 1,2,3.

so you get 1.2*(8/3*1) = ~ 3.2 sec for easy, ~2 sec for medium and 1.2 sec for hard.

oh yeah, i think i could have done this differently too - set a timer that is called every those sec, and call the upper function (swap places of on timer ) - but i think that would be slower. why? timer would fire it's part of code every time. and this way i check if fireing is disabled, if it is don't fire timer. else fire it.

i have a need for

PERFORMANCE MEASUREMENTS from you people!

https://2abb79433838504cbbafafd3207b5c6 ... ZCWGkxWjA/

the game is in semi state - this is only one level with lots of things messed up, but you can drive, shoot, and more.

i would like if you could specify me your PC, average FPS and when do you get slowdowns.

remember - THIS IS A PC GAME!!!! don't play on mobiles/tablets/phones/whatever it won't work!

also - no sound yet!

use

foreach  object
object is on screen              - do something
[/code:3k8uogfx]

yes, that's exactly what i needed, didn't think of it before (different animations ),

thnx a lot!

i have a weapon that shoots canonballs

now since i have different collisions with different objects i had to make events for each on collision differently.

(some are hit differently from the others)

anyway now i want to add another type of bullet (let's say fireball for example), and i want everything else to work

exactly as it is, but i don't want to duplicate code.

so if i put events like this:

cannonball  on collision with object
or
fireball on collision with object           -  do something.. blah blah, and then... destroy fireball, destroy cannonball[/code:3vi72xa8]

is this a good practice? will it bug out when there's no cannonball ?

[quote:2kkzvvzt]hey somebody i'd love you to make a fireball effect. - takin' a round object and applying fire to it. also when that object moves (with bullet or such behaviour) to show a little trail

i've searched up and down for this effect but couldn't find any :/

let me rephrase this - there would be nice if we got an effect of fire burning, when applied to object - make that object burn in upwards direction (when rotated flame should also change it's direction) - would be usefull for static fire effects, fireballs, and more.