[Coco] Profiling emulator?
msmcdoug at iinet.net.au
Tue Sep 13 19:26:26 EDT 2016
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) 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...
| Mark McDougall | "Electrical Engineers do it
| <https://retroports.blogspot.com.au/> | with less resistance!"
More information about the Coco