It's an option, there are a few games that used whole screen images for levels... this is either very convenient for artists, or hugely inconvenient for programmers.
If your game has a single screen as the level, then you could just load that as an image and paste it - same goes for character and enemy sprites - you could grab images from a tile sheet or load them individually, but then pasting images the same way. Really though I think that the benefits are only apparent when the benefits are apparent
- sorry if that makes no sense, but consider that using a tiled map means you have some benefits that are native to that technique - tile based collision detection for example, or being able to just draw the part of the map that you can see on screen, or animating particular tiles and not others. These benefits are less common or non-existant with single image maps. A good example of a single image map game would be a point and clicker, like Monkey Island - each scene is an image, and collision etc is cannot usually be governed by a tile map... heck the collision image might have to return the scale of a character on top of everything else. Another example is Lemmings, where each level is an image, or at least compiled into an image, but the actual image provides collision data and the collision cannot be governed by a tile map.... lems have to dig anywhere they need to, Guybrush needs to scale in the distance or follow an intricate path. My point is there's always a good reason for a single image based map, and if you don't have one then you are better off with tiles. Heck, even just loosing the ability to easily depth sort can make single image maps impractical.
Personally I don't think I'd ever use just 1 single image for a map. I'd use components to make a single image perhaps, but I'd always want to do something that makes single image maps impractical, like having parallax layers, animated tiles, animated water or sky, moving clouds, breakable parts, disappearing platforms... truly I have to say that I see single image maps as a very tall, very top heavy vase on a rickety shelf - looks nice, but it doesn't take much to topple it over - it needs to be used when you want to give an artist total control, have a requirement for per-pixel collision or destructible map, some good reason like that.
Maybe a good trade-off is to use sprites, you can set the depth so could easily layer elements to give a parallax effect but you'd still be using an image for the map, it just means you can easily have layers. Sprites can also be set to alpha fade, rotate, scale, colour, and even change the UV coordinates directly if you're feeling brave. They can also hold a tile sheet - so you could stick to tile sheets for animated sprites and rely on the built in commands for that - if you use PASTE IMAGE, then you have to do everything like that yourself... depth sorting, using several images per character etc etc - sprites are many magnitudes more powerful than PASTE IMAGE. I often make a sprite, hide it, and then set it's frame and PASTE SPRITE - it lets sprites work in much the same way as PASTE IMAGE, but retains the benefits of scaling, rotation, colouring, fading etc. I'm not sure if there's a way to paste a sprite in AppGameKit, you'd probably have to setup a render image for this stuff in AGK... it is worth remembering that sprites in DBPro are pretty much the same as in AppGameKit, so if you wanted to make it mobile, converting to AppGameKit would be nice and straightforward with sprites... with PASTE IMAGE it would basically be a complete rewrite in AGK.
The code is dark and full of errors
