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 / Colouring book so far.......................

Author
Message
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 9th May 2003 23:27
Well after so much trouble so far I thought you might want to see a screen shot of it, this was captured with Paint Shop Pro while actually running the program.
What do you think of the interface, gfx?
The colours and buttons are all animated when pressed and everything actually works now apart from print, flood fill still a bit slow yet.
Will need to draw some more pics as well now.

actual screen runs in 800x600

l8rz

New to DBPro comin from AMOS on the Amiga!
andrew11
23
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 9th May 2003 23:38
Wow... I didn't expect it to be like this. Love the GUI interface.

"All programmers are playwrites and all computers are lousy actors" -Anon
Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 9th May 2003 23:40
hey! thats realy cool, being an artistic idiot I just envy people who can make something that looks decent looks realy profesional, I never publish/show any of my programs because I suspect nobody would take me seriously if they saw what I call graphics :-s (and they would probably think I was 6½ )

Mentor.

rapscaLLion
23
Years of Service
User Offline
Joined: 29th Aug 2002
Location: Canada
Posted: 9th May 2003 23:48
lol that's cool! Did you finally figure out flood fill? I was looking for stuff on that, couldn't figure it out my self. Only thing I could find was a "none recursive" FF routine :S Whatever that means. I suppose this is useless but maybe someone can figure it out, looks to simple to work well... I've attached it on
along with it's intro, but it ain't my code

anyway, LOVE the GUI!!!

Alex Wanuch
aka rapscaLLion
Kousen Dev Progress >> Currently Working On Editors
rapscaLLion
23
Years of Service
User Offline
Joined: 29th Aug 2002
Location: Canada
Posted: 9th May 2003 23:52
Ok, I know this isn't the place and this has probably already been discussed but would this work?

(Psuedo Code!)

Let's assume the base color is white and the new color blue.

1. Start at the position clicked by user.
2. Fill all pixels surrounding it that are white.
3. From there position our virtual cursor at any one of the newly filled pixels and repeat step 2.
4. Just keep going until no more pixels can be filled, then return to the next pixel filled at the base point.

Do you understand? I suppose it would be very memory intensive, to keep track of all the positions.

Anyway, sorry for stealing your post!

