Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » LIB SDL and ClanLIB

This thread is locked; no one can reply to it. rss feed Print
LIB SDL and ClanLIB
Evert
Member #794
November 2000
avatar

Quote:

The call to 'modularize allegro' seems to defeat the purpose of an 'all in one game programming library'.

Not at all. As I would see it, you would install the default packages, which builds the video, audio, input etc. modules. You then have the option of either #including <allegro.h> for the whole package as it is now, or #include <allegro/video.h>, #include <allegro/gui.h>, #include <allegro/packfile.h> etc. and only link against relevant sections.
Note that the header splitup has already been made a while back.

Quote:

Drop timers. The way threading is used in sdl makes them transparent to user so this is a 'good thing'. A high res timer is definitly the way to go.

I know threading can be used to simulate timers or count game ticks. However, from a newbie perspective, I think it would be nice to have timer threads ontop of normal threads. For me at least it is a matter of great convenience that I can just tell Allegro to go run some_function() every 100 milliseconds.
Of course, this could be implemented as a seperate module yet again ontop of the threading API.

Oh, for everyone, making Allegro thread-safe is currently one of the priorities. This probably requires rewriting a lot of code, which means that now would be a good way to untangle some of the mess. I anyone want to help.

EDIT: as for dictators, I still say that Eric should be it, if he's willing. He more or less is in practice anyway at the moment.

Chris Katko
Member #1,881
January 2002
avatar

Couldn't you also only have the DLLs you need, in the directory? (i.e., if you don't use sound, you don't need al_sound.dll) I don't personally know exactly how you would go about that. Just at thought.

Lastly, since the original topic had (almost) nothing to do with this, and this thread is getting very large... might I suggest making a new thread?

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Korval
Member #1,538
September 2001
avatar

What is an overlay?

What is a "gamma ramp"?

Thomas Harte
Member #33
April 2000
avatar

Quote:

What is an overlay?

A (usually YUV colour space) surface overlaid onto the displayed image at pixel output time. It never appears as part of the framebuffer and is intended primarily for video streams. If you have DVD playing software, it will almost certainly use an overlay surface to display the video image. If you use printscreen to capture the display, you should only see a colour keyed box in the DVD player window if this is the case.

The main advantages are:

  • on some hardware the overlay surface comes from a different pixel clock, on all other hardware the pixel sampling is done at least bilinearly - so all resizes are 'nice'

  • YUV colour space means either getting as good as 24bit colour in a 16bit/pixel mode, or if you go with the commonly supported planar modes, almost 24bit colour in 12bits/pixel

  • separate Y channel means fast fading

First card I had that supported overlay surfaces was the S3 Virge that was in my P200.

Quote:

What is a "gamma ramp"

Gamma ramps are sort of like palettes for colour channels. So your card will do something like this:

1) read pixel colour
2) split into r, g, b
3) put r value through 256 entry r lookup table
3) do same thing with g and b and their respective tables
4) output mapped colour

It means you get many of the benefits of a paletted mode without being paletted. For example, your game can change hue (e.g. day to night), can fade and can do some colour transplanting if you deliberately colour your sprites for that purpose all through ramp manipulation.

I've no idea when gamma ramps became common place, but the 'intel integrated graphics' on my current machine - a Celeron 533, does.

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Couldn't you also only have the DLLs you need, in the directory?

Yes, but I'd rather not have allegro.dll, al_sound.dll, al_graphics.dll, al_keyboard.dll, al_mouse.dll, al_joystick.dll, al_mod.dll, al_mp3.dll, al_ogg.dll, al_midi.dll, and whatever else packed into a program instead of a single allegro.dll. On systems where you release source-only, or static link, this wouldn't be much of an issue, but as the current binary releases use dlls, and the dlls need to be packaged with the program to make sure you have what's needed, it creates a lot of extra baggage. It would also be a problem when you add new functionality but forget to package the newly needed dll.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Korval
Member #1,538
September 2001
avatar

Are these facilities OS things that are layered on top of something like DirectX or OpenGL, or are they part of them? Certainly, I don't recall OpenGL having overlays or gamma ramps. How does one usually access them (without SDL or another library)?

Also, one other question. What hardware provides for hardware scaling/rotation/etc blitting without providing for 3D acceleration? You might get some basic alpha effects without 3D accel, but most modern graphics hardware relies on it's 3D systems to handle that kind of thing.

Billybob
Member #3,136
January 2003

Quote:

Lastly, since the original topic had (almost) nothing to do with this, and this thread is getting very large... might I suggest making a new thread?

Why not just move over to the Allegro 5 Forums I'm putting up? I got them installed, I want to customize a few things, maybe make it look more like these forums or something, and get some mods installed. They will be located at [url www.progranism.com] when they are ready.

Evert
Member #794
November 2000
avatar

Quote:

Yes, but I'd rather not have allegro.dll, al_sound.dll, al_graphics.dll, al_keyboard.dll, al_mouse.dll, al_joystick.dll, al_mod.dll, al_mp3.dll, al_ogg.dll, al_midi.dll, and whatever else packed into a program instead of a single allegro.dll.

