PDA

View Full Version : KOSX



DanPotter
November 23rd, 2004, 19:29
I was debating with myself whether this should go in the PC/Mac emulator section or the development section, but I figure in the long run it's a lot more applicable to the latter... so here it is :)

For those who aren't on the KOS devel list, I've been working on a "port" of KOS to Mac OSX. It started out as a port of Parallax, my DirectX-like graphics lib I've used for FoF and future projects. It's evolved a little past that though, and when it's more complete it may be a very interesting way to dev for the DC without most of the normal pains of cross-compiling and debugging.

It uses OpenGL to emulate a PVR (approximately) and will soon emulate the snd_stream and sndsfx_* APIs using CoreAudio. I've got an OGG player going, just haven't integrated the thunking functions in yet.

I've been able to get it running about 4 Parallax demos and 1 Tsunami demo so far, with more on the way. Some screen shots in case anyone is interested:

http://gamedev.allusion.net/softprj/parallax/osx/

I'll be posting all the code for it when it's a little more complete as well, and some of it will be integrated back into the trunk since it's beneficial even for DC (like endian-agnostic font loading for Parallax).

I should also say that it's not out of the realm of possibility that someone could take this and make it a basis of a Win32 KOS port. You'd have to rip out some of the "boilerplate" code, the audio code, etc... but it'd probably be easier than starting from scratch.

Vorrtexx
November 25th, 2004, 07:59
gotta love that MAC interface.

Sounds cool. wasn't there something similar to this for the PC, called KOSine? But I don't think it had the PVR emulation incorporated into it.

DanPotter
November 25th, 2004, 12:18
Yeah, I remember KOSine. It was a little different though, I think the goal there was to actually make it where you could more or less compile KOS programs without changes and have them run. My efforts aren't focused on that as much as on speeding the ports of the 3D and sound, and soon the controller inputs. Which covers the bulk of the code in an average game anyway.

In KOSX I'm not providing a PVR compat layer really, it's a Parallax port. Parallax is very similar to the PVR API but it's got some important differences that factor out some of the DCisms. :)

A lot of KOSisms like the threading functions are defunct now anyway -- you can now use pthreads (or a lot of them anyway) in the latest KOS. Just wish there was an easy, portable way to hijack libc functions like fopen consistently... one of the pieces I'd really love to port over is the VFS :\

wraggster
November 26th, 2004, 12:44
would this enable mac users to code for Dreamcast or is it to enable KOS to have Mac Releases.

sorry if i misunderstood the topic :P

been a long day

warmtoe
November 26th, 2004, 15:15
gotta love that MAC interface.

Sounds cool. wasn't there something similar to this for the PC, called KOSine? But I don't think it had the PVR emulation incorporated into it.


Yes - KosINE was the thing I was working on - and, as Dan says, it was mainly intended to allow for re-compilation of DC apps for the PC.

BlackAura was taking it one stage further a while ago - not sure what happened to that project.

DanPotter
November 26th, 2004, 21:49
KOSX is mainly a porting tool for getting DC programs over to OSX in a reasonable amount of time. But by "reasonable" I mean "if written correctly, instantaneously", so one can do most or all of the development work for a game or app on a Mac, and then recompile under regular KOS to get DC support.

It's not quite so straightforward or easy as that of course... :) But that's the theory.

I now have the snd_stream and oggvorbis functions ported over to the newest version. If the previous screen shots didn't set anyone on fire, try these :D

http://gamedev.allusion.net/softprj/parallax/osx/fof/

EDIT: Err.. I should also say, since screen shots don't have sound, that these also have proper audio as well. Not 100% smooth and still has some GL artifacts (see the logo screen) but getting there!

DanPotter
November 28th, 2004, 01:07
I've posted 9 more screen shots to the above URL that show pretty much all of FoF working almost flawlessly. The biggest problems remaining now are weird GL translucency layering bugs. It has full bgm and sound effect support now, and is actually playable on typing mode. I'm going to have to go back and add in some code to let you play normal controller mode with a keyboard since I don't have any sort of joystick, pad, or controller to test it with :D

Anyway, as a proof of concept, I'd say this KOSX thing is almost ready for a preliminary source posting :)

c99koder
November 28th, 2004, 10:06
Looks awesome! I guess I'll look into switching to parallax sooner than I thought.. hehe

-Sam

c99koder
November 28th, 2004, 14:22
I miss the red / green / blue buttons from the cocoa OpenGL example :P I was looking at the original in XCode today while trying to make DCSquares more "maccy". Now I have a menu bar, and an option that pops up an alert panel! w00t! Obj-C is scary, i've never seen so many []'s before :-/

DanPotter
November 28th, 2004, 22:21
Heh, I tried to get the OpenGLView to work with the new method of driving the window but it wasn't giving me any love.

