* Guile Game Library @ 2013-05-29 0:30 David Thompson 2013-05-29 0:41 ` Nala Ginrut ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: David Thompson @ 2013-05-29 0:30 UTC (permalink / raw) To: guile-user Hello all, In my free time I like to tinker with game development, and I also like to tinker with Guile. I come from a Python background where I used such libraries as Pyglet and Pygame. These libraries were easy to use and had all the conveniences for making 2D games (Pyglet sports a full GL binding for doing more advanced stuff as well). I haven't found a similar library for Guile. Is there one that I haven't discovered? If there isn't, one should be made. Pygame is a fun treat for new Python programmers, and I think a similar library for Guile would be even more fun. :) In the past I've tried to wrap the Allegro 5 library using the Guile C API, and also with the FFI. My experience doing so lead me to the conclusion that a game library developed completely in Guile, not just a mere wrapper, would ultimately be much more satisfying. Now, how would this be achieved? I looked briefly at the source code of Pygame and Pyglet and learned the following: Pygame uses the Python C API to wrap up a bunch of SDL calls. Since Pygame uses SDL, the graphics functions use a software renderer which isn't optimal. Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet sports OpenGL, X11, and FreeType bindings to name a few. I personally prefer this development model over Pygame's. What Guile libraries already exist that can provide needed functionality? (Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics, etc.) What libraries would best suit this purpose? Figl (wingo's GL binding) is an obvious choice, as well as a Freetype binding (that I'm not sure exists). But what about the other important pieces such as sound and input? Thanks, Guilers! - Dave ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 0:30 Guile Game Library David Thompson @ 2013-05-29 0:41 ` Nala Ginrut 2013-05-29 0:45 ` David Thompson 2013-05-29 6:38 ` Javier Sancho 2013-05-29 9:43 ` Panicz Maciej Godek 2 siblings, 1 reply; 15+ messages in thread From: Nala Ginrut @ 2013-05-29 0:41 UTC (permalink / raw) To: David Thompson; +Cc: Guile User [-- Attachment #1: Type: text/plain, Size: 2026 bytes --] 在 2013-5-29 AM8:31,"David Thompson" <dthompson2@worcester.edu>写道: > > Hello all, > > In my free time I like to tinker with game development, and I also like to tinker with Guile. > I come from a Python background where I used such libraries as Pyglet and Pygame. > These libraries were easy to use and had all the conveniences for making 2D games (Pyglet sports a full GL binding for doing more advanced stuff as well). > I haven't found a similar library for Guile. Is there one that I haven't discovered? > > If there isn't, one should be made. Pygame is a fun treat for new Python programmers, and I think a similar library for Guile would be even more fun. :) > In the past I've tried to wrap the Allegro 5 library using the Guile C API, and also with the FFI. My experience doing so lead me to the conclusion that a game library developed completely in Guile, not just a mere wrapper, would ultimately be much more satisfying. > > Now, how would this be achieved? I looked briefly at the source code of Pygame and Pyglet and learned the following: > Pygame uses the Python C API to wrap up a bunch of SDL calls. Since Pygame uses SDL, the graphics functions use a software renderer which isn't optimal. > Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet sports OpenGL, X11, and FreeType bindings to name a few. I personally prefer this development model over Pygame's. > > What Guile libraries already exist that can provide needed functionality? (Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics, etc.) > > What libraries would best suit this purpose? Figl (wingo's GL binding) is an obvious choice, as well as a Freetype binding (that I'm not sure exists). But what about the other important pieces such as sound and input? > I'm glad that someone is interested on it :) And maybe you are looking for TTN's guile-SDL? It works anyway. But I'm not sure that Freetype binding exists. > Thanks, Guilers! > > - Dave > [-- Attachment #2: Type: text/html, Size: 2349 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 0:41 ` Nala Ginrut @ 2013-05-29 0:45 ` David Thompson 2013-05-29 8:09 ` Thien-Thi Nguyen 0 siblings, 1 reply; 15+ messages in thread From: David Thompson @ 2013-05-29 0:45 UTC (permalink / raw) To: Nala Ginrut; +Cc: Guile User On 05/28/2013 08:41 PM, Nala Ginrut wrote: > > I'm glad that someone is interested on it :) > And maybe you are looking for TTN's guile-SDL? It works anyway. > But I'm not sure that Freetype binding exists. > Guile-SDL has some issues of its own (I got frustrated trying to install and use it), and SDL in general (at least until 2.0 is stable) suffers from using software rendering instead of OpenGL. Pygame, although it wraps up many SDL features, provides a very Pythonic API and includes other helpful things written in pure Python (the Rect class comes to mind) and is thus not just an ordinary binding. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 0:45 ` David Thompson @ 2013-05-29 8:09 ` Thien-Thi Nguyen 2013-05-29 10:52 ` David Thompson 0 siblings, 1 reply; 15+ messages in thread From: Thien-Thi Nguyen @ 2013-05-29 8:09 UTC (permalink / raw) To: David Thompson; +Cc: Guile User [-- Attachment #1: Type: text/plain, Size: 236 bytes --] () David Thompson <dthompson2@worcester.edu> () Tue, 28 May 2013 20:45:37 -0400 Guile-SDL has some issues of its own [...] Please, could you describe these issues (in some detail)? -- Thien-Thi Nguyen GPG key: 4C807502 [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 8:09 ` Thien-Thi Nguyen @ 2013-05-29 10:52 ` David Thompson 2013-05-29 18:59 ` Thien-Thi Nguyen 0 siblings, 1 reply; 15+ messages in thread From: David Thompson @ 2013-05-29 10:52 UTC (permalink / raw) To: Thien-Thi Nguyen; +Cc: Guile User On 05/29/2013 04:09 AM, Thien-Thi Nguyen wrote: > () David Thompson <dthompson2@worcester.edu> > () Tue, 28 May 2013 20:45:37 -0400 > > Guile-SDL has some issues of its own [...] > > Please, could you describe these issues (in some detail)? > Sure, the first problem that prevented me from building was that guile-sdl depends on something called "snuggle" that there isn't much information about. Someone on #guile then said that guile-sdl was pretty unstable so I lost interest in building. I can try again. :) SDL alone doesn't meet my requirements since all of SDL's handy drawing functions use a software renderer. Figl has a GLUT binding that will take care of windowing and keyboard/mouse input, further minimizing the usefulness of SDL. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 10:52 ` David Thompson @ 2013-05-29 18:59 ` Thien-Thi Nguyen 2013-05-29 19:07 ` Thompson, David 0 siblings, 1 reply; 15+ messages in thread From: Thien-Thi Nguyen @ 2013-05-29 18:59 UTC (permalink / raw) To: David Thompson; +Cc: Guile User [-- Attachment #1: Type: text/plain, Size: 1004 bytes --] () David Thompson <dthompson2@worcester.edu> () Wed, 29 May 2013 06:52:29 -0400 Sure, the first problem that prevented me from building was that guile-sdl depends on something called "snuggle" that there isn't much information about. It sounds like you were trying to bootstrap from a repo checkout. Did you try a released (versioned) tarball? Someone on #guile then said that guile-sdl was pretty unstable so I lost interest in building. I can try again. :) Who knows, maybe since you last tried things have improved. SDL alone doesn't meet my requirements since all of SDL's handy drawing functions use a software renderer. Figl has a GLUT binding that will take care of windowing and keyboard/mouse input, further minimizing the usefulness of SDL. Well, if your requirements drift into Guile-SDL's domain and you run into specific problems w/ a released tarball, i'd appreciate hearing about them. -- Thien-Thi Nguyen GPG key: 4C807502 [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 18:59 ` Thien-Thi Nguyen @ 2013-05-29 19:07 ` Thompson, David 0 siblings, 0 replies; 15+ messages in thread From: Thompson, David @ 2013-05-29 19:07 UTC (permalink / raw) To: Thien-Thi Nguyen; +Cc: Guile User [-- Attachment #1: Type: text/plain, Size: 1144 bytes --] I'll give a released tarball a shot. Thanks. On Wed, May 29, 2013 at 2:59 PM, Thien-Thi Nguyen <ttn@gnu.org> wrote: > () David Thompson <dthompson2@worcester.edu> > () Wed, 29 May 2013 06:52:29 -0400 > > Sure, the first problem that prevented me from building was that > guile-sdl depends on something called "snuggle" that there isn't > much information about. > > It sounds like you were trying to bootstrap from a repo checkout. > Did you try a released (versioned) tarball? > > Someone on #guile then said that guile-sdl was pretty unstable so I > lost interest in building. I can try again. :) > > Who knows, maybe since you last tried things have improved. > > SDL alone doesn't meet my requirements since all of SDL's handy > drawing functions use a software renderer. > > Figl has a GLUT binding that will take care of windowing and > keyboard/mouse input, further minimizing the usefulness of SDL. > > Well, if your requirements drift into Guile-SDL's domain and you run > into specific problems w/ a released tarball, i'd appreciate hearing > about them. > > -- > Thien-Thi Nguyen > GPG key: 4C807502 > [-- Attachment #2: Type: text/html, Size: 1725 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 0:30 Guile Game Library David Thompson 2013-05-29 0:41 ` Nala Ginrut @ 2013-05-29 6:38 ` Javier Sancho 2013-05-29 10:57 ` David Thompson 2013-05-29 9:43 ` Panicz Maciej Godek 2 siblings, 1 reply; 15+ messages in thread From: Javier Sancho @ 2013-05-29 6:38 UTC (permalink / raw) To: David Thompson; +Cc: guile-user At http://lists.gnu.org/archive/html/guile-user/2013-05/msg00025.html you can read an interesting discussion about games development on Guile. In my opinion, although it would be nice to have something similar to pygame or pyglet, that's not exactly the way. It would be better a more functional style library or engine, as Haskell Yampas, or an entity oriented system as Unity3D. For me, binding i/o features is not an issue. Currently, using Guile FFI allow us to quickly achieve this task. And we have Guile-SDL and Figl. It's more important to design a good scalable way for making games, something that you could use to make prototyping and to make a great professional game, too. Last days, I read "What is an entity system framework for game development?" [1], "Entity Systems are the future of MMOG development" [2] and "Purely Functional Retrogames" [3] and I am directing Gacela, my experimental games engine, to a similar style of doing things, using components for the entities and working with subsystems that could run in the same thread or in various threads. You can find very interesting articles at Haskell Game Development page [4]. Cheers. [1] http://www.richardlord.net/blog/what-is-an-entity-framework [2] http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ [3] http://prog21.dadgum.com/23.html [4] http://www.haskell.org/haskellwiki/Game_Development -- Javier Sancho Fernández - http://www.jsancho.org/ Associate Member of the Free Software Foundation - http://www.fsf.org/ Contra el DRM - http://www.defectivebydesign.org/what_is_drm ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 6:38 ` Javier Sancho @ 2013-05-29 10:57 ` David Thompson 2013-05-30 10:07 ` Javier Sancho 0 siblings, 1 reply; 15+ messages in thread From: David Thompson @ 2013-05-29 10:57 UTC (permalink / raw) To: Javier Sancho; +Cc: guile-user On 05/29/2013 02:38 AM, Javier Sancho wrote: > At http://lists.gnu.org/archive/html/guile-user/2013-05/msg00025.html > you can read an interesting discussion about games development on > Guile. > > In my opinion, although it would be nice to have something similar to > pygame or pyglet, that's not exactly the way. It would be better a > more functional style library or engine, as Haskell Yampas, or an > entity oriented system as Unity3D. > > For me, binding i/o features is not an issue. Currently, using Guile > FFI allow us to quickly achieve this task. And we have Guile-SDL and > Figl. It's more important to design a good scalable way for making > games, something that you could use to make prototyping and to make a > great professional game, too. > > Last days, I read "What is an entity system framework for game > development?" [1], "Entity Systems are the future of MMOG development" > [2] and "Purely Functional Retrogames" [3] and I am directing Gacela, > my experimental games engine, to a similar style of doing things, > using components for the entities and working with subsystems that > could run in the same thread or in various threads. You can find very > interesting articles at Haskell Game Development page [4]. > > Cheers. > > [1] http://www.richardlord.net/blog/what-is-an-entity-framework > [2] http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ > [3] http://prog21.dadgum.com/23.html > [4] http://www.haskell.org/haskellwiki/Game_Development > > -- > Javier Sancho Fernández - http://www.jsancho.org/ > Associate Member of the Free Software Foundation - http://www.fsf.org/ > Contra el DRM - http://www.defectivebydesign.org/what_is_drm Maybe I have an unpopular opinion here, but I've done some reading and experimenting with Entity systems and I remain unconvinced of their usefulness. Is the source for Gacela available? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 10:57 ` David Thompson @ 2013-05-30 10:07 ` Javier Sancho 2013-05-30 11:00 ` David Thompson 0 siblings, 1 reply; 15+ messages in thread From: Javier Sancho @ 2013-05-30 10:07 UTC (permalink / raw) To: David Thompson; +Cc: guile-user David Thompson wrote: > Maybe I have an unpopular opinion here, but I've done some reading and > experimenting with Entity systems and I remain unconvinced of their > usefulness. In my view, playing with entities gives two ways for doing things in a game. Game designers work with "objects" that have components that have properties, i.e., it's possible to create a ship with a position and a velocity. And game programmers work with data (or functions) which are passed to a system (function) that returns data (or functions), so these systems can be treated separately, can be running in another processor, etc. But it's my opinion. What problems have you encountered using entity systems? > Is the source for Gacela available? http://hg.savannah.nongnu.org/hgweb/gacela/ But it's the previous version with an object oriented vision and a little unstable. I am designing a new approach based on entity systems and I hope I start writing code soon. Cheers. -- Javier Sancho Fernández - http://www.jsancho.org/ Associate Member of the Free Software Foundation - http://www.fsf.org/ Contra el DRM - http://www.defectivebydesign.org/what_is_drm ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-30 10:07 ` Javier Sancho @ 2013-05-30 11:00 ` David Thompson 2013-05-30 11:09 ` Javier Sancho 0 siblings, 1 reply; 15+ messages in thread From: David Thompson @ 2013-05-30 11:00 UTC (permalink / raw) To: Javier Sancho; +Cc: guile-user On 05/30/2013 06:07 AM, Javier Sancho wrote: > In my view, playing with entities gives two ways for doing things in a > game. Game designers work with "objects" that have components that > have properties, i.e., it's possible to create a ship with a position > and a velocity. And game programmers work with data (or functions) > which are passed to a system (function) that returns data (or > functions), so these systems can be treated separately, can be running > in another processor, etc. But it's my opinion. What problems have you > encountered using entity systems? I haven't tried implementing an entity-component system in Scheme, but in the past I've tried to grok writings on the subject and wrote an implementation in C++ and later in Python. The Python version worked much better than the C++ version, since Python is more dynamic. I like components in theory as it provides a good separation of concerns, but in practice it always ended up being too complex to work with. The dependencies between components and the message passing were hard to deal with nicely. In the end I would just fall back to a much simpler model to represent game objects. > http://hg.savannah.nongnu.org/hgweb/gacela/ > > But it's the previous version with an object oriented vision and a > little unstable. I am designing a new approach based on entity systems > and I hope I start writing code soon. I'm interested to see how you implement your entity-component system. You seem to have a better idea of how to do it than I do. > > Cheers. > > -- > Javier Sancho Fernández - http://www.jsancho.org/ > Associate Member of the Free Software Foundation - http://www.fsf.org/ > Contra el DRM - http://www.defectivebydesign.org/what_is_drm ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-30 11:00 ` David Thompson @ 2013-05-30 11:09 ` Javier Sancho 0 siblings, 0 replies; 15+ messages in thread From: Javier Sancho @ 2013-05-30 11:09 UTC (permalink / raw) To: David Thompson; +Cc: guile-user David Thompson wrote: > I'm interested to see how you implement your entity-component system. You > seem to have a better idea of how to do it than I do. Ouoh, we will see. For the moment, I only talk a lot, smoke everywhere :-) -- Javier Sancho Fernández - http://www.jsancho.org/ Associate Member of the Free Software Foundation - http://www.fsf.org/ Contra el DRM - http://www.defectivebydesign.org/what_is_drm ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 0:30 Guile Game Library David Thompson 2013-05-29 0:41 ` Nala Ginrut 2013-05-29 6:38 ` Javier Sancho @ 2013-05-29 9:43 ` Panicz Maciej Godek 2013-05-29 11:15 ` David Thompson 2 siblings, 1 reply; 15+ messages in thread From: Panicz Maciej Godek @ 2013-05-29 9:43 UTC (permalink / raw) To: David Thompson; +Cc: guile-user@gnu.org [-- Attachment #1: Type: text/plain, Size: 4401 bytes --] 2013/5/29 David Thompson <dthompson2@worcester.edu> > Hello all, > > In my free time I like to tinker with game development, and I also like to > tinker with Guile. > I come from a Python background where I used such libraries as Pyglet and > Pygame. > These libraries were easy to use and had all the conveniences for making > 2D games (Pyglet sports a full GL binding for doing more advanced stuff as > well). > I haven't found a similar library for Guile. Is there one that I haven't > discovered? > > Actually, I've been trying to develop a game in guile, and on my way I coined the SLAYER environment, which can be obtained via mercurial: $ hg clone https://bitbucket.org/panicz/slayer $ cd slayer Provided that you have all the packages listed in the DEPENDENCIES file, it should get built using $ make However, you may wish to switch to "autotools" branch, which contains some more recent changes and more informative demos: $ hg up autotools $ ./configure and $ make (I wouldn't recommend to 'make install' yet though, as there are still some issues that need to be resolved) If you manage to go through this somewhat cumbersome build process, you can try out the demos, by entering the demos directory and typing $ ./slayer -e3d -islayer.scm and $ ./slayer -ipong.scm There's also a possibility to build a library that wraps the Open Dynamics Engine, and there's a corresponding demo which shows its capabilities (like everything in SLAYER, this isn't just a simple wrapper on the C functions, but rather an interface which simplifies the development) If there isn't, one should be made. Pygame is a fun treat for new Python > programmers, and I think a similar library for Guile would be even more > fun. :) > In the past I've tried to wrap the Allegro 5 library using the Guile C > API, and also with the FFI. My experience doing so lead me to the > conclusion that a game library developed completely in Guile, not just a > mere wrapper, would ultimately be much more satisfying. > > My vision of SLAYER is to make a self-contained development environment, so that it could have its own editors (for code, but also for 3d mesh, sound waves, rigs or video streams) -- so I believe that it could evolve towards something like emacs, but focused on multimedia Now, how would this be achieved? I looked briefly at the source code of > Pygame and Pyglet and learned the following: > Pygame uses the Python C API to wrap up a bunch of SDL calls. Since Pygame > uses SDL, the graphics functions use a software renderer which isn't > optimal. > Pyglet doesn't seem to use any C code and instead uses the FFI. Pyglet > sports OpenGL, X11, and FreeType bindings to name a few. I personally > prefer this development model over Pygame's. > > I have no experience with any of those, so I cannot compare. SLAYER is based entirely on SDL and OpenGL (which is optional). It also wraps SDL_image, SDL_mixer for audio and SDL_ttf for FreeType fonts. Rendering can be done using either plain SDL or via OpenGL (which currently must be enabled using the "-e3d" command line option), and in the latter case no SDL routines are used for rendering. What Guile libraries already exist that can provide needed functionality? > (Windows, Graphics, Sound, Keyboard/mouse/joystick input, Fonts, Physics, > etc.) > What libraries would best suit this purpose? Figl (wingo's GL binding) is > an obvious choice, as well as a Freetype binding (that I'm not sure > exists). But what about the other important pieces such as sound and input? > > Except SLAYER, guile-SDL provides support for all of the features you mentioned (except Physics). Its advantage is a much better documentation (SLAYER currently offers none), easier build process and a larger set of demos. Also, SLAYER has no joystick support (it could be added easily, but I wouldn't have any option to test it). However, the advantage of SLAYER is that it's something more than just a wrapper: it is an abstraction layer, which could be implemented in many other environments. It offers an event-driven input model, so the programmer doesn't have to write his own input loop. Furthermore, it provides a GOOPS-based framework for widgets. I recommend you to look at the source of the demos to see how it works, and if you have any questions, I'm eager to help. Maybe the overall process could help come up with some documentation. Best regards, M. [-- Attachment #2: Type: text/html, Size: 6817 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 9:43 ` Panicz Maciej Godek @ 2013-05-29 11:15 ` David Thompson 2013-05-29 12:00 ` Panicz Maciej Godek 0 siblings, 1 reply; 15+ messages in thread From: David Thompson @ 2013-05-29 11:15 UTC (permalink / raw) To: Panicz Maciej Godek; +Cc: guile-user@gnu.org I'll give SLAYER a try before judging it, but my initial impression is that it's not a good fit for me. Our goals seem to be different, and it seems that you have your sights aimed much higher. Emacs is my development environment and I'm not looking for a specialized development environment to build games in using SLAYER or any other library. I do really like that SLAYER can operate with software rendering OR OpenGL rendering. That is quite the nice feature. Perhaps I should explain my position more. My focus is on 2D game development (but that's not to say that I want a library that is limited to only 2D), which means I want a library with features like sprites, sprite batching, tiling, animation, a 2D scene graph, event scripting, etc. A combination of Guile-SDL and Figl could fit the bill for the base to build off of. Thoughts? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Guile Game Library 2013-05-29 11:15 ` David Thompson @ 2013-05-29 12:00 ` Panicz Maciej Godek 0 siblings, 0 replies; 15+ messages in thread From: Panicz Maciej Godek @ 2013-05-29 12:00 UTC (permalink / raw) To: David Thompson; +Cc: guile-user@gnu.org [-- Attachment #1: Type: text/plain, Size: 2271 bytes --] 2013/5/29 David Thompson <dthompson2@worcester.edu> > I'll give SLAYER a try before judging it, but my initial impression is > that it's not a good fit for me. Our goals seem to be different, and it > seems that you have your sights aimed much higher. Emacs is my development > environment and I'm not looking for a specialized development environment > to build games in using SLAYER or any other library. > > Well, currently I also use Emacs. However, I see that in the process of game development it is very important to be able to make editors for certain features. SLAYER is a very general (or generic) environment, and the idea is just to build various libraries around the core, which is responsible for input handling and audiovisuals. I hope that one day I manage to transpose the idea of REPL onto the world of GUI somehow, but it's just a distant vision. However, having an in-game code editor is just something that I need for the game that I'm developing. I do really like that SLAYER can operate with software rendering OR OpenGL > rendering. That is quite the nice feature. > > Perhaps I should explain my position more. My focus is on 2D game > development (but that's not to say that I want a library that is limited to > only 2D), which means I want a library with features like sprites, sprite > batching, tiling, animation, a 2D scene graph, event scripting, etc. > I know of no library for Guile that would provide those features out of the box. I believe it should be fairly easy to provide animation framework for SLAYER. When it comes to some other features, honestly, I haven't considered the code performance issues yet (I've rather been concerned with the performance of the development process), so I'm unfamiliar with features like sprite batching nor efficient tiling. The sprites themselves are supported, whether they are loaded from external files, or generated as a two-dimensional array (there are array->image and image->array functions that allow for an easy conversion) I follow David Knuth's advice and act as if "premature optimization was the root of all evil" -- I believe it is more important to have a working game ASAP and optimize only when I know which optimizations are needed than to worry a priori. Best regards, M. [-- Attachment #2: Type: text/html, Size: 3310 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-05-30 11:09 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-29 0:30 Guile Game Library David Thompson 2013-05-29 0:41 ` Nala Ginrut 2013-05-29 0:45 ` David Thompson 2013-05-29 8:09 ` Thien-Thi Nguyen 2013-05-29 10:52 ` David Thompson 2013-05-29 18:59 ` Thien-Thi Nguyen 2013-05-29 19:07 ` Thompson, David 2013-05-29 6:38 ` Javier Sancho 2013-05-29 10:57 ` David Thompson 2013-05-30 10:07 ` Javier Sancho 2013-05-30 11:00 ` David Thompson 2013-05-30 11:09 ` Javier Sancho 2013-05-29 9:43 ` Panicz Maciej Godek 2013-05-29 11:15 ` David Thompson 2013-05-29 12:00 ` Panicz Maciej Godek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).