Menu
▾
▴
zengine-develop — List for ZEngine development discussion.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:08:22
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: James T. <ja...@co...> - 2003-10-14 23:24:46
|
>>>- First of all i see that most of the function members return void. I am >>>not a C++ guru so maybe i am wrong but wouldn't be better if they returned >>>a reference to the object ? In this way we could do >>>object.func1().func2()...funcN(). >>> >>> >>> >>Where would this syntax come in handy? I've never really heard of this, >>but that doesn't mean it can't/won't be done. >> I'm just not clear on what type of functions you'd like to see this >>behavior available for, a small example would help. >> >> > > >I dont have something in mind. I just think that this would be a good >feature because in the future someone may wanna use it. On the other hand > >it is trivial to implement it :) > > Sorry, I'm really not liking the idea, and since certain functions need to return real values I don't know what to do. The syntax seems more awkward and hardly useful. Sorry, I'm going to have to pass on this feature unless anybody can offer a real justification. >>I do most of my development on Windows, so the Linux build system is >>lacking. I'm not familiar with configure scripts, >>but when I began ZEngine I was hardly familiar with Make, so that won't >>keep me from adding a configure script. >>Sorry about the ../zlib/unzip.h, that was added when I was first adding >>the code, and I accidentally let it into the release, >>it's already fixed in my local copy of the source. >> >> >> > >I am not familiar with them either, although i develop on Linux... >If you wanna learn it then check out this excellent book (it is free !) >http://sources.redhat.com/autobook/download.html > > > Thanks for the reference to the book, I'll look into it as soon as I get a chance. |
|
From: James T. <ja...@co...> - 2003-10-14 23:15:24
|
I have changed the default rendering to GL_LINEAR and I plan on leaving
it like that unless anybody complains, the speed difference is barley
noticable, and the quality is greatly improved. The reason I have not
added a new parameter is becuase the choice occurs when the image is
loaded, and adding extra calls inside Stretch would be an unwanted speed
penalty.
-James Turk
Filippos Papadopoulos wrote:
>On Mon, 13 Oct 2003, James Turk wrote:
>
>
>
>>>>- I also believe that it would be better to use GL_LINEAR for Image
>>>>Stretching not GL_NEAREST. Maybe u could put an extra parameter in the
>>>>function Resize/Stretch.
>>>>
>>>>
>>>>
>>In SDLGL_Util.cpp, I changed the lines
>>glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
>>glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
>> to
>>glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
>>glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>>and noticed a visible difference. I'm not an OpenGL expert, so why
>>would anyone want to use GL_NEAREST?
>>
>> From what I've seen I propose simply changing these lines and nothing
>>else but if I am going to bother leaving GL_NEAREST, instead of forcing the
>>change inside Resize/Stretch, would it not be best to simply have that
>>as an option defined for each ZImage, that way a minimal number of calls
>>to glTexParamteri would be required, and none would be required inside
>>the rendering loop in most situations, which I'd consider a good thing.
>>
>>Feel free to share any thoughts on this, the finer points of OpenGL are
>>certainly not my specialty.
>>
>> -James
>>
>>
>
>
>Well i am not an OpenGL guru either ;)
>To be honest i havent fully understood what you wanna say here (see
>English is not my native language). I can tell these (by what i have
>understood):
>
>Why not putting an extra parameter in the Stretch/Resize function (or in
>the constructor of a ZImage) e.g named 'smooth' ? This way it is up to the
>developer to decide if he needs smoothed image or not.
> Someone would say that GL_LINEAR produces blurred images, which is not
>always a good case. On the other hand GL_NEAREST is faster than LINEAR.
>
>
|
|
From: Filippos P. <css...@cs...> - 2003-10-14 22:28:59
|
On Mon, 13 Oct 2003, James Turk wrote: > > >> - I also believe that it would be better to use GL_LINEAR for Image > >> Stretching not GL_NEAREST. Maybe u could put an extra parameter in the > >> function Resize/Stretch. > >> > > > > In SDLGL_Util.cpp, I changed the lines > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); > to > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > and noticed a visible difference. I'm not an OpenGL expert, so why > would anyone want to use GL_NEAREST? > > From what I've seen I propose simply changing these lines and nothing > else but if I am going to bother leaving GL_NEAREST, instead of forcing the > change inside Resize/Stretch, would it not be best to simply have that > as an option defined for each ZImage, that way a minimal number of calls > to glTexParamteri would be required, and none would be required inside > the rendering loop in most situations, which I'd consider a good thing. > > Feel free to share any thoughts on this, the finer points of OpenGL are > certainly not my specialty. > > -James Well i am not an OpenGL guru either ;) To be honest i havent fully understood what you wanna say here (see English is not my native language). I can tell these (by what i have understood): Why not putting an extra parameter in the Stretch/Resize function (or in the constructor of a ZImage) e.g named 'smooth' ? This way it is up to the developer to decide if he needs smoothed image or not. Someone would say that GL_LINEAR produces blurred images, which is not always a good case. On the other hand GL_NEAREST is faster than LINEAR. |
|
From: Filippos P. <css...@cs...> - 2003-10-14 22:23:11
|
On Mon, 13 Oct 2003, James Turk wrote: > > - First of all i see that most of the function members return void. I am > >not a C++ guru so maybe i am wrong but wouldn't be better if they returned > >a reference to the object ? In this way we could do > >object.func1().func2()...funcN(). > > > > > Where would this syntax come in handy? I've never really heard of this, > but that doesn't mean it can't/won't be done. > I'm just not clear on what type of functions you'd like to see this > behavior available for, a small example would help. I dont have something in mind. I just think that this would be a good feature because in the future someone may wanna use it. On the other hand it is trivial to implement it :) > I do most of my development on Windows, so the Linux build system is > lacking. I'm not familiar with configure scripts, > but when I began ZEngine I was hardly familiar with Make, so that won't > keep me from adding a configure script. > Sorry about the ../zlib/unzip.h, that was added when I was first adding > the code, and I accidentally let it into the release, > it's already fixed in my local copy of the source. > I am not familiar with them either, although i develop on Linux... If you wanna learn it then check out this excellent book (it is free !) http://sources.redhat.com/autobook/download.html |
|
From: James T. <ja...@co...> - 2003-10-13 20:40:09
|
The Reply-to field now points back to the list, due to the discussion nature of these lists (specifically the ZEngine-develop list) it was decided that this would be best. |
|
From: James T. <ja...@co...> - 2003-10-13 20:35:19
|
>> - I also believe that it would be better to use GL_LINEAR for Image
>> Stretching not GL_NEAREST. Maybe u could put an extra parameter in the
>> function Resize/Stretch.
>>
>
In SDLGL_Util.cpp, I changed the lines
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
to
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
and noticed a visible difference. I'm not an OpenGL expert, so why
would anyone want to use GL_NEAREST?
From what I've seen I propose simply changing these lines and nothing
else but if I am going to bother leaving GL_NEAREST, instead of forcing the
change inside Resize/Stretch, would it not be best to simply have that
as an option defined for each ZImage, that way a minimal number of calls
to glTexParamteri would be required, and none would be required inside
the rendering loop in most situations, which I'd consider a good thing.
Feel free to share any thoughts on this, the finer points of OpenGL are
certainly not my specialty.
-James
|
|
From: James T. <ja...@co...> - 2003-10-13 18:46:17
|
Hey, I really appreciate comments and feedback, and please don't
hesitate to ask for any features or report any bugs, that's what these
lists exist for.
> - First of all i see that most of the function members return void. I am
>not a C++ guru so maybe i am wrong but wouldn't be better if they returned
>a reference to the object ? In this way we could do
>object.func1().func2()...funcN().
>
>
Where would this syntax come in handy? I've never really heard of this,
but that doesn't mean it can't/won't be done.
I'm just not clear on what type of functions you'd like to see this
behavior available for, a small example would help.
> - I also believe that it would be better to use GL_LINEAR for Image
>Stretching not GL_NEAREST. Maybe u could put an extra parameter in the
>function Resize/Stretch.
>
>
That was recently suggested on the boards and in a personal email to me,
and I do plan on adding GL_LINEAR functionality.
> - The compilation in Linux could be much better if u used a configure
>script.I hope you have the time to do so.
> Also the #include "../zlib/unzip.h" in ZE_Includes.h, seems to mess up
>the compiler (at least when i make my project).Each time i install ZEngine
>as root i have to fix this line as "#include "zlib/unzip.h". Dont u think
>../zlib is a kind of a bad hack ???
>
>
I do most of my development on Windows, so the Linux build system is
lacking. I'm not familiar with configure scripts,
but when I began ZEngine I was hardly familiar with Make, so that won't
keep me from adding a configure script.
Sorry about the ../zlib/unzip.h, that was added when I was first adding
the code, and I accidentally let it into the release,
it's already fixed in my local copy of the source.
> - I have the impression that GetFramerate() doesnt return the value as
>set by SetDesiredFramerate(). E.g i set the FPS to be 85 but GetFrameRate
>reports 50. But when i set FPS to 185, the GetFrameRate reports 100~125
>which seems reasonable.
>
>
You're not the first person to report this behavior, but for me the
rates are much closer until I go to high framerates.
I made a note to myself to look into this behavior, but keep in mind
that framerate limiting often isn't a good idea,
especially if you are using it to control movement speeds. If that's
what you're limiting the framerate for, GetFrameTime
exists to help maintain a constant rate of motion even as the framerate
varies.
Thanks for the comments, the simple things should be fixed ASAP,
and I'll try to work on that configure script
when I get the time. (Anyone experience in writing configure scripts is
welcome to help, yours will most likely be
better than my first attempts at one.)
-James Turk
|
|
From: Filippos P. <css...@cs...> - 2003-10-13 12:39:28
|
First of all let me congratulate the ZEngine team :) Really this library is what i was looking for ! Well i have some questions and some requests. - First of all i see that most of the function members return void. I am not a C++ guru so maybe i am wrong but wouldn't be better if they returned a reference to the object ? In this way we could do object.func1().func2()...funcN(). - I also believe that it would be better to use GL_LINEAR for Image Stretching not GL_NEAREST. Maybe u could put an extra parameter in the function Resize/Stretch. - The compilation in Linux could be much better if u used a configure script.I hope you have the time to do so. Also the #include "../zlib/unzip.h" in ZE_Includes.h, seems to mess up the compiler (at least when i make my project).Each time i install ZEngine as root i have to fix this line as "#include "zlib/unzip.h". Dont u think ../zlib is a kind of a bad hack ??? - I have the impression that GetFramerate() doesnt return the value as set by SetDesiredFramerate(). E.g i set the FPS to be 85 but GetFrameRate reports 50. But when i set FPS to 185, the GetFrameRate reports 100~125 which seems reasonable. Well i want the best for this project thats why i am making these remarks...dont get me wrong . i am not a bad guy ;) |
|
From: James T. <ja...@co...> - 2003-07-17 08:19:44
|
This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. This is a second test, the message must be long I think. |
|
From: James T. <ja...@co...> - 2003-07-17 08:14:45
|
this is a test of the list this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message this makes sure that the list does not try to filter out a one line message |
