none
Emitter Optimization RRS feed

  • Question

  • ive coded this emitter here: NMX466 here the version with the Staying "blood" effects: PQW168

    drag and drop the emitter with the left mouse button and activate it with the right mouse button.
    (the old version without the "moving" variable sucked about 20% more performance than the version with the variable.)

    i wanted to see if theres a way to even more optimize this project. if you know how, please tell me! [SOLVED]

    edit:

    Just if someone cares, i updated the emitter code, and it sucks even less performance now. i think i reached the limit of optimization.. (it runs at 5% cpu usage when the sprites are moving, and on about 0% when nothing is happening)

    Import code: PMP013

    greez!
    Live for nothing, OR CODE FOR SOMETHING!
    • Edited by Dudeson Sunday, October 4, 2009 1:59 PM
    Saturday, September 12, 2009 3:16 PM

Answers

  • Some changes:

    1] Use variables rather than Shapes.GetLeft to keep track of locations.
    2] The moving variable is not needed since the mouse control is inside the loop (not an event - cannot be called while it is already running from a previous event call)
    3] Improved logic using a new variable 'dragging ' to only do what is necessary while dragging the emitter - also doesn't loose the emitter if the mouse movement is too fast.

    Import NMX466-0 - the blood is at lease double the speed on my PC.
    • Marked as answer by Dudeson Sunday, September 13, 2009 7:50 PM
    Saturday, September 12, 2009 3:41 PM
    Moderator

