2013/5/5 Thien-Thi Nguyen <t...@gnu.org> > I think that the simplicity could convince some people to employ > slayer to their multimedia projects -- because it requires no > additional setup and works out of the box, so for instance it could > be quite easily employed to implement the picture language from SICP > > Probably the valuation of simplicity depends largely on point of view. > > As the author, for you it is simple and transparent. > > For the newcomer, it is opaque, and its simplicity is to be determined. > > I can't say that my judgements are unbiased, but I claim that the interface of slayer is objectively simpler than the one of SDL (and consequently -- Guile-SDL) -- obiously to the extent to which the comparison makes sense. Slayer is an event-driven abstraction layer over SDL (and OpenGL). Thus, the whole application that, for instance, plays a certain sound when a key is pressed, would look like that in slayer:
(use-modules (slayer)) (define sound (load-sound "sound.wav")) (keydn 'esc quit) (keydn 'm (lambda()(play-sound! sound))) I dare to say that this is much simpler than in raw SDL, where one needs to write his own loop to handle the input, not to mention the fairly complicated initialization routines. Working with images would require employing the widget framework (I admit that the interface is a little unintuitive at the moment, but it can be improved easily) (use-modules (slayer) (slayer image) (widgets base) (widgets bitmap)) (keydn 'esc quit) (define image (load-image "image.png")) (add-child! *stage* (make-image image 70 20)) The above code creates an image that can be dragged around the screen. I agree that it's counterintuitive (because nothing in the code suggests that the image is draggable) and could be done better -- and that without this example it would be difficult to figure out how to do that. But still I dare to claim that it's simpler than if one had to do it in pure SDL (and he would probably end up reimplementing slayer) Things get more complicated when one wants to manually draw the stage, because then he needs to set-display-procedure! (the way it's done in the pong.scm demo). But as I reckon from my experience with SDL and OpenGL, it's still simpler than figuring out the setup for double buffered mode and making things in the right order (and remembering to glFinish()). Also, doing some more sophisticated timing requires creating a new thread, which -- fortunately -- is quite simple in guile. (I admit, however, that because of that reason, the included demos may be non-thread-safe) As Guile-SDL maintainer, i wonder what i can do to attract the same > audience, whether or not it is worth expending the energy to do so, in > what ways have i failed to encourage organic additive (as opposed to > parallel) hacking, and how wonderful/terrible it is for GNU to be so > loosely coupled. > My project transformed and evolved from a C++ OpenGL engine that I've been working on a couple of years ago, and then abandoned it. Years later, the input system that I implemented (array of approx. SDLK_LAST SCM thunks, supported by a few arrays of C function pointers and a loop) turned out to be still useful. Anyway, should you wish to rebase SLAYER onto Guile-SDL (which has > surmounted the documentation, autotools, and certain libguile churn > issues), i, too, am happy to help out. (Maybe we can work together.) > I'd really love to work together! However, there would be very little point in rebasing slayer onto Guile-SDL because of the project's goal, which is to supply a standalone executable that embeds (rather than extends) guile, and can therefore be thought of as a separate environment. I remember Ludovic reprimending me for embedding guile instead of extending it, but I believe that slayer is a humble exception from that otherwise notable rule. Perhaps the difference is psychological rather than technical, and perhaps one day someone decides to transform slayer into a loadable guile module, as it should be a truly trivial task, but for now I think that it will be easier for people to understand that they get "something similar to flash player" (it is for me :D) Besides, I really don't think that we would gain anything by taking the code that works and rewriting it to something else. If you are willing to help, I will appreciate it, and I believe that the experience that you got working on Guile-SDL would then be utilized properly (especially that you plainly put a lot of labour into that project, and your programming style seems more mature than mine). It would be a brand new experience for me to cooperate on an open source project with some other person. When it comes to the line of development, my main motivation for adding new features is the game that I'm trying to create, and -- as I wrote -- slayer is a byproduct, and it's meant to be useful for the set of its users (which is currently a singleton consisting of its author) rather than complete. However, I do have certain ideas of how the slayer environment could be enriched with some useful features (making a scheme editor widget, to begin with) I hope we can make our way somehow Best regards!
