Menu
▾
▴
pysdl-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(30) |
Jun
(44) |
Jul
(37) |
Aug
(9) |
Sep
(59) |
Oct
(21) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: David C. <D. C. <si...@te...> - 2000-05-16 07:34:18
|
Pete Shinners writes: > i'm eagerly pounding away on PySDL for windows. it's been a bit > of learning python extensions just to get it compiling. > > well, now some of it is working, but some of it isn't. > > most noticeably the video system. i've traced it back to > problems creating the window. it appears SDL uses argv[0] > as the classname for the window class. right now this is > NULL when running under python. i'm pretty sure that's the > problem. strangely i can't seem to fix this with simple > changes to the SDL code. hmmmm.. This is very interesting. I've tried compiling under VC4, and I believe someone else tried under ming32, but neither of us have been successful. I have to admit I've been doing nearly all my work under linux, and so I've been a bit distracted. I've also been creating RPM packages for it, and learning RPM has taken up a bit of my time. > anyways, i'm wondering how things are looking for PySDL? > personally i'm quite excited about it, and am surprised there > is so little interest. It hasn't been aggressively advertised, either on the SDL mailing list or on comp.lang.python. Actually, as far as I know, it hasn't even been _mentioned_ on either :) I haven't talked to Mark about this, but my guess is he'd like to get the module to a pretty-much-completed state before opening the floodgates. This is fine with me :) > has anyone had any luck in getting a win32 version running? > i've had to make many small typecasting adjustments to get > it working. i've also been adding a few functions here and > there (like sdl.get_error()) to help me trace my problems down. > > > also, has anyone gotten any work from the project owner, "mbaker" > ?? is the guy dead?? what's happening with PySDL? > While I can't speak to Mr. Baker's existential state :) nearly all of the 'work' so far has been his product. I know he has several other projects besides pySDL, but I have no doubt the project is in good hands. My documentation is nearly current, and I should be releasing my first pySDL application tomorrow. David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Pete S. <psh...@me...> - 2000-05-16 07:20:06
|
i'm eagerly pounding away on PySDL for windows. it's been a bit of learning python extensions just to get it compiling. well, now some of it is working, but some of it isn't. most noticeably the video system. i've traced it back to problems creating the window. it appears SDL uses argv[0] as the classname for the window class. right now this is NULL when running under python. i'm pretty sure that's the problem. strangely i can't seem to fix this with simple changes to the SDL code. hmmmm.. anyways, i'm wondering how things are looking for PySDL? personally i'm quite excited about it, and am surprised there is so little interest. has anyone had any luck in getting a win32 version running? i've had to make many small typecasting adjustments to get it working. i've also been adding a few functions here and there (like sdl.get_error()) to help me trace my problems down. also, has anyone gotten any work from the project owner, "mbaker" ?? is the guy dead?? what's happening with PySDL? |
|
From: Peter N. <pn...@ya...> - 2000-05-16 02:37:36
|
Hi, What would be required to port pysdl to python-win32? --Peter __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: David C. <D. C. <si...@te...> - 2000-05-14 08:13:26
|
The following code reliably crashes my computer:
#! /usr/bin/env python
import sdl
number = 0
while 1:
fb = sdl.image_load('demo.jpg')
number = number + 1
print str(number)
The crash occurs around number 570 or so (I have 128 Mb of ram). I get
bus errors or X crashes, and eventually (if rerun a couple of times)
the entire system freezes with the init process pegged at 99.9% of CPU
time. Pretty spectacular :)
I strongly believe that the image_load() and image_load_type() methods
are never closing the files they open (I've tried it with both - same
result). This code is very similar to code I'm writing for a larger
application right now, which raises an "IOError: too many files open"
exception around iteration 1024. Commenting out the image_load() line
makes the program run perfectly, although it's pretty dull :)
My C skills are lacking, so I don't even know if this is a problem
with pySDL or SDL_image. Could someone look at the code and confirm
that 'demo.jpg' is being closed properly once it's loaded?
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html
--
Don't think 'cause I understand, I care.
Don't think 'cause I'm talking that we're friends.
I've lived my life like I've lived too much.
- Sneaker Pimps, 6 Underground
|
|
From: David C. <D. C. <si...@te...> - 2000-05-14 04:44:29
|
In writing my little app, I've run up against a bit of a issue - I don't know if it's appropriate for inclusion in pySDL or not. I check the event queue a couple of times per second with events_poll(). I'm really only interested in the event that's occurring at the moment of the poll, but I'm finding that (for example) a quick mouse motion across the window is filling up the queue with many events, each of which has to be grabbed from the queue sequentially. As a result, a mouse motion and then a click may take ten seconds to register with my program, as I poll() myself through the queue. What I'm looking for is an events_flush(), which would empty the queue when called. I realize that calling it after each poll() will result in jerky input response, but that's fine for my little hack. Other options would include writing an events_get() for each event type, or IGNORING and then re-ENABLING each event type as it happens. Does anyone have a way around this, or is a new method needed? David Clark si...@te... Preliminary pySDL documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html -- ------------------------------------------------------------------------- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -Bertrand Russell |
|
From: Pete S. <pe...@vi...> - 2000-05-11 22:32:31
|
pysdl is looking great! this weekend i will start really playing with it. i'm wondering how much support there is for some of the other libraries that work well with SDL. specifically i'm interested in running PyOpenGL with pySDL. has anyone got this working? a quick example would really set me straight. and then i'm all-of-a-sudden finding other cool libraries that use SDL. cool looking UI stuff, like LIBUTA http://python.via.ecp.fr/ftp/worldforge/users/sdt/libuta/ anyways, like i mentioned, my early goals will be using opengl with sdl in python. i'm hoping it's been figured out already. -- _____Pete Shinners______ pe...@vi... |
|
From: Mark B. <mb...@0x...> - 2000-04-26 15:42:54
|
On Tue, 25 Apr 2000, "David Clark wrote: > A few questions for Mark that occur tonight... > > - What is the intended use of the joy_update() function? Manual pumping of joystick events. > - Did the bug fixes in the joystick subsection effect the interface? Some functions that I wrote that didn't find their way into the appropriate namespaces are now where they belong. This probably has no impact on your docs. > - I see some mention of GL-related constants and functions in the > module, but nothing in the TODO. Is the OpenGL section of SDL still in > your plans? The OpenGL section of SDL has been finished since the first release, I think. SDL doesn't do any wrapping of OpenGL or anything; you need to use it directly after initializing SDL for OpenGL use. I have yet, though, to use the OpenGL python module in conjunction with PySDL. > - A couple of weeks ago you mentioned SDL_ttf support. Are you still > interested in implementing that? What about David Leimbach's DFont at > http://phoenix.lhup.edu/~dleimbac/Projects/DFont/ or Karl Bartel's > http://www.linuxstart.com/~karlb/sfont.html instead? Does anyone > have a strong preference for one text library or another (I don't)? I'll look into DFont. Some form of font library will be used. I haven't determined yet which one. > - using sound_load() with the wrong frequency just results in > faster/slower playback, but music_load() segfaults. This is probably an issue with SDL_mixer. I've only tested it with mp3s, and I can say that they work. I'll look into its behavior with other music formats. > - doing: > > sound = sdl.sound_load('foo.wav') > sound = sdl.sound_load('bar.wav') > > locks up the interpreter hard on the second load (both files exist). Also, I don't have this problem. What version of SDL_mixer are you using? |
|
From: David C. <D. C. <si...@te...> - 2000-04-25 07:13:09
|
A few questions for Mark that occur tonight... - What is the intended use of the joy_update() function? - Did the bug fixes in the joystick subsection effect the interface? - I see some mention of GL-related constants and functions in the module, but nothing in the TODO. Is the OpenGL section of SDL still in your plans? - A couple of weeks ago you mentioned SDL_ttf support. Are you still interested in implementing that? What about David Leimbach's DFont at http://phoenix.lhup.edu/~dleimbac/Projects/DFont/ or Karl Bartel's http://www.linuxstart.com/~karlb/sfont.html instead? Does anyone have a strong preference for one text library or another (I don't)? - using sound_load() with the wrong frequency just results in faster/slower playback, but music_load() segfaults. - doing: sound = sdl.sound_load('foo.wav') sound = sdl.sound_load('bar.wav') locks up the interpreter hard on the second load (both files exist). David Clark Preliminary pySDL documentation http://www3.telus.net/futility/futility/docs/pysdl/index.html -- "Artists use frauds to make human beings seem more wonderful than they really are. Dancers show us human beings who move much more gracefully than human beings really move. Films and books and plays show us people talking much more entertainingly than people really talk, make paltry human enterprises seem important. Singers and musicians show us human beings making sounds far more lovely than human beings really make. Architects give us temples in which something marvelous is obviously going on. Actually, practically nothing is going on. - Wampeters, Foma and Granfalloons, "When I Was Twenty-One" |
|
From: Mark B. <mb...@0x...> - 2000-04-25 04:36:49
|
On Tue, 25 Apr 2000, "David Clark wrote: > Your link to the SDL_mixer page at pysdl.sourceforge.net is > misspelled. You have: Haha, thanks. That typo would've been somewhat embarrassing. |
|
From: David C. <D. C. <si...@te...> - 2000-04-25 04:29:29
|
Mark Baker writes: Woohoo! Of course, it does just come at the tail end of a four-day long weekend :( Your link to the SDL_mixer page at pysdl.sourceforge.net is misspelled. You have: http://www.devolution.com/~slouken/SDL/projects/SDL_mixser/index.html Should be: http://www.devolution.com/~slouken/SDL/projects/SDL_mixer/index.html Thanks again for all your hard work, Mark! > I just put up 0.0.4 which has fixed a few bugs, and added SDL_mixer/audio > support. I also added two more examples which use the audio capabilities of > PySDL. Currently you can't do low-level sound manipulation, but you can load > and play various sound and music files. The current functionality should cover > what most people would want. > I'll prolly add low-level manipulation for the next release. > > _______________________________________________ > PySDL-devel mailing list > PyS...@li... > http://lists.sourceforge.net/mailman/listinfo/pysdl-devel Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html David Clark -- I'd rather be lost in my empyrean world, Than live down on earth... I can't explain Why I don't belong to this same world - I don't fit in, And I will not stay. - Paula Cole, Saturn Girl |
|
From: Mark B. <mb...@0x...> - 2000-04-25 02:39:34
|
I just put up 0.0.4 which has fixed a few bugs, and added SDL_mixer/audio support. I also added two more examples which use the audio capabilities of PySDL. Currently you can't do low-level sound manipulation, but you can load and play various sound and music files. The current functionality should cover what most people would want. I'll prolly add low-level manipulation for the next release. |
|
From: Mark B. <mb...@0x...> - 2000-04-24 16:44:30
|
On Mon, 24 Apr, 2000, "David Clark wrote: > What is the best way to remove a non-visible framebuffer surface from > memory? I've tried to call fb = None, but this just segfaults. I'm > creating several new surfaces a second, and I'm afraid they'll just > clog up available memory. I assume you mean an offscreen surface, and not a 'framebuffer'. Simply because I can't see any reason that you'd switch video modes that often. In which case, you can assign it any non-surface or del it. PySDL shouldn't segfault when you assign a binding to a new value, and I wasn't able to reproduce it. If you're finding it segfaults, I'd be interested in seeing how you're getting it to. |
|
From: David C. <D. C. <si...@te...> - 2000-04-24 08:16:01
|
What is the best way to remove a non-visible framebuffer surface from memory? I've tried to call fb = None, but this just segfaults. I'm creating several new surfaces a second, and I'm afraid they'll just clog up available memory. -- David "Futility [D!]" Clark | Any sufficiently advanced philosophy | si...@te... | is indistinguishable from despair. | ----------------------------------------------------------------------- |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 21:57:07
|
David Clark <David Clark wrote: > > Thank you everyone for discussing these issues; I'm learning a lot. I > see some people are referring to my pySDL documentation as they try to > determine what's going on, so I'm going to say this as clearly as I can: > > ---> I don't really know what I'm doing. <--- ---> But at least you are doing something. <--- :) > This has two obvious results: > > 1) The documentation is incomplete. If you come up with any insight > into the workings of SDL and pySDL, please let me know. If you feel > that parts of the documentation are unclear or poorly worded, please > tell me. You don't even have to supply replacement wording (as Martijn > so kindly did) Actually the original SDL documentation's wording was confusing (but it's fixed in Sam Lantinga's header files now, so eventually that ought to show up in the docs). So it wasn't your fault. :) [snip] > 2) The documentation is incorrect. In this case, the SDL docs turned out to be incorrect; the SRCKEY and SRCALPHA flags are *always* honored, no matter what the surface is, apparently. Your docs were better, as I didn't find it saying they weren't honored. ;) > Don't rely on my understanding of > the API for very much at this point. Read the SDL documentation too - > in some cases (such as color shifts), I've just cut and pasted from > there or from the __doc__ strings. Don't take what's written in the > pySDL documentation as gospel until you've tested it in the real > world. And as my foray into the SDL docs showed, don't even take the SDL documentation as gospel until you've tested it in the real world, or at least until Mark has tested it in the real world and tells you. :) Anyway, you're doing fine with the docs -- even when the docs are excellent (SDL's docs are generally very nice) and written by the original developer, obscure phrases and documentation inaccuracies can sneak in, after all. Thanks! Martijn |
|
From: David C. <D. C. <si...@te...> - 2000-04-20 21:35:58
|
Thank you everyone for discussing these issues; I'm learning a lot. I see some people are referring to my pySDL documentation as they try to determine what's going on, so I'm going to say this as clearly as I can: ---> I don't really know what I'm doing. <--- This has two obvious results: 1) The documentation is incomplete. If you come up with any insight into the workings of SDL and pySDL, please let me know. If you feel that parts of the documentation are unclear or poorly worded, please tell me. You don't even have to supply replacement wording (as Martijn so kindly did), just tell me "Your explanation of x sucks." and I'll get on it. This documentation needs to be useful to the pySDL community - I'll change whatever needs changing until it is. 2) The documentation is incorrect. Don't rely on my understanding of the API for very much at this point. Read the SDL documentation too - in some cases (such as color shifts), I've just cut and pasted from there or from the __doc__ strings. Don't take what's written in the pySDL documentation as gospel until you've tested it in the real world. >> You can specify HWSURFACE, when you create the surface, and if it can't be >> allocated in hardware memory, it'll be allocated in system memory. > That must be what's happening then; I just checked and I do use HWSURFACE. > So I wonder how David found out it wasn't possible; I suppose he did > a query on the surface after creation? Nothing that dramatic, really - I just noticed that video_info(INFO_HW_A) returned 0 :) That, plus the fact that blits didn't seem to be any faster with video_set_mode(HWSURFACE vs. SWSURFACE). Eagerly awaiting 0.0.4 :) Preliminary pySDL documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html -- ------------------------------------------------------------------------- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -Bertrand Russell |
|
From: Mark B. <mb...@0x...> - 2000-04-20 20:57:17
|
On Thu, 20 Apr 2000, Eric Jacobs wrote: > > > > Wow! Not only did that make the PNG and BMP times the same, it cut > > them by about 40%! Very nice. Thanks for your help. > > I second that wow! However, I'm having a little problem. Whenever I > call either convert() or convert_display(), the alpha channel seems > to be lost. This is coming off of PNGs. If I don't call the convert, > the blit is much slower, but the alpha is preserved. Any ideas? When you convert a surface to the format of the video surface, you're going to lose your per-pixel alpha information. This is because the image is literally converted to the format of the display image. So a 32-bit RGBA PNG is converted to a 16-bit 5-5|6-5 video surface, or a 24-bit surface, or so on and so forth. If you want to preserve the per-pixel alpha information, don't convert the surface. |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 20:43:42
|
Hi there, Argh..having some trouble getting my mail sent to the list; sent this off to Mark alone by mistake. Here it is for you all: [also see my later notes for the followup] Mark Baker wrote: > On Thu, 20 Apr 2000, Martijn Faassen wrote: > > Odd, I thought I did use HW in my code. Also I recall something in the > > docs on the color keyed blits bit. I don't have it here but at > > home, but I'll look tonight if I get a chance. I'll mail a report > > on that tonight, hopefully. That'll be more constructive than my > > vague underinformed bitching of late. :) > > You can specify HWSURFACE, when you create the surface, and if it can't be > allocated in hardware memory, it'll be allocated in system memory. That must be what's happening then; I just checked and I do use HWSURFACE. So I wonder how David found out it wasn't possible; I suppose he did a query on the surface after creation? > Color keying works in software, as well as in hardware. Must be, then! I think I misread this in the SDL reference: SDL_SRCCOLORKEY means that the surface will be used for colorkey blits and if the hardware supports hardware acceleration of colorkey blits between two surfaces in video memory, to place the surface in video memory if possible, otherwise it will be placed in system memory. Our own PySDL says this: SRCCOLORKEY The surface will be used for colorkey blits and if the hardware supports hardware acceleration of colorkey blits between two surfaces in video memory, to place the surface in video memory if possible, otherwise it will be placed in system memory. Both are certainly a bit clunky as written, though it's obvious now that I didn't read them right. I would patch the texts to something like: SDL_SRCCOLORKEY indicates that the surface will be used for colorkey blits. If the hardware supports acceleration of colorkey blits between two surfaces in video memory, SDL will try to place the surface in video memory. If this isn't possible or if there is no hardware acceleration available, the surface will be placed in system memory. Or something like that. Of course I should send it off to Sam Lantinga, so I'll do that now. :) David Clark is also informed of this minor documentation patch. Though I was probably the only one who got confused by the original. Oooh, I finished off this mail, and *now* I found what confused me: SDL_SRCCOLORKEY and SDL_SRCALPHA will only be honored if the display surface is in video video memory (the surface returned by SDL_SetVideoMode() has the SDL_HWSURFACE flag set.) I didn't read the *display* part in display surface, and also managed to ignore what was between the brackets. Silly me! Regards, Martijn |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 20:40:49
|
Mark Baker wrote: > On Thu, 20 Apr 2000, Martijn Faassen wrote: > > Odd, I thought I did use HW in my code. Also I recall something in the > > docs on the color keyed blits bit. I don't have it here but at > > home, but I'll look tonight if I get a chance. I'll mail a report > > on that tonight, hopefully. That'll be more constructive than my > > vague underinformed bitching of late. :) > > You can specify HWSURFACE, when you create the surface, and if it can't be > allocated in hardware memory, it'll be allocated in system memory. That must be what's happening then; I just checked and I do use HWSURFACE. So I wonder how David found out it wasn't possible; I suppose he did a query on the surface after creation? > Color keying works in software, as well as in hardware. Must be, then! I think I misread this in the SDL reference: SDL_SRCCOLORKEY means that the surface will be used for colorkey blits and if the hardware supports hardware acceleration of colorkey blits between two surfaces in video memory, to place the surface in video memory if possible, otherwise it will be placed in system memory. Our own PySDL says this: SRCCOLORKEY The surface will be used for colorkey blits and if the hardware supports hardware acceleration of colorkey blits between two surfaces in video memory, to place the surface in video memory if possible, otherwise it will be placed in system memory. Both are certainly a bit clunky as written, though it's obvious now that I didn't read them right. I would patch the texts to something like: SDL_SRCCOLORKEY indicates that the surface will be used for colorkey blits. If the hardware supports acceleration of colorkey blits between two surfaces in video memory, SDL will try to place the surface in video memory. If this isn't possible or if there is no hardware acceleration available, the surface will be placed in system memory. Or something like that. Of course I should send it off to Sam Lantinga, so I'll do that now. :) David Clark is also informed of this minor documentation patch. Though I was probably the only one who got confused by the original. Oooh, I finished off this mail, and *now* I found what confused me: SDL_SRCCOLORKEY and SDL_SRCALPHA will only be honored if the display surface is in video video memory (the surface returned by SDL_SetVideoMode() has the SDL_HWSURFACE flag set.) I didn't read the *display* part in display surface, and also managed to ignore what was between the brackets. Silly me! Regards, Martijn |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 20:37:14
|
Mark Baker wrote: > On Thu, 20 Apr 2000, Martijn Faassen wrote: > > SDL_SRCCOLORKEY and SDL_SRCALPHA will only be honored if the display surface > > is in video video memory (the surface returned by SDL_SetVideoMode() has the > > SDL_HWSURFACE flag set.) > > > > I didn't read the *display* part in display surface, and also managed to > > ignore what was between the brackets. Silly me! > > This is inaccurate as well, since it will work even if the display surface > isn't in video memory. Yes, comes from reading the documentation instead of trying it out. :) Sam Lantinga just wrote me back that this was incorrect -- he's fixing the documentation. Regards, Martijn |
|
From: Mark B. <mb...@0x...> - 2000-04-20 20:31:31
|
On Thu, 20 Apr 2000, Martijn Faassen wrote: > SDL_SRCCOLORKEY and SDL_SRCALPHA will only be honored if the display surface > is in video video memory (the surface returned by SDL_SetVideoMode() has the > SDL_HWSURFACE flag set.) > > I didn't read the *display* part in display surface, and also managed to > ignore what was between the brackets. Silly me! This is inaccurate as well, since it will work even if the display surface isn't in video memory. |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 20:28:07
|
Eric Jacobs wrote: > > > > > Wow! Not only did that make the PNG and BMP times the same, it cut > > them by about 40%! Very nice. Thanks for your help. > > I second that wow! However, I'm having a little problem. Whenever I > call either convert() or convert_display(), the alpha channel seems > to be lost. This is coming off of PNGs. If I don't call the convert, > the blit is much slower, but the alpha is preserved. Any ideas? Browsing the SDL and PySDL documentation and the PySDL sources, I think you can use convert() and pass sdl.SRCALPHA as the second (flag) argument. For convert_display() the situation is a bit more tricky; the SDL_DisplayFormat (used internally by PySDL) documentation says that: If you want to take advantage of hardware colorkey or alpha blit acceleration, you should set the colorkey and alpha value before calling this function. But presumably these would already be set in your PNG image, as you say that without conversion the alpha blitting is being preserved, right? So that would indicate a bug somewhere. I browsed a bit through PySDL but I couldn't find any bug there (doesn't mean it isn't there, of course :). So that could indicate an SDL bug. Could you do some more testing? Also there doesn't seem to be any obvious SDL function to use to indicate that a surface should use alpha blitting, except during surface creation. Perhaps the documentation means you should go poke in the structure directly, then? (but there isn't any obvious structure member to manipulate, either). Hmm. Regards, Martijn |
|
From: Eric J. <ea...@ri...> - 2000-04-20 19:20:09
|
> > Wow! Not only did that make the PNG and BMP times the same, it cut > them by about 40%! Very nice. Thanks for your help. I second that wow! However, I'm having a little problem. Whenever I call either convert() or convert_display(), the alpha channel seems to be lost. This is coming off of PNGs. If I don't call the convert, the blit is much slower, but the alpha is preserved. Any ideas? |
|
From: Mark B. <mb...@0x...> - 2000-04-20 17:37:01
|
On Thu, 20 Apr 2000, Martijn Faassen wrote: > Odd, I thought I did use HW in my code. Also I recall something in the > docs on the color keyed blits bit. I don't have it here but at > home, but I'll look tonight if I get a chance. I'll mail a report > on that tonight, hopefully. That'll be more constructive than my > vague underinformed bitching of late. :) You can specify HWSURFACE, when you create the surface, and if it can't be allocated in hardware memory, it'll be allocated in system memory. Color keying works in software, as well as in hardware. |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 17:22:21
|
Mark Baker wrote:
> Martijn Faassen wrote:
> > Odd, I'm pretty sure I've used one. I've done blitting with a transparent
> > color after all, and from the docs I gleaned this is only possible with
> > hardware surfaces?
>
> src/video/x11/SDL_x11image.c
> line 149
>
> /* We don't actually allow hardware surfaces other than the main one */
> int X11_AllocHWSurface(_THIS, SDL_Surface *surface)
> {
> return(-1);
> }
> As for color keyed and alpha blits, they can be done in software.
Odd, I thought I did use HW in my code. Also I recall something in the
docs on the color keyed blits bit. I don't have it here but at
home, but I'll look tonight if I get a chance. I'll mail a report
on that tonight, hopefully. That'll be more constructive than my
vague underinformed bitching of late. :)
Regards,
Martijn
|
|
From: Mark B. <mb...@0x...> - 2000-04-20 16:27:43
|
Martijn Faassen wrote:
> Odd, I'm pretty sure I've used one. I've done blitting with a transparent
> color after all, and from the docs I gleaned this is only possible with
> hardware surfaces?
src/video/x11/SDL_x11image.c
line 149
/* We don't actually allow hardware surfaces other than the main one */
int X11_AllocHWSurface(_THIS, SDL_Surface *surface)
{
return(-1);
}
As for color keyed and alpha blits, they can be done in software.
|
