Hi everyone,
As all of you know back in December 2006 USA Games made STFC 1.0 
available for public distribution. What we did not anticipate prier to 
that release is how difficult it would be to get all users up to date 
running the .NET Framework and the current version of DirectX. For most 
users we were able to quickly resolve the issues and make STFC operate 
properly. However, there were a few cases which were without any hope of 
solving easily, and at this moment still remain open as unsolved cases 
of unknown error.
Recently, on the Audyssey list I had made a suggestion that as a 
developer I should design a 3D engine similar to the Quake engine, but 
with all the access features built in. I'm thinking of starting over 
with the USA Games engine and instead of basing it on the .NET Framework 
and switching to C++ with the standard Windows win32 API and MFC which 
comes installed on every Windows system. Even better I can package MFC 
updates with my installer to update them were they needed.
I see many advantages of this switch such as greater security, better 
performance of games, a wider availability of security tools to protect 
USA Games commercial games,and no dependence on the .NET Framework for 
any games designed under the new engine.
The final reason I might consider this route is simply that C++ support 
for game devices, graphics, and sound is first rate. Since it is widely 
used by pro game developers there are often more features for DirectX 
available to a C++ dev than say for VB such as  force feedback support 
for game controllers. The VB support for game controllers doesn't seam 
to work well with feedback devices as both Che and I found out the hard  
way. James north had created the initial Raceway engine in VB, and I 
won't be able to get ff device support using VB or VB.NET. However, in a 
language like C++ it wouldn't even be an issue.
However, using C++ isn't going to be all roses. I've gotten a bit rusty 
with C++, and would probably take some time brushing up my skills, 
finding out what changes were made in the SDKs I'd need, and so on. Game 
production could potentially be slower since C++ isn't the easiest 
language to work with, and I'll admit can be complex at times. Certainly 
not a cinch like C#.NET is. Not only that it would take me quite a while 
to read through my engine code, and begin converting it from C#.NET to C++.
On the other hand, I do have a good thing going with C#.NET. Other than 
the bumps in the road with end users not always having the correct 
versions of the framework etc games like STFC and Montezuma's Revenge 
are doing well. On a fairly modern system with all the latest service 
packs and patches those games should play reasonably well for the audio 
gamers community. I'd kind to hate to switch just when USA Games is 
beginning to get this show on the road you might say.
There are some reasons about the .NET languages I am beginning to 
dislike such as having to encrypt my binaries every time I compile them 
for distribution, end users having mismatched versions of programs which 
causes conflicts, and a few other miner limitations. Otherwise, like I 
said, I am ok with what I am doing.
What do you all think. Are you happy with the way USA Games is doing 
things, having to install the .NET Framework, etc, or would rather us 
move to something more generic like the C++ Win32 API which is pretty 
standardized across MS Windows platforms.
Thanks.


_______________________________________________
Gamers mailing list .. [email protected]
To unsubscribe send E-mail to [EMAIL PROTECTED] You can visit
http://audyssey.org/mailman/listinfo/gamers_audyssey.org to make
any subscription changes via the web.

Reply via email to