Thread: Re: [Alephmodular-devel] Platform-independence structure (was: Developer Rant #1 :) )
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel
|
From: Timothy C. <tco...@ha...> - 2003-01-15 04:22:17
|
> Ok and as a final parting shot about the SDL stuff, it is completely > possible and practical to use, say, SDL_Video to insulate you against > the differences between DisplaySprocket and DirectDraw et al., or > between wgl and agl et al. (for attaching OpenGL contexts to on-screen > windows etc.), etc. without committing to using SDL_main to insulate > you from differences in application initialization between platforms, > and without committing to using SDL_event as the basis for your event > loop. (Perhaps Br'fin's negative experiences have primarily been with > these latter components.) So you can mix-n-match. :) Just to step into this debate a minute... I don't know all that much about SDL. If we made AM be largely SDL-dependent, would that mean that one would have to install SDL to run AM? That is, could all the relevant libraries (reasonably) be part of AM itself, or do they have to be installed separately? Also, what are the different important parts of SDL, how exactly could each be used within AM, and how much interdependence is there among them? The reason I ask these things is that I am leaning, along with Br'fin, strongly in the direction of having SDL be a separate platform. My main reasons are two: dislike of dependence on separately-installed libraries and dislike of SDL widgets. Thank you. Timothy Collett "There is a theory that states that if ever anyone discovers what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory that states that this has already happened." - The Restaurant at the End of the Universe, by Douglas Adams |
|
From: Br'fin <br...@ma...> - 2003-01-15 04:43:16
|
On Tuesday, January 14, 2003, at 11:21 PM, Timothy Collett wrote: > > Just to step into this debate a minute... > > I don't know all that much about SDL. If we made AM be largely > SDL-dependent, would that mean that one would have to install SDL to > run AM? That is, could all the relevant libraries (reasonably) be > part of AM itself, or do they have to be installed separately? Thanks to the magic of OS X bundles... It is possible to embed the necessary SDL Frameworks within a Carbon application that uses them. I made sure this was possible after shoe-horning SDL network code into AlephOne carbon. I too agree that we don't want extra downloadables/installs. I'm not sure if my use of the SDL libs in AlephOne is appropriately setup with respect to OSX's desire/interest to prebind its libraries though. :/ This is not a factor in my arguments against SDL as the base platform. -Jeremy Parsons |
|
From: Mark L. <hav...@ma...> - 2003-01-15 04:50:04
|
> I don't know all that much about SDL. If we made AM be largely > SDL-dependent, would that mean that one would have to install SDL to > run AM? That is, could all the relevant libraries (reasonably) be > part of AM itself, or do they have to be installed separately? Under OS X, SDL is contained within the application bundle (the Carbon version has been dependent on SDL for some time now). On other platforms, it would need to be installed as a system library. --Mark "Don't talk to me about murder. I invented murder." |
|
From: Br'fin <br...@ma...> - 2003-01-15 05:01:17
|
On Wednesday, January 15, 2003, at 12:46 AM, Mark Levin wrote: >> I don't know all that much about SDL. If we made AM be largely >> SDL-dependent, would that mean that one would have to install SDL to >> run AM? That is, could all the relevant libraries (reasonably) be >> part of AM itself, or do they have to be installed separately? > > Under OS X, SDL is contained within the application bundle (the Carbon > version has been dependent on SDL for some time now). On other > platforms, it would need to be installed as a system library. > > D'oh. I forgot about other platforms. :) -Jeremy |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-15 08:26:51
|
On Tuesday, January 14, 2003, at 10:21 PM, Timothy Collett wrote: > Just to step into this debate a minute... > > I don't know all that much about SDL. If we made AM be largely > SDL-dependent, would that mean that one would have to install SDL to > run AM? That is, could all the relevant libraries (reasonably) be part > of AM itself, or do they have to be installed separately? Others have talked about the situation on Mac OS X (can be bundled with the application). FWIW, Windows lets you put the .dll's in the file with the executable, which is how A1/SDL for Windows currently works. (No need to install SDL separately or place things in your system directories etc.) > Also, what are the different important parts of SDL, how exactly could > each be used within AM, and how much interdependence is there among > them? This is too big a question to really answer, but briefly, the purpose of SDL is to provide a common interface across a very wide variety of platforms for the following: * Video (i.e. gaining byte-level access to the framebuffer, blitting 2D surfaces, getting an OpenGL context, setting the screen mode and bit depth, etc.) * Window Manager (very little in here, mostly resize window and toggle fullscreen) * Event Handling (processing mouse clicks, keystrokes, etc.) * Joystick * Audio (very low-level access, you provide the bytes for the sound card to play back) * CDROM (using CD-ROM drive as CD audio player) * Threads * Timers (getting time values, waiting, and asking for periodic scheduling) * Endian-independence (byte-swapping) * Main (providing a single source-code entry point for you so you don't have to worry about things like WinMain() on Windows) Those are in the core "SDL". Each is essentially an independent subsystem which can be used with or without the rest. SDL_net contains, essentially, nonblocking TCP and UDP sockets, select() (i.e. wait for data arrival etc.), and DNS name-to-host resolution. (Many platforms have BSD sockets or something a lot like them, so this isn't too exciting in most cases, but it does serve to hide the little differences. Also, significantly, it works in Mac OS 9, which does *not* have a sockets-like programming API on its own.) SDL_net requires SDL, but only (as noted) for SDL_GetError() and SDL_SetError(). I suppose you could probably provide your own implementations for those symbols if you really wanted to dump SDL and only use SDL_net. SDL_image lets your code load the following image formats into an SDL surface, suitable for byte-level inspection/manipulation (e.g. setting up in an OpenGL texture) or blitting with the SDL Video subsystem: BMP, PNM, XPM, LBM, PCX, GIF, JPEG, PNG, TGA. I suppose it requires the SDL Video subsystem. (From the SDL_mixer site:) SDL_mixer is a sample multi-channel audio mixer library. It supports any number of simultaneously playing channels of 16 bit stereo audio, plus a single [stereo] channel of music, mixed by the popular MikMod MOD, Timidity MIDI, Ogg Vorbis, and SMPEG MP3 libraries. (end quote) It does require the free SMPEG and libvorbis libraries for MP3 and Ogg Vorbis support. (MikMod, which can play virtually any file in the (large) MOD family, is built in directly.) See www.libsdl.org for more information. > The reason I ask these things is that I am leaning, along with Br'fin, > strongly in the direction of having SDL be a separate platform. My > main reasons are two: dislike of dependence on separately-installed > libraries and dislike of SDL widgets. Well I think we've talked about the first one pretty well (though I don't know how it works in Linux etc., IIRC in Mac OS 9 you can also put the library in the folder with the application and have it work - oh right, Mac OS 9 supports bundles too, so the user wouldn't even have to see it). Anyway I assume the plan is probably to use SDL_net anyway...? which means some of the libraries will be there regardless. I'm not sure what you guys are talking about with this SDL widget business. Though there are several cross-platform, typically game-oriented GUI libraries out there that are built on top of SDL, SDL itself has no "widgets". The stuff used in A1 was written by Christian Bauer for A1 and tweaked up a bit by me. Woody |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X