| View previous topic :: View next topic |
| Author |
Message |
Chris Forone
Guest
|
 Posted: Tue Jun 03, 2008 6:02 pm Post subject: [Fwd: design question] |
 |
|
-------- Original-Nachricht --------
Betreff: design question
Datum: Tue, 03 Jun 2008 12:48:57 +0200
Von: Chris Forone <4one@gmx.at>
Organisation: Tele2UTA Telecommunications GmbH
Newsgruppen: comp.lang.c++
hello group,
whats a good design for a loader of different grafic-files. have the
loader-class (fstream) and a texture-class (internal format/RGBA, always
the same). now i want different grafic-files (.bmp, .pcx, other very
simple gfx) loaded for the texture-class.
is there a "filter" design approach?
should i give some functor object for each gfx-format, that acts on the
pic-data?
is it best done via a class hirarchy?
thanks a lot & hand, chris |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Tue Jun 03, 2008 9:04 pm Post subject: Re: [Fwd: design question] |
|
|
Responding to Forone...
| Quote: |
whats a good design for a loader of different grafic-files. have the
loader-class (fstream) and a texture-class (internal format/RGBA, always
the same). now i want different grafic-files (.bmp, .pcx, other very
simple gfx) loaded for the texture-class.
is there a "filter" design approach?
should i give some functor object for each gfx-format, that acts on the
pic-data?
is it best done via a class hirarchy?
|
It probably depends on the processing you need to do to "load" the file.
There are basically two tasks be done: reading the graphics file formats
(.bmp, .pcs, etc.) from their source and doing something with the
content once it is read.
For the reading, something like the GoF Strategy pattern would probably
be best. The relationship (R2) for the right Strategy object would be
instantiated as soon as you know what format the file is (presumably
when the file name is parsed). So one might have something like:
[Client]
| *
|
| R1
|
| invokes
| 1 1 interprets for 1
[FileReader] ---------------------- [FormatStrategy]
R2 A
| R3
+-----------+-----...
| |
[BMP] [GIF]
Here FileReader reads lines, blocks, or whatever from the physical file
and then invokes FormatStrategy to interpret them for the Client.
If this is a pure UI rendering problem, than it might be more convenient
to have the Strategy do that directly (i.e., it reads the file and sends
the appropriate instructions to the display software directly rather
than to the Client). That's because the formats are designed for direct
loading into display buffers.
OTOH, if you (Client) needs to do something more complicated with the
graphics (e.g., some sort of preprocessing filter), then it might be
better for the Strategy objects to simply convert the format in hand to
a single common format to be input to the subsequent processing. That
common format would be returned by FileReader to Client.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Chris Forone
Guest
|
| Posted: Wed Jun 04, 2008 10:35 am Post subject: Re: [Fwd: design question] |
|
|
H. S. Lahman schrieb:
| Quote: |
Responding to Forone...
whats a good design for a loader of different grafic-files. have the
loader-class (fstream) and a texture-class (internal format/RGBA, always
the same). now i want different grafic-files (.bmp, .pcx, other very
simple gfx) loaded for the texture-class.
is there a "filter" design approach?
should i give some functor object for each gfx-format, that acts on the
pic-data?
is it best done via a class hirarchy?
It probably depends on the processing you need to do to "load" the file.
There are basically two tasks be done: reading the graphics file formats
(.bmp, .pcs, etc.) from their source and doing something with the
content once it is read.
For the reading, something like the GoF Strategy pattern would probably
be best. The relationship (R2) for the right Strategy object would be
instantiated as soon as you know what format the file is (presumably
when the file name is parsed). So one might have something like:
[Client]
| *
|
| R1
|
| invokes
| 1 1 interprets for 1
[FileReader] ---------------------- [FormatStrategy]
R2 A
| R3
+-----------+-----...
| |
[BMP] [GIF]
Here FileReader reads lines, blocks, or whatever from the physical file
and then invokes FormatStrategy to interpret them for the Client.
If this is a pure UI rendering problem, than it might be more convenient
to have the Strategy do that directly (i.e., it reads the file and sends
the appropriate instructions to the display software directly rather
than to the Client). That's because the formats are designed for direct
loading into display buffers.
OTOH, if you (Client) needs to do something more complicated with the
graphics (e.g., some sort of preprocessing filter), then it might be
better for the Strategy objects to simply convert the format in hand to
a single common format to be input to the subsequent processing. That
common format would be returned by FileReader to Client.
|
Thanks a lot. What do you think about a class, with stream-iterators
using for example the transform algorithm to modify the data-stream?
cheers, chris |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Thu Jun 05, 2008 9:35 pm Post subject: Re: [Fwd: design question] |
|
|
Responding to Forone...
| Quote: |
[Client]
| *
|
| R1
|
| invokes
| 1 1 interprets for 1
[FileReader] ---------------------- [FormatStrategy]
R2 A
| R3
+-----------+-----...
| |
[BMP] [GIF]
Here FileReader reads lines, blocks, or whatever from the physical
file and then invokes FormatStrategy to interpret them for the Client.
If this is a pure UI rendering problem, than it might be more
convenient to have the Strategy do that directly (i.e., it reads the
file and sends the appropriate instructions to the display software
directly rather than to the Client). That's because the formats are
designed for direct loading into display buffers.
OTOH, if you (Client) needs to do something more complicated with the
graphics (e.g., some sort of preprocessing filter), then it might be
better for the Strategy objects to simply convert the format in hand
to a single common format to be input to the subsequent processing.
That common format would be returned by FileReader to Client.
Thanks a lot. What do you think about a class, with stream-iterators
using for example the transform algorithm to modify the data-stream?
|
You are now in OOP implementation issues and, as a translationist, I
rarely go there anymore. I am also not sure I know what you mean by
'transform algorithm'. B-(
If all the iterators and transform algorithm are doing is extracting
information from the stream, then I would expect them to be part of the
implementation of the FormatStrategy objects. For example, each subclass
implementation would hard-wire the right stream iterator for the format
it deals with.
OTOH, if you want to modify the stream itself prior to using it, my
second paragraph might come into play. There would be advantages in
having the modifications work on a single format rather than being
reinvented for each raw input format. However, I would still expect
things like stream iterators to be part of the implementation of the
objects; there would just be more objects processing the stream at
different stages.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Chris Forone
Guest
|
| Posted: Fri Jun 06, 2008 11:00 am Post subject: Re: [Fwd: design question] |
|
|
Michael DOUBEZ schrieb:
| Quote: |
H. S. Lahman a écrit :
Responding to Forone...
[Client]
| *
|
| R1
|
| invokes
| 1 1 interprets for 1
[FileReader] ---------------------- [FormatStrategy]
R2 A
| R3
+-----------+-----...
| |
[BMP] [GIF]
Here FileReader reads lines, blocks, or whatever from the physical
file and then invokes FormatStrategy to interpret them for the Client.
If this is a pure UI rendering problem, than it might be more
convenient to have the Strategy do that directly (i.e., it reads the
file and sends the appropriate instructions to the display software
directly rather than to the Client). That's because the formats are
designed for direct loading into display buffers.
OTOH, if you (Client) needs to do something more complicated with
the graphics (e.g., some sort of preprocessing filter), then it
might be better for the Strategy objects to simply convert the
format in hand to a single common format to be input to the
subsequent processing. That common format would be returned by
FileReader to Client.
Thanks a lot. What do you think about a class, with stream-iterators
using for example the transform algorithm to modify the data-stream?
You are now in OOP implementation issues and, as a translationist, I
rarely go there anymore. I am also not sure I know what you mean by
'transform algorithm'. B-(
The question was originally posted in comp.lang.c++ so I gues, he means
the std::transform() function of the c++ STL which takes a range
(delimited by a begin and a end iterator) and apply a transformation to
this range into a destination range (output iterator).
If all the iterators and transform algorithm are doing is extracting
information from the stream, then I would expect them to be part of
the implementation of the FormatStrategy objects. For example, each
subclass implementation would hard-wire the right stream iterator for
the format it deals with.
Yes. I suppose the OP wanted an on-the-fly byte transformation from one
format into another. This is of course no possible for non-linear
formats (such as JPG or JPG2000 that are fractal based or wavelet based
representation of the data). For simple format like bmp, pcx ... I guess
it would be possible but I am not sure the design overhead is justified.
OTOH, if you want to modify the stream itself prior to using it, my
second paragraph might come into play. There would be advantages in
having the modifications work on a single format rather than being
reinvented for each raw input format.
The downside is that each format provides a particular set of
information (vector graphics for scaling, bmp for richness...). A
composition of command pattern that applies the transforms on a mutable
object (in the body-envelop fashion) before requiring a final
representation of the image would preserve it. In theory at least, it
might be an overkill for textures and simple things like that.
|
Thanks a lot. My idea was to write a texture-loader class, extended by
small filters they do the bit-transformation. So the Loader can simly
extended by new graphic-formats. Maybe, the filters are objects
operating with the data. The formats .tga and .pcx are rle-encoded, so
the stream-approach is good, but other formats (you said) are more
complicated to decode.
cheers, chris |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Michael DOUBEZ
Guest
|
| Posted: Fri Jun 06, 2008 11:00 am Post subject: Re: [Fwd: design question] |
|
|
H. S. Lahman a écrit :
| Quote: |
Responding to Forone...
[Client]
| *
|
| R1
|
| invokes
| 1 1 interprets for 1
[FileReader] ---------------------- [FormatStrategy]
R2 A
| R3
+-----------+-----...
| |
[BMP] [GIF]
Here FileReader reads lines, blocks, or whatever from the physical
file and then invokes FormatStrategy to interpret them for the Client.
If this is a pure UI rendering problem, than it might be more
convenient to have the Strategy do that directly (i.e., it reads the
file and sends the appropriate instructions to the display software
directly rather than to the Client). That's because the formats are
designed for direct loading into display buffers.
OTOH, if you (Client) needs to do something more complicated with the
graphics (e.g., some sort of preprocessing filter), then it might be
better for the Strategy objects to simply convert the format in hand
to a single common format to be input to the subsequent processing.
That common format would be returned by FileReader to Client.
Thanks a lot. What do you think about a class, with stream-iterators
using for example the transform algorithm to modify the data-stream?
You are now in OOP implementation issues and, as a translationist, I
rarely go there anymore. I am also not sure I know what you mean by
'transform algorithm'. B-(
|
The question was originally posted in comp.lang.c++ so I gues, he means
the std::transform() function of the c++ STL which takes a range
(delimited by a begin and a end iterator) and apply a transformation to
this range into a destination range (output iterator).
| Quote: |
If all the iterators and transform algorithm are doing is extracting
information from the stream, then I would expect them to be part of the
implementation of the FormatStrategy objects. For example, each subclass
implementation would hard-wire the right stream iterator for the format
it deals with.
|
Yes. I suppose the OP wanted an on-the-fly byte transformation from one
format into another. This is of course no possible for non-linear
formats (such as JPG or JPG2000 that are fractal based or wavelet based
representation of the data). For simple format like bmp, pcx ... I guess
it would be possible but I am not sure the design overhead is justified.
| Quote: |
OTOH, if you want to modify the stream itself prior to using it, my
second paragraph might come into play. There would be advantages in
having the modifications work on a single format rather than being
reinvented for each raw input format.
|
The downside is that each format provides a particular set of
information (vector graphics for scaling, bmp for richness...). A
composition of command pattern that applies the transforms on a mutable
object (in the body-envelop fashion) before requiring a final
representation of the image would preserve it. In theory at least, it
might be an overkill for textures and simple things like that.
--
Michael |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
103 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