I agree about ObjC. I used to really like ObjC back when all we had was C and the bad old almost-original C++ dialect. I played around with it quite a bit under Linux. In some ways it is still highly superior to C++, but it's showing its age. For example there is no automated garbage collection and no way to emulate it. In C++ you can at leasy use auto-destructing smart pointers and such, but in ObjC all you have is 'autorelease'. I'll give them that they have ref counting in NSObject (the main base class) but the way they handle the actual garbage collection is to create an AutoreleasePool around usages and release everything that's marked autorelease. Like taking a sledge hammer to fix a watch or something :) There's like a 10-20 line doc about the semantics for memory management in ObjC, and I'm sorry but you just shouldn't need to worry about that sort of thing in a modern development environment.

And exceptions only make it worse. I hear that they have some weird special case rules where if you throw an exception, it'll release AutoreleasePool objects when it unwinds the stack, but nothing else.

I dunno though, I just use it to set up and get out as quick as possible into C++ land. That and for input event handling. KOSX actually has a full maple-compatible system :D

c99koder
November 29th, 2004, 00:47
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:

http://www.c99.org/~ssteele/dcsupdate-thumb.jpg

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
November 29th, 2004, 02:54
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.

Hey, it's ok, we're like the old geezers that no one wants to tell to shove off :D (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 :o

Darksaviour69
November 29th, 2004, 05:31
So, could this also mean commical HB games could be released that worked on both the DC and OSX? that would be cool!

DanPotter
November 29th, 2004, 11:29
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
November 29th, 2004, 11:37
ahhh...but what i mean is a hybrid CD that can play on both dc and OSX?

c99koder
November 29th, 2004, 11:56
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
November 29th, 2004, 12:09
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
November 29th, 2004, 14:25
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
November 29th, 2004, 15:00
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
November 29th, 2004, 17:39
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.

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

Darksaviour69
November 30th, 2004, 04:49
about the hybrid idea:

u make 2 good points, but about the shareware, many shareware companies also offer a CD of the game also well as a download. some people like to have cd and case, to add to there collection.

i used to be a mac man, but support in N.ireland sucks, and the game market is so small, i remember games that were 2 years old were still full price £30, while the p.c. versions were £5, that sucked. the game market is so small that it would be easyer to get noticed on it than the P.C. market.

most dc hb games don't even use a 1/4 of the disk so putting 2 version on one disk would not be a problem size wise, and if you port goes to plan, making a mac version of a dc hb game would not much time.......but u would have to to double the testing

there are pros and cons, but increaseing you potential market is a good thing.... sorry i seem to be going around and around and around

DanPotter
November 30th, 2004, 11:29
u make 2 good points, but about the shareware, many shareware companies also offer a CD of the game also well as a download. some people like to have cd and case, to add to there collection.

That's true...


i used to be a mac man, but support in N.ireland sucks, and the game market is so small, i remember games that were 2 years old were still full price £30, while the p.c. versions were £5, that sucked. the game market is so small that it would be easyer to get noticed on it than the P.C. market.

It's not so different over here. You really don't get a Mac to play games on it (one reason I got one: I have consoles at home and a pretty beefy PC at work if I need gaming :)). That may change if they can get their act together and optimize the sw->hw path a bit more in the 3D world, as well as getting some reasonable documentation. But yeah, I went to look at e.g. Neverwinter Nights (some friends play that regularly) and it's still like $50 at the store. And how long as it been out?

The small market is nice though if you are trying to write games for it. People who happen to have them seem to be pretty happy to get what they can, especially more casual games that don't take 80 hours to complete.


most dc hb games don't even use a 1/4 of the disk so putting 2 version on one disk would not be a problem size wise, and if you port goes to plan, making a mac version of a dc hb game would not much time.......but u would have to to double the testing

Actually I think this is a lot more convincing reason to me than the two I gave. Completing and testing a game on a single platform is hell when you don't have a full QA department to work with (and purgatory even if you do) but trying to test two platforms at once would be even worse.

c99koder
November 30th, 2004, 13:20
The small market is nice though if you are trying to write games for it. People who happen to have them seem to be pretty happy to get what they can, especially more casual games that don't take 80 hours to complete.

I can vouch for that. I've gotten over 300 downloads from Mac users, vs 150 or so for Windows, and around 70 for the Dreamcast. Noone left any feedback on versiontracker, so I don't know if they actually enjoy the game, but a lot of Mac users were at least willing to check it out :)

-Sam

DanPotter
November 30th, 2004, 14:45
Wow, interesting... so how did you get the word out about it to begin with? Versiontracker?

