Fast drawing

[Minuous]

'm the coder of the WinArcadia emulator, which is now feature-complete. I want to optimize it as it is extremely slow, it only achieves 1-2 FPS in most modes, this is with the CPU emulation turned off! The Amiga port of WinArcadia runs faster than this, even through WinUAE!

I'm using SetPixel()/ClipBlit() to do the drawing. Apparently it is much quicker to use SetBitmapBits(), but there doesn't seem to be any reasonable documentation about it.

If I may say so the entire Windoze display subsystem is a joke, it seems convoluted and poorly designed, things are much easier to do on an Amiga. The documentation over at MSDN is absolute crap and there doesn't seem to be any tutorials about it.

I don't want to use DirectX as I know for a fact that it is not necessary to gain adequate performance, there are other emulators of more complex machines which achieve good performance with GDI.

All I need to do is plot pixels one at a time to a bitmap, it only needs to be 8 colours (3 bitplanes), and refresh the window after each frame has been drawn. It already does this of course but much too slowly.

Aaarrrggh....

[Doomulation]

It's called Windows, btw and DirectX was created to make graphics rendering easy while fast.

[ShizZy]

Try SDL?

[Poobah]

Does GDI give you direct access to the screen's location in video memory? SetPixel() functions in just about any API are slow, because they usually do all sorts of checking and other things.

I do agree with you on the Windows display thing. Programming graphics stuff in DOS was easy, but in Windows we are pretty-much forced to learn a bloated API.

[gladius]

http://www.gaffer.scene.org/tinyptc/. If you must do it yourself, the bitblt API is extremely well documented and pretty darn easy to use as well. The function you want to use is called BitBlt (or a variant thereof). Check out http://www.winprog.org/tutorial/bitmaps.html and then take a look at SetDIBits to get a device indepdent bitmap (which will give you byte r,g,b format easily).

[hap]

If you want to stick to GDI, I advise you to use CreateDIBSection, to get a pointer to the bitmap pixel bits, which you can write to directly instead of a slow SetPixel or similar function, and just use BitBlt to blit it to the screen.

*edit* didn't read gladius' post, he basically said the same thing.

[Minuous]

Thanks all, I had a look at http://www.gaffer.scene.org/tinyptc/ and based it on that code. It's dozens of times faster now :-)

@Doomulation: There was no need to use DirectX, why force the users to download and install yet more bloatware? Windoze is bloated enough :-)

[Minuous]

Thanks all, I had a look at http://www.gaffer.scene.org/tinyptc/ and based it on that code. It's dozens of times faster now :-)

@Doomulation: There was no need to use DirectX, why force the users to download and install yet more bloatware? Windoze is bloated enough :-)

[Doomulation]

Thanks all, I had a look at http://www.gaffer.scene.org/tinyptc/ and based it on that code. It's dozens of times faster now :-)

@Doomulation: There was no need to use DirectX, why force the users to download and install yet more bloatware? Windoze is bloated enough :-)

Windoze = Windows.
Anyway, although I haven't tryied GDI, try 3D using it. I'm sure you'll get a headache. Besides that, DirectX isn't bloated, but pretty useful. DirectInput for example. Catches keys and much more flexible than Windows standard input mechanism. DirectShow, which is now part of the Windows SDK, can be used for a lot of things using a filter system. Easily integrated into media players for easy playback.

I consider DirectX to be something good. And for a reason.

[bcrew1375]

Windoze = Windows.

Um, I can't tell if you're being serious or not. It's a joke .