Forum
BritLion's Putchars - Printable Version

+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: How-To & Tutorials (https://www.boriel.com/forum/forumdisplay.php?fid=13)
+---- Thread: BritLion's Putchars (/showthread.php?tid=237)

Pages: 1 2 3


Re: BritLion's Putchars - compiuter - 06-07-2010

Thx to all for your contributions to make this routines.
I´m happy Big Grin with Britlion routine. Now is just I need at the
moment, and separated atr are a module, we can or not
aply atr to our sprites.
I´ll take a look to Lcd block routine.


Re: BritLion's Putchars - LCD - 06-07-2010

britlion Wrote:You do realise that mine should be able to do anything from 1 character to a whole screen just by changing height and width (and making sure there's enough data at the address given!) ?
No, I was confused because you called it PutChars and not PutBlock. Your routine is working char-wise and has no attribute yet (but that is okay in most games), mine is working progressive. Anyway, yours is faster, so if you will add attribute, I would like to use it. I ask you to swap the place of height and width values:
Code:
SUB putChars(x as uByte,y as uByte,width as uByte,height as uByte,dataAddress as uInteger)

britlion Wrote:I'll see about tweaking it to accept attributes....
Thanks, this would be welcome
britlion Wrote:Do you need FLASH? It might be clever to assume you won't want to set a flashing attribute and have it assume that an attribute >128 (or negative) means that the attributes are in the data...
No, I do not need Flash. But I just noticed that while 8-Byte Char format is very good for compression (only full columns are better), using a 9-byte format is very bad for compression ratio. So what you could do, is to precalculate the adress after bitmap/char data, and use it as source for attribute data. Will this be possible?


Re: BritLion's Putchars - britlion - 06-07-2010

LCD Wrote:
britlion Wrote:You do realise that mine should be able to do anything from 1 character to a whole screen just by changing height and width (and making sure there's enough data at the address given!) ?
No, I was confused because you called it PutChars and not PutBlock. Your routine is working char-wise and has no attribute yet (but that is okay in most games), mine is working progressive. Anyway, yours is faster, so if you will add attribute, I would like to use it. I ask you to swap the place of height and width values:

Sorry! Perhaps I should have made it clearer. I did show speed test data for block sizes from 1x1 to 8x8 though! I called it putChars because it can put more than one!

LCD Wrote:
Code:
SUB putChars(x as uByte,y as uByte,width as uByte,height as uByte,dataAddress as uInteger)

If you change the first line to read that way, I'm quite certain it would work exactly as you wanted :-) It would call the 3rd variable width, and the fourth one height instead; but they get used by name in the routine.
I'm definitely sticking to data being used in columns before rows, though. It's just faster that way. Ironically, it's faster to paint attributes in rows and then columns.

The reason for this is you can head down a column of screen data with inc H to go down (unless it's across a 1/3 screen boundary, which gets a little awkward). Inc HL moves to the right for attributes. You have to add 32 to go down.

This might lead to data being in a format that's more convenient for the computer and less convenient for the human reading it; but that's the way to get speed!

LCD Wrote:So what you could do, is to precalculate the adress after bitmap/char data, and use it as source for attribute data. Will this be possible?

I'll see about adding a routine then, that puts attributes on top of the screen data, and either takes one attribute for all of the squares, or assumes it's immediately after the screen data. And actually, since we just had a pointer go through the screen data if we follow on immediately, then we shouldn't need to calculate the attributes address at all - we're already pointing at it.


Re: BritLion's Putchars - LCD - 06-07-2010

britlion Wrote:Sorry! Perhaps I should have made it clearer. I did show speed test data for block sizes from 1x1 to 8x8 though! I called it putChars because it can put more than one!
I did oversee the "s" in PutChars, so my fault.

LCD Wrote:
Code:
SUB putChars(x as uByte,y as uByte,width as uByte,height as uByte,dataAddress as uInteger)
If you change the first line to read that way, I'm quite certain it would work exactly as you wanted :-) It would call the 3rd variable width, and the fourth one height instead; but they get used by name in the routine.
I'm definitely sticking to data being used in columns before rows, though. It's just faster that way. Ironically, it's faster to paint attributes in rows and then columns.
I know this (Yes, I'm able to change the call order myself), but we want some kind of standard if Boriel will put the routine into includes library, and in all Basic variants I know, width comes before height. I think, standartized calls are not a bad idea.You can still use the complete columns data format, I support this as it gives best compression of data, if the user wants to compress them. And if it is faster, I see no reason why change this. The BorIDE graphics editor will support this format.

britlion Wrote:This might lead to data being in a format that's more convenient for the computer and less convenient for the human reading it; but that's the way to get speed!
Thats why I definitivly want to add a Graphics editor to BorIDE, which will produce the correct data format for your routine.
britlion Wrote:I'll see about adding a routine then, that puts attributes on top of the screen data, and either takes one attribute for all of the squares, or assumes it's immediately after the screen data. And actually, since we just had a pointer go through the screen data if we follow on immediately, then we shouldn't need to calculate the attributes address at all - we're already pointing at it.
Great, that was what I wanted. I was meaning not the calculation of attribute address on screen, but the attributes source in the memory, after the bitmap data.


Re: BritLion's Putchars - britlion - 06-08-2010

LCD Wrote:in all Basic variants I know, width comes before height. I think, standartized calls are not a bad idea.

That I did not know. I almost built it with co-ordinates in (y,x) format, to match the format for the PRINT statement; but then followed your template for putchar, since I was building it for ya! Smile Easily swapped. When I do an update, I'll do that.


Re: BritLion's Putchars - boriel - 06-08-2010

Having a standard is almost mandatory if you want your libraries easier to learn and adopt. I suggest you to use x, y (col, row) standard. PRINT uses y, x for Sinclair BASIC compatibility.
The "standard" (ok, there isn't any), is (x, y) for graphics, and (y, x) for text. Since your routines are graphic oriented, it's better to use (x, y) I think.


Re: BritLion's Putchars - LCD - 06-08-2010

More mysterious is why PLOT coordinates in Sinclair BASIC don't start at the top like on every other computer, maybe there can be a flag added for compiler to make Plot the right way round, starting from top. Using a function for calculation correction (191-y) does not feel right.
But there are much worser things like the control chars for PRINT position on C64. On the other hand I loved the solution how sinclair solved strings (a$(7 TO)), as it ls much better than left$, right$ or mid$ used on other micros.


Re: BritLion's Putchars - na_th_an - 06-08-2010

boriel Wrote:Having a standard is almost mandatory if you want your libraries easier to learn and adopt. I suggest you to use x, y (col, row) standard. PRINT uses y, x for Sinclair BASIC compatibility.
The "standard" (ok, there isn't any), is (x, y) for graphics, and (y, x) for text. Since your routines are graphic oriented, it's better to use (x, y) I think.

The thing is, in the Microsoft dialect, the one which QB, Visual Basic, freeBASIC and mostly ZX Basic follow also use (y, x) for character positioning and (x, y) for graphics positioning. Why is it? I've always found it strange.

I mean, the standard "LOCATE y, x: PRINT ..." works exactly like Sinclair's "PRINT AT y, x; ...". In the MS Basic dialect, the SCREEN function (somewhat equivalent to Sinclair BASIC's SCREEN$, but returning an integer value instead of a string) also takes (y, x) rather than (x, y). So the reversed order for text positioning is not the Sinclair BASIC interpreter designers' fault. It's common practice in all BASIC dialects.

Maybe this is reminiscent of the old teletype days. Maybe LOCATE was translated "on the fly" to control chars, so first Y, then X was more convenient. When BASIC was extended with graphical functions, maybe they considered it better to follow the cartesian order most used in maths by most scientists, that's (x, y).

Who knows? Big Grin


Re: BritLion's Putchars - compiuter - 06-09-2010

I modified putchat routine (look above) as Britlion suggest.
Is in that mode quickly than the other?
Regards.


Re: BritLion's Putchars - britlion - 06-10-2010

No, just a more common format for it; people seem to expect x values (and width) before y values (and height) for graphics routines.

It won't change the speed of the routine at all - just how it's accessed.


Re: BritLion's Putchars - britlion - 06-16-2010

I added a paint subroutine (at the top of this thread), so you can paint a block in a single color, and it works the same as the putchars one. I also sped up the putChars routine a little bit.

In fact, it can't be too hard to do something like:

Code:
SUB putCharsOneColour (x as uByte,y as uByte, width as uByte, height as uByte, dataAddress as uInteger, attribute as uByte)
paint (x,y,width,height,attribute)
putChars(x,y,width,height,dataAddress)
end SUB

(Note that I just wrote the above here, and it isn't tested - but you should get the idea.

The biggest WARNING with these routines is that they are not error trapped at all. They are written for speed, and make assumptions that they won't be told to write off the bottom or right hand side of the screen memory.


Re: BritLion's Putchars - LCD - 06-16-2010

Excellent, thank you, Britlion.
How about changing the Paint SUB to handle Attributes from a given Address? If Attribute<256, a fixed attribute is used, otherwise the attributes are streamed from the selected address defined by the variable Attribute?
Or a dedicated subroutine PaintAttrs()?
You routine is extremly fast now.


Re: BritLion's Putchars - britlion - 06-17-2010

Definitely working on that.

I've realised that there's a tradeoff between speed and flexibility - a routine that could do it all could be written, but then it would spend a lot of time testing to see which bits of code need to be run, and graphics (and sound, I suppose) are the parts of programs that are most speed critical.

As a result, I think I'll end up with three subroutines - put down blocks of data, paint in one colour, paint data into the colour area.

If you find those aren't fast enough, I suppose it's possible to combine two of them to put down pixel and colour data - faster than two successive calls.

Even two calls should be fairly fast, though.

Suffice to say: Working on the paintAttr one.


Re: BritLion's Putchars - LCD - 06-17-2010

Excellent! Thanks you for working on that. I would say: Flexibility over speed, but if you could also write a fast Bitmap+Attr combined routine too, I would be even more happy Big Grin.


Re: BritLion's Putchars - britlion - 06-17-2010

Added a paintData sub for you. It's really quite similar to paint - but has to work a bit harder.