Graphics commands over persistent bitmap?
Graphics commands over persistent bitmap?
Hi folks,
First posting. BASIC user since TRS-80 Model 1 and CP/M MBASIC, but nowadays primarily C/C#/C++ .
I love the idea and execution of FreeBASIC - having written (many) millions of lines of BASIC code in the past it's like "coming home" somehow. :-)
I do audio and RF DSP design work, and FreeBASIC looks like simple-but-fast way to plot inputs to and outputs from algorithms I'm working on. That leads me to my question:
Is there a way to create and draw to a persistent bitmap, then create and draw to a non-persistent bitmap that overlays it? The idea is to be able to place a reticule and markers "behind" the data to be plotted. Another way to express it would be overlaying a bitmap with a 32-bit bitmap that has an alpha channel - let's say "0" is the transparent color.
I know I could draw the reticule and then plot the data in the same bitmap, but since this will be happening at hopefully a flicker-free refresh rate, I'd rather not use the cycles required to re-draw or copy the persistent bitmap every time.
After expressing it, I'm thinking that it sounds unlikely, but I'm going to ask anyway. Thanks!
First posting. BASIC user since TRS-80 Model 1 and CP/M MBASIC, but nowadays primarily C/C#/C++ .
I love the idea and execution of FreeBASIC - having written (many) millions of lines of BASIC code in the past it's like "coming home" somehow. :-)
I do audio and RF DSP design work, and FreeBASIC looks like simple-but-fast way to plot inputs to and outputs from algorithms I'm working on. That leads me to my question:
Is there a way to create and draw to a persistent bitmap, then create and draw to a non-persistent bitmap that overlays it? The idea is to be able to place a reticule and markers "behind" the data to be plotted. Another way to express it would be overlaying a bitmap with a 32-bit bitmap that has an alpha channel - let's say "0" is the transparent color.
I know I could draw the reticule and then plot the data in the same bitmap, but since this will be happening at hopefully a flicker-free refresh rate, I'd rather not use the cycles required to re-draw or copy the persistent bitmap every time.
After expressing it, I'm thinking that it sounds unlikely, but I'm going to ask anyway. Thanks!
Re: Graphics commands over persistent bitmap?
Hi,
any which way you'll approach it, it can be done!
First read would be: How to solve flickering ...
Then, you can take it from there.
Note: don't be fooled, it'll take some time, to get used to FB's new syntax ...
any which way you'll approach it, it can be done!
First read would be: How to solve flickering ...
Then, you can take it from there.
Note: don't be fooled, it'll take some time, to get used to FB's new syntax ...
Re: Graphics commands over persistent bitmap?
Hi All
Firstly welcome to the forum.
Don't know if this may give you some ideas, but....
Many years ago I built a machine that weighed diamonds as they slid down a tube.
The background screen was black with a graticule dividing the X,Y axis.
The weight signal was plotted onto the screen as individual white pixels.
By selecting an area of the trace that was reasonably stable (read flat) I could get the weight within a few milligrams.
By remembering which pixels were changed, I could very quickly return these pixels back to black
and start a new trace. The only coordinates I had to remember was the Y, as the X was incremented in mSec.
Additionally I also allowed the colour to increment, which put one trace over the other if I wanted to see a trend, but then it
became harder to remember the pixels and I had to redraw the screen.
This was done in QuickBasic and Assembly, although the pixel routines were QuickBasic.
Hope this gives you some idea.
Regards
Firstly welcome to the forum.
Don't know if this may give you some ideas, but....
Many years ago I built a machine that weighed diamonds as they slid down a tube.
The background screen was black with a graticule dividing the X,Y axis.
The weight signal was plotted onto the screen as individual white pixels.
By selecting an area of the trace that was reasonably stable (read flat) I could get the weight within a few milligrams.
By remembering which pixels were changed, I could very quickly return these pixels back to black
and start a new trace. The only coordinates I had to remember was the Y, as the X was incremented in mSec.
Additionally I also allowed the colour to increment, which put one trace over the other if I wanted to see a trend, but then it
became harder to remember the pixels and I had to redraw the screen.
This was done in QuickBasic and Assembly, although the pixel routines were QuickBasic.
Hope this gives you some idea.
Regards
Re: Graphics commands over persistent bitmap?
Thanks for the replies.
I did some tinkering yesterday, and using Paint to clear the plot area between plots I was able to draw 1020 lines of up to 400 pixels height for a histogram. (1020x400 plot area) With 100ms Sleep between each plotting loop, the CPU usage actually stayed at 0% on the test machine. (i7 6700K @ 4 gHz) I was impressed. :-)
I found a ARM6 version of FreeBASIC on the net somewhere that so far seems to work with a Raspberry PI 3+, and the same program runs around 30% of the CPU as reported by "top" . I was impressed again - a RPI would make a very inexpensive display system for all kinds of projects.
Since FreeBASIC can load Win32 DLL's and Linux .so libs, it looks like I've found my new best friend. Now if I can find or build a socket library, (I haven't looked yet) I could build apps to connect to acquisition servers and stream/plot data over TCP. (I do that now with C# programs that call C libraries, but it's a pain to do realtime plotting in .NET . It can be done but, well it's a pain...)
Looks like I have some learning to do. That's ok with me.
I did some tinkering yesterday, and using Paint to clear the plot area between plots I was able to draw 1020 lines of up to 400 pixels height for a histogram. (1020x400 plot area) With 100ms Sleep between each plotting loop, the CPU usage actually stayed at 0% on the test machine. (i7 6700K @ 4 gHz) I was impressed. :-)
I found a ARM6 version of FreeBASIC on the net somewhere that so far seems to work with a Raspberry PI 3+, and the same program runs around 30% of the CPU as reported by "top" . I was impressed again - a RPI would make a very inexpensive display system for all kinds of projects.
Since FreeBASIC can load Win32 DLL's and Linux .so libs, it looks like I've found my new best friend. Now if I can find or build a socket library, (I haven't looked yet) I could build apps to connect to acquisition servers and stream/plot data over TCP. (I do that now with C# programs that call C libraries, but it's a pain to do realtime plotting in .NET . It can be done but, well it's a pain...)
Looks like I have some learning to do. That's ok with me.
-
- Posts: 862
- Joined: May 05, 2015 5:35
- Location: Germany
Re: Graphics commands over persistent bitmap?
Please notice that the alpha channel doesn't work in FB.
Re: Graphics commands over persistent bitmap?
You must be joking, it works very well however, you'll have to enable itgrindstone wrote:Please notice that the alpha channel doesn't work in FB.
with the: &h40 / 64, in ScreenRes() arguments! More info in fbgfx.bi ...
GFX_ALPHA_PRIMITIVES (constant)
Code: Select all
ScreenRes(scr_w, scr_h, 32,, 64) ' 5th argument = GFX_ALPHA_PRIMITIVES
Re: Graphics commands over persistent bitmap?
Hi, I did not read all previous replies, but the graphics routines can work on the screen as well as on a image buffer. This image buffer can be put to screen (or another image buffer) in various ways, see e.g.: https://www.freebasic.net/wiki/wikka.ph ... utgraphics
Edit: I now see that I did not read all of the question as well.
Edit: I now see that I did not read all of the question as well.
-
- Posts: 862
- Joined: May 05, 2015 5:35
- Location: Germany
Re: Graphics commands over persistent bitmap?
I tried it some years ago, and it didn't work. Now I tried again, and it works fine. Maybe there was a bugfix in the meantime, or (more likely) I missed something back then.MrSwiss wrote:You must be joking, it works very well however, you'll have to enable it
with the: &h40 / 64, in ScreenRes() arguments! More info in fbgfx.bi ...
GFX_ALPHA_PRIMITIVES (constant)
Anyway, thank you for that hint.
Re: Graphics commands over persistent bitmap?
Matter of fact is: even in case of a later fix, one wouldn't find the difference, because:grindstone wrote:Maybe there was a bugfix in the meantime, or (more likely) I missed something back then.
fixes always apply to the version "next" of the compiler (never to the current version!).
It is IMO very bad policy, to post <fake news> (better ask: "is it working?", in case of
uncertainty) especially here, where OP is explicitly asking, whether the feature can
be used!
-
- Posts: 862
- Joined: May 05, 2015 5:35
- Location: Germany
Re: Graphics commands over persistent bitmap?
@MrSwiss: Take care that your halo won't begin to pinch some day...