|
|
|
| LIB SDL and ClanLIB |
|
Gnatinator
Member #2,330
May 2002
 |
hey, you guys. Check out the installer I made a few posts down. Go check it out. I really want feedback on it.
|
|
kazzmir
Member #1,786
December 2001
 |
where is it exactly? |
|
Chris Katko
Member #1,881
January 2002
 |
Bah!! You wrote posts not threads!! Sorry, I had to vent after going through 8 pages of posts. It's here. -----sig: |
|
Marcello
Member #1,860
January 2002
 |
8 pages!? I only have 3... Marcello |
|
Kitty Cat
Member #2,815
October 2002
 |
Quote: In fullscreen applications, it doesn't matter at all Unfortunately, it quite does. If someone has a monitor that's brighter than normal, the gamma will be lower than normal. And for a monitor that's darker than normal (which happens frequently with older/smaller monitors that are set near the max resolution), gamma will be set higher. Changing a user's gamma is akin to changing their brightness and contrast settings, IMO. Quote: Funny, I don't recall inviting you into the design team for any of my projects.
I think you misunderstood that that was my opinion. AFAIK, we're all entitled to one. Quote: But that's cool. I'll stick with programming tools that treat me like an adult, you stick to designing tools that force everyone to agree with your design decisions. I'm sure they'll continue to be as popular as Allegro is now. I never said the ability to modify gamma shouldn't be there. But to modify it for the purpose of screen effects goes a little to far, IMO. I won't play a game long if either a) it continuously messes up my gamma settings, causing me to reset them, or b) if the gamma settings aren't modifyable at all and I lose required screen effects. Quote: As already discussed, so does setting the palette in 8bpp mode. Will you be pushing for Allegro 5 not to allow palette adjustment? Except that the palette is done on a per-program basis. The only time changing the palette effects anything is when Windows' desktop color depth is 8, which is rare enough as it is, and I believe there's even safegaurds for modifying too much of the palette in windowed modes under those conditions. Plus, it's easy to reset the palette if something does mess up, unlike the gamma settings which are set permanent once changed. -- |
|
Oscar Giner
Member #2,207
April 2002
 |
IMHO this discussion about gamma vs no gamma is useless. Adding gamma functions won't hurt anyone, and lets allow the game/application programmer decide when it's appropriate to use this functionality. -- |
|
Korval
Member #1,538
September 2001
 |
