Sphere Mac Version (PPC & Intel, testing)

[Rhuan]

Making use of what I picked up in my last attempt, I have got sphere 1.4 compiled and "running" on osx 10.4.11 ppc.

I've worked out how to deal with endian issues (though I'm not sure if I've caught them all yet), I've sorted the sound, but... Graphics present major problems, colours are all messed up, I'm using the SDL screen handling in the sphere source, but graphics are totally "dodged" I'm not just talking about things loaded from files so it isn't exclusively an endian issue, graphics primitives don't work, full stop, Rectangle(x,y,w,h,c), Triangle(x,y,w,h,c), I get absolutely nothing (text and windows do dispaly just with messed up colour, so it's not a flipscreen issue)

Anyway, I'm going to try and fix this, but I'm not sure exactly how atm.

(edit: topic title now changed to reflect status - neo)

[Radnen]

Ohh! Supply a screenshot! I'd like to see what the colors look like!

[N e o L o g i X]

let me know what your procedure was so i can do it for intel and/or ub. do you have an editor made or should i do one from scratch/wait for one of the cross-platform ones to be ready?

[kamatsu]

let me know what your procedure was so i can do it for intel and/or ub. do you have an editor made or should i do one from scratch/wait for one of the cross-platform ones to be ready?

The procedure for PPC would be different in many cases than for Intel. Intel macs will have NO Endian issues where as they will abound in PPC.

If I had a macbook handy, I could already compile sphere for it, but I don't.

I imagine the procedure is something along the lines of:

* Install XCode
* Build and install Audiere
* Build and install Corona
* Build and install SDL
* Build and install zlib (if it isn't already)
* Build Sphere

Then it's just a matter of grabbing the relevant shared object files plus sphere and chucking them into a zip archive - Rudimentary sphere for Intel Mac.

Universal Binaries would require using a whole pile of weird mac libaries and would probably take months/years to do (unless of course, all UBs do is run a native intel binary with endian emulation on a PPC, in which case it wouldn't be overly difficult)

But otherwise, Easier to just make two seperate compilations.

You may be able to compile wxEditor for Mac but otherwise you're screwed until either Tobi or I finish our editor projects. Tobi is using wx, and I'm not sure if that integrates natively with the Mac GUI but I'm using GTK which would mean you'd have to run my editor in an X11 session unless you did some funky linking and wrapping. I suppose that's not a major deal, particularly seeing as in Leopard at least, the X11 session is pretty seamless.

Also, WINE is available for Intel Macs so... there is some hope for sphere on Mac.

[N e o L o g i X]

ATM i'm on 10.4.11. can't afford leopard yet. I have some experience working with xcode trying to port vgmtool to mac (the hard part is the interface; I can usually find the cross-platform equivalents of certain win32 api functions like multi-byte char handling). next time my mac is online i'll DL all the necessary code & libs.

i'll attempt to start a mac gui for the editor as well, but may keep it slow for a bit while the other editors are in "active" development. as for display drivers, is it recommended to have software AND openGL display drivers available or should we (mac users such as myself & rhuan) stick to only one of the two?

[Kyuu]

as for display drivers, is it recommended to have software AND openGL display drivers available or should we (mac users such as myself & rhuan) stick to only one of the two?

Both are possible within SDL, so both should be considered.
Actually I'm currently working on adding OpenGL support, as well as scaling (like it's in the Windows version) to the Linux version, so it might be better if you two wait until I've finished (give me a few days) and take the Linux version as a base for the Mac port.

[kamatsu]

I've worked out how to deal with endian issues (though I'm not sure if I've caught them all yet), I've sorted the sound, but... Graphics present major problems, colours are all messed up, I'm using the SDL screen handling in the sphere source, but graphics are totally "dodged" I'm not just talking about things loaded from files so it isn't exclusively an endian issue, graphics primitives don't work, full stop, Rectangle(x,y,w,h,c), Triangle(x,y,w,h,c), I get absolutely nothing (text and windows do dispaly just with messed up colour, so it's not a flipscreen issue)

I've used SDL (frozen bubble) fine on a PPC iMac, so I am assuming it must be some issue in Sphere.

[Rhuan]

Endian issues are no problem at all. The problem is something else, it's something to do with the sphere interface to sdl, mac doesn't like it for some reason...

EDIT Slightly messed up colours, but rectangles now work. Can I ask, is the file "sdl_video.cpp" used in any active version of sphere? Because:

Code:

typedef struct tagRECT {
    int top;
    int bottom;
    int left;
    int right;
  } RECT;

and then later on, when storing the clipping rectangle to be used in clipping a rectangle in fact:

Code:

RECT rect = { c_x, c_y, c_x + c_w - 1, c_y + c_h - 1 };

So, top was c_x, bottom was c_y, left was c_x+c_w-1, and right was c_y+c_h-1. Just think about that... The left hand edge of the clipping rectangle is one pixel in from the right hand edge of the screen for a start...

[Rhuan]

let me know what your procedure was so i can do it for intel and/or ub. do you have an editor made or should i do one from scratch/wait for one of the cross-platform ones to be ready?

I think for the time being it would be best to work through it as one project rather than having us both trying to deal with the same problems, I think it would be best to forget about universal binaries, as there is a lot of endian dependent bits in the sphere source, but an intel compile should be fine, the way I'm doing things you should have to just change one flag and click compile, don't start downloading stuff, I should be able to send you xcode projects of sphere and every one of it's dependencies. (I'm trying to make this neat, no fiddling around in the terminal, and no installs into /usr, the way I'm doing things atm, the required libraries all go in ~/library/frameworks).

Regarding editors, nothing yet, I'm working on the engine first, if you'd like to make one that would be great, otherwise, I'll work on one myself if/when I get the engine sorted.

[N e o L o g i X]

send away at your leisure.

neoexmachina at gmail dot com

[Vexo]

send away at your leisure.

neoexmachina at gmail dot com

Obfuscating your address seems rather pointless when there is an unmolested version (complete with mailto: link) under your avatar in every one of your posts.

[Rhuan]

If any current devs could get back to me regarding the status of the sdl files I would appreciate it.

[N e o L o g i X]

@vexo: i'm normally on my cell, and the WAP version of the page only shows user name. as such, i've pretty much completely forgotten what all the mini-icons under my particular user name are.

[Rhuan]

I've sent you the stuff.

I'm still wondering if anyone could comment about the state of the SDL files.

[Kyuu]

I doubt they are tested for years, that's why I suggested to stick with the Linux version of the video implementation, which works definitely.
The SDL and the Linux versions differ in the video implementation, so there is a good chance for bugs in the SDL version.