Display Driver vs. _GrBufCpy

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

Hi guys, I read the tutorial about the display driver and how to write directly to the screen. But I also know that there is an "easier" way to draw to the screen (by using _GrBufCpy). I have to admit that I didn't read the tutorial completely but I've seen that it's difficult to draw lines and somethig like this. By using the driver I'm able to set the column and row easily and can use the auto-increment for more speed.
I just want to know whats easier/faster for programming games (and programs with sprites and other graphics).

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

In the moment I am trying to write a function for displaying sprites with the driver. it seems to be a little difficult to write outside of a byte. I think I'm going to read the byte, then OR it with my sprite and write it back.

Furthermore I think writing with the driver is faster, is it?

€dit:
Can somebody explain me the reason for this behaviour?!?

tifreak8x · Guru Joined: 16 Mar 2005 Posts: 9063 Location: Sol System

I'm sure as soon as Kerm or someone else with some ASM experience comes on, they'll be happy to answer your questions Smile

Tari · Posted: 12 May 2012 09:35:27 am Post subject:

There are very few cases in which you want to write directly to the driver's memory. Advantages of using an in-memory buffer:

Double-buffering makes your code updating the display invisible.
Much easier to write to memory.
Faster (in most access patterns).

You'll typically read and modify a given display location a few times each frame (dependent on what you're actually displaying). Each write requires a delay for the driver, so it should be faster to use an in-memory buffer if you're touching any given part of the display more than once.
If you're not updating the entire display at once, it would be useful to update only the dirty region, which shouldn't be too difficult, depending on the granularity you want.

I wrote a routine for XORing sprites directly to the display a while ago. Not sure if it was ever tested though. Unless you have a compelling reason to write directly to the LCD, it's better to do the usual buffer+fastcopy.
_________________

Ask questions the smart way · タリ

KermMartian · Posted: 12 May 2012 10:17:10 am Post subject:

Indeed, it's much better to do a fastcopy and use the buffer. Well-said, Tari. Unfortunately, the TI-OS _grbufcpy is quite poorly-written and quite slow, so the community has composed a variety of replacements. I for one wrote a version in Doors CS, which I believe is one of the fastest around. It also has special cases that let it work properly on the calculators with buggy LCD drivers and on Nspires at a faster speed, not to mention that it handles interrupts cleanly. Unless you have a burning desire to manipulate the LCD driver yourself, which I don't really think is worth your time, you should use iFastCopy (i for Ion) with graphics routines such as fastline, fastrectangle, and lots of other fun graphics libraries that shell libraries such as Doors CS's DCS and MOS libs provide.
_________________

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

Thank you for the informations! But unfortunately I do not understand why it is faster to write to the buffer.
I think when I call _GrBufCpy the calculator does send the whole buffer to the display. Why should it know what I've updated? And the TI-OS does use the same driver, doesn't it?

Thank you for the tip with Doors CS but first I want to learn "standard" programming for the calculator for understanding.

AHelper · Posted: 12 May 2012 11:18:40 am Post subject:

By driver we mean a special chip inside the ti8x. This chip has its own internal LCD ram, containing all of the pixel on the screen. Now, the CPU doesn't have direct access to that ram, hence why you must use in/out. This requires delays, which takes time.

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

Thank you very much! Now I understood it. Admittedly it is possible to write (Port $11) without waiting - however i understand the advantage.

Overlapping Sprites are - as you said - difficult to handle because you have to read the pixels via IN A, ($11) (+ dummy read).

KermMartian · Posted: 13 May 2012 09:14:14 am Post subject:

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

Sorry for writing wrong arguments, I did understand it wrong^^

I have 2 new questions:
1. Is it possible to decrease a 16-bit register with getting flags?
I want to write a loop with more than 255 loops, so I tried to use DEC BC. Unfortunately it did not work, so I decided to use SBC. But i think this is not a good solution

KermMartian · Posted: 14 May 2012 11:51:55 am Post subject:

1. This is the preferred formulation for a bc-based loop:

CakeOfDestruction · Newbie Joined: 14 Apr 2012 Posts: 12

KermMartian · Posted: 14 May 2012 12:21:44 pm Post subject:

No offense would be taken, even if my code was slower. Smile

Ohhh, you mean that the axes go away? Yes, once you erase the screen, there's nothing automatic that draws the axes in. Remember, you have full control over the screen, and the OS doesn't get to intervene unless you say it can.
_________________

calc84maniac · Posted: 17 May 2012 11:22:32 pm Post subject:

This would indeed be a faster way to clear the graph buffer (and the loop could be unrolled more if needed):