gfa code optimized by compiler

[Marcer]

Hi

Im a bit curious of all these updated extras for gfa compiler etc..

my question is simple.. if you do a easy get & put of an 16*16 4bpl object in a loop with (1) vsync.

compared to clean gfa compiler 3.5 vs todays update.. how much (or even any) cpu % may I gain.. ?

ps. Now I mean the Actually commands GET & PUT.

[simonsunnyboy]

Probably nothing noticable, the commands still call LINEA which depends on TOS of its implementation. Bog slow on TOS1.0 and still slow on more modern TOSes...no, RC_COPY and BITBLT will not give much speedup. Only a custom tailored machine code implementation will do, the Blitter won't help on small blocks like this.

[Marcer]

My thought draws at amigas amos.

For exempel these Sprite compos time ago.
Is it hard to ute such thing.

And make an raster in gfa is a issue.
In amos u just write raster..

Lots of sdpoke and peek commands in gfa but still have trouble to have an stable raster on an stf..

My major quest.. Put command.. Could in my point of view, be optimized 209% by compiler..
Even The color issue. Assembler is cool. But time killing.
Basic should be a speedy way to promot ideas. With maximal limits..

We are not alone singel teenagers anymore and time limited.

Or my excuse crap coder _)

All respect to all familys for all these Who make these cool demos hehe

[lp]

The only thing you will gain from an "alternate" library is the time spent hiding/showing the mouse as that has been removed. That gain won't help at all really. PUT/GET use string management to store the image data, so just getting the address is wasting cycles, as it has to fetch the string descriptor first, then fetch the address from that. Then checks the length for zero, then more time wasted checking if the coordinates fall inside the screen dimensions etc. It is BASIC after all.