Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Printing an updated screenful in one go
#1
Hello everyone,

I'm loving the discovery of zxbc and having a great time working on the game I always wanted to make! Thanks Boriel!

I've written code that randomly generates a map (well, its floor), which is stored in an array. To keep the size in memory down, I store the rows as bits and have written a routine to make reading this back in the game code nice and simple. I can easily determine if any given coordinate is floor or not. I'm really happy with this. Bit operators are brilliant!

I'm now at the stage where I need to start putting my graphics on the screen. Using the map floor as a reference, I intend to display the walls and floor of the dungeon using 3x3 character blocks, with each successive row overprinting the bottom of the row before it. This way I should be able to display a 9 x 9 view with a pseudo 3D view and the player in the middle.

Using the floor as the starting point, what's I'm trying to work out right now is the best way to could assemble the whole view of this and print it to the screen in one go so the player doesn't see it redraw tile by tile. As the game is turn based, I don't mind if preparing and moving the updated screen isn't instant.

I've thought of two methods:
  1. Dynamically create a string and colour it in using control codes, to set everything up that is then printed in one go.
  2. Scroll the screen, a tile in whatever direction needed and then fill in the space.
I think the first would give the best results, if it's possible, and the second should be achievable with the scroll routines I've been reading about.

My questions are whether there are any other approaches I could take and if anyone kindly has any advice on manipulating and embedding control chars into strings. I've read some other posts but these don't go as far as constructing a string.

Thanks,


Steve

I'm probably going to keep throwing my thoughts into this thread (sorry - I do this on car forums when I'm fixing my old car!).

If I'm treating the string as a fake screen, could I use chr$ 22 as if it were AT? Does the string reorder itself if I do something like

LET s$ = s$ + chr$(22, y, x, 17, 1, 65)

And replace the 1 and the 65 with values from an array that stores the colour swatch and characters?

I'm then curious how the string is stored. Is it the logical concatenation of all of the statements like the above that I'll loop through 81 times or does it reorder itself if the AT equivalents were presented in a non-linear fashion?
Reply
#2
I've been experimenting this evening.

Curiously, making a big string full of control codes crashed when it got to so many lines. PRINTing it was also quite slow.

So, I've had a look at putchars() and paint() - thanks Britlion. I set up a pair of arrays and loop through this, putting a character to the screen, then its attribute, one at a time. This is much improved in terms of performance.

I think I'm starting to get somewhere. The array is probably a bit wasteful of memory, so I'm thinking I could construct the starting point to the screen, using putChars() and paint(), scroll it and fill in the gaps with putchars() and paint().

Sorry for rambling publicly!

Steve
Reply
#3
(01-12-2021, 09:43 PM)worcestersource Wrote: I've been experimenting this evening.

Curiously, making a big string full of control codes crashed when it got to so many lines. PRINTing it was also quite slow.

So, I've had a look at putchars() and paint() - thanks Britlion. I set up a pair of arrays and loop through this, putting a character to the screen, then its attribute, one at a time. This is much improved in terms of performance.

I think I'm starting to get somewhere. The array is probably a bit wasteful of memory, so I'm thinking I could construct the starting point to the screen, using putChars() and paint(), scroll it and fill in the gaps with putchars() and paint().

Sorry for rambling publicly!

Steve

Sorry, I've been busy fixing another bug.
What version are you using?

I've recently fixed some bugs in PRINT routine control codes in version 1.14.0
If you're not up to date, please download it.
Reply
#4
(01-14-2021, 09:00 PM)boriel Wrote:
(01-12-2021, 09:43 PM)worcestersource Wrote: I've been experimenting this evening.

Curiously, making a big string full of control codes crashed when it got to so many lines. PRINTing it was also quite slow.

So, I've had a look at putchars() and paint() - thanks Britlion. I set up a pair of arrays and loop through this, putting a character to the screen, then its attribute, one at a time. This is much improved in terms of performance.

I think I'm starting to get somewhere. The array is probably a bit wasteful of memory, so I'm thinking I could construct the starting point to the screen, using putChars() and paint(), scroll it and fill in the gaps with putchars() and paint().

Sorry for rambling publicly!

Steve

Sorry, but I didn't understand what you're trying to achieve.
Also, yes, printing an entire screen is slow, use putchar. PRINT is a very generic routine (hence slow, because it has many features to emulate to be compatible with that of the Sinclair BASIC). Putchar just puts a char at a given coordinate. That's why it's faster. For example:
Code:
PRINT BOLD 1; "HELLO"
prints in BOLD letters (useful for score points, etc to make ROM fonts fancier without wasting memory); ITALIC 1 uses italic.

Not sure what you mean with arrays as a waste of memory: arrays take the amount of memory needed to store their information
Perhaps you mean to encode (i.e. compress) the information needed or use a different data structure? IMHO if you're using bits you're already compressing "columns" in bits so you're gaining x8 in size.

There are scroll routines (pixel by pixel and cell by cell).
Reply
#5
Not to worry. I was totally rambling there!

Yes, I'm storing the floor of the map in an array and compressing the horizontal tiles by using bits. I'm pretty happy with it as it'll generate lovely random maps that increase in size as the levels go by.

As for displaying the screen in one go, I decided to set up another array that takes the floor and works out what wall tiles are needed around it. The array is then drawn by another routine, all in one go with a bit of top-down perspective on it. Its speed is rather acceptable at this stage of development, although I could probably do with shrinking my code a bit.

So all going well so far. Thank you again for making zxbasic!
Reply
#6
(02-01-2021, 06:23 PM)worcestersource Wrote: Not to worry. I was totally rambling there!

Yes, I'm storing the floor of the map in an array and compressing the horizontal tiles by using bits. I'm pretty happy with it as it'll generate lovely random maps that increase in size as the levels go by.

As for displaying the screen in one go, I decided to set up another array that takes the floor and works out what wall tiles are needed around it. The array is then drawn by another routine, all in one go with a bit of top-down perspective on it. Its speed is rather acceptable at this stage of development, although I could probably do with shrinking my code a bit.

So all going well so far. Thank you again for making zxbasic!

Oh, that sounds pretty interesting!! Exclamation Heart

Please, show your program when it's ready!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)