FAQ  •  Register  •  Login

BritLion's Putchars

<<

compiuter

Posts: 51

Joined: Mon May 10, 2010 10:47 pm

Post Mon Jun 07, 2010 9:05 am

Re: BritLion's Putchars

Thx to all for your contributions to make this routines.
I´m happy :D 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.
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Mon Jun 07, 2010 11:09 am

Re: BritLion's Putchars

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?
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Mon Jun 07, 2010 5:05 pm

Re: BritLion's Putchars

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.
Last edited by britlion on Tue Jun 08, 2010 1:36 am, edited 1 time in total.
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Mon Jun 07, 2010 11:45 pm

Re: BritLion's Putchars

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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Tue Jun 08, 2010 1:40 am

Re: BritLion's Putchars

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! :) Easily swapped. When I do an update, I'll do that.
<<

boriel

Site Admin

Posts: 1462

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Tue Jun 08, 2010 7:12 am

Re: BritLion's Putchars

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.
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Tue Jun 08, 2010 9:03 am

Re: BritLion's Putchars

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.
Last edited by LCD on Tue Jun 08, 2010 11:25 am, edited 1 time in total.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

na_th_an

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Tue Jun 08, 2010 10:05 am

Re: BritLion's Putchars

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? :D
<<

compiuter

Posts: 51

Joined: Mon May 10, 2010 10:47 pm

Post Wed Jun 09, 2010 11:17 pm

Re: BritLion's Putchars

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

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Thu Jun 10, 2010 12:35 am

Re: BritLion's Putchars

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.
<<

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Wed Jun 16, 2010 2:17 pm

Re: BritLion's Putchars

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.
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Wed Jun 16, 2010 11:24 pm

Re: BritLion's Putchars

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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Thu Jun 17, 2010 5:43 am

Re: BritLion's Putchars

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.
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Thu Jun 17, 2010 10:11 am

Re: BritLion's Putchars

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 :D.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

britlion

Posts: 764

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Thu Jun 17, 2010 3:19 pm

Re: BritLion's Putchars

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

Return to How-To & Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.

phpBB SEO