ENIGMA Forums

General fluff => General ENIGMA => Topic started by: TGMG on August 10, 2010, 11:18:36 pm

Title: MacOSX problems
Post by: TGMG on August 10, 2010, 11:18:36 pm
I have only made 2 changes to the compiler to get it to compile and run on mac:
OS_Switchboard.h:

Quote
#define TARGET_PLATFORM_NAME "ENIGMA_WS_COCOA"

+  #define TARGET_PLATFORM_ID   OS_MACOSX

Otherwise it will try and look for the windows headers :/
Also:
gcc_backend.cpp:
Quote
-    int failing = better_system(cpath = "cpp", "-dM -x c++ -E blank.txt", ">", "defines.txt");

+    int failing = better_system(cpath = "cpp", "-dM -xc++ -E blank.txt", ">", "defines.txt");

That space makes cpp makes cpp think c++ is a directory :/ Must be an error with cpp on mac as gcc works fine with the space :s

Anyway onto the error..
Enigma finds make/cpp/gcc fine and fills the defines.txt file correctly. But then engima throws out:
Quote
Opening ENIGMA for parse...
ERROR in parsing engine file: this is the worst thing that could have happened within the first few seconds of compile.
             /
            |    |
             \    \
      |       |    |
       \     /    /     \
    \   |   |    |      |
     | /     /\   \    /
    / |     /# \   |  |
   |   \   *    `      \
    \    /   =  # `     |
     |  | #     ___/   /
    /   _`---^^^   `. |
   |  .*     #  =    | \
     |  =   #      __/
    .\____-------^^  `.
   /      #         #  \
  |   =          =     |
  \___    #     #___--^
      ^^^^^^^^^^^

Not found: __GNUC_PREREQ
Not found: __builtin_huge_val
In file included from _types.h: Line 37, position 9: Type definition does not specify a type
code snippet: s, as needed, later.
 */

#ifdef __GNUC__
typedef <<>>__signed char      __int8_t;
#else   /* !__GNUC__ */
typ
------------------------------------------------

Anyway I will continue working on the cocoa part of the engine :)
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 11, 2010, 12:08:26 am
Nice to hear you are still working on this!

Apparently GNU for Mac implements additional built-ins. It seems __signed is among those.
I believe you should be able to fix that. Find this line:
  regt("__builtin_va_list");

Add these lines near it:
  regmacro("__signed","signed"); //false
  regmacro("__unsigned","unsigned"); //false

Repeat that for any other 'problem' types, or just post the error here and I'll tell you what to add.
Thanks much for the update.
Title: Re: MacOSX problems
Post by: TGMG on August 11, 2010, 01:41:16 am
Ah thanks :D

That did fix that one, but:
#ifdef __GNUC__
typedef __signed<<>> char      __int8_t;
#else   /* !__GNUC__ */
typedef cha

Still provides an error, the <<>> switched sides of the __signed from the left to the right.
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 11, 2010, 03:06:30 am
Is the error message the same? "Type definition does not specify a type"?
Doesn't really make sense. You could try just defining them (__signed and __unsigned) as ""... Other than that, no idea what could cause that.

Although, some aspects of GNU's STL undefine my macros for some evil, evil reason. If all else fails, can you check for #undef __signed throughout the GNU headers? Or #define __signed _signed_ or the like?

Your search may be easier if you search
cferr = "Type definition does not specify a type";

And replace with
cferr = "Type definition does not specify a type: `" + n + "' is not a type.";

That way you know exactly what it thinks it's declaring.
Title: Re: MacOSX problems
Post by: TGMG on August 11, 2010, 11:15:58 am
Thank yeah i did eventually manage to fix that one but it was just replaced by another:
Quote
Not found: __GNUC_PREREQ
Not found: __builtin_huge_val
In file included from mach/i386/_structs.h: Line 97, position 9: Redeclaration of `__precis' at this point
code snippet: fl      :1,
            __undfl      :1,
            __precis   :1,
                  :2<<>>,
            __pc      :2,
#if !defined(_POSIX_C_SOURCE) || d
After a while of looking through the mac headers etc I realise I am completely lost :/
Any help is greatly appreciated :D

As for the graphical side of things I managed to get cocoa and opengl working :)
(http://i34.tinypic.com/1zxtjxw.jpg)
Seems to work pretty well, now time to work on input and window functions.
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 11, 2010, 03:50:33 pm
I'm at a loss... Pacman compiled? I thought it used DND... I haven't implemented any of the DND functions yet; they should have thrown a syntax error for being undefined...

Anyway, the redeclaration problem. What's happening is that I missed that a nameless variable can be given a size in a structure for alignment purposes. I'll implement a correction shortly; for now, why don't you just comment that out for now and see if that's the last type of error. Search this:
              cferr = "Redeclaration of `"+name+"' at this point";
              return 0;
Return 1 instead.
Title: Re: MacOSX problems
Post by: TGMG on August 12, 2010, 11:01:21 am
I removed all the Dnd, was planning to add them back in bit by bit, so its just a whole load of objects in a room looking like pacman ;)

I have done that but sadly not the last error:
Quote
Not found: __GNUC_PREREQ
Not found: __builtin_huge_val
In file included from sys/signal.h: Line 194, position 8: Unexpected declarator at this point
code snippet: int            sigev_signo;         /* Signal number */
   union <<>>sigval   sigev_value;            /* Signal value */
   void

Still working on the MacOS functions but got a little side tracked and managed to get engima to compile and run on iphone :)
Sadly nothing is being displayed yet apart from the room background colour due to my lack of openglES experience atm. But its compiling and running the events at at least.
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 12, 2010, 04:08:00 pm
Do you have any remote desktop method? The errors you're finding are little things I didn't know ISO supported (or things I overlooked on account of no other STL implementation using them). It'd take me about ten minutes to go through all the errors you're getting now, plus no wait time for the other to respond. In fact, so little as SSH access would probably be enough, just so I can run make and nano (or pico, as it was originally and as OS X prefers to call it...).

This one happens to be entirely due to my own negligence; for that I apologize (The others had odd chunks of ISO thrown in that not even the Windows GNUs used).

I have fixed the error and committed it. If you trust SVN to resolve any local conflicts without inserting a hundred >>>>>>>>>>>>>>>>, you can simply check out (I'd probably recommend it).

Otherwise, you can fix it yourself if you search this:
    if ((last_named &~ LN_TYPEDEF) == LN_STRUCT
    or  (last_named &~ LN_TYPEDEF) == LN_CLASS
    or  (last_named &~ LN_TYPEDEF) == LN_STRUCT_DD)

You should find it at line 640 of handle_letters.cpp.

And insert another line, so it reads like this:
    if ((last_named &~ LN_TYPEDEF) == LN_STRUCT
    or  (last_named &~ LN_TYPEDEF) == LN_CLASS
    or  (last_named &~ LN_TYPEDEF) == LN_UNION
    or  (last_named &~ LN_TYPEDEF) == LN_STRUCT_DD)

Or, as I said, if you trust SVN to do that for you, just check out, as I have fixed this error locally and committed.


As for removing the DND, I assumed that's what you did. Don't worry, DND is insanely easy to implement (It's just the set of action_* functions).
I'm quite impressed to hear it works on iPhone. I am actually ecstatic that you managed to make the modification to use iPhone's compiler yourself; did you have to edit where ENIGMA's compiler looks for GCC?

Though, I wonder, how do you know it actually runs if it has no output? :P
Title: Re: MacOSX problems
Post by: TGMG on August 12, 2010, 11:07:39 pm
I will install logmein and just tell me when you are around and I can give you all the time you need to work on this. I will recheck out to a different directory so you can work from there as my current source is not stable enough to be committed to svn.

Currently on the iphone all textures seem to appear white:
(http://i33.tinypic.com/2n66f07.png)

Which is really hard to debug and see whats going on. I will try and get the Cocoa target to use the OpenglES renderer instead of the standard to check if its an iphone specific problem.
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 12, 2010, 11:46:01 pm
I'm usually on; if you could message me on MSN That'd be good. I'll keep an eye out for you there. There's also ENIGMA's IRC.
Title: Re: MacOSX problems
Post by: TGMG on August 13, 2010, 08:23:37 am
I'll be on enigma irc :)

Also finally got textures working on the iphone :D
(http://i35.tinypic.com/2hr04zq.jpg)

Turns out it wasn't loading the textures as a power of 2.

Btw in sprite_add_subimage, shouldn't:
unsigned int fullwidth=nlpo2dc(w)+1,fullheight=nlpo2dc(h);
be:
unsigned int fullwidth=nlpo2dc(w)+1,fullheight=nlpo2dc(h)+1;

This was the one thing that as stopping the textures being displayed, after hours of staring at white box's >.<

Tempted to start working on the action functions right away so it can create a full pacman game for the iphone :)
Title: Re: MacOSX problems
Post by: RetroX on August 13, 2010, 02:18:00 pm
Why is it stretched like that?
Title: Re: MacOSX problems
Post by: retep998 on August 13, 2010, 02:26:22 pm
holy shit, enigma on iphone.
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 13, 2010, 03:01:06 pm
O_________O

YES, that should definitely have been both +1 (if either were). Nice catch. Holy f... Damn.
Anyway, great work.
Title: Re: MacOSX problems
Post by: notachair on August 13, 2010, 08:48:22 pm
I thought Apple doesn't allow intermediary wrappers or something like that for iOS apps?
Title: Re: MacOSX problems
Post by: Josh @ Dreamland on August 13, 2010, 09:13:15 pm
Shhh.
Title: Re: MacOSX problems
Post by: TGMG on August 14, 2010, 10:42:31 am
Why is it stretched like that?
Because the window size is set to the size of the iphone screen, so the room is scaled to fit into the window, just like when you resize the GM window, if you resized the gm window to the exact dimensions of the iphone it would look exactly like that ;) But if you are targeting iphone its best to use a view set to the size of the iphone screen so that it won't scale and will look normal.
I thought Apple doesn't allow intermediary wrappers or something like that for iOS apps?
They are very vague, I am tempted to submit and enigma app and see what they say, but unity3d's plan B for iphone development(http://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-update-iii/) was to do something very similar to what enigma does. The enigma part that comes with the game is just a c++ library and the code generated is all c++, I don't see how they could tell that it was written in enigma. If it wasn't allowed would that mean you weren't allowed to use a perfectly normal library of c++ functions :/ Unity apps are still being accepted to the app store also. But we will just have to see :)