Author |
Topic: Card graphics not sticking (Read 166 times) |
|
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
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #21 on: May 16th, 2016, 4:59pm » |
|
on May 16th, 2016, 12:58pm, Turtleman wrote:| Any suggestions besides giving up would be welcome! |
|
It all depends on how much of your program is 'GUI' stuff (graphics/controls/sprites) and how much is 'computational' stuff (arithmetic, string manipulation, file handling, sound and so on).
As I explained before, LB/LBB rely heavily on the Windows API for GUI functionality. If your program makes extensive use of GUI elements then that's the principal concern as regards porting to other platforms - irrespective of what programming language is used.
Apart from Windows itself, only Wine provides a high degree of compatibility with the Win32 API. That at least gives you a route to porting your program to Linux (86) and to Mac OS-X, because both those platforms are well supported by Wine.
Otherwise it's going to mean replacing all the GUI aspects of your program with something more generic. Only you know how practical that would be.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #22 on: May 21st, 2016, 10:09am » |
|
It's feedback time! I cut the program's 37K lines of code down to 2.4K in an attempt to get one common section of code running in LBB at a time. Interestingly, one of the displays was "flickering" several times in LBB when opening a new window, but wasn't flickering when running in LB. It took some time; but as it turns out, I was doing several redundant reads from the hard drive that went unnoticed in LB, but was very evident in LBB. This particular routine is only active when opening a certain segment of code and won't slow down normal operation, but there are undoubtedly other inefficiencies in the rest of the program that I'll be looking into.
I really like the fact that making an executable is so much easier in LBB, along with eliminating a zillion flush statements, so I have a high incentive to continue the investigation. More as I go. 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #23 on: May 21st, 2016, 10:36am » |
|
on May 21st, 2016, 10:09am, Turtleman wrote:| Interestingly, one of the displays was "flickering" several times in LBB when opening a new window, but wasn't flickering when running in LB. |
|
In my experience all sorts of things can influence 'flickering', not just the language. The speed and type of CPU (e.g. whether it is multi-core), the graphics card, the kind of display etc. So even if something is flicker-free on your system you should not assume it will be on somebody else's.
Basically whilst you may get away with repetitively closing-and-opening a window, or using CLS, or anything else which momentarily changes the display, it's far better to avoid doing it. There are usually alternatives which result in minimal display disturbance and they should be flicker-free on all platforms.
LBB's double buffering also gives you more control of exactly when the display is updated, by calling the "InvalidateRect", "UpdateWindow" or "RedrawWindow" APIs, so even in particularly challenging circumstances there is usually a solution.
Running a program in LBB will often reveal weaknesses in your code that you never realised were there, because you 'got away with it' in LB. In such a case the fault is nevertheless with your code, not with LBB.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #24 on: May 21st, 2016, 10:52am » |
|
You said it better than I did, namely that LBB revealed weaknesses in my code that went unnoticed in LB! The flickering was from repeated and unnecessary reads from the HD and writes to the display. That's now been fixed, but probably represents a spoonful of repairs in an ocean of goofs!
There are many CLS and FLUSH statements in the existing program that I hope will be unnecessary in LBB. Sorry for asking again, but does it "slow down" or create other problems to keep those instructions for LB compatibility when running in LBB or should they be deleted? And if the completed program runs better in LBB, is there any reason to maintain LB compatibility?
I'm currently adding additional code and testing in LB and LBB as I go.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #25 on: May 21st, 2016, 11:46am » |
|
on May 21st, 2016, 10:52am, Turtleman wrote:| Sorry for asking again, but does it "slow down" or create other problems to keep those instructions for LB compatibility when running in LBB or should they be deleted? |
|
CLS may well be essential if you are using it to clear the graphicbox/window, which is its primary purpose. Only if you are using CLS purely as a quick-and-dirty way of avoiding cumulative memory usage (and there are usually better ways, such as DELSEGMENT) can you safely delete it. Using CLS for that purpose rather than what it is intended for is a recipe for flickering!
Quote:| And if the completed program runs better in LBB, is there any reason to maintain LB compatibility? |
|
Discussed previously; I have nothing to add on the subject.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #26 on: May 21st, 2016, 12:31pm » |
|
Sorry for the repeating the question; besides, I'm finding the answers as I go and LBB is pointing out coding blunders that probably would have remained unnoticed. Adding back in "cleaned up" portions of code is going very well, and I can't wait to see the end result. Will report back later.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Card graphics not sticking
« Reply #27 on: May 22nd, 2016, 9:07pm » |
|
Quote:| is there any reason to maintain LB compatibility? |
|
Quote:| Running a program in LBB will often reveal weaknesses in your code that you never realised were there, because you 'got away with it' in LB. In such a case the fault is nevertheless with your code, not with LBB. |
|
I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB?
It just should be somewhere - or we assume LBB is perfect (in a god-like sense).
If there are, then LB compatibility supposed to allow checking in two independent realizations, which could pinpoint sloppy coding and so make program better.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #28 on: May 22nd, 2016, 10:18pm » |
|
on May 22nd, 2016, 9:07pm, tsh73 wrote:| If there are, then LB compatibility supposed to allow checking in two independent realizations, which could pinpoint sloppy coding and so make program better. |
|
"LB compatibility" implies not using any of LBB's many language extensions, which would be a ridiculous price to pay simply to allow such checking. You would be throwing away one of the principal reasons for using LBB in the first place!
For example you cannot possibly suggest that avoiding TRY...CATCH...END TRY and instead using ON ERROR GOTO, to maintain compatibility, makes a program "better"! Or not being able to use the extensions to USING$(), or DATE$(), or word-wrap in the TEXTEDITOR, or array arithmetic, or......
And what about LB's bugs? Being forced to use a branch label as the TIMER handler, rather than a SUB (which crashes LB), makes it almost impossible to write well-structured programs. If you want more examples of code you would have to avoid, just look at the LB Bug Tracker Wiki.
So, no, allowing "checking in two independent realizations" isn't a valid reason to maintain compatibility with LB. If you want to check programs for "sloppy coding" write a tool to do it; it would be a useful thing to have.
Richard.
|
|
Logged
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: Card graphics not sticking
« Reply #29 on: May 23rd, 2016, 09:49am » |
|
tsh73,
Quote:| I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB? |
|
If you "really wonder" this, then perhaps put up a bunch of examples?
Quote:| ... we assume LBB is perfect (in a god-like sense). |
|
What the hell does that mean in a programmer-like sense? What program is "perfect?" Certainly not LB!
Perhaps you are making some kind of oblique personal comment? If so, I don't think that part of your post is appropriate in this context.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #30 on: May 23rd, 2016, 10:52am » |
|
I'm a little reluctant to jump into this "friendly discussion," but as a newcomer to LBB, I've had nothing but trouble trying to get what appeared to be properly operating LB code to run in LBB. I was hoping to gain faster execution (and maybe reduce or eliminate infrequent crashes), but was disappointed to see that the program ran several times slower in LBB!
I'm currently dissecting and troubleshooting one section of code at a time; and so far, the problems stem entirely from sloppy programming in LB! After some changes, the code runs just as well in both, though any potential speed benefits won't be assessed until more code is "fixed" and the entire program reassembled. The point I'm making is that LBB has definitely identified "errors" in my LB coding that would have remained unnoticed. For that reason alone, I'm very glad to have "discovered" LBB and am still hoping that other benefits will be forthcoming.
On a side note: if I were talented enough to write a program to check for and identify sloppy coding, I probably wouldn't be making so many mistakes to begin with! 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #31 on: May 23rd, 2016, 12:00pm » |
|
on May 23rd, 2016, 10:52am, Turtleman wrote:| I was hoping to gain faster execution (and maybe reduce or eliminate infrequent crashes), but was disappointed to see that the program ran several times slower in LBB! |
|
You keep saying that LBB is much slower than LB, but you never tell us where the Profiler says the time is being spent, despite me having asked at least twice. Please let us know the answer, perhaps by posting an extract from the Profiler report file.
I can artificially create a program which runs "several times slower" in LBB, but it's not typical of real-world code. Here are some extreme comparisons:
Code: start = time$("ms")
for i = 1 to 1000000
next
finish = time$("ms")
print "Execution time ";finish-start;" milliseconds"
In LB 4.5.0 about 7000 ms and in LBB 3.04 about 90 ms, that's about 75 times faster in LBB. But...
Code: start = time$("ms")
for i = 1 to 100000
a$ = word$(" The quick brown fox jumps over the lazy dog ", 8)
scan
next
finish = time$("ms")
print "Execution time ";finish-start;" milliseconds"
In LB 4.5.0 about 2000 ms and in LBB 3.04 about 8000 ms, that's about 4 times slower in LBB.
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Card graphics not sticking
« Reply #32 on: May 23rd, 2016, 12:10pm » |
|
Quote:If you "really wonder" this, then perhaps put up a bunch of examples?
|
|
If I had examples I had not to wonder. I would then just said that and give examples.
Quote:>>I really wonder if there are reversal - things you get away with sloppy coding in LBB but not in LB?
It just should be somewhere - or we assume LBB is perfect (in a god-like sense).
> What the hell does that mean in a programmer-like sense? What program is "perfect?" Certainly not LB!
|
|
I'll try again.
It was said that trying to run valid working (or seem so) LB program in LBB discovers some defects in coding.
I suppose that should work *both* ways.
That is, having many working LBB programs, occasionally running it in LB will point some defect in coding (not in LB or LBB - but in mine coding, as a BASIC programmer).
Unless one assumes LB is so great that defective in some way code cannot ever work in LBB.
(of cource Richard points out that to have big amount of LBB programs and not to use LBB new features is pointless.
I agree.)
As of the rest please don't think about things I never said.
|
| « Last Edit: May 23rd, 2016, 12:12pm by tsh73 » |
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #33 on: May 23rd, 2016, 12:14pm » |
|
Russell: Perhaps you misunderstood what I meant. The slower execution I was experiencing in LBB was entirely due to sloppy programming in my LB code to start with! I wasn't saying that LBB is or isn't inherently faster or slower, merely that my inefficient program was causing speed related problems, and that once fixed, ran well in LBB! I was actually praising LBB for identifying errors that were going unnoticed in LB.
I'm currently trying to modify part of my program that's showing a very noticeable difference in speed; but as before, it's likely some goof that I haven't caught yet. I've used the Profiler, but haven't identified anything worthy of passing along … yet. This may take a few days, but I'm trying to get to the bottom of things and will be glad to pass along the results as I find them.
I appreciate your continued help.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #34 on: May 23rd, 2016, 3:15pm » |
|
Here's an example of a code snippet that runs noticeably slower in LBB than LB. It's not lifted from my program, which would only confuse, but is totally representative of what I'm trying to show.
The program populates a grid of 10 x 20 colored boxes as defined in the [Fieldvalues]. A left click on any box will sequence through 1-5 numbers and associated colors.
Here's the "problem": In LB, the program opens almost immediately, while it takes considerably longer in LBB. (The grid in my actual program is almost twice as large, and the time to load is even longer.) The opening (and closing) is by a button in another part of the program, and it's somewhat disturbing to watch the graph slowly fill in when using LBB as opposed to LB. (The sytlebits comment at the top of the program has been commented out. While the display could be hidden until finished loading, the delay is still not desirable.)
I hope I've committed some horrendous programming error and that there's a way of speeding things up. In any case, there's a noticeable difference in the time it takes to load in LB vs. LBB.
Any suggestions would be must appreciated. Thanks!
SORRY - I GOT A MESSAGE THAT THE CODE WAS TOO LONG. IT'S ONLY 300 LINES - HOW DO I ATTACH IT?
|
| « Last Edit: May 23rd, 2016, 3:20pm by Turtleman » |
Logged
|
|
|
|
|
