guide to GEM coding with AHCC

[peterlane]

I put together some notes to remind myself how my GEM programs are working. Most of this comes from CManShip, and things I learnt working through a lot of my own misunderstandings. I've also been helped along at times by members of this forum. These notes try to put this information together in one place, and may be useful to anyone else learning how to write GEM programs using AHCC. So far, I have only covered how to work with windows.

The notes are in the form of a pdf document: http://peterlane.info/downloads/guide.pdf. I work through a series of progressively more complex versions of a sample program - the source code for these versions: http://peterlane.info/downloads/guide-source.zip The examples have been tested on a Firebee and an Atari ST.

Let me know if anything's unclear, or could be improved.

Enjoy!

[Cyprian]

Great work!

[vido]

This is realy great and important work!
Thank you!

[wongck]

cool.. looking forward to more proggies

[gstoll]

Let me know if anything's unclear, or could be improved.

In open_vwork you must set work_in[0] to 2 + Getret(). ("work_in[0] = 2 + Getrez();")

https://github.com/petercrlane/sokoban/ ... /windows.c : event_loop
It is not necessary to make a #if for some messages. For example WM_SHADED is also pressend in MagiC or WINX.

[peterlane]

In open_vwork you must set work_in[2] to 2 + Getret(). ("work_in[10] = 2 + Getrez();")

Thanks for the suggestion. It prompted me to look again at the Atari Compendium, and I notice it says for work_in[0]: "For screen devices you should normally use the value Getrez() + 2, however, a value of 1 is acceptable if not using any loaded fonts"

I take it you mean work_in[0] = 2 + Getrez (); ?

(I admit, I took the code for open_vwork directly from CManShip and haven't questioned it.)

https://github.com/petercrlane/sokoban/ ... /windows.c : event_loop
It is not necessary to make a #if for some messages. For example WM_SHADED is also pressend in MagiC or WINX.

I put the #if in as I have previously had problems compiling code with TOS 4 features on my STe. I'll take another look at it though.

[gstoll]

I take it you mean work_in[0] = 2 + Getrez (); ?

Yes, I was to fast with the submit buton.

I put the #if in as I have previously had problems compiling code with TOS 4 features on my STe.

Maybe you use floating point. The ST version from AHCC don't support them. With PureC you can use it.

[Smonson]

This is cool. Thanks for posting this guide - as a GEM beginner, this can benefit me greatly!

[peterlane]

Maybe you use floating point. The ST version from AHCC don't support them. With PureC you can use it.

Yes, that was a problem at first, as CManShip uses float in calculating the slider position. That was one of the things I had to rewrite to get code compiling on an STe with AHCC.

[Mikefulton]

Thanks for the suggestion. It prompted me to look again at the Atari Compendium, and I notice it says for work_in[0]: "For screen devices you should normally use the value Getrez() + 2, however, a value of 1 is acceptable if not using any loaded fonts"

I take it you mean work_in[0] = 2 + Getrez (); ?

(I admit, I took the code for open_vwork directly from CManShip and haven't questioned it.)

"is acceptable" in this case means "won't bite you in the ass most of the time"

But then, once in awhile, it does. The problem is, it's not just fonts. It can also be an issue with loadable screen drivers. It's a rare problem to be sure, but why take a short cut on something so simple and basic?

[peterlane]

Thanks for all the comments and feedback I have received about my guide. This encouraged me to complete the 'second half', and write out what I know about menus, dialogs, events and the scrap library. The Guide has now been extended and updated, and includes more example programs.

In summary, a sample program is constructed step by step, considering each aspect of AES window handling in turn. Later versions feature multiple windows with sliders, menus, and some built-in dialogs. Other example programs include a binary clock to illustrate timer events, a simple sketch program to illustrate mouse events, and a temperature conversion program to illustrate user-defined dialogs. All examples should compile and run on any Atari computer, from the Atari ST to clones such as the Firebee.

Just to emphasise, this is not intended as a complete description of GEM programming. My aim is to help smooth the transition to using AHCC from more comprehensive sources such as CManShip or Professional GEM, which were written for older compilers and conventions.

The guide can be read:

- online in html: http://peterlane.info/gemguide/html/index.html
- or in pdf: http://peterlane.info/downloads/gem-guide.pdf
- and should be read along with the source code: http://peterlane.info/downloads/guide-source.zip

A summary and all these links are on my web page: http://peterlane.info/firebee.html

Let me know of anything that's unclear, is wrong, or could be improved.

[vido]

This is just great Peter!
This is what I was waiting for till now. Many many thatks!!!

Still ... do you have any plans to continue whit this guide. Maybe to describe libraries, some programming advices, ...
It would be cool for someone like me to get faster into C coding on Ataris ...

Vido

[TheNameOfTheGame]

Nice job Peter! Thanks for compiling this information.

[wongck]

i hope more people will study this make more modern and contemporary programs.

[tschak909]

I'm trying to find a proper programming pattern to keep a bitmapped buffer and redraw into the window it when asked by the system, as I am writing a terminal program, and while I seem to be sort of getting it right, but not really...

-Thom

[lp]

GEM does not provide any sort of AES message when data arrives that needs processed. You end up having to use an evnt_multi() with the timer option and then polling the serial port from a timer subroutine.

As for the bitmap buffering. From my own experience, GEM doesn't normally provide rendering to off screen buffers. In this case you end up rendering stuff to the bitmap yourself and then blitting it to a window. There is NVDI, which is a VDI replacement that adds the ability to render VDI calls to off screen buffers. The only problem there is you force the end user to install NVDI if they don't already have it. These off screen calls are pretty cool, but they don't seem to work on any machine using fVDI which drives graphics cards and some clones, like the FireBee.

My VNC app handles writes to the off screen buffer itself. My Boing demo relies on NVDI. My IRC app handles it entirely different, since it only needs text rendering, it buffers the text and renders it on the fly in the window. I'm by no means an expert

[jfl]

These off screen calls are pretty cool, but they don't seem to work on any machine using fVDI which drives graphics cards and some clones, like the FireBee.

On the FireBee, NVDI runs and takes care of this. I know, it's confusing. I never could figure out how the VDI works on that machine

[lp]

On the FireBee, NVDI runs and takes care of this. I know, it's confusing. I never could figure out how the VDI works on that machine

Thanks for the clarification. I forgot you could install NVDI along side other drivers.

[bladeomega]

Nice GEM coding guide Peter. Thx

[sashapont]

Are there any sample with creating windows from rsc dialog?