Cemetech | Forum

12 May 2012 11:18:40 am by **AHelper** Quote · 12 May 2012 11:18:40 am by **AHelper**

It is not always faster. Lets say you want to draw one sprite in the middle of the LCD. If that's the case, use direct LCD commands because they are faster in this case. If you will be doing heavy drawing, like tilemaps or other drawing that renders to the entire screen, or you are drawing by pixels (pretty much everything else), then a buffer will work better. This is because there is no delay when you write to a buffer directly accessible to the CPU.

Here's another way to think about using buffers: When you draw to the LCD driver, you are not drawing everything at once. You draw something, run some code, draw again, etc.. The LCD driver has an internal refresh rate (for me, ~60Hz) that will start drawing everything in its buffer to the LCD. This can cause the LCD to be updated when you aren't done drawing everything. It may take a few refreshes (showing an incomplete image on the screen) until you have everything drawn to the driver's ram.

Another good thing about buffers. What happens if you have overlapping sprites, or you keep modifying the LCD before the final image is ready? Lets say you draw 10 sprites on top of each other. With direct LCD drawing, the LCD driver may update the screen while you are drawing. This will give you a flickering effect where you could see all of those sprites. If you use buffered drawing, only the final result will be sent to the LCD.

Examples of buffered: Tilemaps, greyscale, pixel or line renderings.
Examples of direct LCD: Text output, cursors, small amount of sprites.

13 May 2012 09:14:14 am by **KermMartian** Quote · 13 May 2012 09:14:14 am by **KermMartian**

Nope, that is inaccurate. You still need the delay after writing to Port $11, about 10 microseconds' worth.

14 May 2012 11:46:46 am by **CakeOfDestruction** Quote · 14 May 2012 11:46:46 am by **CakeOfDestruction**

2. I wrote a procedure for deleting the whole GrBuffer because when I called fastCopy oder GrBufCpy it displayed me a coordinate system. It worked really well, but unfortunately I can't use anymore the graph. It seems to be deleted (I wanted to write l-o-l in these brackets but the forums replaces this word with 0x05^^).

14 May 2012 11:51:55 am by **KermMartian** Quote · 14 May 2012 11:51:55 am by **KermMartian**

2. Is that faster than this?

14 May 2012 11:56:42 am by **CakeOfDestruction** Quote · 14 May 2012 11:56:42 am by **CakeOfDestruction**

€dit: "Not really" SORRY. Translation error in line 42 brain.z80
I meant that your code is faster... Don't feel offended please.

Unfortunately I can't see the coordinate system after launching this code (in the emulator)...

17 May 2012 11:22:32 pm by **calc84maniac** Quote · 17 May 2012 11:22:32 pm by **calc84maniac**

Edit: Save SP in HL

12 May 2012 03:56:50 am by CakeOfDestruction	Display Driver vs. _GrBufCpy	Quote
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).

12 May 2012 06:41:08 am by tifreak8x		Quote
I'm sure as soon as Kerm or someone else with some ASM experience comes on, they'll be happy to answer your questions And just for future reference, it's generally not a good idea to double post within a 12 hour period.

12 May 2012 09:35:27 am by Tari		Quote
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.

12 May 2012 10:17:10 am by KermMartian		Quote
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.

12 May 2012 10:41:23 am by CakeOfDestruction		Quote
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.

12 May 2012 11:28:06 am by CakeOfDestruction		Quote
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).

14 May 2012 12:21:44 pm by KermMartian		Quote
No offense would be taken, even if my code was slower. 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.