Welcome, Guest. Please login or register.

Author Topic: some questions about RTG library.  (Read 1864 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: some questions about RTG library.
« on: October 10, 2005, 10:32:21 PM »
Quote

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:
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: some questions about RTG library.
« Reply #1 on: October 10, 2005, 11:03:23 PM »
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.
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: some questions about RTG library.
« Reply #2 on: October 10, 2005, 11:25:38 PM »
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
int p; // A