Questions for a Metal->C++ converter.

[Joseph Duchesne]

OK I have 2 questions: I'm makeing a Metal->C++(or Obj C) converter. I know the syntak for C++ but that's it. To start I a(preferably OpenGL) command for getting the screen width, height and setting a window to specific quardinates. I also need the #include for OGL or whatever your command uses.

[Jake]

Originally posted by Joseph Duchesne
OK I have 2 questions: I'm makeing a Metal->C++(or Obj C) converter. I know the syntak for C++ but that's it. To start I a(preferably OpenGL) command for getting the screen width, height and setting a window to specific quardinates. I also need the #include for OGL or whatever your command uses.

I thought of doing that, and its pointless... learn C and use it, dont write in metal and then convert it.

[Tycho]

You'd probably have as much luck just creating a compiler.

[Joseph Duchesne]

I already have a working model going using the cin and cout (I forget the name of the #include). I just think it would be faster than recoding 4000 lines of code, in the long term. You know you would use a utility like this if there was one:D .

[Jake]

Originally posted by Joseph Duchesne
You know you would use a utility like this if there was one:D .

I would probably use it to test in, and then say "Open GL is cool", and switch to C

Seriously, spend your time on GC

[sealfin]

The #include for OpenGl isÖ

#include <AGL/AGL.h>
#include <OpenGL/GL.h>

Ö(in C and Project Builder anyway) but the real question isÖ do you know C++ fluently enough to write an app which will produce decently optimised code, and make the best use of C++ (ie. object-orientated) concepts? (as, as far as I'm aware, Basic is pretty much non-object-orientated.)

Converters are a fun time-waster to write if you're going between two similar languages, eg. Pascal->C or perhaps Basic->C, and you have a fluent or very good knowledge of both languagesÖ but for any serious development work, you'll usually be far better off by just learning the language.

[Dr. Light]

This could be an excellent learning tool though. See how this and that works, the rough equivalents, prototyping, etc. . I say keep going. Eventually, you can make a converter for This BASIC > That BASIC, so METAL can have a place on windows.

[Joseph Duchesne]

That could be true but:
(A)Even a roughly converted GL code in C++ would be faster than Metals non compiled quickdraw
(B)I use metal not because I don't know C, I use it because you can write an app in basic about 300x faster(slight exaggeration) than C++. I can then spend more time pollishing an app and less time coding it. You wonder why they made C when there was good ol' Assembly?
(D)Metal(as of now) has no support for anything other than mac.
(E)It'll be faster in the long run to make a metal->C++ translator and code my apps in metal then to code them all in C++.

Logic argument? Maybe it isn't but then why arn't you using "Sealfin assembly" on your own chip? It can be done faster using other methods. Drone drone blah... :D there no more arguments.

[NCarter]

Just a thought:

Write a bunch of functions that replicate the basic built-in functionality of Metal. Then write more functions that provide the features you'd like Metal to have. Then make your game by writing C/C++ code that calls those functions.

The thing is, Metal is only easier and quicker than C/C++ because it comes with a bunch of built-in features for doing graphics, sound and so on. Once you've written those functions for yourself (or acquired them from other people's libraries) it doesn't really matter which language you use. You would also get access to better language features (such as proper functions!) by using C/C++.

BTW, I'm not knocking Metal... I sometimes use it for making prototypes before writing a final C++ version because it's quicker than repeatedly recompiling a C++ project! :)

[Dr. Light]

Yeah, as I was saying before, make a conversion "library", so that you can just take the template commands and then just place the values/variable in their proper positions.

[Joseph Duchesne]

Thats what I am doing. It will be like a library. Metal is esier for other reasons like the basic syntax:

Metal

if x=10 and y=13 then x=x+y

C++

if(x==10 && y==13)
{
x=x+y;
}

You tell me which is faster to write(and remember :D )? I'm not saying I won't eventually move to another language(C++) I'm just saying that for what I am doing now MetaL is just fine.

[Jake]

How exacaly are you going to use metal to do this, are you going to make up your own commads? If you do, make sure they have a ' before them, because if you make up a command called GLRENDER or something metal will take that as an error when checking syntex of normal code.

I guesse this could be a decent idea, but its an even better learning experiance.

[Dr. Light]

No no, Jake.:) It supposed to output code compilable in Project Builder, for instance. METAL is just used as the converter, and the libraries specify how to convert it.

[Tycho]

Personally I think writing

if(x==10 && y==13) x+=y;

is just as easy as writing

if x=10 and y=13 then x=x+y


But it doesn't really matter that much, because often very little of a programmer's time is spent actually typing code. You usually spend more time debugging, which is why longer, easier to understand code is better than compact unreadable code.

BASIC is easy to learn and quick to develop in due to the built in functionality, while C/C++/Objective-C have a higher learning curve, but are more powerful and scale better for large projects.

[OneSadCookie]

Originally posted by sealfin
The #include for OpenGl is?

#include <AGL/AGL.h>
#include <OpenGL/GL.h>


Actually, it's

#include <AGL/agl.h>
#include <OpenGL/gl.h>

(again, only for Mach-O compilation on Mac OS X).

What you originally posted, sealfin, won't work if the frameworks are on (for example) a UFS disk where file names are case-sensitive.

[sealfin]

OopsÖ I never considered that (but then again, I've never had to deal with UFS format except on my server.)