Menu
▾
▴
pysdl-devel
|
From: Jan E. <ch...@in...> - 2000-09-11 09:03:16
|
Hi there, I'm having some small problems with PySDL, but I'm not sure this is the correct forum. The regular discussion forums at SourceForge seemed a bit quiet, so I decided to try this instead. Ok, here goes. How do I get a proper list of all accepted video modes using PySDL? I just want to verify that a specific mode can be used with a certain depth. I tried the following code to get some info: #!/usr/bin/python import sdl sdl.init(sdl.INIT_VIDEO) print sdl.video_list_modes(16, sdl.FULLSCREEN) print sdl.video_list_modes(0, sdl.SWSURFACE) print "INFO_HW_A: " + `sdl.video_info ( sdl.INFO_HW_A )` print "INFO_WM_A: " + `sdl.video_info ( sdl.INFO_WM_A )` print "INFO_BLT_HW: " + `sdl.video_info ( sdl.INFO_BLT_HW )` print "INFO_BLT_HW_CC: " + `sdl.video_info ( sdl.INFO_BLT_HW_CC )` print "INFO_BLT_HW_A: " + `sdl.video_info ( sdl.INFO_BLT_HW_A )` print "INFO_BLT_SW: " + `sdl.video_info ( sdl.INFO_BLT_SW )` print "INFO_BLT_SW_CC: " + `sdl.video_info ( sdl.INFO_BLT_SW_CC )` print "INFO_BLT_SW_A: " + `sdl.video_info ( sdl.INFO_BLT_SW_A )` print "INFO_BLT_FILL: " + `sdl.video_info ( sdl.INFO_BLT_FILL )` print "INFO_MEM: " + `sdl.video_info ( sdl.INFO_MEM )` The result from the video_list_modes is always a plain 0. Like this: % ./sdl_info.py 0 0 INFO_HW_A: 0 INFO_WM_A: 1 INFO_BLT_HW: 0 INFO_BLT_HW_CC: 0 INFO_BLT_HW_A: 0 INFO_BLT_SW: 0 INFO_BLT_SW_CC: 0 INFO_BLT_SW_A: 0 INFO_BLT_FILL: 0 INFO_MEM: 0 This seems a bit wrong, so what do I do wrong, or what do I not understand properly? Mainly I'd like to know wether 1024x768 can be opened on the used system, and what depth I can get. Acceleration info could be of some interest too, but not necessary. What is the proper forum for discussion about applications using PySDL or different techniques? I think it would be nice to be able to share ideas and get some help. I'm not that experienced in lowlevel surface handling as needed by SDL (and PySDL). Transparency is for instance one thing that would be nice to learn more about. Is there any publicly available PySDL applications that I could use to see how others have done things? Regards, Chakie --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Pete S. <pe...@vi...> - 2000-09-11 17:45:52
|
> I'm having some small problems with PySDL, but I'm not sure this is the
> correct forum. The regular discussion forums at SourceForge seemed a bit
> quiet, so I decided to try this instead.
>
> Ok, here goes.
>
> How do I get a proper list of all accepted video modes using PySDL? I just
> want to verify that a specific mode can be used with a certain depth. I
> tried the following code to get some info:
this is the best place to come for pysdl help and info.
(unless i'm seriously missing out on something :] )
sdl.video_list_modes(...) will return 0 if the call to
SDL_ListModes(...) returns NULL. my guess is that the
"C" version takes an entire PixelFormat structure, which
is more information that just bpp. because pysdl video_list_modes
is not setting the rest of the PixelFormat structure, SDL
is returning no results.
ugh, this is one of my beefs with current pysdl, the "C"
versions of the functions are usually a lot more flexible
(taking NULL pointers for default/best argument in many cases,
it would be great if pysdl could take "None" as a substitute.
owell, it will likely happen one day)
well jan, i'm guessing you're one of the first person even
using the video_list_modes. the good news is that SDL does
a really good job of emulating any requested video modes you
ask for (ie, setting a slightly larger resolution and just
using a black border to make up the difference. also handling
bpp differences for you automatically.)
unlike using directx or related libraries, with SDL you can
just request any mode and SDL will likely do it, adjusting
what it needs to automatic, but keeping everything on the
programmer end exactly what you wanted.
at this point, i'm not sure what's up with Mark Baker (the
pysdl maintainer) it's been awhile since i've gotten anything
back from him. if SDL 1.1.5 comes out with no word from Mark
i'm going to take a stab at updating the pysdl source with all
the new features. (i'll probably look deeper into this routine
for you also)
for now, i'd just hardcode a small list of screen modes for
your app. just pick the standards, and assume you won't have
any problems. (likely, you wont)
def fake_list_modes(bpp, flags):
"substitute this until sdl.video_list_modes is working, sorry"
return [(0, 0, 640, 680), (0, 0, 600, 800), (0, 0, 1024, 768)]
|
|
From: Jan E. <ch...@in...> - 2000-09-11 18:55:23
|
On Mon, 11 Sep 2000, Pete Shinners wrote: >this is the best place to come for pysdl help and info. >(unless i'm seriously missing out on something :] ) Good. Sometimes 'devel'-lists are meant for those developing on a certain product. Questions from 'users' on those lists are not always welcome. >sdl.video_list_modes(...) will return 0 if the call to >SDL_ListModes(...) returns NULL. my guess is that the >"C" version takes an entire PixelFormat structure, which >is more information that just bpp. because pysdl video_list_modes >is not setting the rest of the PixelFormat structure, SDL >is returning no results. Ok, because whatever I tried feeding to it the function just returned 0. Well, I can manage without it, as I just aim for 1024x768 fullscreen or windowed (togglable by the player). That resolution should be available on almost any hardware today, and if it isn't I think Python is too slow on it anyway... :-) >well jan, i'm guessing you're one of the first person even >using the video_list_modes. Always a pioneer. >at this point, i'm not sure what's up with Mark Baker (the >pysdl maintainer) it's been awhile since i've gotten anything >back from him. if SDL 1.1.5 comes out with no word from Mark >i'm going to take a stab at updating the pysdl source with all >the new features. (i'll probably look deeper into this routine >for you also) This sounds good. I just started using Python 2.0, and the old modules don't work with it, including pysdl. So far I use 1.52 for the development of the parts that use pysdl, and 2.0 for the parts that rely on the new XML handling. It would be nice if there would be a Python 2.0 version of pysdl some day. I have no idea as to how hard it is to do the port, but I hope it's not impossible? >for now, i'd just hardcode a small list of screen modes for >your app. just pick the standards, and assume you won't have >any problems. (likely, you wont) I need only one resolution, 1024x768. I merely wanted to be able to check the possibility of using that mode before having pysdl try to initialize it. Later I think multiple resolutions should be possible, but that is in a later version. One has to start easy and get something simple that works and then build upon it. Thanks a lot for your help! Btw, I figured out how to use transparency. My png:s have a transaprent color, so it was just a matter of calling the method set_colorkey() (if I remember the name correctly), and it all worked ok. Regards, Chakie --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Mark B. <mb...@0x...> - 2000-09-11 20:11:13
|
On Mon, 11 Sep 2000, Pete Shinners wrote: > > I'm having some small problems with PySDL, but I'm not sure this is the > > correct forum. The regular discussion forums at SourceForge seemed a bit > > quiet, so I decided to try this instead. > > > > Ok, here goes. > > > > How do I get a proper list of all accepted video modes using PySDL? I just > > want to verify that a specific mode can be used with a certain depth. I > > tried the following code to get some info: > > this is the best place to come for pysdl help and info. > (unless i'm seriously missing out on something :] ) > > sdl.video_list_modes(...) will return 0 if the call to > SDL_ListModes(...) returns NULL. my guess is that the > "C" version takes an entire PixelFormat structure, which > is more information that just bpp. because pysdl video_list_modes > is not setting the rest of the PixelFormat structure, SDL > is returning no results. You'd guess wrong. If you were to read the source code for the various SDL mode enumeration functions, you'd see this. This would probably be a curteous step, before misinforming people as to why something doesn't work as they expect. > at this point, i'm not sure what's up with Mark Baker (the > pysdl maintainer) it's been awhile since i've gotten anything > back from him. if SDL 1.1.5 comes out with no word from Mark > i'm going to take a stab at updating the pysdl source with all > the new features. (i'll probably look deeper into this routine > for you also) I have not been available to contact, until about yesterday. I have a lot to catch up on, but I've read the last letter you've sent me. I don't currently see making a release of a multifile PySDL codebase as being overly important at this point. Indeed, I'd much rather get back to finishing what it was I was working on, before I left, rather then simply make a release that offered nothing in terms of functionality. However, if you would like to contribute patches to PySDL that included support for new releases of SDL, or anything else, you can feel free. The list is here, send away. |
|
From: Mark B. <mb...@0x...> - 2000-09-11 19:55:13
|
On Mon, 11 Sep 2000, Jan Ekholm wrote: > Hi there, > > I'm having some small problems with PySDL, but I'm not sure this is the > correct forum. The regular discussion forums at SourceForge seemed a bit > quiet, so I decided to try this instead. > > Ok, here goes. > > How do I get a proper list of all accepted video modes using PySDL? I just > want to verify that a specific mode can be used with a certain depth. I > tried the following code to get some info: If you peruse the SDL source code, you'll note that most of the underlying implementations for enumerating acceptable resolutions will always return -1 in non-fullscreen modes, for the current color depth. For the case where the current color depth is not the requested depth, or the requested dimension is not fullscreen, it will return 0. The exceptions are at least SVGAlib, and probably any of the others not natively capable of a non-fullscreen mode. There is also a bug in PySDL's video_modes_list function, but this does not involve inaccurate returns. After taking a look at it, in order to ensure that I hadn't done anything too erroneous. I did, however, notice this: while(rects_ref != NULL) (*rects_ref)++; These are backwards. It should be: while(*rects_ref != NULL) rects_ref++; I have no explaination as to why I did this, but I imagine it may be in part related to not removing all of the original implementation I had written, or perhaps brain damage. Had anyone actually utilized this function with sdl.FULLSCREEN as an option, or for one of the raw framebuffer implementations, they'd've found that bug to be quite irritating. Indirectly, they have you to thank for its repair. ;-) |
|
From: David C. <si...@te...> - 2000-09-11 20:39:17
|
Jan Ekholm writes: > > Hi there, > > I'm having some small problems with PySDL, but I'm not sure this is the > correct forum. The regular discussion forums at SourceForge seemed a bit > quiet, so I decided to try this instead. This is the only real forum for pySDL issues, so it's fine to post here. If anyone can get write access to sourceforge, perhaps we should get rid of the forums, since the mailing list seems to be what we need right now? > How do I get a proper list of all accepted video modes using PySDL? I just > want to verify that a specific mode can be used with a certain depth. I > tried the following code to get some info: >snip code< I haven't found sdl.video_list_modes() to be all that helpful, really. I mainly use sdl in windowed modes, but if I needed to do what you're trying to do, I'd use sdl.video_mode_ok(), and try it with each resolution I was interested in. It's not ideal, I know. > > What is the proper forum for discussion about applications using PySDL or > different techniques? I think it would be nice to be able to share ideas > and get some help. I'm not that experienced in lowlevel surface handling > as needed by SDL (and PySDL). Transparency is for instance one thing that > would be nice to learn more about. The SDL mailing list is really good for this stuff, although they mainly talk C there. http://www.lokigames.com/ml/sdl/ You can also try the #SDL channel at irc.openprojects.net, where I hang around from time to time as Futility. > Is there any publicly available PySDL applications that I could use to see > how others have done things? I've written a few things you could look at, but I'd mainly recommend Pete Shinners's version of pyAliens - it's good, fast, compact and readable. I'd like to see it get incorporated into a demo directory in the pySDL distribution, if possible. http://www3.telus.net/futility/futility/software.html (Look near the bottom.) David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Jan E. <ch...@in...> - 2000-09-12 06:01:05
|
On Mon, 11 Sep 2000, David Clark wrote: >I haven't found sdl.video_list_modes() to be all that helpful, >really. I mainly use sdl in windowed modes, but if I needed to do what >you're trying to do, I'd use sdl.video_mode_ok(), and try it with each >resolution I was interested in. It's not ideal, I know. This works fine. >I've written a few things you could look at, but I'd mainly recommend >Pete Shinners's version of pyAliens - it's good, fast, compact and >readable. I'd like to see it get incorporated into a demo directory in >the pySDL distribution, if possible. Hah, this was exactly what I needed. As I'm new to both SDL and pysdl there is a lot to learn about how to do things in sdl. For instance the update_rects() should be better than always updating the entire display. Is there a real benefit from converting surfaces to the native format with convert_display()? I assume there is, as otherwise the normal SDL would not have included it. I'm not working on a fps game, but slowpaced strategic game, but the amounts of gfx that may need updating every now and then can be very large (scrolling around the map etc). And yes, if anyone likes those kinds of games I'm interested in discussing methods for making them look and play good using pysdl. Anyway, I'm off to experimenting with my newfound knowledge. I'll rip pyaliens to parts and start playing with it a little. :-) I appreciate the swift and good help I got here, so I think I'll hang around on this list. Regards, Chakie --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Pete S. <pe...@vi...> - 2000-09-12 17:19:30
|
> Hah, this was exactly what I needed. As I'm new to both SDL and pysdl > there is a lot to learn about how to do things in sdl. For instance the > update_rects() should be better than always updating the entire display. > > Is there a real benefit from converting surfaces to the native format with > convert_display()? I assume there is, as otherwise the normal SDL would > not have included it. I'm not working on a fps game, but slowpaced > strategic game, but the amounts of gfx that may need updating every now > and then can be very large (scrolling around the map etc). And yes, if > anyone likes those kinds of games I'm interested in discussing methods for > making them look and play good using pysdl. the convert_display() call is probably one of the most important in terms of speed. especially if you're doing a lot of blitting. you should have every graphic surface converted to the same format as the display surface. the only exception to this would be any surfaces where you're manipulating the pixels yourself. but this is pretty rare in python, and in most cases, the map_rgb() will work fine. i'm sure interested to see what you're putting together. don't be a stranger :] |
|
From: David C. <si...@te...> - 2000-09-12 18:33:45
|
Jan Ekholm writes: > > Hah, this was exactly what I needed. As I'm new to both SDL and pysdl > there is a lot to learn about how to do things in sdl. For instance the > update_rects() should be better than always updating the entire display. Most of the time, this is true. At a certain point, you have so many rects that just doing the whole screen at once is quicker. > Is there a real benefit from converting surfaces to the native format with > convert_display()? I assume there is, as otherwise the normal SDL would > not have included it. I'm not working on a fps game, but slowpaced > strategic game, but the amounts of gfx that may need updating every now > and then can be very large (scrolling around the map etc). And yes, if > anyone likes those kinds of games I'm interested in discussing methods for > making them look and play good using pysdl. In my experience, calling convert_display() is always a big win. It creates a very short delay when loading graphics from disk, but increases blit speeds by (in my case) about 50%. My current project is a turn-based, hexmap-based naval warfare game. I'd be pleased to discuss techniques for writing strategic games off-list. In the meantime, might I suggest the following resources: Amit's Game Programming Information (excellent): http://www-cs-students.stanford.edu/~amitp/gameprog.html Tile Based Games: http://www.geocities.com/SiliconValley/Vista/6774/TileBased.html Graphics Programming: http://nondot.org/sabre/graphpro/ Game Programming with Direct X: http://www.geocities.com/SoHo/Lofts/2018/djdirectxtut.html Computer Graphics Topics: http://www.cc.gatech.edu/gvu/multimedia/nsfmmedia/cware/graphics/toc.html The comp.graphics.algorithms FAQ: http://www.bookcase.com/library/faq/archive/graphics/algorithms-faq.html -- David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
×
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