Ideas on extracting image data

[9wqjE3v7]

Hey everyone, I am currently in the prototyping phase of developing a simple subcomponent of my graphics engine, using the console. It is meant to extract vertex and pixel data from a 24 bit color .bmp file into it's own .iod file (my file format).

That data, upon instruction, will be loaded into the vertex buffers, texture arrays and pixel shaders. It will be an external image exporter if you like.

My question is whether I should do this or just get my engine to just directly extract the data and load it into the rendering pipeline without all these extra steps.

Advantages I can think of my current design plan:

*Less memory needs to be dynamically allocated during actual runtime of whatever application is using the engine, since only relevant data has been extracted.
*File formats change over time, having my 'own' (sort of) will save a lot of earache.

Can anyone think of any disadvantages? Is this a good design plan?

I will show you my source code:

*NOTE: It is still under development, I know I should also define my own copy constructor and assignment operator to avoid two pointers sharing the same memory, and I also know that globally using the standard namespace is a bad idea. I wrote it last night.*

*UPDATED*

//UNDER CONSTRUCTION

#include <resource_mgr.h>

using namespace std;

namespace obv {

class resource_mgr { //planning to include png formatting as well, hence the abstract class
virtual void parse() = 0;
};

class bmp_resource : public resource_mgr {
private:
	int block_size;
	unsigned char * scanner;
	bool file_found;
public:
	bmp_resource(const char*); //constructor scans image file data
               bmp_resource(const bmp_resource&); //under costruction
	~bmp_resource(); // deallocates memory from the heap
	void parse(); // 'parses' or 'extracts' appropriate data into new IOD file
};

bmp_resource::bmp_resource(const char* filename) : file_found(false) { 
	ifstream img_file (filename, ios::binary | ios::ate | ios::in);
	if(img_file.is_open()) {
		file_found = true;
		block_size = (int) img_file.tellg();
		scanner = new unsigned char [block_size];
		img_file.seekg(0,ios::beg);
		img_file.read((char*)scanner, block_size);
		img_file.close();
	}
	else {
		file_found = false;
}
}

bmp_resource::~bmp_resource() {
	if(file_found) {
		delete [] scanner;
	}
}

void bmp_resource::parse() {
	if(file_found) {
	ofstream parsed_file;
	parsed_file.open("img_data.oid", ios::binary);
	for(int x = 54; x<block_size; x++) {
		parsed_file << scanner[x];
	}
	parsed_file.close();
}
}
}

int main() {
	obv::bmp_resource test ("testpic1.bmp");
	test.parse();
	return 0;
}

Thanks for any feedback!

[cire]

If you fail to open the file in the constructor, both parse and the deconstructor will result in undefined behavior. Why are you using manual memory management?

[9wqjE3v7]

Thanks for the reply, like I said It is unfinished, and I am planning to add a boolean to determine whether parse and the deconstructor will resume usual behaviour. which part of the code are you referring to with your memory management concern?

[cire]

which part of the code are you referring to with your memory management concern?

All of it.

[9wqjE3v7]

If you mean why I am using raw pointers as opposed to smart pointers, it is because this is just code to demonstrate the idea, it is unpolished. If you are asking why I am dynamically allocating memory as a whole, it is due to the fact that the pixel data is of an undetermined size.

Though that is not answering my question.

[cire]

Can anyone think of any disadvantages? Is this a good design plan?

*Less memory needs to be dynamically allocated during actual runtime of whatever application is using the engine, since only relevant data has been extracted

Maybe I'm missing something here. You want to trade speed for a minor decrease in overall memory usage in a graphics engine?

*File formats change over time, having my 'own' (sort of) will save a lot of earache.

How does that save you effort? Instead of having to deal with just "file formats that change over time" you have to also deal with your own format (that will probably change over time.)

[9wqjE3v7]

Maybe I'm missing something here. You want to trade speed for a minor decrease in overall memory usage in a graphics engine?

