KOSX

[c99koder]

I spent the day playing around with it. I know nothing of ObjC's syntax, so it was basically a lot of google and letting XCode's autocomplete guide me, but I actually got something productive out of it:



One of those typical "A new version is available!" dialogs that every OS X app seems to have. It also seems that my cute little http library is pointless on OS X, 'cause the string class has a constructor that'll fill itself w/ the content of a URL! Those crazy guys at apple.. I didn't use it though, I'll stick with my http_get_file for now

KOSX looks like fun. I had a very hard time trying to get SDL to play nice with cocoa, it's pretty hacked together. I wanted the update "alert panel" (eek I'm talking like a mac developer) to slide out from the top of the window, 'cause I think that effect is really neat, but SDL doesn't let you get a handle to the window it creates :-/

Not to get further off topic, but have you played around with Interface Builder yet? I don't know the syntax to access the objects it creates. I created a new class called UpdaterClass, and I know it creates an instance of it.. but I don't know how to reference it outside of itself or another class by adding it to an outlet. So I did a quick hack and made it set a global pointer to "self" when it gets created, but I'd really like to know the correct way to handle that.

-Sam

[DanPotter]

[quote author=c99koder link=board=Dev;num=1101259752;start=0#10 date=11/29/04 at 00:47:51]Not to get further off topic, but have you played around with Interface Builder yet? Â*I don't know the syntax to access the objects it creates. Â*I created a new class called UpdaterClass, and I know it creates an instance of it.. but I don't know how to reference it outside of itself or another class by adding it to an outlet. Â*So I did a quick hack and made it set a global pointer to "self" when it gets created, but I'd really like to know the correct way to handle that.[/quote]

Hey, it's ok, we're like the old geezers that no one wants to tell to shove off (sorry everyone...)

My first Xcode project, before I started in on this KOSX stuff, was a GUI app to interface with OpenVPN. I use it in a road warrior configuration, which is pretty awesome when your city is covered in wi-fi hot spots. I'm still planning on releasing this thing when it's a little more done, but it does work.

You had the right idea originally on the IB objects actually. That's how you're supposed to do it. I can't remember exactly what goes as an attribute and what goes as an outlet. But you build the objects in IB and they get serialized into a NIB file. This is then loaded at runtime (or you can do it manually) and all those objects are once again instantiated in the form you froze them in. Connections are set up by the NIB loader automatically. So the key is to make sure IB knows about the classes you want to interface with. The simplest thing to do is make a Controller object as a subclass of NSObject on the Classes tab of the IB objects window and then go from there. You get an awakeFromNib message when it loads.

I recommend this tutorial in the docs... Go to Library->Cocoa on the left side of the Help->Documentation window; then Getting Started with Cocoa. There are a few good links on there about Cocoa, ObjC, etc, from a high level. Then hit the link "Developing Cocoa Objective-C Applications: A Tutorial" near the top, which has a step-by-step tutorial to follow.

I sure wish the rest of Apple's docs were as nice as these -- the farther you get from this basic "build an app" path, the worse it gets. By the time you're down to the low level docs about sound and such, you're reading Quicktime programming guides from 1998 for MacOS 9, with examples in Pascal, and which talk about resetting your A5 register after your callback that happens in an interrupt context

[Darksaviour69]

So, could this also mean commical HB games could be released that worked on both the DC and OSX? that would be cool!

[DanPotter]

If they're written correctly, yeah. That's the main reason I'm making this thing, that it makes it easy to compile on either platform so I can work on it when I don't have a DC around. As a side benefit, the output of KOSX may eventually be usable enough for selling as Mac games. It's pretty straightforward to convert from PVR usage to Parallax usage anyway, so it shouldn't be much trouble to port existing things.

[Darksaviour69]

ahhh...but what i mean is a hybrid CD that can play on both dc and OSX?

[c99koder]

Dan: Thanks for the tutorial link, I'm gonna play around with it today The docs I used so far were alright, but I didn't go too deep. I just fired up the class browser, found the class I wanted, and clicked the book icon. The "Most commonly used methods" section was great, 'cause it usually had what I needed.

Darksavior69: The DCSquares cd image is a hybrid that'll work on PC, Mac, and Dreamcast. I'll be adding linux to the mix w/ the Loki Installer in the next version.

-Sam

[c99koder]

When I was your age, we didn't have self-booting tools, and we had to compile our toolchains from scratch! Darn kids and your music.</old geezer>

Anyway in case anyone is curious, here's the bash script I'm using to generate and burn data/data Mac/Joliet hybrid CDs:

#!/bin/sh
. /sw/bin/init.sh
PROD=DCSquares #The directory the data is in, also the volume name
mkisofs -G IP.BIN -l -R -J -apple --osx-hfs -V $PROD -o session1.iso $PROD
dd bs=1024 count=36 < session1.iso > session2.iso
dd bs=1024 count=564 < /dev/zero >> session2.iso
cdrecord dev=IODVDServices speed=16 -multi -xa1 session1.iso
cdrecord dev=IODVDServices speed=16 -eject -xa1 session2.iso
rm session1.iso
rm session2.iso

This assumes your mac has a combo drive or super drive, I don't remember the device name for plain old cd burners.

-Sam

[DanPotter]

Oh I see .. yes, I see no technical reason why not. It might end up being two totally separate pieces of code and sets of data files, but you could do it. You might be able to get away with one set of data files depending on the game design.

There are a couple of reasons why that doesn't really make as much sense though:

1) If you sell PC-style shareware online (Mac, PC, etc) then it's a lot easier to download it and play it than to have to ship a CD, box, etc and then install it. For the DC this isn't true because you have to have it on a CD to play it and it's a little tough to burn one. Selling retail is a whole 'nother ballpark that none of us are likely to break into.

