Author |
Topic: Card graphics not sticking (Read 159 times) |
|
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
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #19 on: May 16th, 2016, 08:39am » |
|
on May 15th, 2016, 8:24pm, Turtleman wrote:| I get an error "Couldn't create bitmap at line 0" Line zero? |
|
Line zero simply means that the error isn't occurring in your BASIC program but (probably) in the LBLIB emulation library. In an ideal world that code ought not to raise such errors, but I know there are circumstances when it can.
What version of Windows are you running? A "Couldn't create bitmap" error used to be more common in Windows XP because all DCBs (Device Compatible Bitmaps) are allocated from quite a small pool on that version, and it wasn't that difficult to use up all the available memory. But on Windows Vista and later much more memory is available for DCBs.
If you're running a machine that is infrequently rebooted (such as a laptop) that can also increase the likelihood of running out of bitmap memory, because crashed programs that don't correctly clean up after themselves can gobble it up. So try rebooting the PC and running the program again.
I assume the windows you are referring to don't create ridiculously big bitmaps (as they might if you specified large limits in a HORIZSCROLLBAR or VERTSCROLLBAR command). Remember that LBB is double-buffered, so makes much heavier use of bitmaps than LB.
Clearly it would be worth tracing the cause of this error, in the unlikely event that it's a bug in LBB. But if your program runs slowly that's another matter - where does the Profiler say the time is primarily being spent?
Richard.
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #20 on: May 16th, 2016, 12:58pm » |
|
Richard: I've (almost) concluded that the main reason I'm having difficulties running my LB program in LBB is, for lack of a better explanation, sloppy coding! When I started the project several years ago, I didn't have a clue how to program. And while I got the program to run, it was pure unadulterated spaghetti code. I did a major rewrite a couple years ago, broke things into more manageable subroutines, and improved speed and reliability significantly. But now that I'm troubleshooting to get it to play nicely with LBB, I'm seeing that the code is still heavily convoluted in many areas. Hopefully, I know a lot more about programming now than I did a couple years ago (and even a couple days ago), so once again I'm going to try rewriting the entire program using more standalone modules. Being able to test as I go in LB and LBB should reveal any incompatibilities and result in a cleaner program.
Eventually, I'd like it to run on Apple and Android devices, and looked into using a more compatible language. I even began playing with Python and just stumbled across BBC Basic, but I'm afraid the learning curve could exceed my life expectancy. So while LB may not be the ideal language, at least I'm more familiar with it than anything else. Any suggestions besides giving up would be welcome!
Thanks again for your help and I'll be sure to post the results of the "new and improved" LBB-compatible program.
|
| « Last Edit: May 16th, 2016, 1:00pm by Turtleman » |
Logged
|
|
|
|
|
