Yuku free message boards

> 1. A game coded in C will be just as fast as one coded in ASM, yes?
Macroscopic performance will be nearly as good in C as in ASM, and C is, on average, 3 to 5 times quicker to develop than the exact equivalent ASM code. On embedded platforms, C is a good trade-off between performance and development time.
That said, the hot spots of your code can be written in assembly for performance (which does also help size a bit, unless some loop unrolling is done). The vast majority of routines in fast GFX libraries (ExtGraph, Genlib) are written in ASM for that reason.
On a simple enough (no caching, very little pipelining) processor like the 68000 is, either the compiler just isn't smart enough, or it's too much of a pain (not to mention dependent on the compiler and its version...) to write C code that the compiler will turn into a well-optimized form.
And you can't do self-modifying code in C.

> 2. I notice that the animated screen shots over at techno plaza run very slow. This worries me a bit. Is this due to bad code practice on their part (i.e. the tutorials give examples which are slow at runtime), or are the animated images just slow due to bad capture software?
I'd say that it's the capture software's fault, but I could be wrong.

> 3. Should I know anything about sprite routines, etc. or should I just roll through the techno plaza tutorials and I will be ok? I know when I used to program for TI83+ we used ion sprites routines and other fast sprites routines which we could find on ticalc.org.
Same on TI-68k calculators. The only thing you need to know for grayscale is the memory layout of the sprites (there are lots of grayscale formats), but that's usually described in the documentation.
At a time, there were many GFX libraries for TI-68k calculators, but only two or three are still maintained and compatible with all TI-68k calculators (V200 and 89T inclued): ExtGraph and Genlib. They have different design philosophies, different execution models (see below).

> 4. If there is anything else I should know I would appreciate any info!
Like every group of human beings, the TI-68k programming community has members who have been around for a long time, and have wildly different opinions on various subjects, e.g.:
* optimization: size optimization, speed optimization, trade-offs ?
* binary compatibility between TI-68k models: should one make binaries that work on both 89/89T and 92+/V200, so that people can freely transfer them between the two kinds of models, at the cost of kilobytes of code+GFX data in large programs ?
* code execution models: should one use the features of PreOS, a so-called "kernel" (PreOS has been for years the only maintained "kernel") ? What are the avantages of kernel-based programming over so-called "_nostub" programming, better called "AMS native" programming, and vice-versa (and what was the evolution of both models over time) ?
* program launchers: should one use specific launchers in order to save several keypresses for the user, or use a generic launcher (ttstart, SuperStart) instead in order to save space as soon as there's more than one specific launcher at a time on a calculator (and SuperStart is actually easier to use than a specific launcher) ?

That sometimes shows in the topics (it used to be much more frequent), so don't be surprised if you stumble across such a discussion/flame

> Thanks for the informative response.
You're welcome

> One thing i do not understand is why all these games that I download have so many files to load up onto calc.
On AMS (the TI-68k standard OS), one cannot make files larger than ~64 KB (65520-byte HANDLEs <-> 65518-byte data available for the user). 64 KB is way too small for the code of the largest programs, let alone their data. Hence the oversized program support in TIGCC (and the kernel-based dynamic library loading support, which is more powerful - but that requires a kernel).
Thank TI for putting stupid protections (neutralized by HW3Patch) in their calculators, and therefore making it harder to make large programs, or simply launch a program from another one...
> Does no one include their sprite data and stuff in the main?
Between many others, most TICT programs do. But that can't be done if code+data exceeds ~64 KB, and this limit is rather easy to reach.
> On ti83+ stuff I would put all sprite data etc. in .inc files and just #include them into the main code. I must learn these ti89 ways.
AFAIK, TI-68k calculators enable you making much larger programs than TI-Z80 calculators do.

> In your opinion, are 32x32 grayscale sprites too much for the 68k to handle?
Definitely no.
That said: tell us more about what you'd like to do. The most common sprite format is 16x16, and it has the most kinds of routines tailored for different types of games:
* "slow" games where sprite routines (clipped or non-clipped) are fast enough;
* scrollers with a background, for which a tilemap engine is often a smart solution;
* brute-force "redraw everything at each frame" with preshifted sprites, which is not always smart.
Currently, ExtGraph has all three kinds of routines for 16x16 sprites, but only the first one for 32x32 sprites. There's the beginning of a 32x32 tilemap engine on my HD, started last year by Michael Hergenrader, but I won't include that in the upcoming ExtGraph 2.00 Beta 5.

> Ok, thanks for the tips on which libs to use. I'll look into that stuff. Thanks!
> BTW, is TICT still pretty active?
TICT has been only me for several years. I've not been very active programming-wise over the last four years, because of school, summer internships and now work.
That said, I've made a dozen of commits on the ExtGraph SVN repository ( http://opensvn.csie.org/ExtGraph , overloaded SVN host due to its popularity) in the past weeks, bringing ExtGraph closer to a release with major improvements. At last, since the latest release of ExtGraph, which I made at the end of 2004, is wildly outdated compared to what's in the SVN repository. Many bugfixes, new features, new demos.

