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 Professional Discussion / Can windows dll's be used to write to screen?

Author
Message
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 7th May 2003 03:14
Trying to use gdi32.dll and it's floodfill routines to update db screen but having no joy. Would I be correct in saying that dll's can not be used to write to the screen as it's not a simple bitmap.

Maybe this is why I have not seen any other dll's that write to screen.
Gronda, Gronda
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 7th May 2003 17:34
Looks like nobody knows how to do this?

New to DBPro comin from AMOS on the Amiga!
Freddix
AGK Developer
23
Years of Service
User Offline
Joined: 19th Sep 2002
Location: France
Posted: 7th May 2003 18:00
in fact you must lock your backbuffer
( Sorry I'm at work and I don't remind the exact command )
but you must lock it and send pointer adress to your dll to use it to modify your screen.

It is possible but I don't know how gdi32.dll work then I can't give you more clue . . .

Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 7th May 2003 18:47
Lock the backbuffer and use the DX object to do writes to it. There is a command to get the backbuffer's pointer IIRC.

Current Project: TANK MELÉE [Artwork]

Do you want Windows menus in your DBP apps? - Get my plugin: http://snow.prohosting.com/~clone99/downloads/tpc_menus_101.zip
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 7th May 2003 22:39 Edited at: 7th May 2003 22:41
I was right about the FloodFill command not working...

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 7th May 2003 22:53 Edited at: 7th May 2003 22:53
Thanks for trying MrTAToad. Even though I have some knowledge of using dll's (with VB6 anyway), I can not get gdi things to work, even the simple 'Rectangle' function. Tried everything from getting window handle and passing that, to locking backbuffer and getting pointer (what use is pointer to a windows dll???)

Oh well, back to drawing board.

Gronda, Gronda
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 7th May 2003 22:57
The problem is the GDI stuff writes to a window, and not to the DirectX buffer...

You need to find a good routine for doing it in DirectX - can't say I've found any unfortunately...

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th May 2003 02:16
Ian to the rescue again!

In the source code box is my flood fill routine - all native DBPro!

As for doing this in a dll, there are two ways:
1) lock the backbuffer, pass the backbuffer pointer/width/height/depth/pitch to your dll, which will implement a flood fill, then unlock the backbuffer when your dll function returns.
2) do exactly the above, but within your dll.

And it just so happens, that within the next 3-4 days, I'll be releasing my C++ to DBPro interface library so that you can do just that I'm just writing some brief documentation at the moment.
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 8th May 2003 15:31 Edited at: 8th May 2003 15:40
Ah - this is the one with problems with complicated shapes ?

Can you use all areas in your C routine (especially sprites) ?

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th May 2003 21:12
Not that I'm aware of. Can you provide an example? You've got my email address.

You can have access to almost all DBPro commands - the exceptions are the array handling commands and the original DLL commands.

You also have access to 4 extra image commands, and a core system command. This list will expand as there are quite a lot of useful bits and pieces hidden away in there.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 8th May 2003 23:09
Yeah it crashes on complicated shapes, will do about 2 or 3 fills but then if you do a big area it crashes? Don't know why?

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th May 2003 23:13
But I tested it on a big area. I did!

It took ages to get code that didn't blow the stack every time. Oh well, back to the drawing board
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 8th May 2003 23:32
Could also be due to specs of machine (memory,processor,etc). I can't get it to blow up at all, even on the most complicated shape and even a full screen fill on a really complicated shape only takes about 2 seconds on my P4 2.64G. Can do multiple fills as well with no problems.

I did have a problem when trying to do a fill routine using the box or dot command and they tended to make program bomb out regularly. The line command appears to be stable to me.

Whats spec is your computer SpecTre?

Gronda, Gronda
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 8th May 2003 23:37
Cant say I've tried your routine Ian - haven't needed a floodfill system yet..

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins - oh my, yes!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 8th May 2003 23:38
Athlon 1Ghz
768 Mb MEM
80Gb Hard disk
G Force 2
DVD
CD-RW
Win XP
Broadband

Spec of PC is fine, plays all my 3D stuff and things like Warcraft III on full effects!!

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th May 2003 00:02
Well, I've been playing with more complex fills and can't get it to crash either. The maximum depth of recursion I get is 2924, nowhere near enough to blow the stack (the limit of a function with 2 args and 2 locals is around 15000). So ... now what?

I didn't use the BOX command to draw lines, because box doesn't work when you use LOCK PIXELS, and sacrificing that caused the POINT() function to slow down more than BOX sped it up.
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 9th May 2003 00:14
Well, I don't know! Tried using stacks and arrays instead of recursive calling but made it too slow. I think there is just too much for DB to do and what we (mainly you!) have done is probably the best you can do. If I get bored over weekend I may try some other ideas but I'm not wasting too much more time on it.

Gronda, Gronda
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th May 2003 00:42
Were you using the arrays as stacks? I've noticed that this can be a relatively slow operation. It keeps reallocating memory for parts of the array storage.

Try allocating your array with 10000 entries and keep track of where you are with an index.
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 9th May 2003 02:47
OK, here's next version of floodfill that does not do recursion and "should" not crash. Don't think it can be made any quicker, so either like it or lump it!



Gronda, Gronda
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th May 2003 15:36
There's a not-so-visible optimisation in my code that this one doesn't take advantage off - because it can't in it's current form.

In the 'while' loop at the end of the recursive function, it searches left, and then right to fill in lines above and below the current line. As soon as it finds a valid area to paint, it paints in the whole line immediately before continuing to check for further pixels on the same line further along. Mostly these will fail, as they've just been painted.

It may be possible for you to do something like include a line length as well as the coordinates on your fill stack.

Anyway, it'd be nice if someone who has has problems with my code could use your code to see if it solves the problem (Spectre )
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 9th May 2003 18:22 Edited at: 9th May 2003 18:22
Yes, but I have put in some other optimizations! If it just painted line marked with 'o's it only needs to add the three points marked with @'s to the stack, instead off ALL unpainted points above and below line.



Gronda, Gronda
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th May 2003 20:42
I'm embarrassed to say that I did miss that ... but it does make it easier for you to put the line-length optimisation in too, to save re-checking pixels that you've already checked.

I might try something like this in my own fill code.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th May 2003 02:41
Thanks for the bitmap Spectre. I did 100 fills over all parts of the bitmap with absolutely no problems though.

I'm starting to wonder whether there is actually a problem with the code, or if it's environmental, like video drivers for example.

Can you run the fill routine with the LOCK PIXELS and UNLOCK PIXELS commented out and see if it still has the same problem?
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 03:00
tried with both, what happens for you when colour in same area twice?

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th May 2003 03:05
It fills it.

Are you using a 16 bit or 32 bit display mode?

The code only fills correctly in 32 bit mode, although even if it is in 16 bit mode, it shouldn't crash, but may just fail to fill.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 16:48
I'm running my program in 16 bit mode, if you fill the area in that is the same colour it thinks for about a minute then crashes out!

Hmmmm, just tried to run it in 32 bit mode but does the same in that? Very strange!

New to DBPro comin from AMOS on the Amiga!
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 10th May 2003 20:19 Edited at: 10th May 2003 20:25
Very interesting.

I still need to modify my (far to slow) DBC filler routine.
It fills a whole lot quicker in DBP but still too slow to
implement in INTERSHIP.

I assume the lock pixels thingy will work here too?

grid.bmp

The more you see, the more you know.
The more you know, the more you see.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 20:40
x-d

Well it's good to see some else who needs a flood fill command!

Looks like there has been quite a bit of interest about this Flood Fill, do you think you would be able to ask for it in the Patch Rich?

Please!!!



New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th May 2003 21:07
What?!? You can't spoil our fun like that!

Heartbone: I put LOCK PIXELS at the top of fillgrid2, and UNLOCK PIXELS at the bottom, and it made quite a large difference.

Anywhere you are doing lots of POINT(), DOT and LINE commands together will speed up, but I did have problems when mixing in the 3D accellerated commands in the past - BOX, PASTE IMAGE etc. I've not retried this since Patch 2, so they might work OK now.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 22:34

This is very frustrating, no matter what I do if you fill (click) areas too quickly or if you fill over the same colour then it crashes.
Thought it was my computer but tried it on a friends P4 system to see what happened and it did the same?!?

I'm using this version of the code



By the way IanM & Sonic you are both in the end title picture (special thanks) that I have just done!

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 13:40
So, who wrote that then? It's similar to my code, but it ain't mine.

Still, I now get the same problems as you've had, and I've got a fix - I don't understand why it fixes it, but it does



There's a sync in there thats commented out. Have a look at the effect with it back in - you may want to keep it in considering the audience for your software.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 14:48

Sonic wrote that one.
See what you've done with the Sync command in there, you can see the colour being drawn to the screen so children can see whats happening!!!

The only thing is, when you colour with the same colour over the top it crashes again!

Really strange because looking at the code, if the colour brought back through the point command is the same as the ink being used then it ignores the fill. Is this correct?
So when I use it why does it crash?
Gonna send you my source code for the program, will you let me know what you think is wrong, it could be something I have done wrong on the program?

New to DBPro comin from AMOS on the Amiga!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 15:28
IanM



add the extra bit ........ and goodtogo <>newink
and change ............... floodfill(mx,my,colour(newink))
put mx,my instead of mousex() , mousey()

this seems to have sorted the crashing on same colour out!!!!!!!!!
so think I've got that sussed!!!
The only thing now is to try and speed the fill up, but I don't know if it will go any faster?
Good idea though m8 to put the sync into the fill so you can see that it is working!!



New to DBPro comin from AMOS on the Amiga!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 15:34
hmmm very odd works in exclusive mode but in window full screen mode it crashes still?

Oh well the program will be compiled in exlusive mode anyway!!!

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 17:05
Aha, we seem to have invented much the same code independently.

