A proposition?

[IAmSerge]

The question isn't whether Python is slower than C (it is, if I correctly recall the numbers in the last batch of benchmarks I looked at), but whether the slowdown involved is significant enough to matter and whether you're willing to embed a bit of C into the Python if you're faced with something time-critical that can't be handled any other way.

(I am allergic to C#, because I have yet to encounter a C# application that will actually run under Mono--Windows devs generally don't care about people running other systems, and no one else seems to be interested in using C#. Screw that. There are dozens of other languages out there that don't have that problem.)

Sorry, mate.  I develop for windows, but thats only because:

A: I've just started
B: I don't really know how to handle developing for other OS's

I don't really like how the windows development is set up, but its the only thing i know.  I wish there was a simple "All encompassing" format that could be used.

Or perhaps a program who's installer determined which sets of code to compile and use, dependent on the OS currently installing.. =/

I assume C++ works on (almost) all OS's?

[alfadorredux]

The simplest way to develop for multiple platforms if you're running Windows is to use an interpreted language--Python, Perl, Java, what-have-you. It is possible to write platform-locked code in languages like this, but it's more difficult. Of course, there's a tradeoff in terms of efficiency--interpreted languages are a bit slower for most operations, on average.

C++ can be compiled for multiple platforms, provided that appropriate precautions are taken (in particular, you need to make sure any libraries you use are available for all the relevant platforms). I believe the switches for platform-specific code normally take the form of preprocessor directives. However, I never liked C or C++ very much, and haven't coded in either in years, so others here could probably give you more precise information about the appropriate syntax (it's very likely the same for both languages--C++ is a syntactic superset of C anyway).

One thing you want to do, if you're developing on Windows and want your code to run on other platforms, is be very cautious of any tool or library that's provided by Microsoft itself, because they have a vested interest in not letting your code run elsewhere. Seek out open-source or at least third-party alternatives where you can. This means using OpenGL or a wrapper library like Allegro rather than DirectX, and similarly, if you really want to develop in C#, use Mono (yes, you can get it for Windows, too) rather than Microsoft's .Net framework.

[alfadorredux]

(In all fairness, I should probably add that I am both a Linux user and something of a grouch. ;P )

[IAmSerge]

Yeah, preprocessor directives... never really knew what all of them did, just know a few of em, like #include, or #pragma once (which I only kindof understand, anyways).

Honestly, I hate Java with all of my soul.

But just as much as I hate Java, I hate Microsoft Visual Studio.  It is NOT a good compiler, HOWEVER it IS the one I know.

and, I am going to be using Allegro.  Or at least, I'll try to.

So I will also figure out how to code for multiple platforms later on =D

And I will!

EventiallY!

[Radical_Dreamer]

Visual Studio is a fantastic IDE.

[Schala Zeal]

I did my homework. XNA has a Mono counterpart, so I went ahead and installed the SDK.

[alfadorredux]

Honestly, I hate Java with all of my soul.

