showing images in GEM

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

showing images in GEM

Postby peterlane » Tue Apr 19, 2016 11:45 pm

I'm looking for help with some examples or pointers to explanations on how to draw images in GEM.

I'm writing a GEM program to display chess games, using C on the Firebee, and have most of the window content displaying fine. I can put up text, coloured rectangles etc using VDI calls. What I want to do now is display some images of chess pieces in the window.

I've found two possible ways of doing this. (I'm referring so far mainly to Peel's book 'The Concise Atari ST 68000 Programmer's Reference Guide' and tos.atari.org.)

One is to use vro_cpyfm to copy directly to the screen memory. This refers to two MFDB blocks. If this is a way to go, how do we find the screen address for the destination? I assume I would need to first AND a mask into the window, and then OR in my graphic.

The second seems to be to put an image in BITBLT format in the RSC file, and use OBJC_DRAW to place it on the screen. The BITBLT table seems to refer to both the mask and image.

In both cases I'm wondering how the screen is represented for 8- 16- or 32-bit displays. Does the screen generalise in the logical way from how the ST does low-res? i.e.: in a 16-bit display
pixels 1 to 16 in the top left of the screen are bits 15 to 0 of words 1-16, word 17 starting pixels 17 to 32, etc.

Perhaps there's a third way?
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: showing images in GEM

Postby mfro » Wed Apr 20, 2016 5:02 am

peterlane wrote:...
One is to use vro_cpyfm to copy directly to the screen memory. This refers to two MFDB blocks. If this is a way to go,

it is.

peterlane wrote: how do we find the screen address for the destination?

You don't need it. Just set the destination address in the target MFDB to NULL. The VDI will replace the correct screen address then. If the target is the screen, you don't need to initialise anything in the (target) MFDB at all: just set the address to NULL and the VDI will know what to do.

peterlane wrote: I assume I would need to first AND a mask into the window, and then OR in my graphic.

The second seems to be to put an image in BITBLT format in the RSC file, and use OBJC_DRAW to place it on the screen. The BITBLT table seems to refer to both the mask and image.

You can do this as well. At least in older VDI versions, the AES can handle single plane BITBLKs only, however. Newer versions (Falcon) support CICON objects that can have multiple planes.

peterlane wrote:In both cases I'm wondering how the screen is represented for 8- 16- or 32-bit displays. Does the screen generalise in the logical way from how the ST does low-res? i.e.: in a 16-bit display
pixels 1 to 16 in the top left of the screen are bits 15 to 0 of words 1-16, word 17 starting pixels 17 to 32, etc.

It doesn't, generally, but you don't need to bother with it as well. You shouldn't make any assumptions about the screen organization at all. This is the duty of the VDI screen drivers. Define your images in VDI standard format (which is just linear planes, _not_ the fancy ST interleaved planes organisation). Then do a vr_trnfm() for each of your images, the result is something you can directly blit to the screen (using vro_cpyfm()), regardless of its physical organisation.

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: showing images in GEM

Postby peterlane » Wed Apr 20, 2016 9:34 am

Many thanks for the guidance mfro. You have made the process appear simpler than I was fearing! I should be able to code something up now.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
Cyprian
Atari God
Atari God
Posts: 1405
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: showing images in GEM

Postby Cyprian » Wed Apr 20, 2016 9:58 pm

mfro wrote:It doesn't, generally, but you don't need to bother with it as well. You shouldn't make any assumptions about the screen organization at all. This is the duty of the VDI screen drivers. Define your images in VDI standard format (which is just linear planes, _not_ the fancy ST interleaved planes organisation). Then do a vr_trnfm() for each of your images, the result is something you can directly blit to the screen (using vro_cpyfm()), regardless of its physical organisation.

are you sure that you can copy 1-8 bitplane screen data to chunky 16/24/32bit screen with VDI?
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: showing images in GEM

Postby mfro » Thu Apr 21, 2016 5:11 am

Cyprian wrote:
mfro wrote:It doesn't, generally, but you don't need to bother with it as well. You shouldn't make any assumptions about the screen organization at all. This is the duty of the VDI screen drivers. Define your images in VDI standard format (which is just linear planes, _not_ the fancy ST interleaved planes organisation). Then do a vr_trnfm() for each of your images, the result is something you can directly blit to the screen (using vro_cpyfm()), regardless of its physical organisation.

are you sure that you can copy 1-8 bitplane screen data to chunky 16/24/32bit screen with VDI?


That's not what I said, because you can't (er, you can, but it doesn't look nice ;) ). You can use vr_trnfm() to convert linear bitplanes (VDI standard format in memory) to whatever bitplane organization the currently active screen drivers use. Then, in a second step, you would transfer these to the screen using vro_cpyfm().
That's VDI standard behaviour all drivers must implement.


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 2 guests