[Coco] Profiling emulator?

[Mark McDougall]

On 14/09/2016 12:36 AM, Bill Pierce via Coco wrote:

> Mark, the original plan was to get the sources into a more "modern"
> state, then swtich the graphics to QT. The whole thing is stuck at the
> moment as the conversion wasn't finished (this is not on github). BTW,
> which branch are you working from? The "Master" has some problems (hence
> the work in the offline version), and the "VCC-1.200b" branch is the
> current release.

I'm using v2.0.1b(final[edit]) but it was only ever experimenting and 
there's less than 10 lines changed in total which I've noted on paper. Now 
that it builds (at least) I can start over and do things "properly".

My immediate goal is to add some sort of rudimentary profiling function so 
that I can optimise and subsequently finally release Knight Lore. Of course 
I'd like to facilitate your above-mentioned goals in the process if I can.

I've never used Qt but this is a good excuse to learn. I'm assuming a 
Qt-based project would be built using gcc rather than Visual Studio?

The only caveat is that, being primarily an embedded and device-driver level 
engineer my C/C++ skills are stuck around C99/C++03. So if you're looking 
for an excuse to use all the features of later revisions I'm not the right 
person for the job.

Also had a thought whilst trying to sleep this morning...

I don't see the utility in having DLLs for the various optional (from a Coco 
POV) components; it's not as if they'll be shared with other programs, 
there's no concept of being able to "plug in" different implementations, and 
by modern standards the size of the executable is microscopic. Plus it 
complicates building and porting to other compilers/platforms, not to 
mention installation/deployment. What was the original thinking here?

Not going to me much fun replacing the DirectX stuff either...

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|   <https://retroports.blogspot.com.au/>    |   with less resistance!"