Hmmm... So was it the rigid syntax, the interpreter startup time, the horribly inefficient IO package, the lack of genuine native GUI support on most platforms without installing a third-party package, the uncontrollable garbage collector that sometimes lets you run out of memory for no reason, Sun's abstruse licensing terms, the multimedia support that's several times harder to use than it needs to be, the CORBA and other junk that only a minority of programmers will ever need folded unremovably in with the main distribution, or some other quirk that I've forgotten that drove you 'round the bend? (Yeah, Java programmer here--I've forgotten more of the bad and ugly things about the language than you ever want to know.)

I hate Microsoft Visual Studio.  It is NOT a good compiler, HOWEVER it IS the one I know.

Visual Studio is an IDE, not a compiler (well, okay, you'd find a compiler of some sort if you dug deep enough into its guts, but it's only a very small part of the package). I can't speak to its quality or lack thereof--when I was on Windows, I either favoured Borland IDE software or lightweight syntax highlighter + compiler packages, depending.

and, I am going to be using Allegro.  Or at least, I'll try to.

A reasonable choice--I know Allegro is available for Linux, anyway. Don't know about OSX.

[Barash]

great idea neo-fusion.
i know nothing about programming or graphics but i compose hell alto of music and my favorite kind of composing is game music.
i have some examples so if u r really in to it tell me and ill upload them.

again, great idea

[IAmSerge]

I KNOW I'm going to regret this in the near future, but...

We all seem to be quite knowledgable in the programming industry.  Perhaps we should collaborate and work on something...

Not chrono related, of course, but...I mean, this community has EVERYTHING: The designers, the coders, the graphical artists, the conceptual artists, the musically talented...

And then we have Allegro, which can pretty much remove the need for us to write an engine.

But seriously, look at what we have.  And look at the progress that this community has already made (CE was 98% or more complete!), a sound example of how strong our wills combined can be.

But... who's going to take part, and where will we start?

Hmm... I am currently working on a storyline of my own, for my own project, but YOURE NOT USING it.  its mine.  alone. 
And so, we would be starting at almost scratch (allegro was already done for us, so not a complete from scratch start).

Who's with me?

[Schala Zeal]

Allegro is available for OS X, even iPhone. CMake ( http://cmake.org ) will help you generate the necessary files. I advise anyone who uses Allegro to use version 4.9 instead of 4.4 as it's a complete rewrite and not backwards compatible, and to get these first though (OS X users can use MacPorts ( http://macports.org ) to install these):

CMake - see above
DirectX SDK (Windows only, links to Feb 2010 release) - http://services.social.microsoft.com/feeds/FeedItem?feedId=76dc8ff9-e34c-4be6-9414-d47e3dd34317&itemId=9baee178-7a6e-4752-b7c6-ca3ee5ec1f77&title=February+2010+DirectX+SDK&uri=http%3a%2f%2fwww.microsoft.com%2fdownloads%2fdetails.aspx%3fdisplaylang%3den%26FamilyID%3d2c7da5fb-ffbb-4af6-8c66-651cbd28ca15&k=Jg8IObKD5Pdqf4Ru3infZkXLetdjn19PLVx7tOuD%2fF4%3d
ZLib - http://zlib.net (VC++ users extract the source .zip as zlib, not zlib-1.2.3), LibPNG needs this
LibPNG - http://www.libpng.org/pub/png/libpng.html (VC++ users, extract this to the same folder as zlib is in, so that the SLN file will detect zlib), This is needed to use PNG images, a really good format I think
LibJPEG - http://ijg.org (rename jconfig.xxx to the appropriate extension, VC++ users need to rename makejvcp.vc9 and makejsln.vc9 to jpeg.vcproj and jpeg.sln), Needed for JPEG image use
FreeType - http://freetype.sf.net - needed for truetype font addon
LibOGG - http://www.xiph.org/downloads/ Dependency for the Allegro Vorbis addon
LibVorbis - http://www.xiph.org/downloads/ Needed to use .ogg audio files
LibFLAC - http://www.xiph.org/downloads/ Needed to use FLAC audio files
OpenAL (OSX has this by default, won't work with Windows) - http://kcat.strangesoft.net/openal.html
PhysicsFS - http://icculus.org/physfs - Needed for PhysicsFS addon, let's you read data from ZIP/HOG/7Z/etc... archives

To install:

Windows users: In your environment variables (System control panel) make the following entries:

Name: LIB
Value: %DXSDK_DIR%\Lib\x86;%LIB%

Name: INCLUDE
Value: %DXSDK_DIR%\Include;%INCLUDE%

Visual Studio 2008 Solution - In command prompt, type: cmake -G "Visual Studio 9 2008"
Xcode Project - In Terminal, type: cmake -G "Xcode"
Unix Makefiles - cmake -G "Unix Makefiles"
MinGW Makefiles - cmake -G "MinGW Makefiles"

Be sure to check the generated CMakeCache.txt file after running this, to make sure it was configured correctly. Rerun the above corresponding CMake command to update it if you make any changes.

[IAmSerge]

Honestly, no, I'm not installing all of that to use Allegro.  Im just going to be using their base drawing and sound functions.

That is, if I can even get the f***ing thing installed.

The install guide is too damn complicated to understand.


****! I forgot to turn in my comp sci homework, which I DID!
 ****in figures

[Ramsus]

Use straight C or a subset of C++ (no templates, no STL, no boost, maybe just a little rtti) with SDL for input, windowing, and audio, OpenGL for rendering (even if it's "2D", but 3D backgrounds with 2D sprites might be an interesting thing to try with a fangame), then create scripting hooks for all the functionality in Javascript using Spidermonkey or Lua using their standard implementation.

If you're an experienced programmer, you can learn C very quickly. This means everyone can contribute. I can even make an installable package for Windows users who want to contribute, where they just install our development tools and start coding and testing. Subversion for version control would be easiest in our case.

Considering we're coding the engine to be just like Chrono Trigger's (albeit, with a few possible improvements here and there), we don't care about flexibility and the complexity of it isn't really that great. Portability and a lightweight code base with few dependencies is more important in our case.

That's because we know pretty much what we want the engine to do.

What we really need to focus on is making powerful, integrated tools for building maps and scripting events and battles. Writing such tools in something like Python would be best, where we can quickly adapt and improve them to suit our needs.

That's my two cents. I bet this continues on as a debate over what languages and tools everyone should use though.

[alfadorredux]

I would be very, very surprised if even a significant subset of the programmers on the Compendium ever agreed on a preferred language and toolset--programmers elsewhere hardly ever do! 

Seriously, I dislike C (and, by extension, C++, which inherited most of its problems) because I find it's much more work than any of the other programming languages I've worked with. If you work in C, the final code will take less machine time to run, but in my experience it takes more time--sometimes a lot more--to write and debug it unless you're already a fairly good C programmer, because the language does so little of the obvious, purely-mechanical error checking on its own that you might as well be working in assembler. I'd rather waste the computer's time by using a less-efficient language than waste my own on doing my own garbage collection and array-bounds checking (unless I'm trying to write something where good execution time is absolutely vital, like a device driver). Others' mileage may vary.  ::shrug::

(I discovered last night that the last version of Allegro for which Gentoo has an ebuild is 4.2.2--there's a version-bump bug filed against 4.4, but no one seems to have done anything about it. Hmmm.)

[Schala Zeal]

I highly advise against learning 4.4 or older if you're a beginner. 4.9 is a non-backwards-compatible rewrite that will become 5.0 and is preferred that all beginners learn that instead. 4.4 has a lot of old code that isn't used today -- support for FLI sprite format, and the Atari graphics engine specifically.

[Ramsus]

I would be very, very surprised if even a significant subset of the programmers on the Compendium ever agreed on a preferred language and toolset--programmers elsewhere hardly ever do!  

Seriously, I dislike C (and, by extension, C++, which inherited most of its problems) because I find it's much more work than any of the other programming languages I've worked with. If you work in C, the final code will take less machine time to run, but in my experience it takes more time--sometimes a lot more--to write and debug it unless you're already a fairly good C programmer, because the language does so little of the obvious, purely-mechanical error checking on its own that you might as well be working in assembler. I'd rather waste the computer's time by using a less-efficient language than waste my own on doing my own garbage collection and array-bounds checking (unless I'm trying to write something where good execution time is absolutely vital, like a device driver). Others' mileage may vary.  ::shrug::

(I discovered last night that the last version of Allegro for which Gentoo has an ebuild is 4.2.2--there's a version-bump bug filed against 4.4, but no one seems to have done anything about it. Hmmm.)

It's not about what you prefer -- it's about what gets the job done. A simple engine written in straight C would be easy to make completely scriptable in Javascript or Lua and would be easy to port to all sorts of platforms, and we can still use a garbage collection and abstract vector/array type library to make up for the language deficiencies. Besides, runtime debugging tools have gotten so good that finding problems in your C code isn't very painful at all in my opinion, unless you're working on large, complex projects. The key is to test and debug your code as you write it.

Considering once the engine has all of the kinks worked out, most of the real coding will be done in the scripting language used by the game, the language used for implementing the actual engine doesn't have to be anything fancy and the game engine itself should not be very large or complicated at all.

Anyway, I'm going to take this as meaning nobody here is a real C programmer or all that interested in becoming one for a single project. It doesn't matter either -- I really don't expect to see anything real come out of this discussion.


EDIT: And just so you know, if we were all talking personal preference, I'd say to code the game engine and all of its tools in Common Lisp. That'd be my preferred way of doing it.