Speed Issues

BlitzMax Forums/BlitzMax Beginners Area/Speed Issues

mindstorms(Posted 2006) [#1]
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...


FlameDuck(Posted 2006) [#2]
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.


(tu) ENAY(Posted 2006) [#3]
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.


mindstorms(Posted 2006) [#4]
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?


ImaginaryHuman(Posted 2006) [#5]
Is this some kind of scorched earth game?


mindstorms(Posted 2006) [#6]
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!


(tu) ENAY(Posted 2006) [#7]
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.


Who was John Galt?(Posted 2006) [#8]
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.


Grisu(Posted 2006) [#9]
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.


mindstorms(Posted 2006) [#10]
Thanks you guys for your help, I will try both using pixmaps and using columns!


LarsG(Posted 2006) [#11]
Please tell us if you get it working, mindstorms..
I'm interrested in how you solved it.. :)


mindstorms(Posted 2006) [#12]
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?




tonyg(Posted 2006) [#13]
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


SebHoll(Posted 2006) [#14]
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:




mindstorms(Posted 2006) [#15]
Thanks seb...I guess I need to update then, don't I?


mindstorms(Posted 2006) [#16]
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)



xlsior(Posted 2006) [#17]
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.


mindstorms(Posted 2006) [#18]
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.


Tachyon(Posted 2006) [#19]
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/


mindstorms(Posted 2006) [#20]
That's neat! Is the source code for that anywhere around? His system works alot better than mine :)


Tachyon(Posted 2006) [#21]
I don't even know who wrote it, let alone if the source code is available. It *is* cool as heck, though.


mindstorms(Posted 2006) [#22]
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....


Tachyon(Posted 2006) [#23]
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.


mindstorms(Posted 2006) [#24]
Is Java that much faster than blitz?


mindstorms(Posted 2006) [#25]
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/ )


mindstorms(Posted 2006) [#26]
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?)


mindstorms(Posted 2006) [#27]
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)