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 / Need help with visualisation data pixel by pixel

Author
Message
bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 7th Apr 2011 02:31
Hello, EveryOne!
First of all. I'm from Russia. Thats why forgive me my english if i miss something.
I have a Code that i need to visualise. Code generates the data pixel by pixel and it need to be visualise some how.
By the way, this is my code:

I try to solve this problem by wrighing data to AVI with DBProAVI.dll wich I find here: http://forum.thegamecreators.com/?m=forum_view&t=75027&b=5
Very-Very Useful! It's a Great Start, but it requires a screen to be rendering, thats slow. And I find this dll: http://forum.thegamecreators.com/?m=forum_view&t=179096&b=5
Advanced2D.dll it provides command a2Dot that draw pixel a little faster then dot, but it's still slow...
I already contact with CJB by mail, and if it possible to make DBProAVI.dll create avi pixel by pixel it will be best solution i think. But if it is not possible I need another solution, thats why I open this topic. Help me if you know some way to visualize this data whithout delays with good fps.

Some words about my code...

It makes the superposition picture of 7 waves source's. Calculation is based on formula see FIG. It shows the Amplitude on distance X from the sorce, so it can be calculated in all points of the screen from one source, then add from another source, and so on... Array SourceParameters# contains the parameters of all source's that need in formula. The interpretation of amplitude after final rendering in avi - see FIG. Why I need this? All this need to simulate UFO (see FIG.) and try to see what happen's then all lightsource's make superposition of lightwaves.

If it wil not show something special, in any case it can be useful for students to show superposition of waves.
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 7th Apr 2011 17:04
a2Dot is slow for some reason, all other a2* commands are fast.

You can use DOT which is usually slow, but you should:



This will be much faster. Try it and see if it is fast enough. If not, then you will need to look at direct memory access.

bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 7th Apr 2011 17:10
Then you test my code make variable DrawFront=0 it is in 120 line of the code. In this case the front of waves will not be shown like waves is already propagate on entire screen. Otherwise you need to make variable Allframe=1000... (it's in line 117) very large so that during all this 1000... frames past the front cover entire screen.
bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 7th Apr 2011 18:28
BatVink, Hi, Command LOCK SCREEN is not work in my DBPRO i have the 6.9 version, maybe it is not supported. However i found Command LOCK FIXELS, I do not understand how to use it yet, it says that there is a command A = GET PIXELS POINTER() wich wright to A a pointer on first pixel of the screen. I still do not understand how can i use this pointer and put a color in pixel by this pointer, and there are many pixels so what is the shift of the pointer value betwen the neighbouring pixels...

About direct memory access! Unfortunately windows became a high bureaucratic system, and no longer provide MCI (Media Control Interface) in which you had a direct acces to the memory of you Graphical Card. Now if you want to make such acces, you need to know additional software and advansed programming. That's bad, I am not a specialist in this region...
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 7th Apr 2011 19:22
He meant LOCK PIXELS and UNLOCK PIXELS but you should update anyway because there are many changes that have happened since then (optimization of many commands).

To update: http://www.thegamecreators.com/?m=view_product&id=2000&page=upgrade7-6

If you want to see what your 6.9 Darkbasic Pro could be before installing the update you can look at the changes of each version here: http://forum.thegamecreators.com/?m=forum_view&t=29734&b=15

bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 7th Apr 2011 21:09
Grog Grueslayer, Ok thank's! I try to manage LOCK PIXELS and update DBPRO...
bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 7th Apr 2011 21:26
Ok! The rendering speed of
LOCK PIXELS

DOT

UNLOCK SCREEN
SYNC
Is not fast enough...

Need to manage GET PIXELS POINTER() if it is close enough by memory access time to the MCI (Media Control Interface) the problem will be resolve...
bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 8th Apr 2011 02:12
Allright suppose we have the 1024*768 screen mode, so we have 786432 total number of pixels.

At first I think that pointer have a shift = 1...
For example if the First Pixel Pointer = A then the second pixel pointer = A+1, the third A+2 ... and the last A+786432.
And also i fink that the color set by the value that we put in the memory cell wich the pointer determine. For example if the first pixel cell adress is 16908288 then we put this value to the variable FirstPixelPointer by this code FirstPixelPointer = GET PIXELS POINTER()
After that if we want to change color of that pixel we put value in it's memory cell by using a pointer *FirstPixelPointer = value
So we can change the adress of memory cell
FirstPixelPointer=FirstPixelPointer+1
And after that write to this adress any value of color
*FirstPixelPointer = value

So that was my thoughts and to check it i wright a code:

The results surprise me! Although I wright the same value of color = 255 in all the memory cell's, the colors in the screen was different. And there is a strange shift of the pointer betwen neighbouring pixels.
Tell me there am I wrong?
How to do it right way?...
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Apr 2011 15:20
On a 32 bit display, pixels are 4 bytes in size, not a single byte as you are using.

You also need to worry about address differences between each row of the display (GET PIXELS PITCH), although this probably won't be a problem with a 1024 pixel wide display.

bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 9th Apr 2011 23:43 Edited at: 10th Apr 2011 01:26
IanM, Thank's it's helped. Now I can fill a vertical line of pixels with this code:

So the pitch is a vertical address differences between pixels...
bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 10th Apr 2011 00:23
IanM, Ok! I think I understand it. Is this code right? Оr something wrong?

And how to use RGB color set system in pointers?
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Apr 2011 01:37
Here's your code reorganised to (hopefully) clarify what is going on.



For 32 bit colour, you simply need to use the RGB command directly.
For 16 bit colour, you need to use a 16 bit POKE WORD command, along with a 16 bit RGB function.

bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 11th Apr 2011 00:11
Ok! I stoped on this version of code to fill the 1024*768 screen with pointers:


I use this approach to fill the screen in my task and here is the final code (Do not forget the DBProAVI.dll which is here:http://forum.thegamecreators.com/?m=forum_view&t=75027&b=5

And finally it's still slow

Any suggestions of other approaches?
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 11th Apr 2011 01:32 Edited at: 11th Apr 2011 01:33
I think what you need to do is to actually measure where your code is slow, rather than assume that it's all the screen drawing.

A very quick addition to your code shows that between 70% and 90% of the time spent in your program is spent within the loop 'for x=1 to AviW', which has nothing to do with drawing. A quick calculation shows that your main set of calculations run over 5.5 million times per frame, and isn't written in the most efficient way.

Another 15% to 25% of the time is spent in the AVI encoding (which got worse as the program continued to run). We can't do anything about that, but that does tell me that this code is not going to be 'real time' no matter how much effort you put into it.

bugfly
15
Years of Service
User Offline
Joined: 6th Apr 2011
Location:
Posted: 11th Apr 2011 02:49
IanM, Yes, a lot of time takes to make superposition of Amplitude from different sources pixel by pixel. Need to add all Amplitudes from 7 sources in each pixel... Thats main trouble... I can even expel sin from calculations and optimize code but superposition stays...

Login to post a reply

Server time is: 2026-07-17 17:23:52
Your offset time is: 2026-07-17 17:23:52