For example, instead of outputting the code to handle SPRITESTOUCHING every time that command is used, the runtime should have a method to handle that command, which can accept parameters such as which sprite number is involved.
Indeed. Something like that could be whipped up.
Some things that you take for granted in Cocoa are written differently in REALbasic. These things must be rewritten in the runtime to act the same as in REALbasic. For example, although Cocoa may have some better way to determine sprite collisions, we must determine them identically to how the current REALbasic Runtime does so. Otherwise, cross-platform computer & phone games will not work correctly, and you will not be able to rely on the built-in debugging.
It'd just have to be made to work exactly alike. Though Xcode comes with a powerful debugger.
Another example would be networking code. We must implement the EZProtocol system so iOS and computer versions of the game may interoperate with command sockets. This should be done beforehand.
I don't even want to think of networking. Networking works on the iPhone quite well but... I have no idea how it'd be paired to work with the EZ Protocol.
For making iPhone compatible games, it'd probably be best to not have networking enabled till it was sorted out.
The biggest problem I can see right now is math support. SilverCreator uses left to right processing of math, while other languages will typically process in PEMDAS order.
PEMDAS is the way to go. It really screws me up when I'm coding in Sc and it doesn't follow that. Especially when programming something math intensive.
-Gan
We can't use any Xcode stuff though except for the command line compiling/app signing stuff. The idea is the user never has to touch Xcode.
True, after a google search I've found ways to make and run an iphone app via command line though... if they had the source they could easily switch from Sc to learning Obj-C in Xcode.
EZ Protocol is just on top of regular TCP/IP. I don't think it would be too hard, but it would be something for the runtime.
I'm mostly worried about how time outs, data encryption, and the handshake would work.
Except if I switch SC to PEMDAS, all existing games will break. I also can't have PEMDAS for iOS and left to right for computers - then you can't easily compile the same game for both. Even if I have a checkbox for each game - "Use PEMDAS" - what if they check it and want to compile for iOS?
Best chance is to just take the jump to PEMDAS. Existing games will either have to be compiled with an older version or updated to support PEMDAS.
-Gan