[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