TV_Text Video Memory
I'm working on a game called Text Action:
http://forums.parallax.com/showthread.php?p=732155
Its a Text-based side-scroller.
I'm happy with it at this point, however in order for me to take it where it needs to go, I need a faster way to read the contents of the screen (or its memory I suppose) because of collisions and smooth animations with no flickering. I believe if I can directly alter the memory that pertains to what characters are on the screen, then I can get instant scrolling action with no "left-overs" that I have to print blank characters on, becuase in essence the entire screen will have been updated since the contents of the memory locations has been shifted.
This is how I'm thinking about it anyway. I also think this will lead me to much faster routines for characters with multiple frames of animation instead of 6 lines of spin to print the " * " character in the right spot.
I'm sure I'm not using the right words to describe these techniques which are usually used for graphical situations I think.
Is what I'm saying making any sense?
Does anyone know if there are "constant" memory locations for the display of on-screen characters with TV_Text?
Thanks,
Rick
http://forums.parallax.com/showthread.php?p=732155
Its a Text-based side-scroller.
I'm happy with it at this point, however in order for me to take it where it needs to go, I need a faster way to read the contents of the screen (or its memory I suppose) because of collisions and smooth animations with no flickering. I believe if I can directly alter the memory that pertains to what characters are on the screen, then I can get instant scrolling action with no "left-overs" that I have to print blank characters on, becuase in essence the entire screen will have been updated since the contents of the memory locations has been shifted.
This is how I'm thinking about it anyway. I also think this will lead me to much faster routines for characters with multiple frames of animation instead of 6 lines of spin to print the " * " character in the right spot.
I'm sure I'm not using the right words to describe these techniques which are usually used for graphical situations I think.
Is what I'm saying making any sense?
Does anyone know if there are "constant" memory locations for the display of on-screen characters with TV_Text?
Thanks,
Rick
Comments
I'm going·do some memory dumps and see what I can about the structure of this buffer.
Rick
Thanks for your input. I tried using Gear to look at the memory while I had Characters on screen but it was confusing to me and just took too long, so instead I decided to go the other way around and write to the memory and see what happens. I have posted screenshots. The reference.jpg shows what my screen looks like with no bytefill commands.
Well· its close to that. 13 x 40 = 520 so I did this - CASE1:
bytefill (text.screenAddress,2,520)
Result: as you can see from the Case1 Screenshot it only printed to half of the screen.
So I went a head and doubled it - CASE 2:
bytefill (text.screenAddress,2,1040)
Result: and it filled the entire screen with the char that represents $02 according to the character chart.
so far things are pretty good accept, I'm using 1040 Bytes to fill up a space that should only need 520 Bytes of data.
I'm figuring that its 2 byte sequences where one byte is the character and one byte is the color?
so I go ahead and do this - CASE 3:
repeat OSCounter from 0 to 1039 step 2
···· bytefill (text.screenAddress+OSCounter,$10,1)
Result: OK things look good, I'm skipping one byte per write and getting the character I expect as it matches up with the chart etc.
So I'm just trying to find out what the reason for the other byte is as well as how I can set the colors of each of these characters via the memory writing method. so I try this - CASE4:
repeat OSCounter from 0 to 1039 step 2
···· bytefill (text.screenAddress+OSCounter,$10,1)
···· bytefill (text.screenAddress+OSCounter+1,0,1)
I dont know what to make of it, I'll tell you this since I've reached my attachment limit, when I write the second byte as a "1" the screen looks like the reference image, when I write the second byte as a "2" it looks just like CASE 3, when I write the second byte as a "4" it looks like a variation of CASE 4.
Anyone know what this byte is for? Anyone know how to set the colors of the characters using these memory writing methods?
I'm already happy with this method because I can write to the last line of the screen without causing a scroll upward.
Thanks,
Rick
the screen isn't bytes, it's stored as words ( 16bits )
pppppC10cccccccc
p = Colour palette
C = Character number ( lowest bit ie AND #1 )
c = Character number AND $FE
eg, in the print routine it does this
screen[noparse][[/noparse]row * cols + col] := (color << 1 + c & 1) << 10 + $200 + c & $FE
hope this helps, if you need more help, let me know.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Great info! Thanks much, I'm going to make lots of use out of it!!
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'm not understanding the color situation... Why would they chop off· the most significant 3 bits?
I'm assuming this palette is·pertaining to the·listing (max 8 colors?) of 8 defined colors consisting of a Fore and a Background color?
Or is it some other means to derive a color.
lastly why the C and also the cccccccc?
You already have the 8 bits (cccccccc) you need so why the C?
Thanks,
Rick
If you can go through the code in the video driver, you'll see how the various bits are moved around and used to index into the ROM font tables.
My hope with understanding this is not only for the game, but for other text/ascii based programs that may have layers or moveable windows like in the late DOS days.
I'd LOVE to see a QuickBASIC style IDE running on the Prop FOR the Prop (or another Prop).
Rick
that I haven't managed to work my brain around. (Anyone else is welcome to try!)
I'm thinking that if I used Propellent and a script to catch the spin file (text) from
the Propeller's editor (a small spin file) then I could compile and send it back
to the prop's memory.
This doesn't eliminate the need for a PC running Propellent, but would be a
very cool step forward!
But I've got to resolve some serious issues with my Full Page text editor first.
(Although I might write a simpler editor just to see if I can make it work.)
OBC
Edit: Sorry if the reply hi-jacked your thread...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
OBC, whats the problem with your Full Page Text editor?
[noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange