|
get pointer from al_map_rgb()? |
Shadowblitz16
Member #16,818
March 2018
|
is there a way to get a pointer to the returned ALLEGRO_COLOR with al_map_rgb()?
|
Edgar Reynaldo
Major Reynaldo
May 2007
|
Whoa. Don't do that. First of all, al_map_rgb returns an ALLEGRO_COLOR on the stack. If you return it's address, you are giving back a dangling pointer because the stack object will go out of scope and die and now you're pointing to a corpse. However, you can use new to create a new ALLEGRO_COLOR that you will have to delete later. ALLEGRO_COLOR* newcolor = new ALLEGRO_COLOR(al_map_rgb(r,g,b)); // later delete newcolor; newcolor = 0;
My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
bamccaig
Member #7,536
July 2006
|
Edit: /beaten A pointer doesn't allocate memory for the data. Only for the pointer itself. You need to concern yourself with where the data will live. If it is on the stack (as with local variables) then it will no longer "exist" once you return from the function and your pointer will be invalid (subsequent function calls will overwrite the data). You basically have three viable options here:
Your results may vary trying to wrap Allegro with C++. It sounds easy at first, but it's not as easy as you think. Many have tried, and most have failed. Avoid globals, and try to design your API to guarantee the order of Allegro calls is valid (e.g., you initialize allegro, install the keyboard, create displays, etc., before loading bitmaps or doing other operations that may fail until you've done the others). I recommend you familiarize yourself with smart pointers and utilize them to help manage the memory. It's a lot safer than managing it yourself. Append: It should be noted that colors are relatively small, and that it makes sense to copy them around instead of passing pointers to them. There is a small performance hit also for dereferencing a pointer (first the CPU has to load the value for the pointer variable from RAM into the CPU, and then it has to load the actual data from RAM into the CPU). Again, this hit is negligible to do once, but it can add up if you're doing a lot of it, and in this case the data itself is probably about the same size as the pointer is so you're not really saving anything by passing a pointer instead of the data directly. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Shadowblitz16
Member #16,818
March 2018
|
EDIT: so what would be best for static calls like so...? 1col col1 = Gfx::newCol(0,0,0);
2// col1 gets deleted outside of function
I am trying to keep the library function based but I wanted to use classes as a way to tell what is coming from where. |
bamccaig
Member #7,536
July 2006
|
Just return the color itself. Colors are small enough that copying them around is negligible, and using pointers gives you no advantages and plenty of disadvantages. If there was a reason to use a pointer for this then Allegro would be returning a pointer to you. The only time you'd want to use a pointer for a color is where the semantics require it, which is unlikely to occur with colors. A color is probably either an integer or a float under the hood. At worst, it's a small structure that is probably only between 4 and 16 bytes in size anyway. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Shadowblitz16
Member #16,818
March 2018
|
my issue is that I want to eventually do indexed color and I would think passing color pointers to images and draw functions would be a good way to do that. |
bamccaig
Member #7,536
July 2006
|
I'm not even sure that you can do that with Allegro's bitmaps and buffers, but that's over my head. Edgar should be able to answer that... I think that Allegro 5 by default uses textures within your GPU for bitmaps. And when you draw to the screen similarly it gets sent to your GPU. This way you get video acceleration... I think there's no way you could access a pointer to a piece of that data, and even if you could, it wouldn't be an ALLEGRO_COLOR that you were pointing at (odds are the format of the bitmap or texture is independent of that, and likely defined by the graphics library or GPU). Append: Indexing apparently means palettes, which last time that I checked Allegro 5 doesn't support. If that's what you intend you might prefer to wrap Allegro 4.4 (which I think does support palettes; if not 4.2 was probably the most stable/popular 4.x there was, and Allegro version there was maybe..). -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
MikiZX
Member #17,092
June 2019
|
Possibly Allegro5 Color add-on can be of interest for its name-to-color feature? https://liballeg.org/a5docs/trunk/color.html#al_color_name Then I'd second what bamccaig said re: palettes though you can easily simulate those in A5 with an array of ALLEGRO_COLOR values and use it to convert from your calling function (that uses the index) to an ALLEGRO_COLOR value (that is used by Allegro5). |
Edgar Reynaldo
Major Reynaldo
May 2007
|
I'm not sure what you want indexed color for, but A4 did this with palettes. Basically, they are an array of colors which you would pass as a uniform to your shader. Then when you draw, you pass the index, which gets looked up in your uniform. This is with shaders. A4 didn't use shaders though, it used 8-bit palettes or color tables. What are you using it for? My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
ZoriaRPG
Member #16,714
July 2017
|
Ugh. I'd go with a global array of *GamePalette[number_of_palettes][palsize] pointers here, if you want to create a simulated/emulated indexed colour palette in Ag5 that you can change from anywhere. Keep it simple. It's a primary part of your game software that you will be using everywhere, so stop using wrapper classes and all sorts of stuff that obfusticates it. Make it easy to know that you are accessing the palettes. I'm not even certain that GamePalette need be a declared as a pointer. Can it be an ordinary array of GamePalette[number_of_palettes][palsize], with each index just storing the colour value as int? Anyway... #define NUMBER_PALETTES 1 #define PALETTE_SIZE 256 ALLEGRO_COLOR *GamePalette[NUMBER_PALETTES][PALETTE_SIZE]; //in main, first: memset(GamePalette,0,sizeof(GamePalette)); Then, make functions to build the initial state of the palettes, and and add functions that have a local array of ALLEGRO_COLOR in the form of a single palette to copy a local instance of this type of array to the global one.: //local function has ALLEGRO_COLOR *TempPalette[PALETTE_SIZE]; //set up or read colours into the indices of TempPalette, then: memcopy(&GamePalette[i], &LocalPalette, sizeof(LocalPalette)); //to copy the colour values to your game palette You can make those functions part of a class/struct, for the sake of organisation, and you can make the *TempPalette a class member if you want, as you stop using it after the class instance is deconstructed.
|
|