Why are you keeping vectors of DMA'd pointers? std::vector::operator[] returns mutable references so it's not like you need pointers to be able to modify the data... and you're using extra time (to allocate the block of memory) and memory (to store a pointer and the data pointed by it) as well as vastly increasing the risk of a memory leak, with no identifiable benefit. I hardly ever use pointers directly in C++. I rarely need them because references and STL containers supersede most uses of pointers.
That would still be dynamic as it uses the default allocator assigned to vector. If you were to make your own allocator class you could make it use a buffer on the stack instead, as an example.
Don't really see how it wouldn't suit your needs unless you are modifying the size of the map after it is loaded, which is unlikely if you are loading it from a file.
I'm writing a game "engine"/library but I have actual concrete goals, its going to be AAA quality for at least the PS2/Xbox/GameCube era of gaming but no way will I be able to make lengthy games as a one man. I've been writing at it on and off because of school for one year. A lot of my code was canned last year due to hardware issues and frustration, I then developed the philosophy that I would never throw away my old code again for learning purposes and possibility of benefiting later from it. My engine has goals, because I learned that there are some things you can't do in certain time periods all on your own.
Heres what I won't do by myself or with the aid of a library or other developers (to speed things up):
College Graduate level (Game Quality) Physics: PhysX or Bullet for things more complex than springs, particles, rigid bodies, and simple dynamics.
GUI (aside from simple low-level graphics driver/dlls): GTK or QT for this.
AI (aside from game dependant logic):
Sound: OpenAL, SFML maybe
What I've done and am doing myself:
Type & Number Systems
Platform independance layer (for windows & unix based machines, done, others not so much,
f*ck Apple)
Resource Management library
Filesystem/IO library wrapper
Data Structures library (all finite set structures, vectors, lists, maps, queues, stacks, etc.)
Math library: vectors, rays, planes, spheres, matrices, points, 2d/3d shape primitives
Custom 2d/3d graphics library : Rasterizer, Image Caches, (Image buffers) Textures , 2d Sprites, etc.
OpenGL or DirectX (haven't decided) wrapper: for Shaders, Hardware Acceleration, Effects
I've learned almost as much as I think I know about development by actually doing as well as reading.
They say make games, not engines, but if you make games you are basically making a simple library. The difference is that I came in on the reverse part of the spectrum thinking I could make a so called "game engine" easily. Many things seem easy on paper, experience thought otherwise. Even after a year I estimate that I am only (arbitrarily 60%) finished with what Ive assigned to myself. Imagine half of what the boost library is and add Ogre, that is what I am aiming for. It is my contingency plan for possibly starting either a small company or having some massive weight to a resume. You know, when they (the employers) weed out all of the dozens of Mc-dojo CS/IT/CIS applications that people get without deep understanding of what they are supposed to know. I see it as (humbly) a small object oriented extender of the stl.
In short, "game engine development" or software library development is so deep that any those topics I've listed could get you lost If you are not goal-minded (seeing the light at the end of the tunnel). Not to mention the mathematics which is a whole nother story :). But it definitely is possible to make what most people call game engines, If and only if you are goal-oriented and know when to stop developing and start profiting. And my library is not my only project, it is helping me do easy software emulation (on a simple 8-bit level) for a spin-off nes emulator.
Don't really see how it wouldn't suit your needs unless you are modifying the size of the map after it is loaded, which is unlikely if you are loading it from a file.
vector<ALLEGRO_BITMAP*> tiles; // create vector to hold tile bitmaps
ALLEGRO_BITMAP *sprite; // create bitmap to hold entire tile sheet
sprite = al_load_bitmap("tilesheet.png"); // load tilesheet png file
for(int i = 0; i < 10; i++) // loop through image file how you want (this is my preference)
{
for(int j = 0; j < 2; j++)
{
tiles.push_back(al_create_sub_bitmap(sprite, i * TILE_SIZE, j * TILE_SIZE, TILE_SIZE, TILE_SIZE));// load each tile into the vector array
}
}
// draw map code here
for (int x = 0; x <= TILEMAP_WIDTH; ++x)
{
for(int y = 0; y <= TILEMAP_HEIGHT; ++y)
{
int tileIndex = map[x][y];
al_draw_bitmap(tiles[tileIndex], y * TILE_SIZE, x * TILE_SIZE, 0); // draw map though I had to flip x/y variable to draw it right
}
}
I would just like to reiterate that I never did mention building a game engine, I was just asking about building a game with an engine, I wanted to know about experiences using them to build games.
Aaaaaand we just ignore OP. Don't worry guy, this happens quite often. Always fun to see this sort of discussion happen anyway; consider your question answered, at least from this forum. For more info I'd suggest looking at gamedev.net instead.
As for the off-heap/dynamic tile loading, you really should just be using an std::vector with value members, not pointers. Less of a performance thing and more of a memory-leak-prevention thing (unless you use STL pointers at least.)
God, if I didn't use products because I don't like the companies business practices I'd never buy anything again and you would hear about me for being arrested for repeated offenses of indecent exposure. All companies and people have questionable practices, some are just more extreme than others.