Alex Wanuch
aka rapscaLLion
Kousen Dev Progress >> Currently Working On Editors
Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 10th May 2003 00:27
yeah! that works, but when you fill large areas you run the risk of eating huge amounts of memory, if you do a search for recursive fill routines you should find that a lot of the discussion is about avoiding stack overflows (most of the discussion is about c++/c#).
you can do a fill that does not use so much memory by just scanning over the image and wherever you find a (say) blue pixel and a place at the side where the colour is background then you fill the place and repeat scanning the image until a pass over the image produces no change, that means the paint process has ended.
btw... I tried a quick snippet to try that out but it takes 7 ½ minutes to paint a medium res screen with a circle 100 diameter in it, the pixel commands in pro are sooo slow I was gobsmacked, and why point `n` dot?, whats wrong with classic plot statement?.

Mentor.

SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 02:15
Thanks u guys, glad you like it so far!

Look out for it on my web site soon.

New to DBPro comin from AMOS on the Amiga!
Richard Davey
Retired Moderator
24
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 10th May 2003 03:09
Mentor - 7.5 mins to fill a screen with the dot command in DBPro? You using a 386 or something?! It's way faster than that. I think you need to check your code. Also bear in mind that pixel locking is a lot faster as well.

"Gentlemen, we are about to short-circuit the Universe!"
spooky
23
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 10th May 2003 03:26
7.5 minutes!!!

look in the 'official' floodfill thread:

http://www.darkbasicpro.com/apollo/view.php?t=9985&b=1

IanM and myself are experimenting with different floodfill routines. Smallish areas are filled almost instantly and full screen really complicated areas take a couple of seconds. This assumes you have a fairly good pc though.

Gronda, Gronda
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th May 2003 03:30
Thanks for the code rap. First impressions are that it is basically a non-recursive version of the span filling routine I already have.

I'll have a better look in the morning, coz I'm off to bed now... where's a 'yawn' smiley when you need one?
Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 10th May 2003 14:00 Edited at: 10th May 2003 14:09
LOL, read the description of how it works again, it scans the WHOLE screen REPEATEDLY until it is unable to add a coloured pixel to the image, that means it may the scan the screen several hundred times, I said/implied (with the word "just") it was a dumb method that didn`t use recursion, just brute force to solve the problem.
even so the pixel commands are SLOW, when you consider I used the same code years ago on a Spectrum and got reasonable results (faster than that for sure) when I was still a relativley basic newbie, and yeah!, I know locking the screen is way faster but I didn`t consider the effort worth it, was just curious how long it would take, I did expect it to be faster than on a Spectrum, which would have made it reasonably fast and probably of some use for the paint program, you could even optimise by limiting the area searched to just around the dot and increaseing it gradualy, but I wasn`t interested, it`s too slow (you can see the fill being built line by line).
you can make a faster version by useing two stacks and loading them alternatly with the positions of the pixels you just filled, but I found the list commands still don`t work right in pro so I dropped the idea, (I HATE workarounds), that would reduce the load on the computer to just remembering the last set of dots it filled, and should have saved on the amount of memory used, oh well!, maybe by patch 6!, cheers.

Mentor.

Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 10th May 2003 22:57
rich without locking the pixels it takes quite a while to fill the screen with the dot command...

800x600 on my Althon Mobile 600Mhz & GeForce2 Go! takes 34minutes... if you lock the pixels it takes a few seconds, why?
answer is quite simple, when you've unlocked the pixel buffer you're grabbing the data from the rendered screen per loop, and also pasing it per loop.

But when you lock them you're dealing with the memory directly, which is just a case of passing a function or two here and there so you're not waiting for the screen to sync to continue with the next pixel.

i thought being on the team you'd of known this?

Within the Epic battle of the fates the Shadow and the Angel will meet. With it will harbinger the very fight of good vs evil!
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 10th May 2003 23:04 Edited at: 10th May 2003 23:05
try that and tell me the results you get as i get
test1 -> 3216.70secs
test2 -> 10.31secs



just to let you know last time i tried this i was using patch1 and Dx8.2 so might've been why it was alot slower. but this system is quite a bit faster than my laptop.

Within the Epic battle of the fates the Shadow and the Angel will meet. With it will harbinger the very fight of good vs evil!
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 10th May 2003 23:10
yup I get

3481 and then 5.9

I think the main thing is here we need a native command?

When you try the flood fill routines they are very unstable and as you see from that a bit slow.

5.9 seconds sounds quick, but try telling that to my 3 and 6 year olds!!!!!!!!!!
They can't wait 2 secs never mind 5.9, and the crashing when clicking too quick and colouring over the same colour they throw a wobbler!!!

Heres the code again see what happens when you use it?



New to DBPro comin from AMOS on the Amiga!
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 10th May 2003 23:17
well for the multiple time crashing, then i'd just setup a boolean switch which until the operation has finished you don't accept mouse click commands.

as for the speed, the only option i can really suggest would be to make the screen in a memblock and just paste that every loop instead of editing the onscreen pixels.

Within the Epic battle of the fates the Shadow and the Angel will meet. With it will harbinger the very fight of good vs evil!
CloseToPerfect
23
Years of Service
User Offline
Joined: 20th Dec 2002
Location: United States
Posted: 11th May 2003 01:27
I made a color book once and instead of using that godawful slow point command I made an array for the size of the draw surface. and did all the draw to the array. That way the way mention above for flood fill(check the arraypixel and change each arround it) worked lighting fast. I would really suggest trying something like this because the point command is the slowdown on any floodfill using it. If there was a way to read video memory directly like a peek command and then poke a new value to it that would be fast to, but I don't know how to do that in DBP.

CTP
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 11th May 2003 02:00
hmmmm you got any example source?

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:58
Various people are guessing why point and dot are slow. Here are the real reasons (there are a lot .

The backbuffer is stored on the video card, not system memory, so every time you access the backbuffer to read, you are reading through the AGP bus. Even at 8xAGP, that bus is only running at 266mhz.

Now figure in the card itself. Most modern sub $1000 cards are optimised to get the graphics displayed as fast as possible, but within a price range. As a part of the price-cutting exercise, the manufacturers ignore performance on other parts of the card, or even introduce bottlenecks to make rendering faster. Reading from video memory is one of the first bits to be nobbled.

Now, we'll look at directx. Because video memory is not a part of the system memory, directx does some trickery behind the scenes to 'map' it into memory so you can access it. This is called 'locking the surface'. To allow rendering to take place again, the surface has to be unlocked. Now locking and unlocking a surface is not a fast process, but needs to be done when you read or write directly to video memory.

The DBPro part of this is the least of it. DOT,POINT and LINE all access video memory directly using the processor. If the memory isn't 'locked', then it has to be locked before the memory can be access. And after it locks it, it then has to unlock it so that rendering can take place.

When you use LOCK PIXELS and UNLOCK PIXELS you are taking the responsibility to do this correctly, instead of DBPro doing it for you. But you will get performance gains from not having the memory continually locked and unlocked.
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 12th May 2003 23:08
Well everyone the game is nearly finished thanks to the help of IanM and Sonic with the Flood Fill routine (very clever!) look out for it soon on my web site!!!!!

Will post when it is on there!



New to DBPro comin from AMOS on the Amiga!
pugmartin
23
Years of Service
User Offline
Joined: 3rd Jan 2003
Location: United Kingdom
Posted: 13th May 2003 00:37
Enough with the technical jargon already everyone!!!

Get back to the main point...

This looks great man. Really well done. Bet the kids love it!

Kangaroo2
23
Years of Service
User Offline
Joined: 26th Sep 2002
Location: United Kingdom
Posted: 13th May 2003 02:21
I really like the interface And I'm glad to hear that the way I make a paint fill is the way opthers do too, I was kinda afraid to post incase I was making it overly complicated (although I've emailed it to a few ppl)

Coming Soon! Kangaroo2 Studio... wait and quiver with anticipation! lol
[email protected] - http://www.kangaroo2.com - If the apocalypse comes, email me
SpecTre1
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 13th May 2003 02:42
Thanks for that, the kids love the game, look out for it soon!!!

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

If any1 is interested if you go to my site, click below, you can now download the Pre-release version of Paint Pot (colouring book), the program works fully apart from only having 3 pics to colour and the print button doesn't work yet. Music is nearly complete and at the moment the rough version of the music is on there!

It downloads as a full setup installer program so you don't have to worry about putting it anywhere once setup has complete, just run the icon! By the way it does have an un-instal option for after that is saved in the main directory!

Any1 that downloads this let me know what you think and if you have kids let me know if they enjoyed it as much as mine!

Happy downloading!

New to DBPro comin from AMOS on the Amiga!

Login to post a reply

Server time is: 2026-07-11 11:04:56
Your offset time is: 2026-07-11 11:04:56