No. The file exporter is an external program. Therefore the graphics 'engine' is not affected in terms of speed. The graphics engine will load the vertex and pixel data from the existing generated file into memory. I hope this clears up a few things.

How does that save you effort?

I will be working with multiple file formats. If their structure changes, I only have to modify my 'parser' program, my engine code will never need to change. Dabbling with the engine code would result in me having to tweak the whole graphics pipeline, since everything would be interlinked.

[N36fSL3A]

Kinda off topic but please answer this and continue with the topic.

What does this virtual void parse() = 0; do?

[3qX21hU5]

It is a pure virtual function or abstract function and is required to be overwritten in a derived class.

I would suggest looking up how classes and polymorphism work to get a better understanding.

[N36fSL3A]

Thanks. I'm finna do that now.

[cire]

No. The file exporter is an external program.

Err.. then why post code that has nothing to do with the design you're attempting to discuss?

I will be working with multiple file formats. If their structure changes, I only have to modify my 'parser' program, my engine code will never need to change.

You only have to modify your 'parser' code if you don't use a proprietary file format, as well.

Dabbling with the engine code would result in me having to tweak the whole graphics pipeline, since everything would be interlinked.

Your "engine" should be dealing with "images" or "textures" and not be remotely concerned about how they're stored in a file, be it proprietary format or other.

[9wqjE3v7]

Err.. then why post code that has nothing to do with the design you're attempting to discuss?

If you have read my post carefully, you would realise that the whole point of the topic was to discuss whether the idea of using an external program would be a good or bad design plan. So the code I posted is relevant.

Your "engine" should be dealing with "images" or "textures" and not be remotely concerned about how they're stored in a file, be it proprietary format or other.

You have misunderstood my aim. I am using the Direct3D API. It used to include a higher level library dealing with the loading of "texture" resources. It is deprecated as of windows 8, so as a result I am loading the pixel data into an array, which will be passed onto a shader, so that it can be rendered pixel by pixel. I cannot just load a "texture" like you are claiming. I am not oblivious as to what I am doing. Are you trying to tell me I can load an image without any data?... I never said the "engine" should be concerned about the way data isstored, though it still has to load it.

This really isn't going anywhere...I think I am going to have to make my own judgement.

[cire]

If you have read my post carefully, you would realise that the whole point of the topic was to discuss whether the idea of using an external program would be a good or bad design plan. So the code I posted is relevant.

I think you'll find that most people aren't going to assume that "a simple subcomponent of my graphics engine" is an entirely different application. Given the following posts, the actual "mock" code serves no purpose unless you're asking about the implementation of that separate application, which apparently you aren't.

You have misunderstood my aim.

No doubt.

The decision to use a proprietary file format is inconsequential to the actual design.

However, using a proprietary file format (and another application on top of that) means extra complexity. Extra complexity in maintenance, because you're maintaining an extra application, and extra complexity for users, because they have to jump through a hoop to convert their art to your format.

Otherwise, we're talking about a single utility function that loads a resource.

I just don't see the design quandary.

[9wqjE3v7]

I think you'll find that most people aren't going to assume that "a simple subcomponent of my graphics engine" is an entirely different application.

Maybe I didn't clearly address my points, but I did mention in later posts, to you specifically, that it was going to be an external application.

I just don't see the design quandary.

You are right. I have been overcomplicating things. Your final post was what the answer I initially from this topic, I was so stuck on trying to cut on performance memory usage that I came up with rather rushed ideas, (besides, the 'exporter' does not really get rid of that much information, so you would only be saving on as small as 80 bytes). Thank you.

EDIT:

Your "engine" should be dealing with "images" or "textures" and not be remotely concerned about how they're stored in a file, be it proprietary format or other.

That is ridiculous, how do you expect the "images" to be "loaded" if the engine cannot find the appropriate data to do so?

[ModShop]

Relevant: http://xkcd.com/927/

[S G H]

Disvantage: Planning a compression algorithm.