BBC BASIC
« Quest for fire library (group effort ) »

Welcome Guest. Please Login or Register.
Jan 20th, 2018, 4:20pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1 2  Notify Send Topic Print
 hotthread  Author  Topic: Quest for fire library (group effort )  (Read 396 times)
DDRM
Global Moderator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 29
xx Re: Quest for fire library (group effort )
« Reply #20 on: Jan 12th, 2018, 12:41pm »

Hi Richard,

What I saw was that the Z position correctly controlled which was drawn in front of the other (I agree very small Z differences don't always work quite as you expect) - and indeed, the flames can render BETWEEN the logs if you position it right - but that when the flames were rendered in front of the logs (but before the logs themselves had been rendered) you couldn't see the logs through them. When you render the logs first, then the flames, you CAN see through them to the logs behind. I can imagine that it's problematic for D3D to realise that something it's already dealt with is transparent, and the new thing it's rendering behind it should be partially rendered with it. I guess the moral of the story is "render transparent things last".

With regard to directories, I agree that library functions need, by default, to save somewhere sensible (and writable!) I rather assumed that the dir$ active at the time relates to the program calling the library - is that not the case? Nonetheless, your point is well made that I can't assume that a program will be running from a writable directory. I wasn't thinking about a "development library", but that the programs using it will be for creating resources (FVF files) as part of the development process: typically I keep all such "helper" programs, together with working resource files, together in one folder (in this case, called D3D), but obviously not everyone works the same way!

Does getting the routine in the library to open a "save as" box seem a reasonable solution? I'm not keen on using temp$ or usr$ because (a) the user may not know where they are, and be unable to find the file, and (b) don't you have to assume that things in the temp directory can be deleted when this use is finished? I don't think Windows does automated garbage collection in the way Android does, but my understanding was that you shouldn't rely on things staying in the temp directory for long... Maybe I'm very old-fashioned in this, as I think you've suggested before wink

Best wishes,

D
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx Re: Quest for fire library (group effort )
« Reply #21 on: Jan 12th, 2018, 3:56pm »

on Jan 12th, 2018, 12:41pm, DDRM wrote:
I rather assumed that the dir$ active at the time relates to the program calling the library - is that not the case?

I'm not sure what you mean by "relates to" in this sense. @dir$ is initialised to point to the directory from which the program was originally loaded, if that is known. If the program was pasted in (or typed, or dropped) then of course that isn't known - indeed the program may not be saved at all - in which case @dir$ cannot be relied upon to point to anywhere specific.

That was the case when I received the 'Invalid channel' error: I had pasted your program from the forum but had not saved it. As a result @dir$ pointed to the EXAMPLES folder of the BB4W installation (under C:\Program Files (x86)\BBC BASIC) which is definitely not writable unless 'run as' elevated.

Quote:
Does getting the routine in the library to open a "save as" box seem a reasonable solution?

I don't think I've entirely understood the possible usage cases. If the purpose of the library is for a software developer to create an FVF file, which he will eventually ship with his program, then he will be wanting to create it in @dir$ or a sub-directory thereof. If it's intended that the library itself be shipped with the program, so that the FVF file is created 'on the fly' at run time, then it will need to be created in @tmp$.

In the former case I suppose it would be acceptable to open a file selector, but not in the latter case. For all I know you may intend that the library can be used in both these scenarios. The only fully flexible approach, I would have thought, is for the path/filename to be supplied as a parameter and not determined by the library at all. Indeed, looking at your code, why does the library decide the directory and extension when these could simply be passed in the name$ parameter?

Finally, I'd recommend that you replace the old CPU-dependent version of FN_f4 (which uses x86 assembler code) with the entirely-BASIC version listed below. Not only is it CPU-agnostic, benchmarking showed it to be faster (you may remember that I posted an earlier version to the discussion group as a challenge to see if anybody could improve on it).

Richard.

Code:
      REM Convert to 4-byte float
      DEF FN_f4(a#)LOCALP%:P%=^a#:IFABSa#<1E-38THEN=FALSE
      =P%!4ANDNOT&7FFFFFFFOR(P%!4-&38000000<<3OR!P%>>29AND7)+(!P%>>28AND1) 

« Last Edit: Jan 12th, 2018, 3:58pm by Richard Russell » User IP Logged

DDRM
Global Moderator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 29
xx Re: Quest for fire library (group effort )
« Reply #22 on: Jan 15th, 2018, 08:13am »

Hi Richard,
Quote:
Indeed, looking at your code, why does the library decide the directory and extension when these could simply be passed in the name$ parameter?


Quote:
MAJIKTHISE:
Bloody ‘ell! That’s what I call thinking! Here Vroomfondel, why do we never think of things like that?

VROOMFONDEL:
Dunno. Think our minds must be too highly trained Majikthise

Duh, yes, that would be much more sensible... I'll change it.

Thanks also for the updated version of FN_f4

Best wishes,

D
User IP Logged

michael
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 141
xx Re: Quest for fire library (group effort )
« Reply #23 on: Jan 17th, 2018, 12:44am »

The 3D fire is pretty cool.
User IP Logged

I like reinventing the wheel, but for now I will work on tools for D3D
Pages: 1 2  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls