Problem is but I cannot picture and figure out how do I implement the "area" where the user(artist or designer) can add items selected from the editor that can be displayed on screen so they can see the result created(could be a simple small map or a simple small level)?
Why don't you use the same routine used for displaying the actual level? From my experience, its easiest to just use the same rendering technique you'd draw your level ingame, and just add custom controlls for manipulating the level in the actual editor.
Yep, this is what I do. Software blitting to a buffer in memory, then copy it to the screen. It's a little slow, but modern computers have no problem with it for simple 2D games, and it minimizes the amount of hardware-specific code.
In the game, I use SDL to get access to the framebuffer, and copy my buffer over. In the editor, I use the FLTK library, which I'd highly recommend if you go C++ because it's nice and simple to set up and use, open source, cross-platform, and doesn't bloat your .exe size or require a big .dll in wondows/system32 or whatever. My final software buffer to screen display looks like this:
[source] fl_draw_image(
(const u8*)screen->pixels,
dest.x,
dest.y,
destWidth,
destHeight,
sizeof(ColorType),
screen->pitch * sizeof(ColorType));[/source]
Where ColorType is just a typedef for unsigned long (32 bit value). And that's done in a function that's called automatically whenever the map view control needs to be redrawn. That's the general way of coding window apps... you create a bunch of windows/controls, and they have functions that get called when they receive input or need to be drawn or whatever, and you do your stuff in those. They'll usually either be virtual functions inherited from a base window class that you override, or you call a library function and pass yours as a function pointer (basically virtual functions implemented manually in C). Some libraries have separate functions for each event, and some have a single function with an event type argument.
Be warned, level editors are often as much work as the actual game. Mine is a little bloated, about 16K lines at the moment, but last week I did a refactoring pass and didn't really find much to be improved on... there's just a lot to be done, editing the actual map data, layers, sprites, collision, the tileset window, where you can have several tilesets loaded per map, and edit the default collision type for each tile of the tileset, and then add undo functions for everything, and serializing data to be saved on disk...
Of course, you can make it a whole lot easier if you keep things simple. One layer, or at least a fixed number of layers, one tileset .bmp loaded at a time, single-level undo that only applies to drawing on the map, no messing with collision in the map editor... just make an array in the code somewhere that matches the order of tiles in your tileset and says whether each tile is solid or not.
Oh, and it's generally better to use a 1D array of width*height entries for the map, rather than a 2D array. Access tiles like map[y * width + x]
Easier to support variable map dimensions, easier to save to disk, most library functions expect things that way, such as the screen buffer in the code snipped above.