Agreed. I'm not sure how this impacts modularization though... perhaps the required symbols are only imported from the shared library if the relevant header file is #included or a relevant .a or .lib file linked to (ie, there is a static portion that gets linked in which contains a constructor that imports the symbols from the shared library)?

Quote:

Why not just move over to the Allegro 5 Forums I'm putting up?

Because there's already a section of these forums dedicated to Allegro development and there's already a mailing list (which has indeed been quite dead for a while now). The last thing we need is to discuss things in a bunch of different places. Discussion needs to be centralized, if we need yet another Allegro 5 discussion at all.
Frankly, I think we're better of with people who write actual code instead of going through yet another lengthy discussion about what needs to be done.

Thomas Harte
Member #33
April 2000
avatar

Quote:

Are these facilities OS things that are layered on top of something like DirectX or OpenGL, or are they part of them?

Hardware features exposed by the OS however it feels fit. Definitely accessible through DirectX and I have a strong suspicion they feature in DGA 2.0 and above also. Not accessible from OpenGL in the strict sense because GL doesn't do any of that low down surface access stuff. In fact I believe OpenGL has something entirely separate it calls an overlay surface.

EDIT:
One quick check later, XFree supports YUV overlays through the 'XVideo Extension' and gamma ramps through something I can only find referred to as the 'XFree86-VidModeExtension' which may or may not be the same thing.

DirectX references, pulled from google: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_m/directx/direct3d/gettingstarted/direct3dsurfaces/gammacontrols.asp (gamma control), http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/ddraw_6x47.asp (overlays)

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Agreed. I'm not sure how this impacts modularization though... perhaps the required symbols are only imported from the shared library if the relevant header file is #included or a relevant .a or .lib file linked to (ie, there is a static portion that gets linked in which contains a constructor that imports the symbols from the shared library)?

What does it matter if a symbol is loaded from a shared/dynamic lib? The point of modularization is to easilly seperate code from each other. It's good coding practice to do this, IMO, but when it comes to dynamic libs, it all needs to be there. Hsving seperate libs creates the need to package more files, which is a Not Good Thing(tm), and having them in one file is exactly what Allegro does now. And static linking is totally irrelevant to library modularization since it already strips out what's not used.

And as a note to TH: you can already use overlays in Allegro (Windows only currently, though: DXOV). Granted there's no way to really manipulate them other than as a sepreate RGB screen for window modes, but the basic code is already there and can be extended upon. And modifuying screen gamma is a Bad Thing since each monitor is different. Especially if there's fast blending (you can use AGL or FBlend for this), there's no need to modify the gamma. I know I wouldn't be happy if I ran a game and my screen suddenly became washed out or very dark. Let alone if it was a windowed app.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Evert
Member #794
November 2000
avatar

Quote:

What does it matter if a symbol is loaded from a shared/dynamic lib?

The symbol needs to be imported from the dynamic library. My suggestion was to have this done by use of a constructor in a library file which is static linked. That way, only symbols needed will be loaded from the shared library. Not sure if that offers a benefit over only loading part of it though.

Quote:

And static linking is totally irrelevant to library modularization since it already strips out what's not used.

Except when all modules interconnect, as is the case with Allegro currently. This is because all modules link to the system driver, which in turn needs to know about them too. (From my understanding).

Billybob
Member #3,136
January 2003

Quote:

Discussion needs to be centralized...

exactly ;)
But hey, I'll leave the boards there anyway. If people don't use them, I don't mind. I figured it'd be nice to have a seperate "centralized" place to discuss development of Allegro 5, ask programming questions, post code releases(including addon libraries which hopefully get merged), etc... If these forums are enough then I'll just take my forums down. I don't mind. BTW the boards are up and running [url www.progranism.com].

Kitty Cat
Member #2,815
October 2002
avatar

If all modules interconnect, it's not very modular code. Though I see your point. The system driver doesn't link to everything in every module, though. Besides, static linking isn't widely used at all anymore. Not since DOS. And afaik, not loading extra symbols from a shared resource doesn't offer any benefit to the program.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Billybob
Member #3,136
January 2003

I think we need sources that can actually compile before we begin production ;) I'm getting this error:
src/poly3d.c:32:35: obj/mingw32/asmcapa.h: No such file or directory
I got the sources right off CVS, module allegro_new. MingW 3.2.3.

As soon as I can get these to compile I'm going to go down the todo-list and proposals list and see what I can do to help.

Bob
Free Market Evangelist
September 2000
avatar

I should add to what Thomas said: Gamma Ramps and Overlays are computed on scan-out, so the actual frame buffer is never modified. Instead, the RAMDAC does the combining/remapping.

In the case of overlays, this costs additional memory bandwidth if the frame rate is low, but ends up saving memory bandwidth if the refresh rate is high enough.

That's on top of the other advantages mentioned.

Quote:

Are these facilities OS things that are layered on top of something like DirectX or OpenGL, or are they part of them? Certainly, I don't recall OpenGL having overlays or gamma ramps.