All replies

  • Some changes:

    1] Use variables rather than Shapes.GetLeft to keep track of locations.
    2] The moving variable is not needed since the mouse control is inside the loop (not an event - cannot be called while it is already running from a previous event call)
    3] Improved logic using a new variable 'dragging ' to only do what is necessary while dragging the emitter - also doesn't loose the emitter if the mouse movement is too fast.

    Import NMX466-0 - the blood is at lease double the speed on my PC.
    • Marked as answer by Dudeson Sunday, September 13, 2009 7:50 PM
    Saturday, September 12, 2009 3:41 PM
    Moderator
  • omg! runs extremely fast! but i used variables instead of getleft, or did i?? but my version with the moving variable sucked less performance while doing nothing. yours sucks more (performance^^). and the moving variable is for the blood, not the mouse movement.

    i'll look trough it. thx!
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 3:54 PM
  • You did use getleft.  You may be OK with with the moving variable for blood, except that:

    The setting of moving only saves time when all the blood have stopped moving when there are no performance issues, so the updating of this variable which takes some small time is only useful when nothing is happening!.

    But the emitter logic is better with the variable dragging.
    Saturday, September 12, 2009 4:04 PM
    Moderator
  • thats what i wanted. i wanted that the blood code is inactive when the blood isnt moving...
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 4:06 PM
  • OK, as you were then for that part.
    Saturday, September 12, 2009 4:13 PM
    Moderator
  • i would have never believed it, but the master made a fault! xD

    the line:

    If MX >= EmitterX-25 And MX <= EmitterX+25 And MY >= EmitterY-25 And MY <= EmitterY+25 then
            dragging = 1
    endif

    should actually be:
     If MX >= EmitterX And MX <= EmitterX+50 And MY >= EmitterY And MY <= EmitterY+50 then
            dragging = 1
    endif

    otherwise you have to click the emitter on the top left area.
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 6:51 PM
  • ok, here you go: NMX466-1

    this is the a bit more optimized version. mainly while doing nothing. about 10% more performance. but theres some strange "lag" while the blood sprites fly around. please check that out... is it because of my moving and mover[i] variables?
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 7:14 PM
  • Not quite sure what the mover[i] is for - it doesn't do anything much OR take much time - I guess it is for some other purpose.  The jerky behaviour is mainly because you stop the vertical acceleration (gravity) at a fixed value of 2  - If BWY[i]<2 Then .  If you increase this, or just don'y have a limit the blood will continue to accelerate down with gravity and appear possibly more natural.

          moving=moving-1
          BWY[i]=BWY[i]+0.05
          BWX[i] = BWX[i] * 0.998

    Saturday, September 12, 2009 7:32 PM
    Moderator
  • the mover[i] is to get wheter the blood sprite is touching the ground or not. if all are touching it, the code gets skipped. and i've put a limit in there because there actually is a max gravity speed, or isnt there??
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 7:38 PM
  • Gravity is an acceleration (velocity keeps increasing).  In reality frictional air resistance limits the acceleration due to gravity by applying a frictional force upwards (against gravity) depending on the mass, shape of the falling object and its velocity (actually velocity squared).

    The jerkiness is due to the acceleration (gravity) suddenly stopping when the downwards velocity is 2.  What you want is something efficient (fast without too much complexity) that looks natural.  Limiting velocity (terminal velocity) can be modelled in many levels of complexity (not a sudden velocity limit though), but for the purposes of your program I would go with simple, fast and looks OK (i.e. ignore air resistance).
    Saturday, September 12, 2009 7:53 PM
    Moderator
  • sry, but no. it still moves strange. even after removing the limit...
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 7:56 PM
  • I guess it is a bit subjective.  The only other things I can see are a couple of necessary lines:

        EmitterX=Shapes.GetLeft(Emitter)
        EmitterY=Shapes.GetTop(Emitter)

    and the blood on the floor should be:

       GraphicsWindow.FillEllipse(BX[i]-5,BY[i]-5,10,10)

    Apart from this and playing with the gravity, possibly the Program.Delay(1), import NMX466-2 is pretty efficient.
    Saturday, September 12, 2009 8:20 PM
    Moderator
  • yup, its pretty nice! but it still lags around.. maybe its just my computer atm... it isnt slow! its a quadcore.

    so that means, shapes get filled from the center??? or also from the top left coordinate? (i mean, because of the -5..)

    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 8:23 PM
  • The speed is not so much your PC as SmallBasic with .Net being slow.  Its not designed for speed, but rather as a learning environment.

    The shapes are drawn from the top left coordinate, hence the -5 if your code coordinates using the shape centre.
    Saturday, September 12, 2009 8:30 PM
    Moderator
  • but why using the centre? i mean, since i want the bloodspots to be there where the blood shapes landed...?
    Live for nothing, OR CODE FOR SOMETHING!
    Saturday, September 12, 2009 8:32 PM
  • Try both and see, the blood is being moved using Shapes.Move(Blood[i],BX[i]-5,BY[i]-5) as well, hence its last position is centred at (BX[i],BY[i]) and this is where you want it to stay.

    You could do everything with the top left coordinates, but probably makes positioning more confusing (for me anyway) especially when you use the mouse coordinates (relative to shape centre) or for collisions - the main thing is to be consistent.

    This explains why I made the change:

    If MX >= EmitterX-25 And MX <= EmitterX+25 And MY >= EmitterY-25 And MY <= EmitterY+25 then

    Since I change the definition of [EmitterX,EmitterY] to be the shape centre
    • Edited by litdevModerator Saturday, September 12, 2009 9:15 PM comment on Emmiter
    Saturday, September 12, 2009 8:53 PM
    Moderator
  • ohh... yeah, it is confusing..


    but that didnt work in the earlyer version, or did it??

    another question btw. is it smart for me to learn c++ right away from small basic, or should i take another step inbetween?
    Live for nothing, OR CODE FOR SOMETHING!
    Sunday, September 13, 2009 12:20 PM
  • I will have made the other required changes to the EmitterX,EmitterY to be defined as the shape centre - check back to the code I uploaded if you want.

    Visual Basic or C++ - both have loads of resources online and books. 

    The fundamentals are not so different from Small Basic, just many many more ways to do it along with some other concepts.  The biggest difference will be that you have to plan the structure of your programs more carefully - the initial design of data and functionality will have big impacts on how the code can be developed.

    The MS Express 2008 C++, VB and C# are free; download them and start with some of the introductory examples.  I guess start with VB, but play with them all, then pick one and get a decent book and use the net resources.  If you feel C++ is where you want to go (as good as any choice) then pick this.  Ultimately they are not that different, leaning one will definitely help with the others, so time leaning VB is not wasted if you want to then use C++.
    Sunday, September 13, 2009 5:03 PM
    Moderator
  • cool thx!

    but am i right when i say that c++ is used for todays game development? because i want to get into game development..
    Live for nothing, OR CODE FOR SOMETHING!
    Sunday, September 13, 2009 5:47 PM
  • Generally yes.
    Sunday, September 13, 2009 5:55 PM
    Moderator
  • cool. ^^
    Live for nothing, OR CODE FOR SOMETHING!
    Sunday, September 13, 2009 7:47 PM
  • To confuse things, you may also want to look at C# XNA.  I don't know much about it, but it looks like it does a lot of the low level graphics, letting you get on with the gameplay ideas.

    http://blogs.msdn.com/coding4fun/archive/tags/XNA/default.aspx
    Sunday, September 13, 2009 8:36 PM
    Moderator
  • thx for confusing me even more.^^ i'll take a look at it. thx!
    Live for nothing, OR CODE FOR SOMETHING!
    Monday, September 14, 2009 2:15 PM
  • Just if someone cares, i updated the emitter code, and it sucks even less performance now. i think i reached the limit of optimization.. (it runs at 5% cpu usage when the sprites are moving, and on about 0% when nothing is happening)

    Import code: PMP013
    Live for nothing, OR CODE FOR SOMETHING!
    Friday, October 2, 2009 7:00 PM