[Coco] Profiling emulator?
Barry Nelson
barry.nelson at amobiledevice.com
Wed Sep 14 00:27:30 EDT 2016
Again, rather than QT, I suggest leaving all the Direct X stuff untouched and using Wine Lib. This will also fix most of the other windows dependencies.
> Mark McDougall 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[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...
More information about the Coco
mailing list