The Sinclair QL Forum

tofro wrote:You can even display mixed text & graphics if you simply make sure you print the identical text into both screens

Tobias

True - but we don't want to have to re-write the QDOS text handling routines....

I no longer have a copy of the QDOS companion and alas there is nothing I can spot in the SMSQ Reference Manual as to what traps and/or vectors work (if any) in supervisor mode.... I seem to remember that some things work

It might be a case for implementing these text adventures, it is necessary to show the graphic screen until a key is pressed and then deal with the text...

RWAP wrote:

tofro wrote:You can even display mixed text & graphics if you simply make sure you print the identical text into both screens

Tobias

True - but we don't want to have to re-write the QDOS text handling routines....

Why not? If we consider that those games will be for black QL, then we do not need to maintain QDOS compatibility. Just store text address in a register and call print routine... Such print routine is not too difficult to write.

Let's raise bar Having possibility to write custom print routine, we could implement:
* proportional fonts
* antialiased fonts (using colors or interlaced pixels)
* different text zoom levels (from 6x7 up to 16x16)

You don't even need to write a print routine.

- Put the text on SCR0 using standard QDOS routines leaving the needed screen estate for the advanced graphics
- move away the system variables (part of screen flipping code)
- blit the text part (or, alternatively, all of SCR0) of SCR0 into SCR1
- enter graphics setup, load picture into area left free in SCR0 and SCR1
- enter graphics flip mode
- leave graphics flip mode as soon as a key is pressed
- clear graphics part of screen

Would only use routines "you'd need to have anyways".

Tobias

Tobias, I am not sure if I got it correct. Do you suggest to clear screen once user would press a key? Wouldn't that be "ugly".
I still belive that this shuffling with sys vars is not worth the effort just to make QDOS happy. Print routine is not a rocket science.

Hi,

Just an idea.

EDIT
Instead of clearing that flipping graphics frame, we may display in its place, on a user keypress, an inventory list, or a game map, a game status, a menu, ... what have you. All static non-interlaced.

Tomas

Whatever works for you. My opinion is that user experience will be decreased, but don't take it as show stopper.

omega wrote: Let's raise bar Having possibility to write custom print routine, we could implement:
* proportional fonts
* antialiased fonts (using colors or interlaced pixels)
* different text zoom levels (from 6x7 up to 16x16)

I happen to be playing with bit-mapped graphic founts at the moment : This is not for plain QDOS, though, as it uses mode 16 sprites. A single 20 pixel high fount
can take up 8-20+k even with RLE compression and all unnecessary sprite data stripped away.
Im making a buffering system, which ensures only the most used glyphs are loaded at any time,
but that could be slow work for floppy based systems.
In other words, implementing nice, anti-aliased, kerned fount capability is quite demanding of
system resources. Zoom-able founts even more so. I wouldnt be surprised if it is possible to go
some way, but I dont think it would be a trivial project.

The system Im working on is just a prover, written mainly in SBASIC, but the design could easily
be converted into a "universal" toolkit that could be used by different programs.

Hi pjw, thanks for sharing. Your environment looks very nice.

I've made a print routine for ZX Spectrum in assembly that uses Sincalir QL fonts with HDF extension (extras for QL DTP application. Maybe from Digital Precision.). I can dig the source code, routine was ~200 bytes long and speed was pretty good (=fast), QL would be similar in speed.

Agree with you that "generic" zoomable antialised routine would be overkill. For black QL we need to use "old-skool" programming methods. Assembly, memory optimization... etc. Let's take an example: HDF font file is a set of uncompressed 1-bit bitmaps. E.g. 24x24 pixel character = 3*24 = 72bytes. Number of characters in font file 26x2 (alphabet small and big) + 10 (numbers) + 10 (symbols) = 72. Table of widths = 72b. Font size = 72 * 72 + 72 = 5256 bytes. Please note that 24x24 font is very big for plain QL. It is definitely not useable in this game.

With zoom levels, I was thinking of several font files stored in the memory. Smaller fonts 8x8 character size will be small in size (e.g. 800 bytes), mid size font (12x12) will be ~ 1k , large font 2k (18x18). In total you'd need ~4k for three zoom levels. Antialiasing would double the size.

All,

I happen to have `QDOS Companion' from a friend (that 2nd book by Andy Pennell). It lists in the appendix traps that are safe calling in supervisor mode.

MT.IPCOM - keyboard control
MT.RCLK - read clock
MT.SCLC - set clock
MT.ACLCK - adjust clock
UT.LINK - link item to list
UT.UNLNK - unlink item from list
MM.ALLOC - allocate heap
MM.LNKFR - link free space
IQ.SET - set up queue
IQ.QTEST - test queue
IQ.QIN - put byte in queue
IO.QOUT - take byte from queue
IO.CSTR - string compare
RI.EXEC - do maths
RI.EXECB - do maths
MD.READ - read MD sector
MD.WRITE - write MD sector
CN.* - all conversion routines

With `QDOS' disabled the I/O Traps#2,3 may not work, but they do accept channel ID and screen# as parameter though. That must have its purpose, surely the designers had something in mind when doing this.

Easiest seems switching to `QDOS' temporarily.

--

@ Per,

Good work that with founts, what a nice system do you have?
I am also looking at Dilwyn's article on `Fun with fonts', just to get the idea how big, custom fount may be. It also shows some tricks on font resizing.

I fear that we may need to balance code and data carefully, to save on memory and disk space. `Level9' interpreter may need to be put on `QL' diet, to safe a few bytes here and there, which may result in non-portable code for standard unexpanded systems.

Tomas

omega wrote: Converted files for QL [rename TXT to ZIP]
http://files.omega.webnode.com/20000035 ... ns_zip.txt

This seems a zero byte file... could someone check please?