Quote: If someone has a monitor that's brighter than normal, the gamma will be lower than normal. And for a monitor that's darker than normal (which happens frequently with older/smaller monitors that are set near the max resolution), gamma will be set higher. Changing a user's gamma is akin to changing their brightness and contrast settings, IMO. I agree that arbitrarily changing the user's gamma settings is wrong, because they vary per-monitor. However, it is not unreasonable to give the user an appropriate dialog or whatever so that they can determine what the correct gamma settings are. Then, these settings are saved with the regular configuration data. However, I am fully, 100% against misuse of something. Like using gamma as an effect. Gamma is for converting from a non-linear colorspace to a linear one (or something like that. I don't fully understand it myself). The API for it would have to be explicitly designed to prevent pathalogical use of the gamma ramp. Like using a single floating-point value like most gamma correction settings do. Just because there is a toy to play with doesn't necessitate that it ought to be played with. I am also concerned about what would happen if an application crashes. You can catch crashes with a C++ exception, but only if you are higher in the call stack. In order to catch all exceptions, the library itself would have to, effectively, be main(), or somehow higher up in the call stack. Unless you expect the library itself to define main() and call some "AllegroMain()" function that the user writes, this is not possible. Also, the library would have to be C++ to catch the exception. Quote: I'll stick with programming tools that treat me like an adult, Being an adult means knowing when to touch something and when something should be left alone. And if you don't know enough yet to know that improper use of the gamma ramp is silly, then you don't deserve to be treated as an adult. Basically, the logic goes like this. If you have some need to fiddle with the gamma ramp in ways that it is not intended to be fiddled with (for effects rather than true gamma correction), then you are exactly the person who should not be allowed to filled with the gamma ramp. It has one specific purpose; just because you can finangle that purpose into some diabolical vision doesn't mean that you have the right to. It isn't your machine; it's the guy playing the game. And an API should have just as much respect for the player's PC as it does for the programmer. That's one of the primary reasons why we have hardware abstraction API's. Because programmers can't be trusted to go poking directly at the hardware. Poking the gamma ramp directly is clearly poking at the hardware. There's a simple abstraction to this that allows the gamma ramp to be used for exactly and only the purpose for which it was designed. Ergo, that is the abstraction that should be used. |
|
X-G
Member #856
December 2000
 |
Quote: Unless you expect the library itself to define main() and call some "AllegroMain()" function that the user writes, this is not possible. Uhm, isn't this what we are kinda doing already? -- |
|
CGamesPlay
Member #2,559
July 2002
 |
Only on windows, and only for compatibility. -- Ryan Patterson - <http://cgamesplay.com/> |
|
Bob
Free Market Evangelist
September 2000
 |
AFAIK this is true on all platforms (except DOS). About gamma, what about a restricted gamma - say between 0.5 and 3.0. This should prevent people from setting the gamma to zero or some really high value (and thus making it rather difficult to reset in case of a crash). I don't like the idea of trapping exceptions - when my program crashes, I want to know where and how, and have the debugger pop up. I certainly do not to have it cought by some handler, that forwards the error as something like "Oups. I crashed. Oh well", and then don't leave me the option of debugging my code. -- |
|
Marcello
Member #1,860
January 2002
|
Bob: well, couldn't it be disabled when you compile in debugmode? Marcello |
|
Korval
Member #1,538
September 2001
|
Quote: Bob: well, couldn't it be disabled when you compile in debugmode? Sure. Except that every time the debug build crashes, your gamma's screwed up. Also, it is sometimes useful (re: necessary) to debug release builds. God knows I've had my fair share of wading through optimized code trying to figure out where my variables are... BTW, on the gamma stuff: ATI's Catalyst driver release notes said: Upon making changes to certain monitor calibration software, the gamma settings will not be applied or loaded for the display. Color and gamma profiles for third party applications and games are also affected. By design of these drivers, all color and gamma settings are controlled via the ATI Color tab in Display Properties. This feature allows for separate control of gamma and color profiles for 2D and 3D applications. It is advised to use the ATI Color tab as a central location to maintain color and gamma profiles. So, it seems that an entire set of cards is "not for adults", to use Thomas Harte's phrase. You're not even allowed to set the gamma from a 3rd party application (ie, stuff we make). |
|
spellcaster
Member #1,493
September 2001
 |
I dont understand this discussion. Changing the gama ramps does allow for nice blending. On the other hand, I'd simply use a quad (or a bunch of quads) ontop of the current imahe and change the alpha value of it... Same effect, less discussion trouble. -- |
|
Bob
Free Market Evangelist
September 2000
|
Quote: I mean, if I want I can delete stuff in the systems directory on windows. You'd have to really want it, because Win2k/XP' file protection will kick in and replace that file from a copy stored in a file cache... -- |
|
Glenn Prince
Member #3,081
December 2002
|
Unless you've disabled file restore because it hogs system resources and hard disk space. EDIT- Spelhing |
|
Kitty Cat
Member #2,815
October 2002
|
The discussion, as far as I understood, was about using gamma to create screen fade effects. I don't think anyone's said you shouldn't be able to modify gamma, but you shouldn't do it just to create an effect. -- |
|
Chris Katko
Member #1,881
January 2002
|
My argument was for being able to modify it. Not necessarily for an effect (I mentioned Q3As gamma control). But if you can't modify it for an effect, you can't modify it at all. Which isn't something you should enforce on the developer, IMHO. I was suggesting being able to modify it for actual gamma purposes. Which I think you should be able to do. -----sig: |
|
Carrus85
Member #2,633
August 2002
 |
Okay, here is my $0.02: DOS DUMP dos for crying out loud. All it is doing is holding us back. Just the simple act of dumping dos should help increase our productivity. Supporting archaic operating systems is not going to help our cause 2d-OpenGL This personally sounds like a brilliant idea, although by incorperating 2d-OpenGL we would be alienating those who do not have an OpenGL card. But this shouldn't be too big if a deal, considering that OpenGL has a software mode (correct?). Besides, by incorperating 2d-OpenGL, you would be at the same time incorperating support for 3d-OpenGL (well, not at the same time, but it would be easily added). I'm sure this would make life easier for bob (namely), who has been putting up with the pain for quite a while of writing a library (AllegroGL) that interfaces new hardware features with an old programming library. Modularization Good Idea, to a certain extent. Personally, I think this would be great to include if you wanted to make your program more "readable," so you could determine what exactly is being used in code. However, for newb-ized purposes, it would still be helpful to have something along the lines of a <allegro-all.h> or something to simplyfy the process for those who are less fortunate than us. The GUI Personally, I think the gui should be ripped out and reworked. I mean, it is ugly, the design system isn't exactly the most intuitive the planet has ever seen, and it just doesn't work the way some people think it should. I would include the gui as an optional addon download to the library. Those who want it, can download and install it. Don't make us suffer with an inferrior gui system because your too lazy to use Masking or any of those other great gui systems. My Conclusion My opinion is that, if Allegro is to survive, we need to get up with the times. First of all, start recoding from scratch. That way we can avoid having old code that is dependant on other old pieces of code somewhere else. Dump Datafile support-- who needs it? With zlib, you can just use ZIP compression (combined with some password protection) to store our files. One less thing to implement, one less piece of code off of our shoulders to maintain. The Timer system needs to be replaced with a threading system. The FIXED type, in my opinion should be dropped. It has really lost is usefulness. The Sound part of the library needs to be reworked for hardware support. Am I missing anything? Basically, Allegro 5 needs to be a complete rework instead of an addition on top of allegro 4. Allegro 4 is a bit to much on the "legacy" side of the line. We need to move more to the "current" side of the line. EDIT: Some grammatical errors fixed.
|
|
X-G
Member #856
December 2000
|
Something to put the DOS thing into perspective: Why are we no longer supporting the Atari? Allegro started out on that platform, you know. Also, if we're going to support DOS, why not also C64 and Amiga systems, SNES and NES consoles and other outdated platforms? As for the GUI ... I don't think it should be a part of Allegro at all. The only argument for having it is so that we can have graphical tools like the grabber; but really, who says the grabber has to be a part of the core Allegro release? We might as well have a command-line utility for that and have the grabber be a utility for Allegro that you can download separately. It could then be linked to pretty much any GUI system you could think of and not be limited to Allegro or anything. -- |
|
Carrus85
Member #2,633
August 2002
|
Exactly, X-G. Hence another good point in my argument that datafiles could be completely dropped to begin with. There are so many utilities out there that handle Zip Files, and with zlib out there, why complicate things by reinventing the wheel? I mean, it is way easier to click and drag the files you want to use to a zip editing program that trying to use the grabber... It is, after all, one less piece of code for us to maintain. Let the Zlib people handle the zip compression/datafile stuff. EDIT: Added some additional grammer fixes.
|
|
X-G
Member #856
December 2000
|
I agree with that point. Why make a datafile system of our own when there's a widely supported standardized storage system out there already that would work just fine? EDIT: Another thing that definitely needs to be reworked is the way fonts are loaded. -- |
|
Carrus85
Member #2,633
August 2002
|
Someone needs to be making a list of all of this stuff... We need to do some things: First of all, we need to settle on a style for coding. Personally, I would go with using fixed tabs so your not forced to use wierd tab sizes on different formats, and something along the lines of this for the API coding: int g_int; // global integer int m_int; // member integer int a_int; // Argument integer // etc. Just something so we can make our code as readable as possible. Part of the problem with the current library is that it is too much backwards compatable bloat for what you get... EDIT: Yeah, the fonts should be fixed... Add it to the list! EDIT2: Another thing that should be fixed are the file formats that are supported. Maybe "broadening our horizens" and providing native support for jpg, png, gif, etc. wouldn't be too bad of an idea.
|
|
Sirocco
Member #88
April 2000
 |
Quote: This personally sounds like a brilliant idea, although by incorperating 2d-OpenGL we would be alienating those who do not have an OpenGL card. No problem there; just stick with Allegro 4 if compatibility becomes an issue. Same thing with DOS -- although I'm an ardent supporter of DOS, there's no reason to advance it beyond the already superb support present in Allegro 4. Stick with 4 if DOS is your thang. --> |
|
Carrus85
Member #2,633
August 2002
|
So, anyone have any ideas on who the supreme dictator of this project is going to be? I'm excited... Let us blow SDL out of the water! Personally, I am going to have to be more of a grunt programmer than anything... I haven't taken a whole lot in the line of college programming classes (aka. none), and high school AP testing is going to have me busy for the next couple weeks... Votes anyone? EDIT: one more note about the "dictator" idea. It is great and all, but it may prove to be a bit of overkill on one person. If we can get 2-3 people who can agree on the format 100%, we could have a "counselship" of dictators on the project. That way, things get done faster because we are not waiting on one person to free up his schedule. Just make sure we have a web page/mailing list/something that can be used to keep track of the progress and keep everyone on the right page.
|
|
Bob
Free Market Evangelist
September 2000
|
Quote: int g_int; // global integer Yuk. What about: ::some_global; this->some_member; some_argument_or_local; Let the compiler do the work for you. Finally, the coding style is pretty much described in the ahack document, so you can just look that up. -- |
|
|
|
