Is this an issue?
#11
(07-03-2022, 05:48 AM)DSMan195276 Wrote:
(07-02-2022, 09:35 PM)madscijr Wrote: Maybe instead of using a DLL to add functionality, let's look at what it is you ultimately want the DLL to do. Is it something that can be done directly in QB64, avoiding the overhead you would incur by using an external library?

Well the reality here is that the 'overhead' of using an external library is basically non-existent, and with that a C version of some functionality will basically always be faster than a QB64 version. But I don't think this should be all that surprising, lots of languages are like this. The advantage of a language like QB64 is ease of use, not speed at all costs.

And for the most part, I find QB64 to be plenty fast. I have been learning tricks like for faster graphics using hardware images (thanks to Steve and the folks here for their advice & guidance on these things) but mainly haven't had too many speed issues. 

One thing I still need to figure out is how to call COM type DLLs and Windows APIs from QB64. Mainly I want to figure out how to use the Windows Raw Input API to be able to read 2 or more USB mice (and keyboards) plugged into the computer as separate input devices. It's possible but all the examples I have found are done in C++ or C# which is beyond my skill level. Also I would like to have some better audio capability, like synthesizing sounds in realtime with different waveforms, controlling ADSR & playing multiple channels simultaneously. Stuff like that probably would need the speed & low level control of pure C++. 

I think it would be cool if they introduced some way to let you get at the "intermediate" C code generated when you compile your QB64 code, where you can tweak it & optimize it, before it's compiled into the final machine code executable. And maybe be able to designate your optimized C code as a library or module as "precompiled" or something, that your regular QB64 code could call for the extra speed or functionality. I think that could help make QB64 more
versatile and capable.
Reply
#12
(07-03-2022, 03:05 PM)madscijr Wrote: One thing I still need to figure out is how to call COM type DLLs and Windows APIs from QB64. Mainly I want to figure out how to use the Windows Raw Input API to be able to read 2 or more USB mice (and keyboards) plugged into the computer as separate input devices. It's possible but all the examples I have found are done in C++ or C# which is beyond my skill level. Also I would like to have some better audio capability, like synthesizing sounds in realtime with different waveforms, controlling ADSR & playing multiple channels simultaneously. Stuff like that probably would need the speed & low level control of pure C++.

Unfortunately I think there's only so much we can do to make such APIs easy to use. That said I'm not very familiar with COM, so perhaps something could be done. In regards to synthesizing sounds, there is
_SndRaw
already which does basically let you do this (though it's potentially a little lower level than you're thinking). The lack of threads or callback support makes it a bit hard to use though, from what I've seen (It can be hard to ensure you're always filling the buffer in time).

(07-03-2022, 03:05 PM)madscijr Wrote: I think it would be cool if they introduced some way to let you get at the "intermediate" C code generated when you compile your QB64 code, where you can tweak it & optimize it, before it's compiled into the final machine code executable. And maybe be able to designate your optimized C code as a library or module as "precompiled" or something, that your regular QB64 code could call for the extra speed or functionality. I think that could help make QB64 more
versatile and capable.

That sounds kinda like "inline C" in a similar vein to inline assembly. I think it could potentially be done, but the problem is that the QB64 internal APIs are not stable, so it would be hard to not break that code with updates. On that note though, using
DECLARE LIBRARY
with a header file that has inline functions in it basically already allows you to do this, and also has a consistent way to interface with the QB64 code - so if you want to mix C code with your QB64 code that's really the way to go.
Reply




Users browsing this thread: 6 Guest(s)