Author |
Topic: Card graphics not sticking (Read 158 times) |
|
Turtleman
New Member
member is offline
Gender: 
Posts: 29
|
 |
Re: Card graphics not sticking
« Reply #4 on: May 14th, 2016, 11:59am » |
|
Hi Richard and thanks for your speedy reply. I was an electronics hardware engineer and manager in my former life and writing code is a royal struggle. I'm truly in over my head and am sure that a "real" programmer would be able to greatly simplify and speed up what I already have. But as ugly and inefficient as my code is, the program is functioning better than my expectations.
The program has several functions and windows, and I'm now trying to get each one to run in LBB as a standalone item before recombining everything. Aside from the graphics displays, there are numerous data displays that are all currently being flushed. Eliminating that requirement is more than a little appealing.
Yeah, I'd love to see LB5, especially if it will run on more than a Windows OS, but I'm not holding my breath. Then again, maybe LLB would eventually work with LB5. I'm very new and inexperienced with LBB (and not overly swift with LB either), but I'll check out the Profiler you mentioned. The program makes heavy use of arrays, but I'm not sure exactly sure what Word$() functions you say may be very slow in LBB. I guess I'll find out shortly as I modify each section of code as maybe be required.
Thanks again for your help, it's greatly appreciated!
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #5 on: May 14th, 2016, 2:24pm » |
|
on May 14th, 2016, 11:59am, Turtleman wrote:| I'd love to see LB5, especially if it will run on more than a Windows OS, but I'm not holding my breath. |
|
As you know, LBB is based on BBC BASIC, a language which (unlike Liberty BASIC) has been multi-platform since shortly after its inception in 1981. At the last count BBC BASIC has been implemented on about seven different CPUs and ported to about 30 different platforms!
Indeed the 32-bit x86 variant of BBC BASIC on which LBB is based has only recently been ported to Linux (86) and Android (86), and is well on its way to being ported to Mac OS-X. However the difficulty with porting LBB is that, exactly like LB 4, it is highly dependent on Windows for the functionality of its GUI components, i.e. windows, controls, dialogs and sprites. Both dialects consist only of thin wrappers around the Windows API as far as these aspects are concerned.
So whilst the core LBB Run-Time-Engine could easily be ported to other platforms - in fact it already has been because the LBB RTE is the BBC BASIC RTE! - that still leaves large parts of the language which cannot be implemented - at least not in a substantially compatible way - because of their dependence on the Windows API.
Quote:| I'm not sure exactly sure what Word$() functions you say may be very slow in LBB. |
|
LBB's documentation of the WORD$ function is here. If you don't use it, which from your comments would seem to be the case, you don't need to worry!
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #6 on: May 14th, 2016, 4:08pm » |
|
Here's another question, probably more generic than LBB using the QCard lesson example given earlier: Upon initially opening the program, is there a way of hiding the window until it's positioned and ready to run? The brief flickering while the screen is being built and positioned is less than attractive.
Not so much in the small QCard example, but the several screens in my program first have to fetch the window's prior coordinates from disk, position the screen accordingly, and load several graphics. Is there a way to make it visible only after being loaded and ready to run? Thanks!
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #7 on: May 14th, 2016, 5:21pm » |
|
on May 14th, 2016, 4:08pm, Turtleman wrote:| Upon initially opening the program, is there a way of hiding the window until it's positioned and ready to run? |
|
Which window are you referring to? In the case of the mainwin that's exactly what is supposed to happen: if your program contains a NOMAINWIN statement the mainwin should never appear at all, however briefly, unless and until you execute a MAINWIN statement (if the program is compiled to an EXE that is; you may see the mainwin flash briefly when run from the IDE).
As far as GUI windows are concerned (i.e. those you create yourself using OPEN) then it's entirely under your own control. If you want to create the window initially hidden, and then only show it when you are ready, it's simply a case of clearing the WS_VISIBLE bit with STYLEBITS and then later using the SHOW command (example code below). This works in both LB and LBB.
But maybe I've misunderstood the question.
Richard.
Code: nomainwin
stylebits #w, 0, _WS_VISIBLE, 0, 0
open "Initially hidden" for window as #w
timer 2000, [show]
wait
[show]
timer 0
#w "show"
wait |
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #8 on: May 14th, 2016, 6:47pm » |
|
I can't believe I didn't know about hiding the GUI using stylebits and a show statement. (Didn't need to use a timer.) I've been doing crazy things in LB such as initially positioning off screen. This is a whole lot easier! Anyway, I got one of the windows behaving under LBB and will start on another. Or on second thought, maybe I'll postpone that and see if I can get the main program running faster. Oh, and changing the icon is a heck of a lot simpler. Thanks again and have a great weekend!
|
| « Last Edit: May 14th, 2016, 6:48pm by Turtleman » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #9 on: May 14th, 2016, 8:06pm » |
|
on May 14th, 2016, 6:47pm, Turtleman wrote:| Didn't need to use a timer. |
|
The delay was just to show that something out-of-the-ordinary was happening.
Quote:| Oh, and changing the icon is a heck of a lot simpler. |
|
Unlike LB, LBB supports multi-format icons (where the .ICO file contains several icons in different sizes and color depths) which can for example result in a high quality 256x256 image being used on a high-DPI screen.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #10 on: May 15th, 2016, 11:21am » |
|
Good morning - and time for my stupid questions of the day!
Going back to the simple QCard example (minus the playwave and pause statements to speed things up), is there a way of using "call BlitBack hBox, 700, 440" instead of flush statements in LB to restore the screen after its been minimized? Without flush statements, the graphics disappear, unlike in LBB.
The 700 and 440 parameters evidently correspond to the graphicbox's dimensions, but larger numbers seem to work as well. It's not a big deal, but is there a downside for using larger numbers so the same call BlitBack statement can be kept consistent throughout the program when used with different size graphicbox's?
I've been using the LB Workstation for development for its ease of use and line statements. Unfortunately, I can't seem to redirect the paths under Preferences to send the program to LBB instead of LB. Is there a trick for doing that? It would be great to at least have line numbers on LBB. I see there are numbers on the LBB pane, but it doesn't display the exact same code.
Whoops - false alarm! I just saw the 09/18/2013 post "Using Liberty BASIC Workshop with LBB" and must have goofed before. It's now working with Workshop.
Sorry if my other questions are confusing. Thanks!
|
| « Last Edit: May 15th, 2016, 3:09pm by Turtleman » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #11 on: May 15th, 2016, 3:25pm » |
|
on May 15th, 2016, 11:21am, Turtleman wrote:| Without flush statements, the graphics disappear, unlike in LBB. |
|
Why would you want to do it a "different way"? FLUSH is the method LB uses to cause graphics to 'stick'; a rather unsatisfactory method in my opinion, but there it is. So if you want to retain compatibility with LB keep the FLUSH statements, LBB won't mind.
Quote:| It's not a big deal, but is there a downside for using larger numbers so the same call BlitBack statement can be kept consistent throughout the program when used with different size graphicbox's? |
|
Only Microsoft could answer that question. There may be a cost in 'clipping' the rectangle to the size of the window, or there may not. You could try profiling it!
Quote:| Whoops - false alarm! I just saw the 09/18/2013 post "Using Liberty BASIC Workshop with LBB" |
|
There's also this Wiki article.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #12 on: May 15th, 2016, 3:37pm » |
|
Thanks Richard. May I safely assume that LBB totally ignores flush statements? I love that LBB doesn't need them, but is there any downside to keeping them in the code to retain compatibility with LB?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #13 on: May 15th, 2016, 5:06pm » |
|
on May 15th, 2016, 3:37pm, Turtleman wrote:| May I safely assume that LBB totally ignores flush statements? |
|
No. I explained previously that FLUSH still has a function in LBB when paired with REDRAW; it is not ignored. The LBB Help file describes what each statement does, including FLUSH.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #14 on: May 15th, 2016, 5:19pm » |
|
I probably shouldn't have said "totally ignores." However, it's my understanding that an abundance of flush statements consume memory in LB and was wondering if keeping them in the code when using LBB (only to maintain compatibility) also consumes resources. In other words, will it make any difference if the flush statements are left in or removed?
And I'm still unsure if there's a good way of restoring a graphics screen using LB after the window has been minimized if flush statements are removed. I'm obviously a confused code writer, but am slowly figuring it out. Thanks!
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #15 on: May 15th, 2016, 6:58pm » |
|
on May 15th, 2016, 5:19pm, Turtleman wrote:| it's my understanding that an abundance of flush statements consume memory in LB and was wondering if keeping them in the code when using LBB (only to maintain compatibility) also consumes resources. |
|
Cumulative resources, no. There's no requirement, as there is in LB, to use CLS or DELSEGMENT to avoid a constantly increasing use of memory.
Quote:| And I'm still unsure if there's a good way of restoring a graphics screen using LB after the window has been minimized if flush statements are removed. |
|
A question for an LB expert, which isn't me (and arguably questions about LB are off-topic here).
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #16 on: May 15th, 2016, 7:04pm » |
|
Got it! So for now, I might as well keep the flushes just to maintain compatibility until I get everything working in LBB. It's a lot easier dealing with single versions of code.
I'm now trying to figure out why the program is running much slower in LBB than LB even when the graphic windows aren't opened. Way too much code to post, but will get to the bottom of it eventually. Appreciate all your help.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #17 on: May 15th, 2016, 8:15pm » |
|
on May 15th, 2016, 7:04pm, Turtleman wrote:| I'm now trying to figure out why the program is running much slower in LBB than LB even when the graphic windows aren't opened. |
|
I've never suggested that LBB is suitable for all programs; it clearly isn't. Some programs rely on features that LBB doesn't have (e.g. arbitrary precision integer arithmetic or graphics segments), others rely on undocumented features of LB that I either don't know about or can't easily emulate, and some make heavy use of non-standard features that have to be emulated at run-time and are therefore very slow.
It sounds as though your program falls into that last category, so - especially considering what you have said about FLUSH - this is probably one of those rare occasions when it would be more sensible to stick with LB.
Richard.
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #18 on: May 15th, 2016, 8:24pm » |
|
I appreciate your input. Slower is just one of the problems. There are 8 selectable windows in addition to the main one, and when I try to open a particular one, I get an error "Couldn't create bitmap at line 0" Line zero? I don't have a clue what that means, especially since that particular window doesn't even use any bitmaps! Maybe that's a clue, but I don't have the foggiest what's going on. I hate to give up this early in the LB to LBB game, and I'll report back if I ever figure it out. All the other windows and overall program runs normally, albeit very slowly. Very confusing.
|
|
Logged
|
|
|
|
|
