Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Dll Drawing?

Author
Message
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 10th Jun 2009 07:25
What do you think?

Would it be faster to draw with a dll by passing a pointer to a memblock bitmap and then making the bitmap back from the memblock after the dll changes the values?

Sounds like it, but i don't want to Do all that and have it be worth nothing lol.

New Site! Check it out \/
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 10th Jun 2009 12:22 Edited at: 10th Jun 2009 12:23
If you've got the "Extras" folder with the DBC install, have a look at the "LotsOfSprites" example. It puts 1000 images to screen each refresh, stopping off on the way to rotate those images, and runs at about 90fps on my computer (though mine seems to have that as a limit as to how fast it can transfer data from a memblock back to the screen).

Pasting 1000 images in DBC alone is crippling on the computer, Screen fps drops to something like 10 or 20 at best, and drawing sprites is even slower.

So, I'd say go for the dll option (and if you find a nice easy way, let me know for Dark Windows! )


Edit: Actually, I just had another thought - if you call "Lock Backbuffer", you can get the pointer to the current screen and modify bitmap 0 directly. I'm completely out of my depth on this, but it might be worth a shot.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 10th Jun 2009 21:50 Edited at: 11th Jun 2009 00:31
Wait you can get the pointer to that actual bitmap!? that would be even faster! hmmmmmmm

I will look into that. Really it's not hard to do, you pass the pointer to a memblock bitmap to the dll then the dll modifies the values just like you would in dbc, only faster, if you know any c++ it would look something like this:




Havn't tested that but i think it would work.... Hmmmmm

if you can get the direct pointer to bitmap 0 that would be GREAT!

EDIT:

Ok well i tested it out, i made a dll that is supposed to draw box to a bitmap that's passed to it. instead of using a DWORD pointer i used a array of BYTE pointers, i think thats how i was supposed to do it anyway...

well here's my DLL Code:



That should work with a memblock pointer or the Backbuffer pointer(i looked up the commands! didn't even know about those!)

but dbc is returning a "Severe Exception!" Error, here's the DBC Code:




If this actually works i will stop posting here, as it will become a c++ dll project, but at this point i still trying to figure out if it will work with dbc lol.


!!EDIT!! !!AGAIN!!

Ok i got it to draw, it's drawing funky, Here's a screeny(Attached).

that's when i put in the coordanets 0,0,5,5 and used the Get Back buffer ptr() command. well it looks promising considering it is atleast drawing lol

Any Ideas?

!!EDIT!! !!LAST TIME HOPEFULLY!!

Ok i got it to work but it's WAAAYYYY slower then db box command which is weird... the problem was that when i switched back to usign a DWORD pointer then did the Offset equation(Offset = (Y*Width+X)*4) then i was doing *4 dwords! not Bytes! whoops so i took that out and fixed it, oh the other problem with that pic was you cant use the bitmap pointer directly, unless it might be in different format then the memblock bitmap... idk dbc help doesn't say either way.

here's the C++ Code:



and a db example(pretty simple, just call the dll lol)



New Site! Check it out \/

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th Jun 2009 00:32
The advantage of a dll is the speed achieved from any looping and or math commands. The initial creating of pointers and and the use of memblocks is still subject to the speed of DarkBASIC. So, yes, drawing can be faster using a DLL but may not be worth it depending on what you want to do.

Quote: "If you've got the "Extras" folder with the DBC install, have a look at the "LotsOfSprites" example. It puts 1000 images to screen each refresh, stopping off on the way to rotate those images, and runs at about 90fps on my computer (though mine seems to have that as a limit as to how fast it can transfer data from a memblock back to the screen).

Pasting 1000 images in DBC alone is crippling on the computer, Screen fps drops to something like 10 or 20 at best, and drawing sprites is even slower."


The lots of sprites demo is a bit misleading and maybe not the greatest benchmark of image speed as a result of using a DLL. Lots of sprites copies a single bitmap to bitmap zero after redrawing the bitmap in the background so it's not really showing any sprites at all and it runs slower than I though it would probably because of the MAKE MEMBLOCK FROM BITMAP command.

I wrote up a demo in DBC without a DLL that "pastes 1000 sprites to the screen". It runs at about 73 FPS on my machine, but from what I can tell the original Extras lots of sprites runs at about 54 FPS on my machine.



And if you really want to take the illusion of multiple images on the screen to an extreme, check out this code from Kevin Picone. This has virtually and unlimited number of images on the display with no change in FPS. It's a cool trick and shows that depending on what you are doing, a little clever programming will supercede the need for a DLL:



As far as using LOCK BACK BUFFER, it is a bit slow. Actually slower than bitmap/memblock commands if I remember correctly. It is useful and it gives you a pointer to what's being drawn on bitmap 0. But it uses pitch, so you'd have to calculate the scan line length to find the positions and colors of individual pixels. And to use it in real time, the pointer can constantly change so you'd have to lock it to get the pointer each time you want to manipulate it (it being the back buffer). I'm not trying to discourage you, just giving you a heads up in case you thought there would be a blazing speed burst by manipulating the back buffer.

You should check out Ashingda's flood fill on the Code Snippets board. He uses full screen memblocks and does complete, multishaped flood fills in milliseconds. Pretty good code and leaves any drawing one would do with the 2d commands in the dust in terms of speed. Now that code in a DLL, because of the looping and the 16 bit calculations, would rival the speed of commercial apps I wouldn't doubt (though there are a few tweaks here and there that could imporve it).

Enjoy your day.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 11th Jun 2009 04:57
Hmmm Thanks for that info, that was really the question i had in my first post, Weather or not it was a good idea to try. do you have any idea why it's so slow? i'm getting 150 milliseconds on i think 100, 100x100 squares. which is really slow compared to dbc square... it was way faster then the dbc box command when it was leaving spaces between pixels(still same amount of pixels just leaving spaces). any ideas?

Hey do you think ashinga would want to help me understand it and then put that we could convert it to c++ and put it in a dll cuz thats a good idea!

If Ashinga Reads this then What do you think?

New Site! Check it out \/
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Jun 2009 01:43
Quote: "you have any idea why it's so slow?"

Anything involving bitmap 0 tends to be a little slow. My guess is because bitmap 0 is the display screen, it has to queried first of all to make sure it is finished being drawn on, then any updates are copied to a buffer, which is then copied to the back buffer. The back buffer is waiting to swap information with the front buffer (bitmap 0) when you lock it. Bitmap 0 is never updated directly, but a memory area is updated first then presented to the front buffer. That's what the back buffer is used for, drawing on and sending information to the front buffer. That allows any drawing/painting operations to complete while the next frame is being set up to draw.

So when you lock the back buffer, all current drawing tasks are finished to make sure each buffer is filled with the current information; then all drawing stops waiting for you to do whatever you are going to do while the backbuffer is locked. If you make any changes to the backbuffer, those are going to show up on the front buffer after you release the backbuffer. Think of locking the back buffer as losing a sync in the current iteration. Because you are going to engage the back buffer directly, it has to finish what it's doing before it can let you take over so that if you unlock it without changes, the display will roll along without problems.

I'm just guessing based on a few things I read about here and there.

Enjoy your day.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 12th Jul 2009 06:58
Oh ok i see thanks, I had never thought about it like that.

New Site! Check it out \/

Login to post a reply

Server time is: 2024-05-20 11:14:51
Your offset time is: 2024-05-20 11:14:51