some questions about RTG library.

[kas1e]

Hi all.

Well, can anyone explain to me: rtgmaster, can be as ppc version or 68k only ? And if ppc version can be, it is fast or no ? and what version of library is lastest (68k or ppc - whatewer).

thanks.

[Piru]

Whatever you do, avoid rtgmaster at any cost.

It's one of the worst things that happened to Amiga.

[Karlos]

Piru wrote:
Whatever you do, avoid rtgmaster at any cost.

It's one of the worst things that happened to Amiga.

I dunno, I once spilled a full bowl of rice crispies (a cereal I liked before this trauma) and milk upside down onto my A1200D.

That was like the worst thing that happened to my amiga anyway :lol:

[LuisTHE]

 Why do you say that?

[Piru]

@LuisTHE

Some of the reasons:
- It nukes horribly due to stupid programming bugs.
- It incorporates horrible and butt-ugly custom modeid requester nonsense. Yuck.
- Inconsistent and utterly broken API. It seems 0 designwork went into this.
- Utter bs and lies about ppc.library in the documentation.
- About every app using it crashed in a way or another. Often the reason could be tracked directly to rtgmaster.
- Unfinished/lacking documentation.
- It doesn't lock/unlock the bitmap properly (at least cgx).

[Karlos]

I've never felt inclined to develop any code for it.

As for PPC (OS3.x I mean) stuff, you generally need to do context switches for display handling anyway, so I usually write a few 68K functions that in one go refresh the display, swap bitmaps, lock them etc before returning to the PPC, which just has to worry about calling my 68K function each frame and can run along unhindered the rest of the time.

[Piru]

@Karlos

Indeed, this is exactly what I did aswell. Group as much as possible OS calls into one chunk of m68k asm code and then call it with argument structure.

Imagine for example calling some 68k routine 256 times in a loop with full cacheflush in between, and then calling the 256 x 68k routines in one go, and then doing *single* cacheflush afterwards... Needless to say, the speedup was massive.

[Karlos]

It's a good plan.

I had my own display context that upon calling the refresh() function for it, it would switch to 68K, bitmaps unlocked, switched, all IDCMP messages since the last frame gathered into a local buffer, display refreshed, new bitmap locked and then back to PPC.

The PPC would then call native callbacks for the buffered input events.

End result, 1 full context switch but you get all the OS work done and you get to handle your input natively on the PPC in time for the next frame. Not a bad result.

-edit-

Good heavens, did we just agree on a coding issue? :-D

[kas1e]

I want to do it not for code, but for testing some stuff (games basically), so, just want to know what latest/fastest version of this sucking rtg library

[Piru]

I guess it would be:
gfx/board/rtgmaster_user.lha

Good luck.

[kas1e]

it's strange, but Napalm work pretty good in 640x512x8 ..