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: Martijn F. <fa...@ve...> - 2000-04-20 10:12:00
|
Mark Baker wrote: > SDL doesn't allow for hardware surfaces in X. The only exception I can think > of, is DGA, and only the main surface is in video memory. 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? Regards, Martijn |
|
From: Martijn F. <fa...@ve...> - 2000-04-20 10:10:34
|
David Clark <David Clark wrote: [snip] > Out of curiousity, is anyone able to create a HWSURFACE? Yeah, I've had no problems with that. Now what was my video card again.. I'm running a stock 6.1 Red Hat box at 1024x768 16 bits at home. Regards, Martijn |
|
From: David C. <D. C. <si...@te...> - 2000-04-20 03:06:07
|
Mark Baker writes (referring to the differences in blit speed between
PNGs and BMPs):
>
> I'm willing to bet that the speed difference in the blit, is due to the fact
> that surfaces aren't in the same format as the video surface before you blit.
> The blit function converts them at runtime, if it's not in the same format.
>
>
> Try changing
> src = sdl.image_load("./happy.png")
> to
> src = sdl.image_load("./happy.png").convert(fb, sdl.SWSURFACE)
>
> To be fair, you'll want to do it to the BMP, too. This should give comparable
> figures.
>
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.
Preliminary SDL documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html
--
----------------------------------------------------------------
David "Futility [D!]" Clark | Everyone's gotta be something.
si...@te... | Me, I'm garbage.
| It's all I've ever wanted to be.
| Shock me again, and I'll say
| anything you want me to. -MGB
|
|
From: Mark B. <mb...@0x...> - 2000-04-20 02:56:19
|
On Wed, 19 Apr 2000, "David Clark wrote:
> Ok, I've tried blitting the various file formats supported by
> image_load() and image_load_type(). My results:
>
> BMP: fine.
> JPG: fine.
> PNG: about 50% slower than bmps or jpgs.
> PCX: good speed, same as bmps and jpgs, but odd palette (yellows were
> blue)
> TIFF: failed to create surface: "RuntimeError: unable to allocate SDL
> surface" for image_load(), and "RuntimeError: unable to acquire file
> info" for image_load_type().
> PPM: untested
> GIF: untested (my copy of the Gimp doesn't output these types)
I'm willing to bet that the speed difference in the blit, is due to the fact
that surfaces aren't in the same format as the video surface before you blit.
The blit function converts them at runtime, if it's not in the same format.
TIFF support, though mentioned in SDL_image, is not yet implemented.
As such, you can't load TIFFs, yet. I may write a loder and send it to Sam
Lantinga, if I ever find time to.
Try changing
src = sdl.image_load("./happy.png")
to
src = sdl.image_load("./happy.png").convert(fb, sdl.SWSURFACE)
To be fair, you'll want to do it to the BMP, too. This should give comparable
figures.
|
|
From: David C. <D. C. <si...@te...> - 2000-04-20 02:33:45
|
Ok, I've tried blitting the various file formats supported by
image_load() and image_load_type(). My results:
BMP: fine.
JPG: fine.
PNG: about 50% slower than bmps or jpgs.
PCX: good speed, same as bmps and jpgs, but odd palette (yellows were
blue)
TIFF: failed to create surface: "RuntimeError: unable to allocate SDL
surface" for image_load(), and "RuntimeError: unable to acquire file
info" for image_load_type().
PPM: untested
GIF: untested (my copy of the Gimp doesn't output these types)
--
----------------------------------------------------------------
it's crowded and i feel lost in here
i'm trying to find a familiar fear
i look everywhere but i just can't see
there's not anything that reminds me of me
- Chantal Kreviazuk, Wayne
|
|
From: David C. <D. C. <si...@te...> - 2000-04-20 02:19:13
|
Mark Baker writes:
>
> > Blitting a png takes about 50% longer than an identical bmp. (Of
> > course, the png is compressed to 5% of the bmp's size :)
>
> Are you including the loading time? PNGs are decompressed on load, like all
> other image types, so after the load, it should blit at the same rate as a BMP.
>
The images were loaded to a non-visible surface before the timing
loop begins, so I believe there actually is a difference in blit rates
between PNGs and BMPs. Here's my (ugly) code:
<snip>
import sdl, random, sys, time
width = 640
height = 480
depth = 16
fb = sdl.video_set_mode(width, height, depth, sdl.SWSURFACE)
src = sdl.image_load("./happy.png")
#src = sdl.image_load("./happy.bmp")
start = time.time()
for i in range(500):
x_pos = (random.random() * (width * 0.9))
y_pos = (random.random() * (height * 0.9))
fb.blit(src, (0, 0, 64, 48), (x_pos, y_pos, 64, 48))
fb.update_rect((x_pos, y_pos, 64, 48))
# fb.update_rect( (0,0,0,0) )
end = time.time()
print "500 repetions took", end-start, "seconds."
print "That's", (end-start) * 2, "milliseconds per blit."
sdl.quit()
sys.exit(0)
<snip>
As you can see, pretty unsophisticated - I switched between options
just by uncommenting and recommenting code :) Anyway, I realize that
the timed loop is pretty full, but I was looking for relative numbers
here, not absolute measurements.
Preliminary pySDL documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html
--
-------------------------------------------------------------------------\
David "Futility [D!]" Clark | "Being healthy" is merely dying at the |
si...@te... | slowest possible rate. |
|
|
From: Mark B. <mb...@0x...> - 2000-04-20 02:07:36
|
On Wed, 19 Apr 2000, "David Clark wrote: > I was doing a little video testing, profiling large numbers of blits > to the framebuffer, and noticed a few interesting facts... > > A blit of a 7k bmp from one SWSURFACE to another took less than a > millisecond. Woohoo! > > update_rect((0,0,0,0)) is expensive, but not prohibitivly so. Updating > a 640 x 480 surface all at once only took about 20 times longer than > updating a 64 x 48 rectangle, in spite of the fact that the surface is > 100 times bigger than the rectangle. Well this is good. SDL is fairly speedy, all things considered, and I've heard good things about the V3 X server. It's my hope we won't get too much in the way, with PySDL. > Blitting a png takes about 50% longer than an identical bmp. (Of > course, the png is compressed to 5% of the bmp's size :) Are you including the loading time? PNGs are decompressed on load, like all other image types, so after the load, it should blit at the same rate as a BMP. > Out of curiousity, is anyone able to create a HWSURFACE? I'm simply > unable, using the setup below. I realize this is kind of off topic, so > feel free to ignore this question :) SDL doesn't allow for hardware surfaces in X. The only exception I can think of, is DGA, and only the main surface is in video memory. |
|
From: David C. <D. C. <si...@te...> - 2000-04-20 01:52:20
|
I was doing a little video testing, profiling large numbers of blits to the framebuffer, and noticed a few interesting facts... A blit of a 7k bmp from one SWSURFACE to another took less than a millisecond. Woohoo! update_rect((0,0,0,0)) is expensive, but not prohibitivly so. Updating a 640 x 480 surface all at once only took about 20 times longer than updating a 64 x 48 rectangle, in spite of the fact that the surface is 100 times bigger than the rectangle. There was no performance difference between windowed and fullscreen drawing. Blitting a png takes about 50% longer than an identical bmp. (Of course, the png is compressed to 5% of the bmp's size :) Out of curiousity, is anyone able to create a HWSURFACE? I'm simply unable, using the setup below. I realize this is kind of off topic, so feel free to ignore this question :) i586 Celeron 525 Voodoo3 video card XFree86 3.3.5 Kernel 2.2.12 SVGA video driver Preliminary pySDL documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html -- 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-19 22:57:47
|
On Wed, 19 Apr 2000, Martijn Faassen wrote: > I'm still not convinced we can't simply accept the slower option if that > makes the API more clean. That's generally the Python approach, after all. You don't have to worry, since I've no intentions of using strings as a source of data, regardless of the paticular performance benefit it offers for MetaKit. StringIO can be used, if people really want to use strings this way. This is the best aspect of Eric's patch. |
|
From: Martijn F. <fa...@ve...> - 2000-04-19 18:17:53
|
Eric Jacobs wrote: > > > Loading from strings directly doesn't seem necessary to me either; you can > > easily use StringIO or cStringIO to wrap the string up as a file-like > > object after all? > > Yes. > > I included that solely on account of performance, not functionality. I've > been doing some cursory testing; it seems that for large images (I used a > 62k 800x600 RGB PNG) it takes roughly the same amount of time whichever > method you load it with, from MetaKit or from the filesystem. But with > small images (an assortment of PNGs from 100 bytes to about 2K), I found > that MetaKit can approach the performance of the filesystem, but only > by loading the image as a string; the amount of data used constructing and > deconstructing wrappers was high relative to the actual amount of image > data being transferred. What about wrapping cStringIO around the string? Have you tried that? > The function overloading is ugly but necessary in this case, especially as > more functions are implemented that use SDL_RWops. I would hate to see the > size of the API mushroom as little functions are multiplied to cover every > little case. I'm still not convinced we can't simply accept the slower option if that makes the API more clean. That's generally the Python approach, after all. Hopefully soon I'll get some time to study all this myself, though. :) Regards, Martijn |
|
From: Mark B. <mb...@0x...> - 2000-04-19 18:00:33
|
On Wed, 19 Apr 2000, Martijn Faassen wrote: > Mark Baker wrote: > So it'll accept both file objects and filenames. > That's overloading it. It's confusing if you can put a filename string into > a function *and* a file object. I'd rather have two differently > named functions, one for the filename string, one for the file object. > Or just the latter; it's trivial to do an open() myself, after all. Yes, it will accept both filenames and file-like objects. If you don't want to supply filenames, then you don't have to. > > For languages like C++, function overloading using different types is common > > place. Though these are through seperate functions, in C++, the internal > > representation to the user of PySDL isn't overly important. > > I know C++ allows stuff like this, but that doesn't mean we should > apply it here. :) I think it pollutes the API to do this, and it just > doesn't seem necessary. I understand it already works like that, so in > that case I'm complaining about the current functionality (I haven't > experimented with it yet). Python also allows for this as well, in a somewhat less 'clean' manner, via type() and the types module. Inspecting an object for read, write, seek, etc methods is no more type pure, either. Does anyone else feel strongly against this? I could change it, I simply see no real reason to. I would simply remove the ability to load from a filename entirely, and leave it to people to manage their files. Seems pointless to me, but I'd like to hear what the consensus is first. |
|
From: Eric J. <ea...@ri...> - 2000-04-19 17:59:44
|
> Loading from strings directly doesn't seem necessary to me either; you can > easily use StringIO or cStringIO to wrap the string up as a file-like > object after all? Yes. I included that solely on account of performance, not functionality. I've been doing some cursory testing; it seems that for large images (I used a 62k 800x600 RGB PNG) it takes roughly the same amount of time whichever method you load it with, from MetaKit or from the filesystem. But with small images (an assortment of PNGs from 100 bytes to about 2K), I found that MetaKit can approach the performance of the filesystem, but only by loading the image as a string; the amount of data used constructing and deconstructing wrappers was high relative to the actual amount of image data being transferred. The function overloading is ugly but necessary in this case, especially as more functions are implemented that use SDL_RWops. I would hate to see the size of the API mushroom as little functions are multiplied to cover every little case. |
|
From: Martijn F. <fa...@ve...> - 2000-04-19 17:13:29
|
Mark Baker wrote: > On Wed, 19 Apr 2000, Martijn Faassen wrote: > > I think we shouldn't overload the load function too much. Can't we > > instead have two functions, one to load from a file object, and another > > to load through a filename? Or perhaps just don't have the last one > > at at all; it's not hard to create a file object after all. Generally > > it's better to have multiple functions instead of one function which > > can receive an argument that can be fundamentally different types (such as > > strings or file-like objects). > > The load function will remain the same, API wise. So it'll accept both file objects and filenames. That's overloading it. It's confusing if you can put a filename string into a function *and* a file object. I'd rather have two differently named functions, one for the filename string, one for the file object. Or just the latter; it's trivial to do an open() myself, after all. > For languages like C++, function overloading using different types is common > place. Though these are through seperate functions, in C++, the internal > representation to the user of PySDL isn't overly important. I know C++ allows stuff like this, but that doesn't mean we should apply it here. :) I think it pollutes the API to do this, and it just doesn't seem necessary. I understand it already works like that, so in that case I'm complaining about the current functionality (I haven't experimented with it yet). > > Loading from strings directly doesn't seem necessary to me either; you can > > easily use StringIO or cStringIO to wrap the string up as a file-like > > object after all? > > I agree. Polluting the API isn't worth the hassle, and its use is fairly > limited. But it's already polluted now. :) This is just confusion: f = "foo.bmp" load(f) and this: f = "foo.bmp" f = open(f, "r") load(f) It should just accept one and not the other. It shouldn't be too smart and try to guess what the user meant; Python isn't Perl after all. It should complain as soon as it gets a string. > > From what I understood from the example, it seems 'file like' objects > > are supported already, as I saw StringIO being used, right? > > In my implementation, file objects are supported. This is a direct type check > in the module, so it doesn't support non-file objects with the same relative > API. > Eric Jacob's patch adds "file-like" object support, via inspecting the object > passed to the various load functions, and determining if they have > read/seek/etc methods; this is why StringIO works in his example. That would indeed be an improvement. Regards, Martijn |
|
From: Mark B. <mb...@0x...> - 2000-04-19 16:06:59
|
On Wed, 19 Apr 2000, Martijn Faassen wrote: > I think we shouldn't overload the load function too much. Can't we > instead have two functions, one to load from a file object, and another > to load through a filename? Or perhaps just don't have the last one > at at all; it's not hard to create a file object after all. Generally > it's better to have multiple functions instead of one function which > can receive an argument that can be fundamentally different types (such as > strings or file-like objects). The load function will remain the same, API wise. For languages like C++, function overloading using different types is common place. Though these are through seperate functions, in C++, the internal representation to the user of PySDL isn't overly important. > Loading from strings directly doesn't seem necessary to me either; you can > easily use StringIO or cStringIO to wrap the string up as a file-like > object after all? I agree. Polluting the API isn't worth the hassle, and its use is fairly limited. > From what I understood from the example, it seems 'file like' objects > are supported already, as I saw StringIO being used, right? In my implementation, file objects are supported. This is a direct type check in the module, so it doesn't support non-file objects with the same relative API. Eric Jacob's patch adds "file-like" object support, via inspecting the object passed to the various load functions, and determining if they have read/seek/etc methods; this is why StringIO works in his example. |
|
From: Martijn F. <fa...@ve...> - 2000-04-19 13:09:24
|
Mark Baker wrote: > On Tue, 18 Apr 2000, Eric Jacobs wrote: > > I have a patch for PySDL 0.0.3 to allow any Python > > file-like object to be loaded or saved as an image. > > It also allows strings to be loaded as data. This > > could be useful for games and other programs that > > might not want to store all of their images in > > individual files. > > I'll need to think about the real need of the introspection, but it seems like > it'd be good to not only support file object, but "file-like" objects, as well. > You mention MetaKit, for instance, which could alleviate hassles of back-end > management. > > Using strings as a source of data, though, seems less useful. Flexible, > perhaps, but it's not worth making the API nasty with an optional argument > indicating whether a string is a filename, or a source of data. I think we shouldn't overload the load function too much. Can't we instead have two functions, one to load from a file object, and another to load through a filename? Or perhaps just don't have the last one at at all; it's not hard to create a file object after all. Generally it's better to have multiple functions instead of one function which can receive an argument that can be fundamentally different types (such as strings or file-like objects). Loading from strings directly doesn't seem necessary to me either; you can easily use StringIO or cStringIO to wrap the string up as a file-like object after all? From what I understood from the example, it seems 'file like' objects are supported already, as I saw StringIO being used, right? Regards, Martijn |
|
From: Mark B. <mb...@0x...> - 2000-04-19 04:25:36
|
On Tue, 18 Apr 2000, Eric Jacobs wrote: > I have a patch for PySDL 0.0.3 to allow any Python > file-like object to be loaded or saved as an image. > It also allows strings to be loaded as data. This > could be useful for games and other programs that > might not want to store all of their images in > individual files. I'll need to think about the real need of the introspection, but it seems like it'd be good to not only support file object, but "file-like" objects, as well. You mention MetaKit, for instance, which could alleviate hassles of back-end management. Using strings as a source of data, though, seems less useful. Flexible, perhaps, but it's not worth making the API nasty with an optional argument indicating whether a string is a filename, or a source of data. > And I hope someone's reading this list, because I > didn't see any messages in the archives... ;) PySDL is a fairly new project. The mailing list archives apparently work on a monthly basis, so the contents of the last few weeks won't be archived for a while. Thanks for the contribution. I'll probably work it into the next release, and alter the sound subsystem (which I'm currently working on) to use it as well. |
|
From: Eric J. <ea...@ri...> - 2000-04-19 02:04:51
|
I have a patch for PySDL 0.0.3 to allow any Python
file-like object to be loaded or saved as an image.
It also allows strings to be loaded as data. This
could be useful for games and other programs that
might not want to store all of their images in
individual files.
So an image could be loaded any of these ways:
i = sdl.image_load("test.jpg")
i = sdl.image_load(open("test.jpg"))
i = sdl.image_load(open("test.jpg").read(), 1)
i = sdl.image_load(StringIO(open("test.jpg").read()))
The extra parameter is used to inhibit PySDL from
interpreting the string as a filename.
The functions that can work that way are: image_load,
image_is, image_load_type, and image_save_bmp. It
should be pretty easy to add support to any function
that uses SDL_RWops.
It works with MetaKit and Mk4py, in two ways:
taking the field straight out as a string, and
using the supplied MkMemoIO.py wrapper class as
a file-like object.
bugs/issues:
Saving to a string works, although it's not supposed
to (since strings are immutable.) Use StringIO or
cStringIO instead.
Exceptions are propagated, however the tracebacks are
sometimes a bit confusing because the actual callback
from C isn't traced. (When using native Python
objects.)
It's assumed that upon receiving an I/O error, SDL
will clean itself up and return an error, and not
try to recover or continue.
sure there's other things...
And I hope someone's reading this list, because I
didn't see any messages in the archives... ;)--spruceEVOHCFYNQPCNSDURERGN
Content-Type: application/octet-stream; name="sdl.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sdl.diff"
KioqIG9yaWcvc2RsbW9kdWxlLmMJVHVlIEFwciAxOCAxNzo1Njo0MiAyMDAwCi0tLSBzZGxtb2R1
bGUuYwlUdWUgQXByIDE4IDIwOjUxOjQxIDIwMDAKKioqKioqKioqKioqKioqCioqKiAyMywyOCAq
KioqCi0tLSAyMywxNjggLS0tLQogICNkZWZpbmUgbWF4KHgseSkgeCA+IHkgPyB4IDogeQogICNl
bmRpZgogIAorIHN0cnVjdCBQeXRob25fU0RMX1JXb3BzIHsKKyAJU0RMX1JXb3BzIGJhc2U7Cisg
CVB5T2JqZWN0ICpvYmo7CisgCVB5T2JqZWN0ICpzZWVrX21ldGhvZDsKKyAJUHlPYmplY3QgKnRl
bGxfbWV0aG9kOworIAlQeU9iamVjdCAqcmVhZF9tZXRob2Q7CisgCVB5T2JqZWN0ICp3cml0ZV9t
ZXRob2Q7CisgCVB5T2JqZWN0ICpjbG9zZV9tZXRob2Q7CisgCWludCBlcnJfc2V0OworIH07Cisg
Cisgc3RhdGljIGludCByd29wc19weXNlZWsoU0RMX1JXb3BzICpjb250ZXh0LCBpbnQgb2Zmc2V0
LCBpbnQgd2hlbmNlKSB7CisgCXN0cnVjdCBQeXRob25fU0RMX1JXb3BzICpydyA9IChzdHJ1Y3Qg
UHl0aG9uX1NETF9SV29wcyAqKSBjb250ZXh0OworIAlQeU9iamVjdCAqcmVzdWx0OworIAlpbnQg
cmV0dmFsOworIAkKKyAJaWYgKHJ3LT5lcnJfc2V0KSByZXR1cm4gLTE7CisgCWlmICghcnctPnNl
ZWtfbWV0aG9kKSB7CisgCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9yLCAiZmlsZSBv
YmplY3QgY2Fubm90IHNlZWsiKTsKKyAJCXJ3LT5lcnJfc2V0ID0gMTsKKyAJCXJldHVybiAtMTsK
KyAJfQorIAlpZiAoIXJ3LT50ZWxsX21ldGhvZCkgeworIAkJUHlFcnJfU2V0U3RyaW5nKFB5RXhj
X1R5cGVFcnJvciwgImZpbGUgb2JqZWN0IGNhbm5vdCB0ZWxsIik7CisgCQlydy0+ZXJyX3NldCA9
IDE7CisgCQlyZXR1cm4gLTE7CisgCX0KKyAJCisgCXJlc3VsdCA9IFB5T2JqZWN0X0NhbGxGdW5j
dGlvbihydy0+c2Vla19tZXRob2QsICJpaSIsIG9mZnNldCwgd2hlbmNlKTsKKyAJaWYgKCFyZXN1
bHQpIHsKKyAJCXJ3LT5lcnJfc2V0ID0gMTsKKyAJCXJldHVybiAtMTsKKyAJfQorIAlQeV9ERUNS
RUYocmVzdWx0KTsKKyAJcmVzdWx0ID0gUHlPYmplY3RfQ2FsbE9iamVjdChydy0+dGVsbF9tZXRo
b2QsIFB5VHVwbGVfTmV3KDApKTsKKyAJaWYgKCFyZXN1bHQpIHsKKyAJCXJ3LT5lcnJfc2V0ID0g
MTsKKyAJCXJldHVybiAtMTsKKyAJfQorIAlyZXR2YWwgPSBQeUludF9Bc0xvbmcocmVzdWx0KTsK
KyAJUHlfREVDUkVGKHJlc3VsdCk7CisgCXJldHVybiByZXR2YWw7CisgfQorIAorIHN0YXRpYyBp
bnQgcndvcHNfcHlyZWFkKFNETF9SV29wcyAqY29udGV4dCwgdm9pZCAqcHRyLCBpbnQgc2l6ZSwg
aW50IG1heG51bSkgeworIAlzdHJ1Y3QgUHl0aG9uX1NETF9SV29wcyAqcncgPSAoc3RydWN0IFB5
dGhvbl9TRExfUldvcHMgKikgY29udGV4dDsKKyAJUHlPYmplY3QgKnJlc3VsdDsKKyAJaW50IHJl
dHZhbDsKKyAJCisgCWlmIChydy0+ZXJyX3NldCkgcmV0dXJuIC0xOworIAlpZiAoIXJ3LT5yZWFk
X21ldGhvZCkgeworIAkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgImZpbGUgb2Jq
ZWN0IGNhbm5vdCByZWFkIik7CisgCQlydy0+ZXJyX3NldCA9IDE7CisgCQlyZXR1cm4gLTE7Cisg
CX0KKyAJCisgCXJlc3VsdCA9IFB5T2JqZWN0X0NhbGxGdW5jdGlvbihydy0+cmVhZF9tZXRob2Qs
ICJpIiwgc2l6ZSAqIG1heG51bSk7CisgCWlmICghcmVzdWx0KSB7CisgCQlydy0+ZXJyX3NldCA9
IDE7CisgCQlyZXR1cm4gLTE7CisgCX0KKyAJcmV0dmFsID0gUHlTdHJpbmdfU2l6ZShyZXN1bHQp
IC8gc2l6ZTsKKyAJbWVtY3B5KHB0ciwgUHlTdHJpbmdfQXNTdHJpbmcocmVzdWx0KSwgcmV0dmFs
ICogc2l6ZSk7CisgCVB5X0RFQ1JFRihyZXN1bHQpOworIAlyZXR1cm4gcmV0dmFsOworIH0KKyAK
KyBzdGF0aWMgaW50IHJ3b3BzX3B5d3JpdGUoU0RMX1JXb3BzICpjb250ZXh0LCBjb25zdCB2b2lk
ICpwdHIsIGludCBzaXplLCBpbnQgbWF4bnVtKSB7CisgCXN0cnVjdCBQeXRob25fU0RMX1JXb3Bz
ICpydyA9IChzdHJ1Y3QgUHl0aG9uX1NETF9SV29wcyAqKSBjb250ZXh0OworIAlQeU9iamVjdCAq
cmVzdWx0OworIAkKKyAJaWYgKHJ3LT5lcnJfc2V0KSByZXR1cm4gLTE7CisgCWlmICghcnctPndy
aXRlX21ldGhvZCkgeworIAkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgImZpbGUg
b2JqZWN0IGNhbm5vdCB3cml0ZSIpOworIAkJcnctPmVycl9zZXQgPSAxOworIAkJcmV0dXJuIC0x
OworIAl9CisgCQorIAlyZXN1bHQgPSBQeU9iamVjdF9DYWxsRnVuY3Rpb24ocnctPndyaXRlX21l
dGhvZCwgInMjIiwgCisgCSAgICBwdHIsIHNpemUgKiBtYXhudW0pOworIAlpZiAoIXJlc3VsdCkg
eworIAkJcnctPmVycl9zZXQgPSAxOworIAkJcmV0dXJuIC0xOworIAl9CisgCVB5X0RFQ1JFRihy
ZXN1bHQpOworIAlyZXR1cm4gbWF4bnVtOworIH0KKyAKKyBzdGF0aWMgaW50IHJ3b3BzX3B5Y2xv
c2UoU0RMX1JXb3BzICpjb250ZXh0KSB7CisgCXN0cnVjdCBQeXRob25fU0RMX1JXb3BzICpydyA9
IChzdHJ1Y3QgUHl0aG9uX1NETF9SV29wcyAqKSBjb250ZXh0OworIAlQeU9iamVjdCAqcmVzdWx0
OworIAkKKyAJaWYgKHJ3LT5lcnJfc2V0KSByZXR1cm4gLTE7CisgCWlmICghcnctPmNsb3NlX21l
dGhvZCkgeworIAkJcmV0dXJuIDA7CisgCX0KKyAJCisgCXJlc3VsdCA9IFB5T2JqZWN0X0NhbGxP
YmplY3QocnctPmNsb3NlX21ldGhvZCwgUHlUdXBsZV9OZXcoMCkpOworIAlpZiAoIXJlc3VsdCkg
eworIAkJcnctPmVycl9zZXQgPSAxOworIAkJcmV0dXJuIC0xOworIAl9CisgCVB5X0RFQ1JFRihy
ZXN1bHQpOworIAlyZXR1cm4gMDsKKyB9CisgCisgc3RhdGljIFNETF9SV29wcyAqcndvcHNfcHl0
aG9uKFB5T2JqZWN0ICpvKSB7CisgCXN0cnVjdCBQeXRob25fU0RMX1JXb3BzICpydzsKKyAJaWYo
UHlGaWxlX0NoZWNrKG8pKSB7CisgCQlyZXR1cm4gU0RMX1JXRnJvbUZQKFB5RmlsZV9Bc0ZpbGUo
byksIDApOworIAl9CisgCWlmKFB5U3RyaW5nX0NoZWNrKG8pKSB7CisgCQlyZXR1cm4gU0RMX1JX
RnJvbU1lbShQeVN0cmluZ19Bc1N0cmluZyhvKSwgUHlTdHJpbmdfU2l6ZShvKSk7CisgCX0KKyAK
KyAJcncgPSBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBQeXRob25fU0RMX1JXb3BzKSk7CisgCXJ3LT5v
YmogPSBvOworIAlydy0+c2Vla19tZXRob2QgPSBQeU9iamVjdF9HZXRBdHRyU3RyaW5nKG8sICJz
ZWVrIik7CisgCXJ3LT50ZWxsX21ldGhvZCA9IFB5T2JqZWN0X0dldEF0dHJTdHJpbmcobywgInRl
bGwiKTsKKyAJcnctPnJlYWRfbWV0aG9kID0gUHlPYmplY3RfR2V0QXR0clN0cmluZyhvLCAicmVh
ZCIpOworIAlydy0+d3JpdGVfbWV0aG9kID0gUHlPYmplY3RfR2V0QXR0clN0cmluZyhvLCAid3Jp
dGUiKTsKKyAJcnctPmNsb3NlX21ldGhvZCA9IFB5T2JqZWN0X0dldEF0dHJTdHJpbmcobywgImNs
b3NlIik7CisgCXJ3LT5lcnJfc2V0ID0gMDsKKyAJcnctPmJhc2Uuc2VlayA9ICZyd29wc19weXNl
ZWs7CisgCXJ3LT5iYXNlLnJlYWQgPSAmcndvcHNfcHlyZWFkOworIAlydy0+YmFzZS53cml0ZSA9
ICZyd29wc19weXdyaXRlOworIAlydy0+YmFzZS5jbG9zZSA9ICZyd29wc19weWNsb3NlOworIAor
IAlpZiAoIXJ3LT5yZWFkX21ldGhvZCAmJiAhcnctPndyaXRlX21ldGhvZCkgeworIAkJZnJlZShy
dyk7CisgCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9yLCAKKyAJCSAgICAiZmlsZSBv
YmplY3RzIG11c3QgYmUgYWJsZSB0byBlaXRoZXIgcmVhZCBvciB3cml0ZSIpOworIAkJcmV0dXJu
IDA7CisgCX0KKyAJUHlFcnJfQ2xlYXIoKTsKKyAJCisgCXJldHVybiAoU0RMX1JXb3BzICopIHJ3
OworIH0KKyAKKyAKICB2b2lkIGluaXRzZGwoKQogIHsKICAJUHlPYmplY3QqIG1vZHVsZTsKKioq
KioqKioqKioqKioqCioqKiA3MTUsNzQ2ICoqKioKICAJUHlPYmplY3QqIHN1cmZhY2VfcmVmOwog
IAlTRExfUldvcHMqIHNfb3BzX3JlZjsKICAJY2hhciogZmlsZTsKICAKISAJaWYoIVB5QXJnX1Bh
cnNlVHVwbGUoYXJncywgIk8iLCAmYXJnX3JlZikpCiAgCQlyZXR1cm4gTlVMTDsKICAKISAJLyog
V2UgbmVlZCB0byBkZXRlcm1pbmUgaWYgdGhlIGZpcnN0IGFyZ3VtZW50IGlzIGEgRmlsZSBvYmpl
Y3QsIG9yIGEKISAJICogZmlsZW5hbWUuIElmIGl0J3MgbmVpdGhlciwgdGhlbiB3ZSB0aHJvdyBh
IFR5cGVFcnJvci4KISAJKi8KISAJCQohIAlpZihQeUZpbGVfQ2hlY2soYXJnX3JlZikpCiEgCXsK
ISAJCXNfb3BzX3JlZiA9IFNETF9SV0Zyb21GUChQeUZpbGVfQXNGaWxlKGFyZ19yZWYpLCAwKTsK
ISAJCXN1cmZhY2VfcmVmID0gc2RsX3N1cmZhY2VfTkVXKElNR19Mb2FkX1JXKHNfb3BzX3JlZiwg
MCkpOwohIAohIAkJUHlfRnJlZShzX29wc19yZWYpOwohIAohIAkJcmV0dXJuIHN1cmZhY2VfcmVm
OyAKISAJfQohIAkKISAJaWYoUHlTdHJpbmdfQ2hlY2soYXJnX3JlZikpCiAgCXsKICAJCWZpbGUg
PSBQeVN0cmluZ19Bc1N0cmluZyhhcmdfcmVmKTsKICAJCXJldHVybiBzZGxfc3VyZmFjZV9ORVco
SU1HX0xvYWQoZmlsZSkpOwogIAl9CiAgCiEgCVB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJy
b3IsICJ0YWtlcyBhIGZpbGUgb2JqZWN0IG9yIHN0cmluZyBhcmd1bWVudCIpOwohIAlyZXR1cm4g
TlVMTDsKICB9CiAgCiAgc3RhdGljIFB5T2JqZWN0KiBzZGxfaW1hZ2VfaXMoUHlPYmplY3QqIHNl
bGYsIFB5T2JqZWN0KiBhcmdzKQotLS0gODU1LDg4NSAtLS0tCiAgCVB5T2JqZWN0KiBzdXJmYWNl
X3JlZjsKICAJU0RMX1JXb3BzKiBzX29wc19yZWY7CiAgCWNoYXIqIGZpbGU7CisgCWludCBub3Rf
ZmlsZW5hbWUgPSAwOwogIAohIAlpZighUHlBcmdfUGFyc2VUdXBsZShhcmdzLCAiT3xpIiwgJmFy
Z19yZWYsICZub3RfZmlsZW5hbWUpKQogIAkJcmV0dXJuIE5VTEw7CiAgCiEgCVB5X0lOQ1JFRihh
cmdfcmVmKTsKISAJaWYoIW5vdF9maWxlbmFtZSAmJiBQeVN0cmluZ19DaGVjayhhcmdfcmVmKSkK
ICAJewogIAkJZmlsZSA9IFB5U3RyaW5nX0FzU3RyaW5nKGFyZ19yZWYpOworIAkJUHlfREVDUkVG
KGFyZ19yZWYpOwogIAkJcmV0dXJuIHNkbF9zdXJmYWNlX05FVyhJTUdfTG9hZChmaWxlKSk7CiAg
CX0KKyAJCisgCXNfb3BzX3JlZiA9IHJ3b3BzX3B5dGhvbihhcmdfcmVmKTsKKyAJaWYgKCFzX29w
c19yZWYpIHsKKyAJCVB5X0RFQ1JFRihhcmdfcmVmKTsKKyAJCXJldHVybiAwOworIAl9CisgCQor
IAlzdXJmYWNlX3JlZiA9IHNkbF9zdXJmYWNlX05FVyhJTUdfTG9hZF9SVyhzX29wc19yZWYsIDAp
KTsKICAKISAJZnJlZShzX29wc19yZWYpOwohIAlQeV9ERUNSRUYoYXJnX3JlZik7CiEgCQohIAly
ZXR1cm4gc3VyZmFjZV9yZWY7CiAgfQogIAogIHN0YXRpYyBQeU9iamVjdCogc2RsX2ltYWdlX2lz
KFB5T2JqZWN0KiBzZWxmLCBQeU9iamVjdCogYXJncykKKioqKioqKioqKioqKioqCioqKiA3NDks
NzczICoqKioKICAJUHlPYmplY3QqIHN1cmZhY2VfcmVmOwogIAlTRExfUldvcHMqIHNfb3BzX3Jl
ZjsKICAJaW50IHR5cGUsIHN0YXR1czsKICAJCiEgCWlmKCFQeUFyZ19QYXJzZVR1cGxlKGFyZ3Ms
ICJPaSIsICZhcmdfcmVmLCAmdHlwZSkpCiAgCQlyZXR1cm4gTlVMTDsKISAKISAJaWYoUHlTdHJp
bmdfQ2hlY2soYXJnX3JlZikpCiAgCQlzX29wc19yZWYgPSBTRExfUldGcm9tRmlsZShQeVN0cmlu
Z19Bc1N0cmluZyhhcmdfcmVmKSwgInJiIik7CiEgCWVsc2UKISAJaWYoUHlGaWxlX0NoZWNrKGFy
Z19yZWYpKQohIAkJc19vcHNfcmVmID0gU0RMX1JXRnJvbUZQKFB5RmlsZV9Bc0ZpbGUoYXJnX3Jl
ZiksIDApOwohIAllbHNlCiEgCXsKISAJCVB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3Is
IAohIAkJCSJ0YWtlcyBhIGZpbGUgb2JqZWN0IG9yIHN0cmluZyBhcmd1bWVudCIpOwohIAkJcmV0
dXJuIE5VTEw7CiAgCX0KICAKICAJaWYoIXNfb3BzX3JlZikKICAJewohIAkJUHlFcnJfU2V0U3Ry
aW5nKFB5RXhjX1J1bnRpbWVFcnJvciwgInVuYWJsZSB0byBhY3F1aXJlIGZpbGUgaW5mbyIpOwog
IAkJcmV0dXJuIE5VTEw7CiAgCX0KICAKLS0tIDg4OCw5MTEgLS0tLQogIAlQeU9iamVjdCogc3Vy
ZmFjZV9yZWY7CiAgCVNETF9SV29wcyogc19vcHNfcmVmOwogIAlpbnQgdHlwZSwgc3RhdHVzOwor
IAlpbnQgbm90X2ZpbGVuYW1lID0gMDsKICAJCiEgCWlmKCFQeUFyZ19QYXJzZVR1cGxlKGFyZ3Ms
ICJPaXxpIiwgJmFyZ19yZWYsICZ0eXBlLCAmbm90X2ZpbGVuYW1lKSkKICAJCXJldHVybiBOVUxM
OwohIAkJCiEgCVB5X0lOQ1JFRihhcmdfcmVmKTsKISAJaWYoIW5vdF9maWxlbmFtZSAmJiBQeVN0
cmluZ19DaGVjayhhcmdfcmVmKSkKICAJCXNfb3BzX3JlZiA9IFNETF9SV0Zyb21GaWxlKFB5U3Ry
aW5nX0FzU3RyaW5nKGFyZ19yZWYpLCAicmIiKTsKISAJZWxzZSB7CiEgCQlzX29wc19yZWYgPSBy
d29wc19weXRob24oYXJnX3JlZik7CiAgCX0KICAKICAJaWYoIXNfb3BzX3JlZikKICAJewohIAkJ
aWYgKCFQeUVycl9PY2N1cnJlZCgpKSB7CiEgCQkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1J1bnRp
bWVFcnJvciwgInVuYWJsZSB0byBhY3F1aXJlIGZpbGUgaW5mbyIpOwohIAkJfQohIAkJUHlfREVD
UkVGKGFyZ19yZWYpOwogIAkJcmV0dXJuIE5VTEw7CiAgCX0KICAKKioqKioqKioqKioqKioqCioq
KiA4MDcsODEyICoqKioKLS0tIDk0NSw5NTEgLS0tLQogIAl9CiAgCiAgCVB5X0ZyZWUoc19vcHNf
cmVmKTsKKyAJUHlfREVDUkVGKGFyZ19yZWYpOwogIAlyZXR1cm4gUHlfQnVpbGRWYWx1ZSgiaSIs
IHN0YXR1cyk7CiAgfQogIAoqKioqKioqKioqKioqKioKKioqIDgxNyw4NDEgKioqKgogIAlTRExf
UldvcHMqIHNfb3BzX3JlZjsKICAJaW50IHR5cGU7CiAgCVNETF9TdXJmYWNlKiBzX3N1cmZhY2Vf
cmVmOwogIAohIAlpZighUHlBcmdfUGFyc2VUdXBsZShhcmdzLCAiT2kiLCAmYXJnX3JlZiwgJnR5
cGUpKQogIAkJcmV0dXJuIE5VTEw7CiAgCiEgCWlmKFB5U3RyaW5nX0NoZWNrKGFyZ19yZWYpKQog
IAkJc19vcHNfcmVmID0gU0RMX1JXRnJvbUZpbGUoUHlTdHJpbmdfQXNTdHJpbmcoYXJnX3JlZiks
ICJyYiIpOwohIAllbHNlCiEgCWlmKFB5RmlsZV9DaGVjayhhcmdfcmVmKSkKISAJCXNfb3BzX3Jl
ZiA9IFNETF9SV0Zyb21GUChQeUZpbGVfQXNGaWxlKGFyZ19yZWYpLCAwKTsKISAJZWxzZQohIAl7
CiEgCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9yLAohIAkJCSJ0YWtlcyBhIGZpbGUg
b2JqZWN0IG9yIHN0cmluZyBhcmd1bWVudCIpOwohIAkJcmV0dXJuIE5VTEw7CiAgCX0KICAKICAJ
aWYoIXNfb3BzX3JlZikKICAJewogIAkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1J1bnRpbWVFcnJv
ciwgInVuYWJsZSB0byBhY3F1aXJlIGZpbGUgaW5mbyIpOwogIAkJcmV0dXJuIE5VTEw7CiAgCX0K
ICAKLS0tIDk1Niw5NzcgLS0tLQogIAlTRExfUldvcHMqIHNfb3BzX3JlZjsKICAJaW50IHR5cGU7
CiAgCVNETF9TdXJmYWNlKiBzX3N1cmZhY2VfcmVmOworIAlpbnQgbm90X2ZpbGVuYW1lID0gMDsK
ICAKISAJaWYoIVB5QXJnX1BhcnNlVHVwbGUoYXJncywgIk9pfGkiLCAmYXJnX3JlZiwgJnR5cGUs
ICZub3RfZmlsZW5hbWUpKQogIAkJcmV0dXJuIE5VTEw7CiAgCiEgCVB5X0lOQ1JFRihhcmdfcmVm
KTsKISAJaWYoIW5vdF9maWxlbmFtZSAmJiBQeVN0cmluZ19DaGVjayhhcmdfcmVmKSkKICAJCXNf
b3BzX3JlZiA9IFNETF9SV0Zyb21GaWxlKFB5U3RyaW5nX0FzU3RyaW5nKGFyZ19yZWYpLCAicmIi
KTsKISAJZWxzZSB7CiEgCQlzX29wc19yZWYgPSByd29wc19weXRob24oYXJnX3JlZik7CiAgCX0K
ICAKICAJaWYoIXNfb3BzX3JlZikKICAJewogIAkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1J1bnRp
bWVFcnJvciwgInVuYWJsZSB0byBhY3F1aXJlIGZpbGUgaW5mbyIpOworIAkJUHlfREVDUkVGKGFy
Z19yZWYpOwogIAkJcmV0dXJuIE5VTEw7CiAgCX0KICAKKioqKioqKioqKioqKioqCioqKiA4NjYs
ODc1ICoqKioKLS0tIDEwMDIsMTAxMyAtLS0tCiAgCQkJYnJlYWs7CiAgCQlkZWZhdWx0OgogIAkJ
CS8qIHNkbF9zdXJmYWNlX05FVyB0aHJvd3MgYW4gZXhjZXB0aW9uIGlmIGl0cyBhcmd1bWVudCBp
cyBOVUxMICovCisgCQkJUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1ZhbHVlRXJyb3IsICJpbGxlZ2Fs
IGltYWdlIHR5cGUiKTsKICAJCQlzX3N1cmZhY2VfcmVmID0gTlVMTDsKICAJfQkJCQkJCQkJCQkJ
CQkJIAogIAogIAlQeV9GcmVlKHNfb3BzX3JlZik7CisgCVB5X0RFQ1JFRihhcmdfcmVmKTsKICAJ
cmV0dXJuIHNkbF9zdXJmYWNlX05FVyhzX3N1cmZhY2VfcmVmKTsKICB9CiAgCioqKioqKioqKioq
KioqKgoqKiogODkxLDg5NyAqKioqCiAgCiAgCWlmKCFzdXJmKQogIAl7CiEgCQlQeUVycl9TZXRT
dHJpbmcoUHlFeGNfUnVudGltZUVycm9yLCAidW5hYmxlIHRvIGFsbG9jYXRlIFNETCBzdXJmYWNl
Iik7CiAgCQlyZXR1cm4gTlVMTDsKICAJfQogIAkJCi0tLSAxMDI5LDEwMzcgLS0tLQogIAogIAlp
Zighc3VyZikKICAJewohIAkJaWYgKCFQeUVycl9PY2N1cnJlZCgpKSB7CiEgCQkJUHlFcnJfU2V0
U3RyaW5nKFB5RXhjX1J1bnRpbWVFcnJvciwgInVuYWJsZSB0byBhbGxvY2F0ZSBTREwgc3VyZmFj
ZSIpOwohIAkJfQogIAkJcmV0dXJuIE5VTEw7CiAgCX0KICAJCQoqKioqKioqKioqKioqKioKKioq
IDIwMjcsMjA1NiAqKioqCiAgCVNETF9SV29wcyogc19vcHNfcmVmOwogIAlpbnQgc3RhdHVzOwog
IAljaGFyKiBmaWxlOwogIAkKISAJaWYoIVB5QXJnX1BhcnNlVHVwbGUoYXJncywgIk8iLCAmYXJn
X3JlZikpCiAgCQlyZXR1cm4gTlVMTDsKICAKISAJaWYoUHlGaWxlX0NoZWNrKGFyZ19yZWYpKQoh
IAl7CiEgCQlzX29wc19yZWYgPSBTRExfUldGcm9tRlAoUHlGaWxlX0FzRmlsZShhcmdfcmVmKSwg
MCk7CiEgCQlzdGF0dXMgPSBTRExfU2F2ZUJNUF9SVyhzdXJmYWNlX3JlZi0+c3VyZiwgc19vcHNf
cmVmLCAwKTsKISAKISAJCVB5X0ZyZWUoc19vcHNfcmVmKTsKISAJCXJldHVybiBQeV9CdWlsZFZh
bHVlKCJpIiwgc3RhdHVzKTsKISAJfQohIAohIAlpZihQeVN0cmluZ19DaGVjayhhcmdfcmVmKSkK
ICAJewogIAkJZmlsZSA9IFB5U3RyaW5nX0FzU3RyaW5nKGFyZ19yZWYpOwogIAkJc3RhdHVzID0g
U0RMX1NhdmVCTVAoc3VyZmFjZV9yZWYtPnN1cmYsIGZpbGUpOwogIAogIAkJUHlfRnJlZShzX29w
c19yZWYpOwogIAkJcmV0dXJuIFB5X0J1aWxkVmFsdWUoImkiLCBzdGF0dXMpOwogIAl9CiAgCiEg
CVB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJ0YWtlcyBhIGZpbGUgb2JqZWN0IG9y
IHN0cmluZyBhcmd1bWVudCIpOwohIAlyZXR1cm4gTlVMTDsgIAogIH0KICAKICAvKiBBdWRpbyBy
ZWxhdGVkIGNvZGUgKi8KLS0tIDIxNjcsMjIwMyAtLS0tCiAgCVNETF9SV29wcyogc19vcHNfcmVm
OwogIAlpbnQgc3RhdHVzOwogIAljaGFyKiBmaWxlOworIAlpbnQgbm90X2ZpbGVuYW1lID0gMDsK
ICAJCiEgCWlmKCFQeUFyZ19QYXJzZVR1cGxlKGFyZ3MsICJPfGkiLCAmYXJnX3JlZiwgJm5vdF9m
aWxlbmFtZSkpCiAgCQlyZXR1cm4gTlVMTDsKICAKISAJUHlfSU5DUkVGKGFyZ19yZWYpOwohIAlp
Zighbm90X2ZpbGVuYW1lICYmIFB5U3RyaW5nX0NoZWNrKGFyZ19yZWYpKQogIAl7CiAgCQlmaWxl
ID0gUHlTdHJpbmdfQXNTdHJpbmcoYXJnX3JlZik7CiAgCQlzdGF0dXMgPSBTRExfU2F2ZUJNUChz
dXJmYWNlX3JlZi0+c3VyZiwgZmlsZSk7CiAgCisgCQlQeV9ERUNSRUYoYXJnX3JlZik7CiAgCQlQ
eV9GcmVlKHNfb3BzX3JlZik7CiAgCQlyZXR1cm4gUHlfQnVpbGRWYWx1ZSgiaSIsIHN0YXR1cyk7
CiAgCX0KICAKISAJc19vcHNfcmVmID0gcndvcHNfcHl0aG9uKGFyZ19yZWYpOwohIAlpZiAoIXNf
b3BzX3JlZikgewohIAkJUHlfREVDUkVGKGFyZ19yZWYpOwohIAkJcmV0dXJuIDA7CiEgCX0KISAJ
CiEgCXN0YXR1cyA9IFNETF9TYXZlQk1QX1JXKHN1cmZhY2VfcmVmLT5zdXJmLCBzX29wc19yZWYs
IDApOwohIAkKISAJZnJlZShzX29wc19yZWYpOwohIAlQeV9ERUNSRUYoYXJnX3JlZik7CiEgCWlm
ICghUHlFcnJfT2NjdXJyZWQoKSkgewohIAkJcmV0dXJuIFB5SW50X0Zyb21Mb25nKHN0YXR1cyk7
CiEgCX0gZWxzZSB7CiEgCQlyZXR1cm4gMDsKISAJfQogIH0KICAKICAvKiBBdWRpbyByZWxhdGVk
IGNvZGUgKi8KKioqIG9yaWcvc2RsbW9kdWxlLmgJVHVlIEFwciAxOCAxOTozMzo1NSAyMDAwCi0t
LSBzZGxtb2R1bGUuaAlUdWUgQXByIDE4IDIwOjUxOjQwIDIwMDAKKioqKioqKioqKioqKioqCioq
KiAxODAsMTkzICoqKioKICAKICBzdGF0aWMgUHlPYmplY3QqIHNkbF9pbWFnZV9sb2FkKFB5T2Jq
ZWN0KiBzZWxmLCBQeU9iamVjdCogYXJncyk7CiAgc3RhdGljIGNoYXIgc2RsX2ltYWdlX2xvYWRf
X2RvY19fW10gPQohIAkiaW1hZ2VfbG9hZChmaWxlIG9yIGZpbGVfb2JqZWN0KSAtPiBTdXJmYWNl
XG4iCiAgCSJUaGlzIGZ1bmN0aW9uIGNyZWF0ZXMgYSBTdXJmYWNlIGZyb20gYW4gaW1hZ2Ugc3Rv
cmVkIGluIGZpbGUuXG4iCiAgCSJPciBpZiBhIGZpbGUgb2JqZWN0IHdhcyBwYXNzZWQsIGluc3Rl
YWQgb2YgYSBmaWxlIG5hbWUsIGEgU3VyZmFjZVxuIgohIAkiaXMgY3JlYXRlZCBmcm9tIGFuIGlt
YWdlIHN0b3JlZCBhdCB0aGUgY3VycmVudCBwb3NpdGlvbiBpbiB0aGUgZmlsZS4iOwogIAogIHN0
YXRpYyBQeU9iamVjdCogc2RsX2ltYWdlX2lzKFB5T2JqZWN0KiBzZWxmLCBQeU9iamVjdCogYXJn
cyk7CiAgc3RhdGljIGNoYXIgc2RsX2ltYWdlX2lzX19kb2NfX1tdID0KISAJImltYWdlX2lzKGZp
bGUgb3IgZmlsZV9vYmplY3QsIHR5cGUpIC0+IGludFxuIgogIAkiUmV0dXJucyAxIGlmIHRoZSBj
b250ZW50IG9mIHRoZSBmaWxlIG9yIGZpbGUgb2JqZWN0J3MgbG9jYXRpb24gaXMgYW5cbiIKICAJ
ImltYWdlIGluIHRoZSBzcGVjaWZpZWQgZm9ybWF0LlxuIgogIAkiU3VwcG9ydGVkIGZvcm1hdHM6
XG4iCi0tLSAxODAsMTk1IC0tLS0KICAKICBzdGF0aWMgUHlPYmplY3QqIHNkbF9pbWFnZV9sb2Fk
KFB5T2JqZWN0KiBzZWxmLCBQeU9iamVjdCogYXJncyk7CiAgc3RhdGljIGNoYXIgc2RsX2ltYWdl
X2xvYWRfX2RvY19fW10gPQohIAkiaW1hZ2VfbG9hZChmaWxlIG9yIGZpbGVfb2JqZWN0IFssbm90
X2ZpbGVuYW1lXSkgLT4gU3VyZmFjZVxuIgogIAkiVGhpcyBmdW5jdGlvbiBjcmVhdGVzIGEgU3Vy
ZmFjZSBmcm9tIGFuIGltYWdlIHN0b3JlZCBpbiBmaWxlLlxuIgogIAkiT3IgaWYgYSBmaWxlIG9i
amVjdCB3YXMgcGFzc2VkLCBpbnN0ZWFkIG9mIGEgZmlsZSBuYW1lLCBhIFN1cmZhY2VcbiIKISAJ
ImlzIGNyZWF0ZWQgZnJvbSBhbiBpbWFnZSBzdG9yZWQgYXQgdGhlIGN1cnJlbnQgcG9zaXRpb24g
aW4gdGhlIGZpbGVcbiIKISAJIklmIHRoZSBvcHRpb25hbCBub3RfZmlsZW5hbWUgcGFyYW1ldGVy
IGlzIHNldCB0byAxLCB0aGVuIGEgc3RyaW5nXG4iCiEgCSJ3aWxsIG5vdCBiZSBpbnRlcnByZXRl
ZCBhcyBhIGZpbGVuYW1lLCBidXQgYXMgdGhlIGFjdHVhbCBpbWFnZSBkYXRhLiI7CiAgCiAgc3Rh
dGljIFB5T2JqZWN0KiBzZGxfaW1hZ2VfaXMoUHlPYmplY3QqIHNlbGYsIFB5T2JqZWN0KiBhcmdz
KTsKICBzdGF0aWMgY2hhciBzZGxfaW1hZ2VfaXNfX2RvY19fW10gPQohIAkiaW1hZ2VfaXMoZmls
ZSBvciBmaWxlX29iamVjdCwgdHlwZSBbLG5vdF9maWxlbmFtZV0pIC0+IGludFxuIgogIAkiUmV0
dXJucyAxIGlmIHRoZSBjb250ZW50IG9mIHRoZSBmaWxlIG9yIGZpbGUgb2JqZWN0J3MgbG9jYXRp
b24gaXMgYW5cbiIKICAJImltYWdlIGluIHRoZSBzcGVjaWZpZWQgZm9ybWF0LlxuIgogIAkiU3Vw
cG9ydGVkIGZvcm1hdHM6XG4iCioqKioqKioqKioqKioqKgoqKiogMjAxLDIwNyAqKioqCiAgCiAg
c3RhdGljIFB5T2JqZWN0KiBzZGxfaW1hZ2VfbG9hZF90eXBlKFB5T2JqZWN0KiBzZWxmLCBQeU9i
amVjdCogYXJncyk7CiAgc3RhdGljIGNoYXIgc2RsX2ltYWdlX2xvYWRfdHlwZV9fZG9jX19bXSA9
CiEgCSJpbWFnZV9sb2FkX3R5cGUoZmlsZSBvciBmaWxlIG9iamVjdCwgdHlwZSkgLT4gU3VyZmFj
ZVxuIgogIAkiQWxsb3dzIHRoZSBsb2FkaW5nIG9mIGEgU3VyZmFjZSwgYnV0IHdpdGggYSBzcGVj
aWZpYyBsb2FkZXIuIjsKICAKICBzdGF0aWMgUHlPYmplY3QqIHNkbF9pbWFnZV9pbnZlcnRfYWxw
aGEoUHlPYmplY3QqIHNlbGYsIFB5T2JqZWN0KiBhcmdzKTsKLS0tIDIwMywyMDkgLS0tLQogIAog
IHN0YXRpYyBQeU9iamVjdCogc2RsX2ltYWdlX2xvYWRfdHlwZShQeU9iamVjdCogc2VsZiwgUHlP
YmplY3QqIGFyZ3MpOwogIHN0YXRpYyBjaGFyIHNkbF9pbWFnZV9sb2FkX3R5cGVfX2RvY19fW10g
PQohIAkiaW1hZ2VfbG9hZF90eXBlKGZpbGUgb3IgZmlsZSBvYmplY3QsIHR5cGUgWyxub3RfZmls
ZW5hbWVdKSAtPiBTdXJmYWNlXG4iCiAgCSJBbGxvd3MgdGhlIGxvYWRpbmcgb2YgYSBTdXJmYWNl
LCBidXQgd2l0aCBhIHNwZWNpZmljIGxvYWRlci4iOwogIAogIHN0YXRpYyBQeU9iamVjdCogc2Rs
X2ltYWdlX2ludmVydF9hbHBoYShQeU9iamVjdCogc2VsZiwgUHlPYmplY3QqIGFyZ3MpOwoqKioq
KioqKioqKioqKioKKioqIDM5Nyw0MDMgKioqKgogIAogIHN0YXRpYyBQeU9iamVjdCogc2RsX3N1
cmZhY2Vfc2F2ZV9ibXAoUHlPYmplY3QqIHNlbGYsIFB5T2JqZWN0KiBhcmdzKTsKICBzdGF0aWMg
Y2hhciBzZGxfc3VyZmFjZV9zYXZlX2JtcF9fZG9jX19bXSA9CiEgCSJzYXZlX2JtcChmaWxlIG9y
IGZpbGUgb2JqZWN0KSAtPiBpbnRcbiIKICAJIlRoaXMgZnVuY3Rpb24gc2F2ZXMgdGhlIFN1cmZh
Y2UgYXMgYSBCTVAgZmlsZS4iOwogIAogIC8qIHNvdW5kIHJlbGF0ZWQgcHJvdG90eXBlcyBhbmQg
X19kb2NfXyBzdHJpbmdzICovCi0tLSAzOTksNDA1IC0tLS0KICAKICBzdGF0aWMgUHlPYmplY3Qq
IHNkbF9zdXJmYWNlX3NhdmVfYm1wKFB5T2JqZWN0KiBzZWxmLCBQeU9iamVjdCogYXJncyk7CiAg
c3RhdGljIGNoYXIgc2RsX3N1cmZhY2Vfc2F2ZV9ibXBfX2RvY19fW10gPQohIAkic2F2ZV9ibXAo
ZmlsZSBvciBmaWxlIG9iamVjdCBbLG5vdF9maWxlbmFtZV0pIC0+IGludFxuIgogIAkiVGhpcyBm
dW5jdGlvbiBzYXZlcyB0aGUgU3VyZmFjZSBhcyBhIEJNUCBmaWxlLiI7CiAgCiAgLyogc291bmQg
cmVsYXRlZCBwcm90b3R5cGVzIGFuZCBfX2RvY19fIHN0cmluZ3MgKi8K |
|
From: David C. <D. C. <si...@te...> - 2000-04-18 01:20:03
|
Could anyone who received Mark Baker's pySDL status update for April 17 please forward it to me at si...@te...? I received only a mangled header... Thanks. Preliminary pySDL documentation available at: http://www3.telus.net/futility/futility/docs/pysdl/index.html David "Futility [D!]" Clark | Any sufficiently advanced philosophy | si...@te... | is indistinguishable from despair. | ----------------------------------------------------------------------- |
|
From: Mark B. <mb...@0x...> - 2000-04-17 21:58:34
|
Sorry for my lack of response the last few days; I've been working on constructing a vegetable garden, and Vermont soil consists of mostly rock. So, it's been a long and arduous task, that I'm not nearly finished with, but am taking a short reprieve from. I thought I'd indicate our current developmental status: I've fixed the memory leaks Martijn Faassen pointed out. I would like to thank him for pointing these silly mistakes out for me, as well. I've been puttering with the audio system, which is mostly done. All I need to do is finish the construction of the manipulation/mixing routines, and we'll be set. I've also started going through the code and replacing the non-complex Py_BuildValue calls, with the exact copy-constructor functions. This is mostly for single integer or string returns, where it's not a matter of adding complexity to the code, but does turn a very small amount of efficiency. I've not yet looked into the question of Win32, but from the mail I recieved, it seems more like an issue with the compilation of SDL, than PySDL. The initialization routine is a very thin wrapper over SDL's. I'll see about finding a Win32 machine to compile PySDL on, and see what I can turn up. |
|
From: David C. <D. C. <si...@te...> - 2000-04-16 02:20:04
|
I'm about three-quarters done documenting the event subsystem in 0.0.3. Everything but the joystick functions is pretty much complete - I don't know when I'll get to the joystick, since I don't have one to experiment with :) I've written a short program that should let you explore the pySDL events - it's eventtest.pl, and is in the Examples section of the event page. Whew. 72k of documentation so far; that's a lot of typing :D This is a lot of fun :) Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html -- "But why Hell for me?" he asked. "And why for all? Was it not to keep it only for a few that Christ redeemed us?" Father Casper laughed like the God of the damned. "Why, when did He redeem you? On what planet, in what universe do you think you are living now?" - Umberto Eco, The Island of the Day Before |
|
From: Martijn F. <fa...@ve...> - 2000-04-15 12:57:15
|
Hi there,
I've discovered a memory leak in sdl_events_poll() and sdl_events_wait(),
and also fixed them. I noticed my python processes becoming enormously
huge very quickly in my event loop, and tracked it down to this:
sdl.init(sdl.INIT_VIDEO)
while 1:
e = sdl.events_poll()
And obviously that shouldn't happen. What I added was this:
Py_Free(s_event_ref);
in both functions, just before the last return statement:
return Py_BuildValue("i", -1);
That fixed it.
PySDL is way cool, by the way. Python too. Amazing how quickly you can
prototype a nice app; I now have objects which draw themselves when
first used, but draw to a buffer and then later on use blit their
pre-drawed contents, and the rest was pretty easy too. I can't do that
in C or C++ so quickly. :)
Regards,
Martijn
|
|
From: Krolours <kro...@fr...> - 2000-04-13 17:35:49
|
Hello, I'm trying to use pysdl in windows. I built it sucessfully with mingw32 but it does not work as expected : Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sdl >>> sdl.init(sdl.INIT_AUDIO) 0 >>> sdl.init(sdl.INIT_VIDEO) -1 >>> It seems it can create the pysdl types Surface_Type, CD_Type, ... Maybe someone has ideas about what I made wrong. I'll send patches to the author once it works. pysdl rock ! -- --------------------------------------------------------------------- G.Quiniou kro...@fr... --------------------------------------------------------------------- |
|
From: Mark B. <mb...@0x...> - 2000-04-13 14:54:46
|
On Thu, 13 Apr 2000, "David Clark wrote: > Where does USEREVENT belong? Is it one of the types of events that you > can create using event_new()? Is the space between event types QUIT > (decimal representation 12) and USEREVENT (24) intended for future > expansion? I can only imagine the space, which is the product of the SDL people, is there for future expansion. The USEREVENT is there for people to use with event_new(), in that it should be possible to subclass it and do what they will with it. With no mechanism to really pass around other information, the manner of using it may become a bit convoluted, but I'd rather not stand in the way of someone's creative genius. Practically speaking you might consider it useless, unless of course you find it useful ;-) |
|
From: Mark B. <mb...@0x...> - 2000-04-13 14:47:42
|
On Wed, 12 Apr 2000, "David Clark wrote: > Are these two methods identical? Both take a color number / palette > index and return an RGB tuple. Am I missing something here - are color > number and palette index concepts interchangable? Nahh. get_rgb() takes a color, palletized or not, and converts it into the RGB components for the given surface. It's more or less the opposite of map_rgb() pal_get_at() returns the RGB components of the entry at index in the palette. The palette can be changed, where as the values returned by get_rgb() should be constant for the given surface and color. The palette functions are also only valid for 8-bit surfaces, since they're the only ones with palettes. |
|
From: David C. <D. C. <si...@te...> - 2000-04-13 05:24:47
|
Where does USEREVENT belong? Is it one of the types of events that you
can create using event_new()? Is the space between event types QUIT
(decimal representation 12) and USEREVENT (24) intended for future
expansion?
Thanks.
--
----------------------------------------------------------------
David "Futility [D!]" Clark | Everyone's gotta be something.
si...@te... | Me, I'm garbage.
| It's all I've ever wanted to be.
| Shock me again, and I'll say
| anything you want me to. -MGB
|
