Quote:
I disagree. There almost certainly IS a way, you just need to be efficient about figuring out what needs to be displayed and what doesn't.
If your scrolling the entire background every frame, then it would be necessary to redraw everthing.
Quote:
Although I haven't tried making a tile game before, I believe GDI is sufficient for most 2D needs other than alpha blending and crazy dynamic stuff (which can probably be closely simulated with pre-generated animations anyways). Besides which, GDI performance issues might force a lazy developer to figure out more efficient algorithms and better design.
The GDI is not too well designed from the standpoint of loading bitmaps, blitting them, etc. but it's not too hard to create wrappers of it. People make all sorts of mistakes such as forgetting to select in the old bitmap when your done, forgetting to delete the device context when it's done.
Quote:
>>this is creating a large surface in video memory to pan on.
Why not create several smaller surfaces (i.e. one for each unique tile) - or in GDI you might use HDC's or just HBITMAPS - and blit them to the primary surface when they scroll onto the screen, instead of drawing the whole thing in one go?
I do both. I have the tiles loaded into memory along with a paning surface. In reality it's not just a large surface but three for the different parallax levels(Only two are map layers , the other one is just a bitmap). But for a while I was only using one surface, and I did not think the scrolling was as smooth as a video arcade's. The scrolling is still not done with one very huge surface, it's actually done with a fairly large surface with calls resync the surface with map data when the boundaries cross over. Since this does not happen too often, it's not noticed. My video card is not all that good, however.
Quote:
>>but even this could probably be improved by using directx/opengl.
The point wasn't optimization - it was that GDI can be used, and is a good thing to learn anyways. From your comments, I'd guess that you haven't learned GDI very well yourself.
I am to the point where I can pretty much look up the arcane functions and create code. I understand the basic mechanisms of CreateCompatibleBitmap, LoadImage, and SelectObject. But that said, I will always create something overtop of the gdi code. Ok, one of the reasons why my map editor was little flickerly using gdi was that I had not overrid OnEraseBkgnd(this would occur when the user scrolled down very fast) but this is besides the point.
Quote:
It's obvious that DirectX or OpenGL would offer significant performance enhancements (if the graphics ever get as complex as that), but... well, DUH. They're game libraries (well, OK so OpenGL is all-purpose. Whatever.). GDI is fairly simple compared to both though, IMO.
I don't think the simple argument holds here. I consent that if he was creating a map editor, he would most likely want to use MFC and the MFC's gdi code but this doesn't mean the bulk of the gdi's code will be any simpler. Once someone has written out the main abstractions for bitmap loading and blitting and directx initialization, I don't think gdi would have any advantage. If simplicity was the deciding factor, then the SDL or allegro are much more simpler to use.