2) The Mac and DC markets don't really overlap a whole lot (maybe a tiny bit, but probably statistically insignificant) so to me it seems like you'd want to handle each separately to best market to it, distribute, do support, etc... for example if we made a homebrew DC game and had GOAT Store publish it, they are probably not as interested in trying to deal with Mac support (and they'd end up having to do some of that). Also we'd have no real hard statistics on who bought it for what platform, which are somewhat important numbers

On the other hand you had MetaFox's idea that maybe the hybrids would raise DC awareness and popularity, and maybe that would happen. I wouldn't bet too much on it still though (sorry Meta )

[scherzo]

This is really a great idea. I've gotta tell you I'm rather sick of powering on my DC over and over everytime I want to test some code, AND we'll finally be able to do step by step debugging to find logical bugs. This should really aid development. At least it will for me. I'd be willing to help on a Windows port if you're open to a hand.

Besides your parallax lib, how many of the libraries in kos-ports will you attempt to get ported? If you properly emulate the snd_streem_ functions, libraries like mp3 and ogg should work fine, right?

By the way, I've noticed slinkie in KOS svn. Is this intended to be a "modern" replacement for dc-load? Is it usable yet?

[DanPotter]

[quote author=scherzo link=board=Dev;num=1101259752;start=15#18 date=11/29/04 at 15:00:27]This is really a great idea. I've gotta tell you I'm rather sick of powering on my DC over and over everytime I want to test some code, AND we'll finally be able to do step by step debugging to find logical bugs. This should really aid development. At least it will for me. I'd be willing to help on a Windows port if you're open to a hand.[/quote]

A couple of people have expressed interest in making a Windows version actually. Seems like it might be better to start with KOSine and work from there on that front, but it may also be pretty far behind now (dunno the status of it but I haven't heard anything in a while).

One of the problems you'll run into is that OSX is actually a POSIX OS for the most part, and KOS tries to be as well. So there's a lot of functionality that "just works". For example if you use pthreads in KOS (with the latest svn versions) then it'll probably just recompile under OSX and work fine. Not so for Win32.

Might be interesting though.

Besides your parallax lib, how many of the libraries in kos-ports will you attempt to get ported? If you properly emulate the snd_streem_ functions, libraries like mp3 and ogg should work fine, right?

I've currently got:

- Parallax
- Tsunami
- liboggvorbisplay
- snd_sfx_* and snd_stream_* functions
- Maple (yes, you read that right ) with kb support only for now
- Png
- Jpeg
- Zlib (this may not be needed, OSX seems to want to link its own zlib anyway)
- Random KOS functions (assert_msg, dbglog, mat_*, etc)

liboggvorbisplay was almost a direct port-over, I mainly modified it not to use its own thread since OSX starts an audio callback thread anyway.

By the way, I've noticed slinkie in KOS svn. Is this intended to be a "modern" replacement for dc-load? Is it usable yet?

Yes, and no (respectively). It is capable of uploading code and doing a basic file server/console. It actually mostly uses the dcload-ip protocol, which is kind of where the problems come in. There are some things in dcload's protocol which just make the communication non-deterministic unfortunately (and thus you get connection losses, lockups, etc). I'd intended it to correct that but have been too lazy to finish it so far