Powerful PCs = New Way of Programming (I hope!)

Well I have been writing programs on and off since the BBC micro (at a fairly basic level), and there has always been an accepted way of doing things. For example I am currently trying to write a platform game. The accepted way of doing this has been to use a grid system and check a number of grid squares round the character for collisions. I wrote a couple of programs like this on my old Amiga A500 (8Mhz CPU).
However since modern PCs are vastly more powerful - loads of memory and power I figure I can create any background I want (in an art package) and then use ImageCollide(image,x,y,0,background,0,0,0) to check for collisions. This means I don't have to draw platforms to a grid, and that slopes become very easy to implement, and I can destroy bits of platforms and do other stuff very easily which would have been a lot tougher to program using the old accepted way.
Is this a good idea? I've got a simple platform game up and running, but it slows down a bit (with debug on), and I'm worried when I get more objects on screen, all doing background collision checks, its going to get very slow.
Can I speed up collison checks my using a dummy reduced-color background (so there are less layers?). I don't really know why doing an imagecollide of a character(32 x 32) with a large background (1024 x 768) should be so hardwork for a modern PC, especially when you see whats possible in 3D these days.
I would like the thoughts of more experienced programmers on this technique - if I could use it, then it would be great because it requires a lot less effort, and is quite flexible - I can have any shapes in my background, and its easy to add enemies. I'm just worried about it being very slow. I'm using 16bit color depth by the way.
Would someone also tell me what pixmaps and collision layers are exactly, the manual doesn't really explain?
Thank you for any help :)

Rico

No idea where you might improve your code as you don't provide any. Personally, if not using a tile system, I would use a simple black+white image representing your level for collisions.
A pixmap is an area of system memory which defines the pixels within the texture you loaded. This pixmap *CAN* be drawn but is much slower than applying the texture to a surface (which is what Drawimage does).
Collision layers are exactly that. You write image data to a collision layer. Then, when you do your collision test, the system doesn't need to check the image against all others but just against the layer data. The system then returns an array with all the objects with which there has been a collision.

I've never used any of the internal Blitzmax collision checking, prolly never will. All of my platform code is based on tiles, only takes one check to see if a sprite is over a tile. Granted it's not pixel perfect, but if I needed that I would just make an array holding the pixel data of the tile/sprite and compare as needed.

However for huge multi scrolling worlds you will still need a tile map because vram still isn't big enough for huge bit mapped worlds in memory. ;)

I've used it, it works fine and isn't too slow.

I've read where the built in image collision checking works well, I just don't want to reply on a system that may not be available if/when porting to other platforms, mobile, etc. Collision checking in pure 100% code should be portable, hopefully. lol..

I want to do a test to see how many ImagesCollide(image,x,y,0,background,0,0,0) I can do in a frame- my monitor runs at 60Hz. Where 'image' is a relatively small object(16bit) and the 'background' is a 1024x768, 16 bit color image.
Is there a command to find the position of the vertical beam, like in older Blitz's? If I can't do enough of these collision checks before I go over a frame interval - I will have to use the more standard collision checking technique. (I am planning on having a lot of objects in my game all of which will need collision checks with the background, as well as other objects.

Thanks Rico

I had this problem with large maps in an old game I wrote. My solution was to build a collision map in the form of a 2D array, but made it 3 times smaller than the actual image size. This meant it only took a ninth of the memory. The tricky bit is when you destroy a piece of the graphic the user sees, then you must clear the collision array at the same area.