|
Allegro 4.9.7 |
Thomas Fjellstrom
Member #476
June 2000
|
I was only partially sure it was a compiz issue on the first report, but with glut causing issues as well? I'm pretty sure now. -- |
lemranger
Member #10,003
July 2008
|
Just tested the released 4.9.7.1 with these results on my iMac/3.06Ghz/Intel/2GB/NVIDIA GeForce 8800 GS machine: - ex_fs_resize buggered my desktop icon placement (squished them up). - ex_mouse_cursor has no different cursor for keys 1, 2, or 3 - ex_ttf - when I substituted a fix-ed width font (monaco) the letters were unusually wide apart. - ex_noframe[4291] *** Assertion failure in -[ALWindow _changeJustMain], /SourceCache/AppKit/AppKit-949.43/AppKit.subproj/NSWindow.m:8598 - ex_threads[4309] *** _NSAutoreleaseNoPool(): Object 0x1aeea0 of class NSConcreteValue autoreleased with no pool in place - just leaking (x 5) - ex_winfull did not work at all I think my last testing focussed on the new stuff so I didn't check the whole WIP. Serious question: I am converting an old flight simulator of mine to use OpenGL and wanted to avoid using a bunch of different libraries for text/image-loading/saving/sound which is why A5 is so appealing to me. However, in the few tests that I have done, it is not clear to me that I can use those Allegro routines within an OpenGL context (my quick experiment with the TTF addon and OpenGL failed). Is there a simple way to incorporate the new text and image routines within OpenGL? Thanks for your hard work! -- Paul |
Evert
Member #794
November 2000
|
Quote: - ex_fs_resize buggered my desktop icon placement (squished them up). I don't think fullscreen resize (on OS X) worked at all at the time the WIP came out; it works in current SVN though. Quote: - ex_mouse_cursor has no different cursor for keys 1, 2, or 3 Cursors 2 and 3 are the "busy" and "question" cursors if I recall correctly. OS X has no separate cursors for either of those. Quote: - ex_ttf - when I substituted a fix-ed width font (monaco) the letters were unusually wide apart. Weird. That's something that someone should try to reproduce on another platform as well. Quote:
- ex_noframe[4291] *** Assertion failure in -[ALWindow _changeJustMain], /SourceCache/AppKit/AppKit-949.43/AppKit.subproj/NSWindow.m:8598 - ex_threads[4309] *** _NSAutoreleaseNoPool(): Object 0x1aeea0 of class NSConcreteValue autoreleased with no pool in place - just leaking (x 5) Ah! Yes, I noticed those too, but forgot to comment on them. Thanks for pointing them out again. Quote: - ex_winfull did not work at all It should be fixed in current SVN. |
Peter Wang
Member #23
April 2000
|
Here's what it looks like on my Linux machine. Is that how it looks for you? I also noticed for DejaVu Sans Mono (and also DejaVu Sans) that there are extraneous dots at the bottom right of some words. Any ideas?
|
Elias
Member #358
May 2000
|
Quote: Serious question: I am converting an old flight simulator of mine to use OpenGL and wanted to avoid using a bunch of different libraries for text/image-loading/saving/sound which is why A5 is so appealing to me. However, in the few tests that I have done, it is not clear to me that I can use those Allegro routines within an OpenGL context (my quick experiment with the TTF addon and OpenGL failed). Is there a simple way to incorporate the new text and image routines within OpenGL? There will be a function to directly get the OpenGL texture id from an Allegro bitmap, so image loading for use in OpenGL should be very easy. You can of course always get the contents of a bitmap as RGBA data and pass to glTexImage to transfer to an OpenGL texture, that's also only a single line of code. As for TTF, someone was working on a TTF renderer which renders to triangles - I think it would be really nice to have one or two OpenGL specific functions who translate directly to OpenGL shapes. Or maybe we can be even more advanced and have some kind of callback mechanism where the callback gets passed triangle data for a glyph, so you could easily make things like a vertex array version or even DirectX version for glyph rendering. In any case, need to wait for the triangle-font addon to be done. With the bitmap-based ttf addon, I'm not sure how to expose the internal data. Could maybe also have some kind of glyph-rendering callback: void opengl_callback(float x, y, int gl_texture_id, x, y, w, h) And for each glyph to render, the callback would be passed the coordinates, the OpenGL texture and the rectangle within the texture where a rendering of the glyph is cached. EDIT: Quote: I also noticed for DejaVu Sans Mono (and also DejaVu Sans) that there are extraneous dots at the bottom right of some words. Any ideas? Fixed in SVN. When the change was made to cache multiple glyphs in one texture, they were put a bit too close together. (Or alternatively, there's some clipping bug which allowed overwriting neighbor glyphs. Adding a 2 pixel space between glyphs fixed it in any case.) -- |
lemranger
Member #10,003
July 2008
|
Quote: You can of course always get the contents of a bitmap as RGBA data and pass to glTexImage to transfer to an OpenGL texture, that's also only a single line of code. I guess that would work the other way too: get an OpenGL rendering to RGBA data and make a bitmap of it for conversion to an image file for saving? Perhaps for the TTF rendering of canned strings, I could make bitmaps of the text I need, then pass the RGBA version as an OpenGL texture? For I/O I suppose doing the same thing on the fly would be more expensive, but in my sim at least, there is no need for speed when asking for text input from the user. I'll try that as an interim solution... thanks. --Paul |
Evert
Member #794
November 2000
|
Quote: There will be a function to directly get the OpenGL texture id from an Allegro bitmap When? Quote: As for TTF, someone was working on a TTF renderer which renders to triangles - I think it would be really nice to have one or two OpenGL specific functions who translate directly to OpenGL shapes. Or maybe we can be even more advanced and have some kind of callback mechanism where the callback gets passed triangle data for a glyph, so you could easily make things like a vertex array version or even DirectX version for glyph rendering. In any case, need to wait for the triangle-font addon to be done. Is this a different one from the drawing primitives addon? Hoe many planned addons are still missing? I thought the list was just
are there more? |
Elias
Member #358
May 2000
|
Evert said: When? Maybe it's there already. Otherwise the function would be quite simple, something like: int al_opengl_get_texture_id(ALLEGRO_BITMAP *bitmap) { return bitmap->opengl_texture; }
Evert said: Is this a different one from the drawing primitives addon? Well, I was thinking of Thomas Harte's font rendering code.. -- |
lemranger
Member #10,003
July 2008
|
Quote:
Quote: - ex_ttf - when I substituted a fix-ed width font (monaco) the letters were unusually wide apart. Weird. That's something that someone should try to reproduce on another platform as well. I tried a bunch of other mono fonts and none of them exhibited that wide spacing. Must have been my monaco.ttf file. --Paul |
Evert
Member #794
November 2000
|
Quote: I tried a bunch of other mono fonts and none of them exhibited that wide spacing. Must have been my monaco.ttf file.
Could be. I tried on my Mac and I got the same output as Peter. |
lemranger
Member #10,003
July 2008
|
I downloaded a Monaco_Linux.ttf file (I don't get the forum through my e-mail) and the spacing problem was resolved (although the 12 point font was messed up). ex_ttf seems to work fine with proper .ttf files though. --Paul |
Evert
Member #794
November 2000
|
Quote: I downloaded a Monaco_Linux.ttf file (I don't get the forum through my e-mail) and the spacing problem was resolved (although the 12 point font was messed up).
Oh? Do you have a screenshot? Quote: ex_ttf seems to work fine with proper .ttf files though. It's probably a problem with FreeType, which is what Linux and Allegro both use to handle .ttf files. Additional: Quote: Maybe it's there already. Otherwise the function would be quite simple, something like: Ok, I'll check. Quote: Well, I was thinking of Thomas Harte's font rendering code.. Ah, right! Sounds good. |
lemranger
Member #10,003
July 2008
|
I used your monaco font file (finally saw the paperclip, duh..) and the "linux" one I tried. You can see the results. Either too wide or can't do the small fonts. I installed the linux font file on my system and it shows okay at the small fonts. It's also 4x the size for some reason. I'm running 10.5.6. Urgh - can't upload multiple files go here: |
Evert
Member #794
November 2000
|
I can confirm the problem with the file you linked to (iBook running 10.4.11, but I don't think that matters). You can attach multiple files by uploading them one at a time. |
Matthew Leverton
Supreme Loser
January 1999
|
Quote:
Is an A4 compatibility layer even a good thing? I think it might serve as an excuse to not make A5 as easy to use as it should be. |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: I think it might serve as an excuse to not make A5 as easy to use as it should be. Yes, lets rip out the event system and replace it with A4's key[] array and mouse_ variables. (thats essentially what the compatibility layer is providing, some things to ease initial ports, but it won't be fully compatible, some things in a4 just won't work even with the compatibility layer) -- |
CGamesPlay
Member #2,559
July 2002
|
This thread might be a good place to gather opinions about something I brought up a while ago: How do users feel about the idea of linking all of the bundled add-ons into one binary file? This would primarily serve to shorten the length of the linker line, but would also mean that there were fewer DLLs to distribute. It would still maintain the same level of separation that the add-ons afford now, because the only connection would be that the add-ons are linked into the core. -- Ryan Patterson - <http://cgamesplay.com/> |
Evert
Member #794
November 2000
|
Quote: Is an A4 compatibility layer even a good thing? Yes - as long as it doesn't detract from making A5 as good as it can be. Quote: I think it might serve as an excuse to not make A5 as easy to use as it should be.
Those excuses will not be accepted. |
Thomas Fjellstrom
Member #476
June 2000
|
Just static link them. Why bother with linking all of the addons into core when that affects Binary Compatibility? -- |
CGamesPlay
Member #2,559
July 2002
|
It doesn't affect binary compatibility as long as all of the add-ons maintain binary compatibility themselves. -- Ryan Patterson - <http://cgamesplay.com/> |
Thomas Fjellstrom
Member #476
June 2000
|
We'd have to have some magic script that builds the windows DLL in the proper way, in the proper order each release, and thats just a pain in the ass. The current allegro.def generator is already annoying, imagine extending it to include 5 extra libraries? -- |
Elias
Member #358
May 2000
|
Quote: This thread might be a good place to gather opinions about something I brought up a while ago: How do users feel about the idea of linking all of the bundled add-ons into one binary file? This would primarily serve to shorten the length of the linker line, but would also mean that there were fewer DLLs to distribute. It would still maintain the same level of separation that the add-ons afford now, because the only connection would be that the add-ons are linked into the core. I'm all for it. And as far as I can see, this mainly would need someone volunteering as Windows packager who creates this DLL in addition to the separate one (which we should keep as well). Maybe some code changes are necessary as well, it seems in Windows you need to alter function declarations depending on if they go into a DLL or not. Also the build will need an extra option for this, but if cmake is as good as they say, it probably is easy. -- |
Matthew Leverton
Supreme Loser
January 1999
|
Quote: Yes, lets rip out the event system and replace it with A4's key[] array and mouse_ variables. How did you read that into my post? [Disclaimer: some method names / properties may be wrong.] Eg., as a programmer, say I just want to add a "wait for any key" at the end of some miscellaneous function: ALLEGRO_KEYBOARD_STATE key_state; bool keydown = false; while (!keydown) { al_get_keyboard_state(&key_state); for (int i = 0; i<MAX_KEYS && keydown == false; ++i) { if (al_key_down(&key_state, i)) keydown = true; } } or ALLEGRO_EVENT_QUEUE *queue = al_create_event_queue(); ALLEGRO_EVENT event; al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*) al_get_keyboard()); while (al_get_next_event(&event) && event.type != ALLEGRO_KEY_UP) {} Here's what will happen: #include <allegro5/allegro.h> #include <allegro5/allegro-compat.h> int main() { // lalala, use Allegro 5 normally. // boy this function sure was a simple way to wait for a key press, let's bring in the compatibility layer! while (!keypressed()) { } } When, perhaps a native solution could simply be: #include <allegro5/allegro.h> int main() { while (!al_keypressed(NULL)) al_poll_keyboard(); } Now we've eliminated the need for a compatibility crutch by just making A5 easier to use. Events are still there. The only thing that is different, is now Allegro has a default key struct that can be populated by polling. I just don't know why it has to be treated as a second class approach. And furthermore, I don't see how an A4 compatibility layer will solve a lot of problems, as you'll still have to go through your code and make sure it all works. I think a better use of time would be to write a conversion upgrade guide. |
CGamesPlay
Member #2,559
July 2002
|
Correct me if I'm wrong, but all you have to do is static link the add-ons objects into the DLL's core objects. That means you only need to have the .def generator include the source files for the addons. Should be relatively trivial. Since everything is going into one library, you don't need to worry about the order of linking. Allegro is supposed to be easy to use. Forcing someone who's never used a compiler before to figure out the proper order to linking 10 or so libraries together is not conveying a good message. -lalleg -lkcm_audio -licodec -lacodec -lpng -lz -lGL -lGLU ... -- Ryan Patterson - <http://cgamesplay.com/> |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: Also the build will need an extra option for this, but if cmake is as good as they say, it probably is easy. It probably is normally, but allegro uses some pretty hacks to get multiple builds of the lib on a single configure (cmake really doesn't know how to do that by itself, which imo is a mistake). Quote: Correct me if I'm wrong, but all you have to do is static link the add-ons objects into the DLL's core objects. static linking into the core lib may not actually get those symbols exported. You generally have to give windows a special declaration to have it export symbols. -- |
|
|