MacOSX problems

[TGMG]

I have only made 2 changes to the compiler to get it to compile and run on mac:
OS_Switchboard.h:

#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:

-    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:

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

[Josh @ Dreamland]

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.

[TGMG]

Ah thanks

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.

[Josh @ Dreamland]

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.

[TGMG]

Thank yeah i did eventually manage to fix that one but it was just replaced by another:

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

As for the graphical side of things I managed to get cocoa and opengl working

Seems to work pretty well, now time to work on input and window functions.

[Josh @ Dreamland]

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.

[TGMG]

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:

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.

[Josh @ Dreamland]

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?

[TGMG]

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:


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.

[Josh @ Dreamland]

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.

[TGMG]

I'll be on enigma irc

Also finally got textures working on the iphone


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

[RetroX]

Why is it stretched like that?

[retep998]

holy shit, enigma on iphone.

[Josh @ Dreamland]

O_________O

YES, that should definitely have been both +1 (if either were). Nice catch. Holy f... Damn.
Anyway, great work.

[notachair]

I thought Apple doesn't allow intermediary wrappers or something like that for iOS apps?