PT Forum

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 12th Jun 2007 22:00

The real problem with DBP is it's performance, functions themselves are fairly quick for the most part; but DBP code is quite slow.

people have shown ways to improve this, but it'll never reach purebasic or even blitz3d speed; especially using pointers. That in particular is extremely slow.

try to use memblocks with the memblock function calls, think i did a performance test app a while ago (must be 3years now) that showed how slow pointers actually were. very confusing given dbp is compiled to machine code, but oh well.

found the best way around problems like this is to program a new plug-in via C++ to do the operations i want, then use that function with dbp code. this said i'm using DGDK more now, as it elimiates the need to do the back'n'forth.

hopefully Lee will take some time out after the X10 engine is complete to overhaul the compiler with what he's now learnt about low-level programming.

man id unknown Joined: 31st Jan 2007
Location:

Posted: 12th Jun 2007 23:56

Raven, I agree. My routine was written in FreeBASIC, (including inline Assembly). The routine can run at about 100 FPS without hardware rendering. The slowdown occurs when trying to copy the buffer to a bitmap or backbuffer. If I could find a faster way to transfer the buffer, the problem wouldbe solved.

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 13th Jun 2007 0:45

If you want, post up the code you're using (if it's sensitive cut it down to the actual operation or whatever). I can then take a crack at optimising it.

Got quite good at it after a few years of DBP workarounds hehe

man id unknown Joined: 31st Jan 2007
Location:

Posted: 13th Jun 2007 1:00

In all truth, this is the simplicity of the code that is causing the slowdown. Keep in mind, the procedure Outline() simply represents my procedure. I have thoroughly tested and confirmed that my procedure is not the source of the slow-down. You can replace this statement with any code you see fit. The source of the slow-down is the Copy Memory () statement.

+ Code Snippet

Sync On
Sync Rate 0

`Setup
 Lock BackBuffer
  Memory_Size = (Get BackBuffer Pitch() * Get BackBuffer Height())
  Memory_Ptr = Make Memory(Memory_Size)
 Unlock BackBuffer

`Main Loop
 Do
  Lock BackBuffer
   Copy Memory Memory_Ptr, Get BackBuffer Ptr(), Memory_Size
   Outline(Memory_Ptr, RGB(0, 0, 0))
   Copy Memory Get BackBuffer Ptr(), Memory_Ptr, Memory_Size
  Unlock BackBuffer

  Sync
 Loop

man id unknown Joined: 31st Jan 2007
Location:

Posted: 13th Jun 2007 1:02

I should have mentioned, the above code executes at only 8- FPS. If I remove the Copy Memory () statements, the programs speed increases to 90+ fps.

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 13th Jun 2007 2:02

was testing out SynergyIDE, but here's a possible performance rewrite:

+ Code Snippet

#CONSTANT BITSIZE = 8

SYNC ON
SYNC RATE VOID
 
LOCK BACKBUFFER
	Memory_Size = (GET BACKBUFFER WIDTH() * GET BACKBUFFER HEIGHT() * (GET BACKBUFFER DEPTH() / BITSIZE))
 	Memory_Ptr	= MAKE MEMORY(Memory_Size)
UNLOCK BACKBUFFER

REPEAT
	CLS	// ignore if background active
	LOCK BACKBUFFER		
		BackBuffer_Ptr = GET BACKBUFFER PTR()
		CopyMemory(Memory_Ptr, BackBuffer_Ptr, INT(Memory_Size / INT(GET BACKBUFFER DEPTH() / BITSIZE))
		Outline(Memory_Ptr, RGB(0, 0, 0))
		CopyMemory(BackBuffer_Ptr, Memory_Ptr, INT(Memory_Size / INT(GET BACKBUFFER DEPTH() / BITSIZE))
	UNLOCK BACKBUFFER
	SYNC
UNTIL ESCAPEKEY()
	DELETE MEMORY Memory_Ptr
END

FUNCTION CopyMemory(From_Ptr, To_Ptr, Size)
	FOR I = 0 TO Size
		To_Ptr = *From_Ptr
		INC From_Ptr, 4		// pointer system only works in dwords
	NEXT I
ENDFUNCTION

try to call certain fuctions as little as possible. I think that actually outperforms the memory copy function, only tested it a little.

man id unknown Joined: 31st Jan 2007
Location:

Posted: 13th Jun 2007 2:32

Sir, unfortunately, this method actually reduced the FPS to 3. I suppose I'm at a dead end.

<1 2 >

Sign In