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: Jan E. <ch...@in...> - 2000-09-18 08:35:48
|
On Sun, 17 Sep 2000, Pete Shinners wrote:
>--- should rects return nonzero if only one of width or
>height is 0? with a zero width or height, SDL isn't going
>to do anything during blits or fills. on the other hand,
>there is some size info still in there, this may be helpful
>in some cases.
><<rect will return nonzero only if both width and height
>are nonzero>>
IMO a rect with 0 height or width is valid. I could think of situations
where a rect needs to shrink for some reason until is is just a line with
no width/height. No blits would be done, of course.
>--- operator math? i've been trying to think of clean and
>useful cases to add operator math to the rectangle. (+-*%).
>it could be useful for "rect += (10, 40)" to move a
>rectangle. but there is effort needed to define all
>the cases with clean and consistent usage
><<not planning for this (at least in first release). if
>someone really wants this stuff, please compile a list
>of all the operators you'd like to use, as well as what
>types of arguments they can take and what the results
>should be>>
Personally I think I'd so far like plain methods for doing these kind of
things, such as resize(), move() etc. But I'm not too experieced with
Python yet, but in C++ I'd do it with methods.
>--- when changing rectangle attributes, should the rect
>automatically try to maintain non-negative values?
><<i'm currently planning to have the rect automatically fix
>negative sizes. yes, there's potential for confusion, but i
>can't think of a good case where one would actually want to
>keep the negative value. plus all of the rects method results
>become undefined when fed rects with negative sizes. so best
>to take the extra step to avoid them>>
Either automatically or then throw an exception. I'd maybe prefer to have
an exception, as "flipping" a rect indicates an error from the programmer.
>--- what should the return values/modification behavior be
>for all of the rectangle methods. in the standard python
>modules, the usual rule is, if a method changes the values
>of "self", then it returns none. otherwise the method returns
>a new object with the result of the changes, the original goes
>unchanged. (a potential third option is to change the original
>and return a reference to the original). ok, since this is
>the most important one i want to make sure everyone understands
>the full effects of this. for the method rect.clip, we have
>three main strategies.
>rect.clip can just change the rectangle it is working on ("self")
> and return nothing.
>rect.clip can create a new rectangle with the results and return
> that.
>rect.clip can modify "self" and return a reference to itself.
>ok, the three options may not sound to different, here are the
>CONS for each approach
>"Only Change Self": with this approach, everytime you want
> to change something about a rect, it takes a separate
> line. some things can require a couple steps, and it
> makes it impossible to send values to functions with
> 'on the fly' changes'. think of the list methods, like
> list.sort(), etc.
I'd like to use this way of doing things.
I look forward to be able to test your new class, as it can make
gui-making a lot easier.
--------------------+--------------------------------------------------------
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...@sh...> - 2000-09-18 05:44:22
|
> Is the source to pysdl ever going to end up in cvs? > Attached is a patch for what appears to be a memory leak in the > event polling/waiting functions. this is a good question. i saw this leak also, and reported it as a bug to Mark last week. i've got another submittal waiting with no response as well. for now i've decided to wait off on working with the "core" pysdl, since development seems backed up. |
|
From: Ray K. <rh...@ne...> - 2000-09-18 03:01:59
|
Attached is a patch for what appears to be a memory leak in the event polling/waiting functions. When running cowtipping without the patch, it would leak 4k approximately every 5 seconds. With the patch installed I let cowtipping run over night (I changed it so that cows were killed when they reach the left edge of the screen) without a change in memory size. |
|
From: Ray K. <rh...@ne...> - 2000-09-18 01:20:00
|
Is the source to pysdl ever going to end up in cvs? |
|
From: Pete S. <psh...@me...> - 2000-09-18 01:07:31
|
ok, i'm finishing up the rectangle class. as i finish up, i'd
like to get some quick help thinking some of the design through.
i'll start off with the quicker ones. my current thoughts
are at the end of each consideration in << >>
everyone please go ahead and doublecheck my logic
--- should rects return nonzero if only one of width or
height is 0? with a zero width or height, SDL isn't going
to do anything during blits or fills. on the other hand,
there is some size info still in there, this may be helpful
in some cases.
<<rect will return nonzero only if both width and height
are nonzero>>
--- operator math? i've been trying to think of clean and
useful cases to add operator math to the rectangle. (+-*%).
it could be useful for "rect += (10, 40)" to move a
rectangle. but there is effort needed to define all
the cases with clean and consistent usage
<<not planning for this (at least in first release). if
someone really wants this stuff, please compile a list
of all the operators you'd like to use, as well as what
types of arguments they can take and what the results
should be>>
--- when changing rectangle attributes, should the rect
automatically try to maintain non-negative values?
SDL is not happy with negative sized rectangles. so it
would be nice to try to avoid them alltogether. nonetheless
when a rect goes behind the scenes and changes your all your
numbers, things can get a bit confusing. there are a couple
ways to handle this. here's the test case... say we have a
rectangle with values "rect(10, 10, 100, 100)". this rectangle
spans from column 10 to 110 (width=100). let's say the user
changes the left edge to 200, "rect.left = 200". we have a
couple ways of handling this. the main plan with these rect
attributes is that changing one edge doesn't effect any of
the others (therefore, the right edge shouldn't move).
without any special handling, the resulting rectangle is
"rect(200, 10, -90, 100)". now we can either leave it like
this, or automatically flip the reverse width, to give us
rect(110, 10, 90, 100)". Now this is technically probably
what we'll end up wanting, but we just set the left edge to
200, and it comes back as 110. would this end up too confusing?
>>> rect.left = 200
>>> print rect.left
110
maybe i'm putting too much worry into this? the other last
minute option is to set the width to 0 when one of the edges
crosses over the other?
<<i'm currently planning to have the rect automatically fix
negative sizes. yes, there's potential for confusion, but i
can't think of a good case where one would actually want to
keep the negative value. plus all of the rects method results
become undefined when fed rects with negative sizes. so best
to take the extra step to avoid them>>
(whew, last one, and probably most important. send feedback!)
--- what should the return values/modification behavior be
for all of the rectangle methods. in the standard python
modules, the usual rule is, if a method changes the values
of "self", then it returns none. otherwise the method returns
a new object with the result of the changes, the original goes
unchanged. (a potential third option is to change the original
and return a reference to the original). ok, since this is
the most important one i want to make sure everyone understands
the full effects of this. for the method rect.clip, we have
three main strategies.
rect.clip can just change the rectangle it is working on ("self")
and return nothing.
rect.clip can create a new rectangle with the results and return
that.
rect.clip can modify "self" and return a reference to itself.
ok, the three options may not sound to different, here are the
CONS for each approach
"Only Change Self": with this approach, everytime you want
to change something about a rect, it takes a separate
line. some things can require a couple steps, and it
makes it impossible to send values to functions with
'on the fly' changes'. think of the list methods, like
list.sort(), etc.
"Create New Rect": the drawback to this style, if you want to
simply change the values of a rectangle, you need to make
an extra assignment. "rect = rect.clip()"
"Change and return self": the problem here is it becomes very
ambiguous, and goes against the 'unwritten' python standards.
it makes a compromise between the other two styles.
<<my (unfinal) decision is for all methods to not change
themselves, but return a new rectangle with the results. this
gives the user undoubtedly the most flexibility, the only drawback
being you must reassign a rectangle to its method to change it
in place>>
anyways, don't be afraid to send in your opinions that are different
that what i've got here. i'm opened minded about all this, and would
love some help discussing some of these options all the way through.
(ie, it just struck me i haven't thought at all about needs for GUI)
the good news is it's really easy for me to switch between any
of these styles, but it'd be nice to nail it all down before
a first release. (hard to change after that for other reasons :])
|
|
From: Pete S. <pe...@vi...> - 2000-09-14 20:33:02
|
> After a brief flirtation with windowed mode and wxWindows, > I've decided to go the minimal custom gui route. I'll be > implementing it in python, and I've never done a gui before, > so no promises as to its quality or general usefulness. I'll > be implementing only what I need for my game at first, and > with Assembly class starting tomorrow, I can't make any > promises about progress. If anyone with a higher level of > competence wants to take it on as a project, here are my > thoughts: your design sounds good. i think the best plan is to keep it simple. nothing too elaborate, just handles the simple cases really well. there are two main ways to do a simple UI like this, one is the method you outlined, and you seemed to hit all the big points perfectly. the other method involves using one bitmap to represent the whole "panel". to create the panel you usually provide two bitmaps of the whole panel. one in "idle" state and one in an "action" state. from there, each button is provided as a rectangle in the panel. to draw the panel you just blit the entire "idle" image. then go back and blit the areas for any buttons that are in action. i've done simple versions of both of these in C before. i can't really think that one method has a clear advantage over the other. (very balanced list of pro/con). i'd say write your UI however it will fit your game best. i just wanted to let you know about the other way of doing a similar ui. for long-term-flexibility, i'd say writing it the way you described is a better bet. heh, my one last tip of advice. when drawing all the buttons in the list, draw them in 'forward' order. but when checking for a button that the mouse is over, go through the list in 'reverse' order. doing it this way will help overlapping buttons behave correctly. (ps, you could also reverse the two procedures, so that buttons created first will be on top of later button) anyways david, it sounds like you've got everything nailed down for a good start. |
|
From: David C. <si...@te...> - 2000-09-14 19:50:13
|
Jan Ekholm asks: > > Speaing of GUI:s. Is there any ports of the SDL GUI toolkits ported to > > pysdl? Pete Shinners responds: > there was just a short discussion on this, this month. > check in the archives on sourceforge. as for summary... Yup. Check here for the thread titled pySDL gui?: http://www.geocrawler.com/lists/3/SourceForge/2768/25 After a brief flirtation with windowed mode and wxWindows, I've decided to go the minimal custom gui route. I'll be implementing it in python, and I've never done a gui before, so no promises as to its quality or general usefulness. I'll be implementing only what I need for my game at first, and with Assembly class starting tomorrow, I can't make any promises about progress. If anyone with a higher level of competence wants to take it on as a project, here are my thoughts: - Widget appearance should be completely custom. Controls in a video game might look like nearly anything, so a button instance should have two pngs associated with it: pressed and unpressed. I think this is more flexible than drawing a button containing a label or pixmap object. I think this is how Paragui does it. - Controls would be placed on Panels, which would receive events from the pySDL event subsystem (dispatching events to the panels would have to be done manually). From there on, the panels would dispatch the events to its member controls itself. A Panel could work as a dialog box or a persistant control panel, and could be a solid color, transparent or a bitmap. - The module would be a separate module from pySDL, so you could import it if and only if you needed it. Incidentally, Mr. Shinner's Rect class sounds like a good idea. Implementing it in C is best, and if we need to subclass it, we can just write a python interface class and subclass that. -- David Clark si...@te... Preliminary pySDL Documentation http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Jan E. <ch...@in...> - 2000-09-14 19:21:18
|
On Thu, 14 Sep 2000, Pete Shinners wrote: >If you end up banging one out, I know I'd like to see >the results. It sounded like David Clark was working on >some simple widgets for his own project. I think I may "bang out" something that works for me. If it will be usable for other people remains to be seen. I still have very experience with Python AND pysdl, so don't have too high hopes for somethign really good... :-) Pete: you don't need to reply directly to me, as I'm on the list, so I just end up with duplicates of every mail. --------------------+-------------------------------------------------------- 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...@sh...> - 2000-09-14 14:12:06
|
> Speaing of GUI:s. Is there any ports of the SDL GUI toolkits ported to > pysdl? I'd need something really simple, i.e. pushbuttons, a listbox and > similar. Yes, they are not hard to do using pysdl, but why reinvent the > wheel if someone else has already done something similar. Otherwise I'll > hack something that works for me. there was just a short discussion on this, this month. check in the archives on sourceforge. as for summary... Everyone seems to want a good gui class. unfortunately no one is really taken with any of the current SDL gui libraries (unfinished and in c++, so binding is tougher) If you end up banging one out, I know I'd like to see the results. It sounded like David Clark was working on some simple widgets for his own project. |
|
From: Jan E. <ch...@in...> - 2000-09-14 08:36:08
|
On Wed, 13 Sep 2000, Pete Shinners wrote: >ok, you're thinking.. a "rectangle" class? how basic is that? >Ha! well, here is what I'm gonna be writing starting tomorrow. >You might as well get your advice and good ideas in now while >the gettin's good. > >i wrote up a dizzying document to organize my thoughts and >make it clear to you guys what's coming. i plan to fully release >this and get it embedded into pysdl once it's ready. > >here it comes. probably not best to include the whole thing >in replies to the list :] This seems like a quite good idea. Should make sprites really easy to create and handle, as well as other highlevel features such as GUI widgets. Speaing of GUI:s. Is there any ports of the SDL GUI toolkits ported to pysdl? I'd need something really simple, i.e. pushbuttons, a listbox and similar. Yes, they are not hard to do using pysdl, but why reinvent the wheel if someone else has already done something similar. Otherwise I'll hack something that works for me. --------------------+-------------------------------------------------------- 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...@sh...> - 2000-09-14 06:29:19
|
ok, you're thinking.. a "rectangle" class? how basic is that?
Ha! well, here is what I'm gonna be writing starting tomorrow.
You might as well get your advice and good ideas in now while
the gettin's good.
i wrote up a dizzying document to organize my thoughts and
make it clear to you guys what's coming. i plan to fully release
this and get it embedded into pysdl once it's ready.
here it comes. probably not best to include the whole thing
in replies to the list :]
-----------------------------------------------------------------
sdl.Rect class proposal
Purpose: Now that I've gotten a good deal of pysdl developing
under my belt. I've noticed my strong need for a helpful
rectangle class. I was going to code it up in python,
(which is still a possibility). The idea to do it in
C struck me as a benefit, mainly because of optimizations.
I'm going to start coding it up soon, but thought I'd
iron out all my ideas, as well as present it for peer
review
Features: The most important feature will be for the class
to deal back and forth with lists and tuples seamlessly.
The other benefit will be that data is stored in the
SDL_Rect structure. so passing back and forth with
the SDL calls will require no conversions. Finally,
built in calls for collision detection and rectangle
merging will run much quicker in C than in python.
Also can make blitting more like C SDL_Blit, where
the blit() call will adjust the size of the destination
rect to the clipping area. (a feature we don't have now)
Cons: The only other option is to write the class in python.
Writing the class in python makes it easy to inherit from
and makes the code more accessible to other developers.
Finally: Well, in the long run, I feel i can take better advantage
of things and provide a more feature-full rectangle class
if it is done in C. (and more speed to boot) This is the
plan i'll be starting soon. I'm still open to outside wisdom
and advice, so get it in now.
The Class: Here's a list of methods and interfaces I'm planning
for. Here's where I'm hoping for the most peer-review :]
Rect(x, y, w, h) -> RectInstance
Rect((x, y), (w, h)) -> RectInstance
Rect((x, y, w, h)) -> RectInstance
Rect(RectInstance) -> RectInstance
Creating a new rectangle instance has a variety of
methods. This makes it most flexible in taking any
type of storage schemes
rect.top, rect.bottom, rect.left, rect.right -> Int
rect.width, rect.height -> Int
rect.topleft, rect.topright -> (Int, Int)
rect.bottomleft, rect.bottomright -> (Int, Int)
rect.center, rect.size -> (Int, Int)
the rectangle will contain a set of "virtual members"
which can be retreived and assigned to. this is one
of the features I really look forward too. assigning
one of these fields will move that field to the given
position (except for center, which will move the whole
rect, and size which will 'inflate' the whole rect)
<slicing, assignment, indexing, comparison>
the rectangle will be able to act and behave like a
standard list of 4 numeric elements. so you'll be able
to slice, index, and abuse it as if it were a standard
list object. (no append, insert, delete, etc) this will
allow you to pass a Rect where a function is expecting
a list or tuple of dimensions (fill_rect for instance).
indexing/slicing the rectangle will return results like
it was a list of [x, y, w, h]
__nonzero__ -> boolean
isempty() -> boolean
returns true if the rectangle size is (0, 0)
this will be the same result if the rectangle
is checked for nonzero ("if rect1 and not rect2:")
union(RectInstance) -> new RectInstance
returns a new rectangle that surrounds the current
and given rectangle
intersect(RectInstance) -> new RectInstance
returns a new rectangle of the overlapping area between
the current and given rectangle. returns an empty rect
if no overlap
cleanup(RectInstance) -> list of RectInstances
will return a list of all the rectangles needed to
fill the area of the two rectangles with no overlapping
parts (will always be at least 1 rect, usually 2, max of 3)
normalize() -> none
if the dimensions of the rectangle are negative, this will
swap things around, so the width and height are positive.
note that none of the pysdl or rectangle functions will
return a rectangle with negative size, although if passed
a negative sized rectangle the results are undefined.
i've never 'accidentally' created a negative sized rect,
but if you start doin some whacky math and aren't sure,
this makes an easy way to guarantee things are ok.
collidepoint((x, y)) -> boolean
returns true if the given position is inclusively inside
the rectangle
colliderect(RectInstance) -> boolean
returns true if the given rectangle overlaps this
rectangle. remember, you will be able to pass any
form of rectangle constructor, so you could easily
compare it to a list or tuple of rectangle values
collidelist([RectInstance, ...]) -> index int (-1 if nothing)
will return the index of the first rectangle that
intersects the current rectangle. having the rectangle
check against a list is better than looping over
a list of rectangles in a slower python loop.
(still trying to decide if i should allow for an
optional start/end range, i'm thinking so)
collidelistall([RectInstance, ...] -> [index, index, ...]
returns a list of all the indexes for the rectangles
the intersect with the current rectangle.
(same thing here with the start/end range)
well, thats it (or is it?) at first thought a rectangle class
may sound a bit trivial. but i've used good ones in the past
(in C, not python) and they can make life amazingly simple
i'm at the point where i'm really wanting one now, so i
figured i'd throw this all out there before coding it up
in my closet.
|
|
From: Pete S. <pe...@sh...> - 2000-09-14 05:07:12
|
> P.S. Pete do you have a version of pysdl with the > numpy surface transfer in it? I've been wanting to > play with bump-mapping and other stuff but I'm lazy > about it when I know it will be super slow. if you want my 'python 2.0 preview' with the quick numpy extension, i can put that together for you quick (tonight) if you want it for the ancient python 1.5.2, you might have to wait awhile (all my builds are now keyed into 2.0 with the latest cvs for sdl&friends) argh. worst of all, ever since numpy when to version 16.0 they've started including all this stuff i can't get compiled (so you'll be stuck with numpy-15.3, there's a good chance they'll be compatible for the stuff you'll be using) let me know how you want it served |
|
From: Peter N. <pn...@ya...> - 2000-09-14 04:51:26
|
That's no big surprise I guess -- what I read about python2c made it sound like a work in progress and you don't often get something for nothing. I think Mark was talking a while back about possibly adding functions to enable integrating PySDL into C programs for scripting -- probably a ways off if it happens, but I guess this would allow much of a program to be basically in Python but with the slowest parts moved to C. Anyway PySDL is really not that slow. It certainly can beat Director, and with hardware acceleration it can be pretty fast. Also I read that the different threading makes Python 2.0 a lot faster in Windows when not using threads, so maybe this will help? Speaking of Director the new image object in Director 8 is almost identical to an SDL surface, blitting syntax is basically the same except blits have an optional last argument for 'ink effects' which let you do different surface operations before copying to the destination. This kind of thing might be nice in PySDL, maybe the scripting stuff would make this feasible. P.S. Pete do you have a version of pysdl with the numpy surface transfer in it? I've been wanting to play with bump-mapping and other stuff but I'm lazy about it when I know it will be super slow. --Peter __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ |
|
From: Pete S. <pe...@vi...> - 2000-09-14 00:07:32
|
i've been experimenting with Python2C to see if there's any
chance for 'free' optimizations. sadly, it looks like this
isn't going to be the tool that helps many people.
all these results gotten from windows NT (using SDL's GDI driver)
i expect similar results across all platforms and drivers.
This was also all done with python 1.5.2. (i'm not sure of
python2c's compatibility with newer versions)
first, i tried python2c out on the stars examples that comes
with python ("sf"). the "C" version actually ended up about
2 fps slower than the python version. i doublechecked things
a couple times. the python version ran about 31fps, the
python2c version ran at 29fps.
not too encouraging there. i decided to try something a little
more "sprite-based". i tried getting it to work with my
pyaliens demo, but python2c was getting internal errors while
translating it, doh. i also tried it on David Clark's earlier
pyaliens-1.1, and while i did get it compiled, the code gave
me an "Interger Overflow Error" right after starting up.
needless to say, python2c doesn't look like it handle's all
python code.
just for sanity, i tried running python2c on "pystone", a
python runtime benchmarker. the python2c compiled code ran
about 1.3 times faster. (so it can speed up some code, heh)
(the gurus on comp.lang.python back this up once in awhile
stating that compiled python code won't gain that much
performance in most situations. it seems that's the case)
anyways, this seems to support the theory that most of your
game's runtime is spent inside the SDL library anyways. so
using SDL in python is not losing a whole lot to using SDL
in C. (woohoo!)
|
|
From: Jan E. <ch...@in...> - 2000-09-13 06:40:05
|
On Tue, 12 Sep 2000, Pete Shinners wrote: >ok, i got into the SDL CVS area and grabbed the latest >SDL_Image-1.0.10 and SDL_TTF-1.1.2. this is also compiled >with the current CVS of SDL-1.1.5. This is also compiled >with pysdl-0.0.7 and the standard SDL_mixer-1.0.6 A few minor upgrades. :-) >ohyeah, these are windows binaries only, sorry. >unzip the files into your python directory. it will >create a subdirectory with all the needed libraries. >it also creates an "sdl.pth" so python will use this >directory for all SDL goods. Ok. The binaries won't help me then, as I'm developing using Linux. Thank you anyway. I'll have a look wether there are official SDL RPM-files for the new versions and see wether I can get pysdl compiled myself. As the saying goes: "How hard could it be?" (famous last words). If anyone has a Linux module I'd be happy to test it out. --------------------+-------------------------------------------------------- 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...@sh...> - 2000-09-13 05:39:48
|
ok, i got into the SDL CVS area and grabbed the latest SDL_Image-1.0.10 and SDL_TTF-1.1.2. this is also compiled with the current CVS of SDL-1.1.5. This is also compiled with pysdl-0.0.7 and the standard SDL_mixer-1.0.6 quite a batch of libraries thrown in there. i've got it all compiled and working with python 2.0b1. This won't work with python 1.5.2 http://www.shinners.org/pete/py2preview_pysdl.zip note, there's likely some growing pains mixed in there with the meshing of different library versions. i know the image clipping won't work for you with this. but as far as i've tested, all the 'standard' features behave ohyeah, these are windows binaries only, sorry. unzip the files into your python directory. it will create a subdirectory with all the needed libraries. it also creates an "sdl.pth" so python will use this directory for all SDL goods. note that this will require you to rename/remove any "sdl.pyd" files in your python2 folder good luck, i'll help anyone out if there's trouble |
|
From: Jan E. <ch...@in...> - 2000-09-12 18:37:07
|
Hi again, If anyone has PySDL compiled for Python 2.0 I'd be happy to test it! I'm reaching a stage where I can no longer keep my 1.52 code (PySDL code) and other code separate (XML scenario handling). I need to be able to use PySDL to visualize the game data I've read in from XML. 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: 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 |
|
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: 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-11 23:25:32
|
Peter Nicolai wrote: > > I'd like to play around with this. It shouldn't be > too hard to flip the alpha channels on images as they > are loaded, right? no, i'd wager not. when this got submitted into SDL they mentioned SDL_image-1.0.10 was right behind it so i never bothered. still waiting for it though. > Just wondering... is there anything about python 2 > that jumps out at you as being a big improvement? It > seems pretty similar to 1.6 for such a big jump in > version number. well, Guido has mentioned a couple times that while there's a lot of new features for the new python, the 2.0 has more to do with the status of the new ownership of python (now owned by BeOpen). Guido also feels that python gets some bad mojo for being a 1.x release (heh, 10 years and still 1.5), so some of it is marketing as well. a well defined list of changes is found at http://www.pythonlabs.com/tech/python2.0/news.html. those are the changes since 1.6. 1.6 mainly added unicode and a new regexp module. the current plan is for the official python 2.0 release early next month (barring anything necessitating a 2nd beta or release candidate) the good news is pySDL seems to recompile just fine for the new release, so it will only benefit pySDL. (although i noticed the Py_Malloc and Py_Free macros were gone. didn't look into it, but quickly swapped them out with malloc and free) my testing has been admitedly limited to this point. |
|
From: Peter N. <pn...@ya...> - 2000-09-11 22:26:15
|
> well, if anyone's interested, i have a version of my > super-secret, unlreased source-split version of > pysdl ready > as a binary release for python 2.0b1 (win32). i've > been using > it for my testing and it works quite well. my big > grief with > it now is that it's using the latest CVS SDL and the > alpha- > slightly-incompatible SDL_image-1.0.9. so all image > alphas > are backwards. it's a pain using images with alphas > (for now) > but it does work with python2. if anyone wants, i'll > post the > binaries. I'd like to play around with this. It shouldn't be too hard to flip the alpha channels on images as they are loaded, right? Just wondering... is there anything about python 2 that jumps out at you as being a big improvement? It seems pretty similar to 1.6 for such a big jump in version number. __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ |
|
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: 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. ;-) |