I don't think it will get much faster than this I'm afraid. See if you can take my code (in the first post I made) and put it into your program. It's optimised a little bit more than sonics code - less parameters passed recursively, less functions called in the fill loop etc.

As for your code, I might have done things a little differently , but I can't see anything obvious wrong.

Windows does some funny stuff with colours in standard windows with a 16bit display. I've not looked for a way to solve it, because I tend to use 32bit mode, but it shouldn't cause your program to crash - just paint in a funny way.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 17:47
hmmmmm I thought I got it cracked but it still doesn't work with some colours, I think I might have found a bug with the point command.

Heres what I have noticed :

if it is a primary colour eg red (255,0,0) the point command will bring back the correct number value for it and so won't re-fill that section.
if it is a variation of a colour eg pink (255,200,200) the point command doesn't bring back the correct number value and so crashes the computer.

Is this a bug with the point command or the routine?

New to DBPro comin from AMOS on the Amiga!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 18:06
yup think this is why it keeps crashing?

tried in 16 and 32bit but every time for example pink 255,200,200 the value comes back different every time:

pink rgb(255,200,200) value return = -14136 (in 16bit)
pink value from point command = -12849

function crashes because points don't match up?

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 18:21
The only time I can get it to fail is in a 16 bit display mode. Under 32 bits, it works every time.

SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 19:20
this code does the same as mine, so now I run my colouring book in 32 bit mode and it still does it!!!

Is it something to do with dword command?

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 19:44
Maybe, although I haven't had any problems that I'm aware of when I forget to do it

Officially, colours should be read into a dword - see tutorial 3 here http://www.darkbasicpro.com/tutorials.php.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 20:34
dim colour()

colour()=rgb(,,)
goodtogo=point(,)

the value in colour() doesn't match goodtogo

tried dword as well but still no dif for other colours!

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 21:59
How about if you try:

global colour as dword
global goodtogo as dword

colour=rgb(,,)
goodtogo=point(,)

That's assuming that they both need to be global!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 23:27


Try running this little test program to see what you get in 16 bit and 32 bit modes, 16bit is what effect I get in my colouring book and 32 bit is ok, but when I run my colouring book in 32 bit mode I still get incorrect results!!!

very odd

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th May 2003 23:57
In all 16 bit modes
-14136
-14136
-12849
-12849
-12849
4294953160

In all 32 bit modes
-14136
-14136
-14136
-14136
-14136
4294953160

Try this instead:



16 bit mode:
4294953160
4294953160
4294954447
4294954447
4294954447
4294953160

32 bit mode:
4294953160
4294953160
4294953160
4294953160
4294953160
4294953160

So, use dwords and 32 bit modes.
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 12th May 2003 00:26
Quite agree, ALL variables that hold point or ink colours MUST be defined first as dwords as normal integers just are not big enough.

16 bit mode just doesn't cut it for accurate colour values.

Try following test:



In 16bit mode, all the different methods of drawing produce different results!!!! The only two that match are CLS and BOX. How stupid is that.

Why do the three main drawing commands, BOX, LINE and DOT draw in different colours. 32bit mode seems to work ok though.

Gronda, Gronda
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 12th May 2003 02:04
hmmm try this




I get in 32 bit round 1:

4294953160
4294953160
4294953160
4294953160
4294953160
4294953160

round 2 after fill routine:

4294953160
4294953160
16763080
16763080
16763080
4294953160

what about u?

and in 16 bit round 1:

4294953160
4294953160
4294954447
4294954447
4294954447
4294953160

round 2:

same as round 1

very odd??????

New to DBPro comin from AMOS on the Amiga!
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th May 2003 02:17
32bit, both times for all numbers, I get 4294953160.
16bit, I get your first set of 16 bit numbers each time.

The only thing I can think of suggesting now is updating your drivers and ensuring you are running DX8.1 or 9.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 12th May 2003 02:23


Very puzzling this???????

What do you get sonic??

Will try my drivers Got direct X 8.1 on I think, where do I get direct x9 from?

New to DBPro comin from AMOS on the Amiga!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 12th May 2003 03:19
ok!

just put directX 9 and new drivers NVIDIA march 23 2003 on computer!

Computer runs a bit faster!!........but.............

same results!!

There must be a bug in DB Pro !!!!!!!!!!!!

RICH any ideas?!?!?!?!?!?!?


New to DBPro comin from AMOS on the Amiga!
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 12th May 2003 04:02
Done a new super-fast INSTANT fill routine for ya!!!!!

Works in any resolution or depth mode!!!!!

Look in code box below.

Most of code is self explanatory but as it is now 1 oclock in morning and I am falling asleep and I need to be at work by 8am, I can't be bothered to do any documentation.

Basically, the program pre-calculates the fill areas which is blindingly fast. Could speed up with a few optimisations but may not need it.

Should be pretty obvious which bits you need to copy to your program.

Gronda, Gronda

Login to post a reply

Server time is: 2026-07-11 12:02:34
Your offset time is: 2026-07-11 12:02:34