Speed Issues
BlitzMax Forums/BlitzMax Beginners Area/Speed Issues
| ||
I am new to max, and was working on this, with the end result hopefully being something where explosions underground will affect the "top soil".'Strict Global objects:TList = New TList Global walkability[800,600] Const move_speed# =1 ' used by fps code Local old_ms=MilliSecs() Local renders Local fps Type dirt Field x#,y#,xPos,yPos Function start_game(pheta#) Local Width% = 800, Gravity# = 9.8 Local V0# = Sqr(((width/2)*Gravity)/(Sin(pheta)*Cos(pheta))) Local T# = 2*V0*Sin(pheta)*.5 For Local i# = 0 To T Step .01 Local x# = V0*Cos(pheta)*i Local y# = 600-((V0*Sin(pheta)*i) - (gravity*i*i*.5)) While y < 599 And x < 799 dirt.create(x,y) y = y+1 Wend Next EndFunction Function create(x#,y#) Local temp:dirt = New dirt temp.x = x temp.y = y temp.xPos = Floor(temp.x) temp.yPos = Floor(temp.y) walkability[temp.xPos,temp.yPos] = True objects.addlast(temp) EndFunction Function _Delete(x,y) For Local temp:dirt = EachIn objects If temp.xPos = x And temp.yPos = y Then walkability[temp.xPos,temp.yPos] = False objects.remove(temp) Exit EndIf Next EndFunction Method update() If walkability[xPos,yPos+1] = False Then walkability[xPos,yPos] = False y:+move_speed If y > 598 Then y = 598 xPos = Floor(x) ; yPos = Floor(y) walkability[xPos,yPos] = True EndIf Plot x,y EndMethod EndType Graphics 800,600 dirt.start_game(60) Repeat Cls For Local temp:dirt = EachIn objects temp.update() Next If MouseDown(1) Then For Local i = -20 To 20 For Local k = -20 To 20 dirt._delete(MouseX()+i,MouseY()+k) Next Next EndIf renders=renders+1 ' calculate fps If MilliSecs()-old_ms>=1000 old_ms=MilliSecs() fps=renders renders=0 EndIf DrawText fps,10,10 Flip Until KeyDown(1) Or AppTerminate() End ...It is SLOW ...Any Ideas? Also, is there a way to sort items in lists? It would be nice if the soil would all move together when the layer beneath it is wiped out... |
| ||
Erm, you have 387498 objects. ...It is SLOW ...Any Ideas? Yes. Use less objects. Also, is there a way to sort items in lists? Yes, but since it uses Bubblesort (quadratic time complexity) that's not even remotely plausible with the ammount of objects you have in play here.I think you need to rethink how you want to handle all that data. |
| ||
Don't forgot that using Plot for every single pixel on screen, that would slow down your game even without without 387498 objects. And I'm betting you're using this super plotting routine just to draw the underlaying background to a game too. |
| ||
Originally I had an image that I loaded for each object, but that took about 20 minutes to load...Is there a way so that the rest of the "dirt" will become a large picture while the area that the mouse clicked (and above) will become the pixel by pixel objects? |
| ||
Is this some kind of scorched earth game? |
| ||
It was going to be sort of like pocket tanks...I figured it would be fairly simple, the only difficult part being the menus...APPARENTLY NOT! |
| ||
Dude, if you REALLY must use this really slow technique for your gfx. I suggest you never use CLS and only plot pixels in parts of the screen where there are tanks or movement underneath, then you're never drawing the entire screen each frame. That'd be faster, but still not really that fast and also you'd need some pretty good algorithms and lists to sort out your drawing routines. I think though there's a far better way to do what you're trying to do. Not just in max, but in any language. |
| ||
Dont have a type for every grain of dirt - think about a method that just stores the top and bottom pixel position of every column (without any vertical space in it) of dirt. Only perform logic and individual redraw on columns that have been affected by a blast. You could use drawrect or drawline to draw whole columns where they are changing position. |
| ||
How about: 1. Calculating the level terrain at startup. 2. Store it as pixmap. 3. Only manipulate the pixels inside when needed. 4. Draw the pixmap once a loop for display. |
| ||
Thanks you guys for your help, I will try both using pixmaps and using columns! |
| ||
Please tell us if you get it working, mindstorms.. I'm interrested in how you solved it.. :) |
| ||
Here is a faster version using pixmaps, but it is slow i am guessing when it tries to grabimage the whole screen? Also after "clicking" for a while the green started to become slightly different shades, is there any reason for that? |
| ||
What level of Bmax are you using as that source doesn't compile on 1.20. You're not using Timage and TPixmap types for a start. <edit> You also have an unnecessary 'cls' in your update_chunk method |
| ||
Not that I know much about this but here is mindstorm's code with the types defined (so it can compile on 1.20) and the Cls in the Update_Chuck() method removed: |
| ||
Thanks seb...I guess I need to update then, don't I? |
| ||
This has been eluding me. It should work, but it just deletes the l_pixmap, making the area where it was black. (goes in place of grabimage, drawpixmap, and drawimage in upate dirt)pixmap = LockImage(image) For Local g = 0 To PixmapWidth(l_pixmap)-1 For Local h = 0 To PixmapHeight(l_pixmap)-1 WritePixel(pixmap,x+g,y+h,ReadPixel(l_pixmap,g,h)) Next Next UnlockImage(image) |
| ||
Dude, if you REALLY must use this really slow technique for your gfx. I suggest you never use CLS and only plot pixels in parts of the screen where there are tanks or movement underneath, then you're never drawing the entire screen each frame. That'd be faster, but still not really that fast and also you'd need some pretty good algorithms and lists to sort out your drawing routines. Except you can't actually *count* on the backbuffer not getting cleared by the driver, so there is no guarantee that you still see the 'unaffected' areas on the screen. In addition to that, some video adapters alternate between multiple backbuffers, meaning you need to account for all movement during the last *couple* of frames if you choose not to redraw the entire screen... Not just the last one. |
| ||
Ive found a faster way, with the only slow part coming when it tries to grabimage the whole screen (and comes up with an error if you try to click multiple times in the same area?). In my post above, I posted some not-working code that seems to me like it should. I have been over it in debug, and put the colors into debuglog, but have found nothing...I am awfull at catching bugs. |
| ||
Okay, this doesn't address mindstorm's problem but it does show an example of something I think he is trying to do... this link is to a game (well, it's not really a game as much as it's just a software toy) where you can create TENS of THOUSANDs of independantly flowing pixels, which fall and flow properly using some kind of fluid dynamics. I've never seen anything like it, but given the discussion going on here, I'd love to know how this is done without killing the average PC. http://chir.ag/stuff/sand/ |
| ||
That's neat! Is the source code for that anywhere around? His system works alot better than mine :) |
| ||
I don't even know who wrote it, let alone if the source code is available. It *is* cool as heck, though. |
| ||
Do you suppose he has a huge image and writes to it each frame, or does he have multiple images that take up a section of the screen, and then only updates each image every other time.... |
| ||
I don't know...there appears to be an overall fluid-like dynamics to the whole thing. For example, make a "U" shaped bucket and let it fill, then punch a large hole in the bottom of it...you can see the different colors and layers mix and flow together as it pours out. It looks like it's a per-pixel type calculation. It's amazing...I have no idea how it's done with such speed. |
| ||
Is Java that much faster than blitz? |
| ||
found a C++ source...can anyone point me to the right files to download for porting? (source files found at http://www.piettes.com/fallingsandgame/src/ ) |
| ||
Okay, found the right files...not having much luck seperating what is important (the handling of particles) from all the fancy stuff (the elements, window...everything else...). Can someone take a look at the files and show me which parts are important? (I am guessing that most of void calculate is important, but am I missing any other functions?) |
| ||
I'm having lots of trouble, narrowed it down to 4 void functions, but am having trouble with how he is using the arrays...HELP! I'm getting nowhere with this code! (I'm using the files Sand-4-20060322.cpp and Sand-4-20060322.h) |