[Coco] VCC Update

Steve Strowbridge ogsteviestrow at gmail.com
Thu Apr 13 15:55:46 EDT 2017


I'm also thinking this may be a great topic to bring up this Saturday,
April 15th on CoCoTALK! which will air live at 3:00 PM EST at
http://live.ogsteviestrow.com  if anyone wants to join to live skype call,
or join the live chat, hit me up, love to have you, and love to discuss
this in a civil and respectful way :)


Steve Strowbridge, aka
The Original Gamer Stevie Strow
http://ogsteviestrow.com
ogsteviestrow at gmail.com


On Thu, Apr 13, 2017 at 3:54 PM, Steve Strowbridge <ogsteviestrow at gmail.com>
wrote:

> I don't pretend to know what it's like to work on these or
> update/migrate/port them in the slightest, and I hope I have not offended
> Bill or anyone else, and I didn't even mean to imply that pissing contests
> were based around VCC in particular, but I have seen a lot of people with a
> lot of varying opinions and favoritism towards one platform or the other
> over the past few years, I am just merely throwing out that there, that
> since there are some platforms that already exist and are already multi OS
> compliant, why not integrate some of these rather than reinventing the
> wheel.
>
> Also, regarding "competition" I agree that everyone should have the right
> and freedom to create a product they so chose, and nobody is making any
> money by doing any of this, so I'm not sure "competition" is the best word,
> but "freedom", "variety", "options" all seem more appropriate, but again,
> and these are just my opinions, sometimes the amount of variety can serve
> to alienate a percentage of the population.
>
> Since none of these 3 options is a completely perfect,  or super easy
> solution, and different camps are going to defend/stick with the choice
> they made/support, those people are going to be somewhat "stuck" with
> certain options/features or lack thereof.
>
> Since efforts are being made, and applaud them all, again, just my
> opinion, I don't know all the facts, logistics, reasons, potential
> pitfalls, etc., for not doing so, but I think if more "cooperation" was
> applied than the "competition", the resulting product would be something
> everyone could benefit from in the long haul.
>
> That's my 6809 cents.
>
>
>
> Steve Strowbridge, aka
> The Original Gamer Stevie Strow
> http://ogsteviestrow.com
> ogsteviestrow at gmail.com
>
>
> On Thu, Apr 13, 2017 at 3:42 PM, James Ross <jrosslist at outlook.com> wrote:
>
>> Bill Pierce wrote:
>> > James, keep me updated on this. It sounds like you're moving in
>> > the right direction.
>>
>> Will do Bill!  Thanks.
>>
>> > Though the original idea was to drop directx and move to QT or
>> > something similar that's cross-compilable.
>>
>> Yes, that would be ideal! But ...
>>
>> First, please understand this in NOT a “pissing contest” as Stevie put
>> it.  I know sometimes (or a lot of times) putting thoughts and expressions
>> in writing can come across has harsh, when the intent was really not to be.
>>
>> I would love to see VCC ported to work on all the major platforms, like
>> MAME & XRoar already do.
>>
>> How to do that, is a different story. To take the existing code and
>> somehow shoe-horn that into Qt code using OpenGL – might be possible, but
>> man … extremely difficult. I applaud the effort, but I believe the
>> possibility of success is extremely low on that approach. They are two
>> completely different “beasts” to tame.
>> To do that, (again, this is just my opinion, duck and cover) it is a
>> complete re-write.
>>
>> I am talking starting over from scratch.
>>
>> Now, what a person can do is use the existing VCC code as a road-map.
>> Base a lot of the logic of the VCC engine for the CPU and peripherals. You
>> could say start w/ the VCC code in one folder and the new from-scratch Qt
>> code in another folder. And as you re-implement sections of the code/logic
>> then you delete that code from the VCC folder.
>>
>> BUT it is NOT just a cut-and-paste proposition.  Each section will have
>> to be re-done, re-engineered.  The VCC code was NOT done in a manner of
>> separation of concerns like your model/view MVC concept. All the logic
>> there is intertwined w/ the GUI stuff and the DirectDraw stuff.
>>
>> So the question is, how big of an effort for a ground up re-write using
>> Qt/OpenGL?
>>
>> It is BIG (at least in my opinion it’s huge). UNLESS, you’ve done this
>> kind of thing before. And are young and fast. But if you’re like me, in
>> addition to the re-engineering / re-construction of the VCC code you have
>> the learning curve of Qt/OpenGL to boot.  For me to do this – I’d be
>> looking at 500 hours -- bare minimum on a project like that. Possibly
>> closer to 1000 hours. AND then after ALL that – you will still be in C/C++
>> land. A land that is still full of pitfalls. Even after just a few days
>> working w/ the VCC I’m thinking, oh, yeah, that’s why I don’t do anything
>> in C/C++ now, or have for many years. C/C++ is not the go-to language for
>> new development these days.
>>
>> My thinking is this: if you want to modernize – dump C/C++ altogether. Do
>> the re-write in C# or Java (I would be cool w/ either, but prefer C#)
>> These days, C#/Java are perfectly adequate for speed -- even comparable to
>> C/C++ to a certain degree. But forget keeping compatibility older versions
>> of Windows! (which in this scenario, would be OK)
>>
>> C#/Gtk#/OpenGL --> OpenTK / SharpGL or figure out which OpenGL C# binding
>> is most popular and maintained – also I believe there are some C#
>> multiplatform game-kits that call on the best available graphics engine
>> behind the scene (SDL on Linux/DirectX on Windows etc. could be looked.
>>
>> Same thing would go for Java. Might have even more options w/ Java
>> including might be possible to use JavaFX to do the whole thing.
>>
>> That would be my 2c for a complete a re-write (which to summarize, in my
>> belief, is the only way that a multi-platform VCC’ish – i.e. based of the
>> VCC code -- gets done)
>>
>> James
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>
>


More information about the Coco mailing list