Talk:Bitmap: Difference between revisions

From Rosetta Code
Content added Content deleted
(Languages built-in bitmap functions?)
(Why not?)
Line 5: Line 5:


:What is unclear to me is, can we use the existing bitmap image services of the language, or should we implement it from scratch using e.g. arrays? In RapidQ, I used QCanvas object. It has built-in methods for filling image, for drawing pixel and for reading pixel color, so there is no need to define any procedures. Many BASIC versions write directly to display hardware (e.g. in DOS or when using OpenGL or DirectX). Can this be used or should we have an off-screen image storage? --[[User:PauliKL|PauliKL]] 16:31, 20 February 2009 (UTC)
:What is unclear to me is, can we use the existing bitmap image services of the language, or should we implement it from scratch using e.g. arrays? In RapidQ, I used QCanvas object. It has built-in methods for filling image, for drawing pixel and for reading pixel color, so there is no need to define any procedures. Many BASIC versions write directly to display hardware (e.g. in DOS or when using OpenGL or DirectX). Can this be used or should we have an off-screen image storage? --[[User:PauliKL|PauliKL]] 16:31, 20 February 2009 (UTC)

::I would say it is OK to use device contexts, hardware buffers etc. So long you can implement the task from this [[:Raster graphics operations|category]]. However it could become quite tricky when it comes to digital filtration and other image processing techniques, because drawing contexts are usually oriented only to rendering. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 20:24, 20 February 2009 (UTC)

Revision as of 20:24, 20 February 2009

It seems quite a few of the examples don't fulfill the task. The task asks for 3 procedures, Create, Get, and Set, but only two or three of the examples have them.

Also, I'm kind of unclear on the "get the color" procedure. For example, C++ returns a boolean? I thought the point was to return the pixel's color? --Mbishop 08:02, 20 February 2009 (UTC)

The boolean return value indicates success. The C++ GetPixel routine returns the color by modifying three variables the caller passes into it. The alternative would be to return a special data type, or a packed integer. Many C++ environments have the special datatype, such as Win32's RGBTRIPLE, RGBQUAD and COLORREF, but it's not strictly C++, and they're not really necessary. And returning a packed integer would require the caller to do their own processing. Using pointers or references as arguments is a common idiom in C++. However, I can add another C++ example that provides those three types as arguments to SetPixel and return values for GetPixel, and throws exceptions on failure instead of returning false. --Short Circuit 09:00, 20 February 2009 (UTC)
What is unclear to me is, can we use the existing bitmap image services of the language, or should we implement it from scratch using e.g. arrays? In RapidQ, I used QCanvas object. It has built-in methods for filling image, for drawing pixel and for reading pixel color, so there is no need to define any procedures. Many BASIC versions write directly to display hardware (e.g. in DOS or when using OpenGL or DirectX). Can this be used or should we have an off-screen image storage? --PauliKL 16:31, 20 February 2009 (UTC)
I would say it is OK to use device contexts, hardware buffers etc. So long you can implement the task from this category. However it could become quite tricky when it comes to digital filtration and other image processing techniques, because drawing contexts are usually oriented only to rendering. --Dmitry-kazakov 20:24, 20 February 2009 (UTC)