Author |
Topic: Passing Parameters with SYS (Read 1092 times) |
|
Michael Hutton
Developer
member is offline
Gender: 
Posts: 248
|
 |
Re: Passing Parameters with SYS
« Reply #8 on: Sep 18th, 2009, 12:16am » |
|
One of the reasons I would like to be more proficient with C++ was/is to create assembler routines, or rather check my own. I have now been able to look at the output of various programs and have been happy that the disagreeembler code seems to follow very closely the C++ output. I would even say (ahem!) that some of my hand written stuff is actually better,,,I mean, faster than the compiler, but only by using 'shortcuts' or destroying registers and probably doing 'unsafe' things. Which leaves the obvius problem of not being able to integrate them at a latter date without doing the needed saving of registers etc. They are not exactly encapsulated objects. I will try to come up with an example...all are pretty short at the moment and not really worth posting. It is a very interesting excercise. I am particularly intrigued with C++ use of the stack and the definition of entry and exit points from code blocks. { and }.
I hear you warning about the dll 'bloat'. I am not out here to change what isn't broken in BB4W. In fact I entirely agree that a BB4W library file is more than good enough for 99.9..% of applications. But, for example, could GFXLIB be translated to a dll easily? (David, we need a blur routine!!! (and more documentation!!!) - sorry for outburst!) and I think that the GFXLIB_PlotPixelList may need changing because it doesn't like the pixel list to be part of a larger sturcture....ie PointList{()} x%,y%,c%, something, else} ) Also, some colour routine such as the hsvtorgb and vice vesa would be suited to a dll (Yes/no?). Or are they best left as B4W libraries. I would be interested in peoples thoughts.
Also, I have found the idea of having LOCAL variables in different code blocks very good. Could this be a feature added to BB4W? for instance, a FOR.. NEXT loop can have its iterator made local to that code block and other variables declared in it can be made local. I tend to use the static variables (A%-Z%) for local and loop iterators due to their speed.
Anyway, have to go..
Michael
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: Passing Parameters with SYS
« Reply #9 on: Sep 18th, 2009, 01:32am » |
|
on Sep 18th, 2009, 12:16am, Michael Hutton wrote:| But, for example, could GFXLIB be translated to a dll easily |
|
I've been working on GFXLIB a lot lately - specifically, I've had another go at trying to modularize it (and I'm actually succeeding this time!). So, except for a small set of commonly used 'core' routines, the programmer would just INSTALL the routines that she requires, viz.:
Code:INSTALL @lib$+"GFXLIB" : PROCAutoInit32
INSTALL @lib$+"GFXLIBmodules\PlotRotate" : PROCInitModule
INSTALL @lib$+"GFXLIBmodules\BoxBlur3x3" : PROCInitModule
INSTALL @lib$+"GFXLIBmodules\PlotScaleFade" : PROCInitModule
etc.
on Sep 18th, 2009, 12:16am, Michael Hutton wrote:| (David, we need a blur routine!!! |
|
It has a few now (and some of them are actually employed in Crystal Hunter II -- just hit 'P' for pause during the game to see some blurring):
GFXLIB_BoxBlur3x3
GFXLIB_BoxBlur3x3R
GFXLIB_BoxBlurNxN
GFXLIB_BoxBlurNxNR
GFXLIB_BrushBlur
(The R suffix means 'Replace' - that is, the bitmap to be blurred is replaced by the final blurred bitmap.)
The blurring routines currently suffer from two defects (which I don't intend to fix unless there's popular demand for it (unlikely)):
1. They are comparatively slow
2. The blurring of the edges of a bitmap are not handled as well as they could be, leading to a slight (but often hardly noticeable) darkening around the edges of the bitmap, a few pixels wide).
Please feel free to contribute a Gaussian blur routine, Michael. ;-)
on Sep 18th, 2009, 12:16am, Michael Hutton wrote:| (and more documentation!!!) - sorry for outburst!) |
|
I agree. :)
on Sep 18th, 2009, 12:16am, Michael Hutton wrote:| and I think that the GFXLIB_PlotPixelList may need changing because it doesn't like the pixel list to be part of a larger sturcture....ie PointList{()} x%,y%,c%, something, else} ) |
|
Yes, I think you meant PlotPixelList. It wasn't intended to be flexible enough to read coordinates (+ optional colour value) from nested(?) structures - only contiguous blocks of fixed-format data (int X, int Y[, int RGB32]).
David.
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Passing Parameters with SYS
« Reply #10 on: Sep 18th, 2009, 09:07am » |
|
Quote:| Also, some colour routine such as the hsvtorgb and vice vesa would be suited to a dll (Yes/no?). Or are they best left as B4W libraries. I would be interested in peoples thoughts. |
|
It seems to me that there are two main differences between putting code in a DLL compared with putting it in a BB4W library.
The first is that a DLL will (almost certainly) be written in C or C++, whereas a BB4W library will have to be a mixture of BASIC and assembler.
The second is that with a DLL you don't need to 'ship' the source code, but with a BB4W library you do.
My view is that, in both cases, there's no clear argument as to which is 'better'. Writing in C may be quicker/easier, but the final code may execute more slowly (or it may not). On the other hand a BASIC/assembler hybrid approach can be very powerful, but learning assembler to the required degree of proficiency isn't easy.
As far as incorporating the source code is concerned it can make the 'library' solution rather bloated (although there are ways to avoid the source using up memory at run time, e.g. by CALLing it) but on the other hand it means everything is openly available for any BB4W user to learn from and adapt to his own needs.
I think it's perhaps this last point that I feel most strongly about. Of course if you particularly want your source code to be kept 'secret' then a DLL is the way to go, but then nobody other than you can fix bugs, make improvements etc. I always worry that if the original author loses interest, or drops dead, we could be left with a 'white-elephant' DLL if a bug or incompatibility is discovered.
Richard.
|
|
Logged
|
|
|
|
|
