Double buffering of WB?

[Minuous]

I'm writing an emulator and am planning to have it be able to run in full-screen mode and as a window on the Workbench screen. The problem is that currently the graphics are much too slow and flickery. I'm running OS3.9 under WinUAE.

Is it possible and allowed to do double-buffering on the Workbench screen? Are there restrictions on what screenmodes it would work with (ECS/AGA/RTG)? I notice there are some programs that seem to do fast smooth animation in a WB window, eg. Heretic 2, Frogger, etc. so it must be possible...? Many thanks.

[Minuous]

I found Piru's AWin package on Aminet. It seems to be almost perfect except that you have to use custom replacements for OpenWindowTags() etc. which makes it unusable because I want a ReAction window (ie. NewObject() to open the window). Any way around this?

[Karlos]

How do you mean, double buffer the workbench screen? You mean the entire screen or just the window?

If you need to just double buffer the window area and you are aiming for RTG, your best bet is to simply AllocBitMap() an offscreen BitMap that is allocated using the workbench display's Screen->RastPort.BitMap as a friend (thus ensuring it is the same format and in video ram etc).

Create a new RastPort for this BitMap (so that you can use any OS routines that use RastPorts) and you can then render all your stuff to this offscreen BitMap.

When you need to update the window, you can simply use ClipBlit() to blit it to wherever you need it in your window.

It's always worked for me.

[Minuous]

OK, just the window is all I need to buffer, phew...

Thanks.

On a similar topic...When the emulator is in full-screen mode, I'm writing directly to bits in the bitmap on my custom screen. This is extremely slow if I have UAE set up to do cycle-exact blitting, but quite quick if I have it set up to do immediate blits.

Just wondering what the reason for that is? Because I'm using the CPU, not the blitter, to write the bits. So I wouldn't think the blitter had anything to do with it? And the copper should still be redrawing the screen at the usual intervals? So I can't see why there would be a speed difference...I must be missing something obvious...?

[Thomas]

Cycle-exact is not directly related to blitting. It slows down the entire emulation because it syncronnises the CPU and the custom chips to the exact cycle counts like on a real Amiga.

If you write into the screen's bitmap, the blitter is not used. But in case of cycle-exact the update is captured and promoted to the display immediately. This massively slows down the code. You should not use cycle-exact emulation and especially you should not write code which needs cycle-exact emulation. This code won't be compatible to different Amiga models with different custom chip versions.

As suggested above you should render into an off-screen bitmap and then blit the entire picture into your Window or screen.

Bye,
Thomas

[Minuous]

OK, I've done as suggested.

However although it is smoother, it is just as slow as it was before. Even though the Amiga shouldn't be having to redraw the display every time I change a pixel (since I'm now using an offscreen bitmap).

The draws are taking about 5 seconds per frame in 16-colour OCS 320x256 mode (in cycle-exact mode). I'm not using scrolling or anything. It needs to be fast in cycle-exact mode so it is fast on real Amigas, and so UAE users don't have to fool around with their settings just to run my emulator.

Obviously it must be possible to do fast smooth graphics under OCS, as all the vintage Amiga games (eg. Hybris, Shadow of the Beast, etc.) do it, but I'm mystified as to how they can run perfectly under UAE at A500 speed but my emulator is crawling at fastest possible speed!?

Code sample from the emulator can be posted on request.

[Piru]

@Minuous

However although it is smoother, it is just as slow as it was before. Even though the Amiga shouldn't be having to redraw the display every time I change a pixel (since I'm now using an offscreen bitmap).

The draws are taking about 5 seconds per frame in 16-colour OCS 320x256 mode (in cycle-exact mode). I'm not using scrolling or anything. It needs to be fast in cycle-exact mode so it is fast on real Amigas, and so UAE users don't have to fool around with their settings just to run my emulator.

No real 7MHz 68000 Amiga can do this either.

Obviously it must be possible to do fast smooth graphics under OCS, as all the vintage Amiga games (eg. Hybris, Shadow of the Beast, etc.) do it, but I'm mystified as to how they can run perfectly under UAE at A500 speed but my emulator is crawling at fastest possible speed!?

These classic games use scrolling (poking bitplane shift regs + bitplane pointers + only updating the newly visible (well actually it's typically insvisible) area by blitting in new, precalculated/drawn gfx). They also use sprites and/or bobs to update only part of the display. They do NOT update whole 320x256x4 at once, esp not pixel at a time. It's just not possible with the std 68000 Amiga.

[Minuous]

OK, thanks for enlightening me Piru.

Final question, I promise... :-)

Is there an easy way to use your rather impressive AWin routines without using your custom functions for opening windows and handling input? As I want to use a algorithmically laid-out ReAction window, but it seems AWin is not designed for this? ie. I use NewObject() instead of OpenWindowTags(). If I handled the window opening and input processing myself, but used your blitting functions, I presume that wouldn't work (your functions initialize some things that the normal functions don't?), otherwise you wouldn't have needed to write enhanced replacements for those functions, am I right?

[Piru]

@Minuous

AWin is a one unmaintainable spaghetti code. It certainly isn't modular, so you'd need to separate all the blitting code from it, which again would mean rewriting large parts of the code.

While AWin contains some rather advanced and fast code, it surely isn't good programming example. Sorry. :-)