> Are there any other programming groups, or forums that are still active?
The TI-68k subsection of yAronet ( http://www.yaronet.com/en/forum.php?s=2 ) is more active than this one... but French is usually spoken there.
That said, it doesn't hurt to post there in English, especially now that the English-speaking TI-68k section, which never became very active, was closed (AFAIK). I've already done it for several English-speaking programmers.

Thanks for mentioning other, more active, boards. I mentioned only those that I attend on a regular basis.
I can see that the most active members of Mobifiles attend all other boards.


@Jonathan: OK, now I understand why you worry about the capabilities of TI-68k calculators

The optimal range of framerates is something like [10-12 FPS, 20 FPS]. Framerates above that range are a waste of power (because of the screen quality), and framerates below that range tend to feel choppy to human beings. Just to mention two large and good games that people are happy with: Ice Hockey 68k and Duke68k are, IIRC, around 15 FPS on average.

In the three kinds of algorithms I mentioned above, in order to draw the background:
* clipped sprite routines are too slow to handle such a game (ExtGraph demo12);
* the memory requirements of preshifted sprites are at least an order of magnitude above the amount of usable RAM of the TI-68k calculators;
* that leaves the tilemap engine (ExtGraph demo17 is the equivalent of demo12; demo13-16,24-25 show off other features, some of which were strongly inspired by Genlib). The tilemap engine needs 1 or 2 bytes per tile + sprite data, thus benefiting from the redundancy of backgrounds.

In order to draw sprites over the background: a single mask for both planes of the sprite is certainly enough (and is faster), but still, a 32x32 grayscale sprite with single mask is 384 bytes. Multiplied by 8*(6+4+3), that's 39 KB worth of sprite data.
That's significant, but not insane: there are several games that have between 200 and 300 KB of code + data, which is less than half of the amount of memory available in 89 or 92+ running AMS 2.xx (patched with MaxMem if the calculators are HW1s, the oldest hardware model whose production ceased about 9 years ago).
The advantages of not compressing sprite data are that you can read it directly from archive memory without decompressing it first... but since sprite data is fairly compressible, this increases the size of large sprite data sets quite a bit.

I'm not aware of any complete 32x16 or 32x32 tilemap engine. Maybe one such engine is embedded in a game, but I'm definitely unsure of that, since 16x16 sprites are more common in tilemap engines.

> Looking forward to reading your always well written reply.
You're welcome

> I have already started doing some major graphics work by drawing tiles and sprites. Here is some stuff I have for sonic: [...]
Looks nice

> For the tiles I am drawing 8x8 tiles. I believe this will aid in speed, and personally I find it easier to draw tiles and break things down to an 8x8. So I do believe this is a good choice.
Drawing smaller tiles does probably help reducing the number of sprites, but it will definitely decrease performance of the tile RefreshBuffer routine (in ExtGraph terminology).
I don't have any bench right now to measure the exact impact (that wouldn't be very hard to do, but I can't do it in the next few days), but writing 16 bits is just as fast as writing 8 bits (the 68000 has a 16-bit data bus); writing a B/W 16x16 sprite requires 1*16 writes to memory with a 16x16 routine, 4*8 writes to memory with a 8x8 routine.

> Also what I am thinking is make the tiles black and white, and only make the sprites grayscale. This should also increase the speed yes?
Indeed:
* the Refresh routine for the tiles will be roughly twice faster;
* a custom DrawBuffer routine (B/W tiles -> grayscale screen) will need to do a single read from memory and a single shift operation, instead of two reads and two shifts. No change on writes to memory.

My objectives as of right now are to:
> -write and 8x8 B&W sprite tilemap engine
I'm too lazy to check the documentation of Genlib to be _sure_ whether there's such an engine in Genlib, but ExtGraph contains 8x8 and 16x16 tilemap engines for both B/W and grayscale.
> -get 8 way smooth scrolling working
Tilemap engines make this transparent.
> -implement some array indexed animation for sprites
Yes.

> What I need is a black and white 8x8 sprite clipping routine,
Er, I wouldn't do that
I think clipped sprites are too slow for your purposes, as show ExtGraph demo12 and demo17 - and the speed ratio would be even higher if switching to 8x8 sprites.
Tilemap engines have a two-stepped architecture:
* RefreshBuffer (in ExtGraph terminology) use buffers larger than the screen, where they draw raw tiles without any shifting. Routines of the RefreshBuffer kind are essentially Tile8x8/16x16 routines wrapped in a loop;
* DrawBuffer (in ExtGraph terminology) reads the large buffers, and writes the properly shifted data to a screen-sized buffer.

> and a 32x32 masked grayscale routine.
Both ExtGraph (GrayClipSprite32_(S)MASK_R) and Genlib (put_masked_big_sprite) have this, the former being a specialized routine tailored for 32xn sprites and the latter being a generic routine that can draw sprites whose width is a multiple of 16, up to 240x128.

> Yes, I do hope this will generate some life and excitement around here. Programming is quite a neat thing isn't it.
Indeed