Gamma Ramps is something that's provided by the OS. Overlays is in DDraw, but can be accessed via WGL (if OGL rendering to overlays is supported).

Quote:

You might get some basic alpha effects without 3D accel, but most modern graphics hardware relies on it's 3D systems to handle that kind of thing.

It's more of an API problem than a hardware capability one. That said, video cards usually have at least two modes of operation: 2D and 3D. In 2D mode, most of the pipeline is shut down to save power/heat/fan noise. However, this 2D mode is more or less defined in terms what can be done via DDraw than anything else.

Quote:

In fact I believe OpenGL has something entirely separate it calls an overlay surface.

There are AUX buffer in GL, but that's not the same thing. Other than that, I'm not sure what you could be refering to.

Quote:

Especially if there's fast blending (you can use AGL or FBlend for this),

But FBlend doesn't do gamma-correct blending ;D

Like I said above, this is handled by the RAMDAC, so is essentially free.

--
- Bob
[ -- All my signature links are 404 -- ]

Marcello
Member #1,860
January 2002
avatar

Gamma seems like something you would want an option for in game, so the user can set the 'default' level to work with their screen... Then if you were to modify it, you'd base it off their default level.

I personally don't see these things as the main focus of A5 though, isn't the point for a cleaner yet more versatile API? That is, getting rid of global variables, moving stuff to namespaces, reducing number of redundent functions, closer integration of opengl, support for multiple displays/windows/screens.

Personally, I have recently been using full allegro C++ wrappers, so switching to A5 api is simply a matter of updating the wrappers. That will be pretty sweet. :-)

Marcello

Kitty Cat
Member #2,815
October 2002
avatar

It may be free, but it's highly dependant on external hardware. If you want it for fast fading, you should use FBlend or AGL instead. Gamma ramping only gives you two colors to fade to, white and black, and affects the whole screen (this is Very Bad for windowed apps). The other way gives you one of 16.7 million colors to fade to and lets you specify areas you want affected.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Billybob
Member #3,136
January 2003

How do you generate an allegro.def file for mingw32? I fixed the compile errors I was getting(see the mailing list) but I don't know how to generate the allegro.def. I tried "misc/fixdll.sh" under cygwin but still no allegro.def.

Bob
Free Market Evangelist
September 2000
avatar

Make depend.

--
- Bob
[ -- All my signature links are 404 -- ]

Billybob
Member #3,136
January 2003

that errors.

'sed' is not recognized as an internal or external command, operable program or batch file.

EDIT: Cygwin got further but errors too:
process_begin: CreateProcess((null), del _depend.tmp, ...) failed.
make (e=2): The system cannot find the file specified.

Bob
Free Market Evangelist
September 2000
avatar

Then download sed.

--
- Bob
[ -- All my signature links are 404 -- ]

Billybob
Member #3,136
January 2003

Ok, got make depend to run. But still no Allegro.def in lib/mingw32

Thomas Harte
Member #33
April 2000
avatar

Kitty Cat said:

And modifuying screen gamma is a Bad Thing

Funny, I don't recall inviting you into the design team for any of my projects. 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.

Quote:

Gamma ramping only gives you two colors to fade to, white and black

Depends how you define fading, really. If the blue channel can converge to one point, the red channel to another and the green to a third, why is this an any less valid fade than an 'every rgb converges to a particular rgb', given that the human eye is infinitely more sensitive to luminance than chrominance, neither of which are preserved in either scenario?

Quote:

and affects the whole screen

As already discussed, so does setting the palette in 8bpp mode. Will you be pushing for Allegro 5 not to allow palette adjustment?

Bob said:

There are AUX buffer in GL, but that's not the same thing. Other than that, I'm not sure what you could be refering to.

Well neither am I. It really is just something someone said to me once, without really explaining what OpenGL people therefore tend to refer to as overlays. I'll take your word over that half gleamed piece of ancient 'wisdom' any day of the week.

Marcello said:

Personally, I have recently been using full allegro C++ wrappers

Personal or well known wrappers? Popularity of different wrappers would be an interesting way to determine how people actually like their API to be (give or take C++ v C stuff).

Chris Katko
Member #1,881
January 2002
avatar

Quote:

And modifuying screen gamma is a Bad Thing

Not exactly. In fullscreen applications, it doesn't matter at all, as long as your program doesn't crash (and if it does, it fixes it on exit). For windowed modes, either use a software method, or allow the user to decide. Nobody complained that Quake 3 allowed you to change the gamma in a windowed mode.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Marcello
Member #1,860
January 2002
avatar

The only wrapper I've released is alBitmap, the rest are either under construction, or more specific to my style of coding (such as full game wrappers that handle timing, drawing, flipping, etc.).

I have also been working on ones for opengl/allegrogl (textures, fonts, and full game wrappers) as well.

I'm guessing, if I wanted to try sdl I could also modify the wrappers to work with that, although they are tailored for allegro's style of handling things.

Marcello



Go to: