Well, the conundrum I have is that I have an vector of class instances. But inside the class I am trying to allocate a char array with 'new' and having a data 'blob' inside the class instance.
All is working ok (with the allocation done in the OP) and the data 'blob' that gets allocated is fine.
But if I then add another instance to the vector the 'blob' gets a heap corruption. I am guessing it is because of the internal shuffle that goes on in the vector and the data 'blob' pointer is pointing to the wrong place.
The data blob is a particularly important aspect for me and I need a way to be able to iterate through all of the instances and process this data, without having to manually know about each class instance.
Any advice on how I should approach this would be great
Note the operator | instead of the ','. Also, while this does not matter, I would usually prefer to call the flags std::ios::in and std::ios::binary since they belong to streams in general and not just file streams.
Genius, changing the comma to a pipe fixed it instantly.
It is odd because I copy and pasted the code from the project that I made that does the encoding in the first place.
I was obviously lucky that the writing component worked in the first place - hehe.
Game engines are hard to design, at some point the generic engine code stops, and the game specific code starts. The problem is, where is that point.
I am reading from your post there are no obvious open areas in your engine any more. That means to me, you're finished making your engine!
Now, it is probably useful for learning purposes, to evaluate your engine. In other words, how good does it do its job?
(I do hope you have a list of requirements what your engine is supposed to handle).
Thus, testing time has arrived. Package the engine, give it a fancy name and version number (fooengine, 0.1 alpha, build 21583).
Then make a new directory, unpack the engine, and now make a game, like pong, tetris, pacman, space invaders, whatever you want. (Smaller is better, it's the first test, don't try anything big until you're confident small things "are trivial".)
Here you're supposed to write only game-specific code. Assuming you will finish at some point, leave it for a week, and then look again at the code you actually wrote, and the changes you made in the engine code (which you are not supposed to change?!). Could you re-use parts for another game? Did the engine code cause restrictions where you had to work around, or even hack the engine code to make it work?
At this point, you can decide to fix or expand the engine, making a new version, and a new test cycle begins.
If things look good, it's probably useful to do at least 2 or 3 games, to verify your findings.
And here you see the disadvantage of focusing at an engine. The games are not the goal any more, the engine is the goal. The games you make become sort of by-products of testing the engine. With each test cycle of the engine you have to write a lot of games, or update already written games.
If this is what you want to do, it's fine, just be aware of it.
For myself, being someone working on an engine myself, this is arguably the best post I have ever read!