c99koder
November 30th, 2004, 23:08
Yep, just submitted it to versiontracker. I'm not sure of a similar free Windows site, so i wouldn't know where to begin promoting the Windows version. It's certainly not worth paying cnet for a download.com listing. Once I get everything sorted out for the next release, I'll try submitting to macupdate, too, and see what they think. It's so much easier to promote freeware for the Mac than Windows. I guess freeware is a foreign concept to Windows users.. it's either shareware or commercial :(

-Sam

DanPotter
December 1st, 2004, 03:21
Yep, just submitted it to versiontracker. Â*I'm not sure of a similar free Windows site, so i wouldn't know where to begin promoting the Windows version. Â*It's certainly not worth paying cnet for a download.com listing.

You don't want that anyway. I've heard stories about people having their programs submitted to download.com "for" them, with spyware attached. I'm sure the spyware authors did it, but it's not a super reputable place to get stuff (to me) after I read that.


Once I get everything sorted out for the next release, I'll try submitting to macupdate, too, and see what they think. Â*It's so much easier to promote freeware for the Mac than Windows. Â*I guess freeware is a foreign concept to Windows users.. it's either shareware or commercial :(


I believe you misspelled "freeware or pirated" :D But yeah... anyway, let me know how that works out for you :)

c99koder
December 31st, 2004, 12:04
Since 1.4 has been out for a bit, here's a quick followup about the differences between VersionTracker and MacUpdate and some other random stats:

VersionTracker (http://www.versiontracker.com/dyn/moreinfo/macosx/25139) downloads: 439, rating: 5 stars, feedback for the rating is a little 1-liner

MacUpdate (http://www.macupdate.com/info.php/id/16784) downloads: 492, rating: 3.5 stars, feedback is a nice, in-depth review with suggestions for improvements.

MacUpdate also has a much nicer page layout for both their listings and their developers section, but only allows 1 screenshot instead of VersionTracker's 2.

I also submitted the linux version to freshmeat using the same description as the mac listing (omitting the macintosh sentence), and they edited it to be incorrect. They changed "Compete with players world-wide in the online high score ladder!" to "Internet play is included." which is not true, and some people expecting internet play will be quite disappointed :(

Statistics from access_log (this doesn't include a few windows sites that provide mirrors):
Mac: 1144 downloads
Linux: 127 downloads
Windows: 112 downloads
Dreamcast plain files: 44 downloads
CD Image: 43 downloads

-Sam

Edit: I was skimming the top referrers, and looks like someone submitted DCSquares to macgamefiles.com (http://www.macgamefiles.com/detail.php?item=18502). Downloads: 67. It got 4 stars there, another 1-liner review. Pretty cool I guess :)

DanPotter
December 31st, 2004, 19:43
Thanks for the update.. interesting stuff. Any word on how the Windows versions are doing?

c99koder
January 1st, 2005, 23:00
I still haven't found any decent sites to promote the Windows version. I have listings on winsite.com and freewarefiles.com but the downloads are pretty small there. The high score table is still dominated by Windows, though, so the Windows users that are playing are much more likely to submit scores than other platforms. Though, it was nice to see the first non-beta-tester linux score posted a few days ago :)

Winsite.com (which mirrors the files so they can't be counted from access_log) downloads: 102. But that's both 1.3 and 1.4 combined. Noone's left any ratings or feedback at the Windows sites.

-Sam

DanPotter
January 2nd, 2005, 22:30
Don't mean to toot my own horn too much here ;) but I made an OSX dev forum on my phpBB to discuss this sort of stuff. So we can stop being off topic on DCEmu :D

http://www.cagames.com/phpBB2/viewforum.php?f=9

Darksaviour69
January 4th, 2005, 05:33
i just want to point out that the dc downloads might be missleading as sbiffy.com has sbi of dcsquares (i think most people use dream inducer these days, i do) and we (dcemu) have a download of it too. not saying its as high as the other downloads but Dreamcast plain files: 44 downloads CD Image: 43 seems a bit low. btw will done c99koder ;)

c99koder
January 5th, 2005, 17:52
Yep, the SBI downloads would probably even out the Dreamcast version quite a bit. I have a link to sbiffy.com on the downloads page that has been followed 16 times (tracked by AXS). I would assume direct visits to sbiffy.com and dcemu would produce a lot more, but I don't have (and don't really want) access to that data.

I don't put a lot of value into the download stats, they're just kind of fun to look at. I find the referrers a lot more interesting, so I can get an idea of who's interested in the game and what they might like improved.

I do occasionally look at the hostnames of visitors (only if something really interesting catches my eye on another staticstics page) to see who's spending time reading my site instead of working ::) It's always fun to see an ibm.com or microsoft.com or other big company in there, 'cause I know that at least one person that works there likes my games :) I also like looking at the countries the visitors are from, it's cool to see someone in Tokyo, Japan download DCSquares.

-Sam

Christuserloeser
January 30th, 2005, 19:09
...then, DCEvolution.net released a CDI with DCSquares too... plus yep, I guess you're missing a lot of download counts through sbiffy.com

edit: Some DC users might even have downloaded the windows version only because there too lazy to burn a CDR, so I'd take that into account too ;)

Ender
February 7th, 2005, 23:33
Well, I just got an ibook, and this would be really handy in speeding up my processes. So is there source kicking around yet, or are you still holding it?