HGFX Intro, part 3 In the third and fourth parts of the HGFX introduction, let's skip the theory of the planar, we will talk about a few nifty details of this graphic expansion. 1. Nonlinear vs. linear memory layout. The Spectrum's very special way of videoram format is pretty noticeable when a ZX-screen is slowly loaded from a tape. The lines are placed in thirds of the screen, in the order of lines 0, 8, 16, ... to 56, followed by lines 1, 9, ... to 57, etc. ZX Spectrum bitmap structure 1st line ... byte 0 to 31 2nd line ... byte 256 to 287 ... 8th line ... byte 32 to 63 9th line ... byte 288 to 319 ... To make HGFX easy to use with almost every existing one ZX Spectrum program, this original non-linear arrangement of a videoram is set by default in the HGFX. In case we don't need a ZX-screen compatibility, let's try a linear memory format. It will enable fast time-saving operations such as copying parts of the screen and DMA transfers (shifts of a screen by one pixel, for example). HGFX Linear video memory 1st line ... byte 0 to 31 2nd line ... byte 32 to 63 3rd line ... byte 64 to 95 ... 2. Transparency The original ZX-screen with attributes can be preserved simultaneously with the HGFX turned on. If we enable the transparency, the ZX-screen will be displayed under the HGFX layer and will only be visible at places where the index color no.0 is set in the HGFX graphics. With the HGFX videoram set by default, from 16384, we draw simultaneously to the ZX videoram and to the HGFX video memory. HGFX diplay buffers have a priority though. If the transparency is not turned on, the HGFX will cover the ZX attributed graphics with its colour. Keeping the ZX-screen in parallel with the HGFX will show its magic when patching programs and games for the HGFX. Not all graphic elements, however, are needed to be converted to the HGFX (e.g. a game background) and it could be also very laborious. 3. Offsets Offsets are certainly remembered by those who programmed in the Beta Basic and used the system variables XOS and YOS. The rest of us are let's remember the simple definition: an offset sets a drawing position on the screen. The X and Y coordinates in pixels are in the HGFX system given as follows: --------------------------------------------------------------- | X,Y: 0,0 X,Y: 255,0 | | adr. 16384 adr. 16415 | | | | 256 pixels, 32 bytes per line | | | | | | | | 192 lines | | 192*32 = 6144 bytes | | | | | | | | | | | | | | X,Y: 0,191 X,Y: 255,191| | adr. 22496 adr. 22527 | --------------------------------------------------------------- Example 1: We set OffsetX=0, OffsetY=16 and print a character to the videoram. We store the first byte at address 16384, the next byte at 16416 (16384+32), etc. A character will appear on the screen as printed using basic's PRINT AT 2.0; Example 2: Printing letters 6 pixels wide. We set offsets to 0,0. We print classically (as in the first example) at address 16384. Coordinates for the second letter we will also set by an offset. Set OffsetX to 6, and print... again to the address 16384 (?! yes, a method to transform coordinates into bytes and bits of the exact location in memory does really NOT apply, even character bit templates don't need to be shifted!). For the third character, we set OffsetX to 12 and print again to 16384. This is how we proceed this with all characters. You can certainly imagine other examples yourself. Time savings of programs are tremendous when using offsets. Whether it's a job of proportional fonts (or with a non-standard width of 4 to 7 pixels) or some motion graphics. Until the next chapter about HGFX, let's try to calculate how much effort these offsets will save us when putting sprites to positions other than multiples of eight. In conclusion, searching readers can be hinted to some expert lessons: offsets can surprise us, eg they can hold negative numbers and maybe they will help us with HiRes graphics.