My game projects in C/C++ and GameSmith

[clebin]

After a 1-year hiatus which started with the birth of my daughter, I'm getting back into Amiga programming again.

I have a newbie question:

What's the best way to take over the Amiga keyboard in C? In GameSmith's examples, they have this nasty looking code:

// BAD PRACTICE ALERT! ptr to hardware keyboard reg
unsigned char *keybrd=(unsigned char *)0xbfec01;
unsigned char key;
.
.
.
key = *keybrd;

// escape key pressed
if( key == 0x75 ) return(1);

It appears that some key-strokes are still sent to the Shell when the game runs, which is not ideal.

So what's the correct way?

[Samurai_Crow]

One way is to open a RAW: device and get the key presses from there.

[demolition]

C++ is probably optimistic for the Amiga although it would be very nice to have a decent C++ compiler. Many people seem to think that C++ is inferior to C performance-wise however I disagree. It offers some convenient features but if used correctly it will create as efficient code as well-written C but should be easier to maintain and avoid bugs in your code. One feature I particularly enjoy with C++ apart from OOP are vectors which are a convenient and very efficient way of creating dynamic arrays without having to worry about memory leaks since all memory are automatically deallocated when it goes out of scope.

There is also the Hisoft C++ compiler for Amiga however I don't know how good it is. I have tried SAS/C and it does not do C++ out of the box. Rather use a decent ANSI C compiler though than a bad C++ one.

Originally Posted by clebin

What's the best way to take over the Amiga keyboard in C? In GameSmith's examples, they have this nasty looking code:
It appears that some key-strokes are still sent to the Shell when the game runs, which is not ideal.

That method will read the kb register directly so it works in parallel with the system keyboard handler so all keystrokes will still be passed through to the system. Reading the register directly is efficient, but since you want to keep it system-friendly, one should use the Amiga API.
I think this documentation should cover it:
http://amigadev.elowar.com/read/ADCD.../node00FE.html

Edit: How about just using getchar()? System keys like keyboard shortcuts will be filtered and not received by your program but if you want full access, you probably need to to bang the hardware directly.

[clebin]

Originally Posted by demolition

C++ is probably optimistic for the Amiga although it would be very nice to have a decent C++ compiler. Many people seem to think that C++ is inferior to C performance-wise however I disagree. It offers some convenient features but if used correctly it will create as efficient code as well-written C but should be easier to maintain and avoid bugs in your code. One feature I particularly enjoy with C++ apart from OOP are vectors which are a convenient and very efficient way of creating dynamic arrays without having to worry about memory leaks since all memory are automatically deallocated when it goes out of scope.

There is also the Hisoft C++ compiler for Amiga however I don't know how good it is. I have tried SAS/C and it does not do C++ out of the box. Rather use a decent ANSI C compiler though than a bad C++ one.

What about StormC? I think I can plug that into Cubic IDE, although I'm going to persevere with straight C for the time being.

Vectors would be nice to have though. I'm working on a smaller game to get me going again and because it's a fixed play-area, I've got away without any dynamic allocation at all. It's sort a sort of Tetris-y/Columns type game I guess (but different) and to drop tiles in place I'm just doing a memcpy() to "playarea[row][col].bob" when something changes. I don't know if this is necessarily the right idea, but it works.

That method will read the kb register directly so it works in parallel with the system keyboard handler so all keystrokes will still be passed through to the system. Reading the register directly is efficient, but since you want to keep it system-friendly, one should use the Amiga API.
I think this documentation should cover it:
http://amigadev.elowar.com/read/ADCD.../node00FE.html

Edit: How about just using getchar()? System keys like keyboard shortcuts will be filtered and not received by your program but if you want full access, you probably need to to bang the hardware directly.

I'll give both options a go tonight - thanks! I've bookmarked the elowar's site. I've known about the ROM Kernel Reference Manuals forever but never thought to check them! I think they'll come in very useful.

[demolition]

Originally Posted by clebin

Vectors would be nice to have though. I'm working on a smaller game to get me going again and because it's a fixed play-area, I've got away without any dynamic allocation at all.

Even without the need for dynamic memory allocation, vectors is still a nice way to ensure that all memory are freed properly no matter how the program terminates. When using malloc() or similar allocation methods, this may not always be the case unless Amiga OS has some kind of cleanup method from a crashed process? Perhaps this is not too relevant on Amiga since a program crash will normally just show the reboot/suspend requester and in suspend mode, the memory will never be freed. My experience with Amiga programming is quite limited and I may be spoiled by modern compilers and OSs.

[Samurai_Crow]

Storm C versions prior to 4 are too buggy. Storm C 4 is just GCC. If your 2d array is global or static local the compiler will deallocate it for you at the end so no worries.

[Thorham]

Originally Posted by clebin

What's the best way to take over the Amiga keyboard in C?

Another way is to use IDCMP messages from a window. In a full screen game you'd open a screen, open an invisible window the size of the screen, and use a wait message loop to get the IDCMP messages. You can also get mouse input etc like that.

Has one big drawback: You'll need multi threading.

[clebin]

Originally Posted by Thorham

Another way is to use IDCMP messages from a window. In a full screen game you'd open a screen, open an invisible window the size of the screen, and use a wait message loop to get the IDCMP messages. You can also get mouse input etc like that.

Has one big drawback: You'll need multi threading.

Thanks Thorham. I've manged to use keyboard.device to read keypresses now. More particularly I'm reading the keyboard with KBD_READMATRIX and getting the status of individual keys from that. This works really well although I'm still getting stray keypresses. I assume it's because they're being buffered and the backlog builds up during play.

I think I will need to open some kind of invisible window to "soak them up". Samurai_Crow mentioned a RAW: device, which I read is a variation of the console which has unbuffered keypresses so I'm hoping that will work. EDIT: I just found some code in the RKM that might help - "Using the Console Device Without a Window".

In other news, I used a RastPort for the first time to write a make-shift scoreboard. That one turned out to be dead easy. At times learning this stuff has been like wading through treacle, so It's great when that happens!

[clebin]

Time for a screenshot.

The game is called Landfill. It's a little like Tetris or Columns but also different from either and unique as far as I know, but more on that later...

The gameplay is done so it's all polishing up now. I'm very happy with it. It's the first game I've written that I find myself sitting down with to try and beat my high score, so that's got to be a good sign.

What do people think of the background on the left? People I've shown it to seem to like it but would something more stylised or cartoony work better? I've just seen Lumberjack on the Amiga and I feel that's the level of presentation I need to aim for.

[clebin]

The lack of response probably confirms what I knew deep down - the presentation isn't good enough right now.

I need to create a new background that properly integrates the playarea, scoreboard, etc. Possibly I'll turn it into a two-player game. The reason the play-area is so basic is that I'm drawing it with the rastport so I can have different size playareas for different game modes, but I might need to lose that feature. I like the blocks/tiles but the rest needs to go up a level or two.

It's funny that after setting Lumberjack as a benchmark, I read some guy describe this unreleased game as mediocre shovelware and that they would struggle to give it 1 out of 5 in a PD review. I know people think what they say doesn't matter but it's actually quite demotivating to read stuff like that.

I've also just spent a whole evening trying to blit out a double-size version of the tiles and hit a brick wall. The image is there but the colours are wrong as if a bitplane is missing. I'm pretty new to pointer arithmetic and bitwise operations in and I need to stop now because I'm tying myself in knots.

All in all I'm going to bed on a bit of downer but tomorrow's another day and it's back to PPaint...

[attle]

I like the artwork style Keep at it!

[idrougge]

Yes, the backdrop looks like a nice Licenceware game.

[clebin]

@attle, idrougge

Thanks both! Really appreciate the feedback. I'll play around with some less drastic changes.

[clebin]

Quite a productive evening - I kept the background but added this old wooden TV with an LED-style display for the score.

[Overflow]

Its kinda hard to judge gameplay based on a still picture, and thats my guess why there has been a lack of feedback so far.

I notice you compare it somewhat with Tetris, and thats encouraging, cause brainteaser games is always fun to play.

[Gzegzolka]

It looks awesome I would love to play Your game.

[clebin]

@Gzegzolka
Thanks mate, that's nice to hear!

Originally Posted by Overflow

Its kinda hard to judge gameplay based on a still picture, and thats my guess why there has been a lack of feedback so far.

I notice you compare it somewhat with Tetris, and thats encouraging, cause brainteaser games is always fun to play.

Cheers - that makes sense. I've got one in-game pop-up to add and then I'll record a video. That'll explain the gameplay better than I can!

[Gzegzolka]

Clebin, I do not know why You do not receive more positive response. In my case - I do not have now much spare time, and if I have I play lumberjack. Also I do not think that Your game lacks presentation. Graphics looks very nice, even if it's still picture. I would love to see short gameplay to see it in action and I'm sure most of EAB users would like to see it too.
Just do not spend too much time on adding new stuff and balancing old ones, make it playable and everything else could be fixed later or used for next projects. I do not know how I could miss Your post.

[kriz]

Interesting read, and very nice game in progress !! Want to try Landfill

[clebin]

@Gzegzolka, kriz
Thanks for all your encouragement.


Here's a video!

[ Show youtube player ]


The object is to match items in a chain. At the beginning of the video you'll see Jam + Bread. Over time, new items are added to the chain - Bread + Toaster, Toaster + Electrical Plug, and so on. As new items are added it becomes a quick memory/observation test of what goes with what (I think I have 28 items in total).

To make things easier, you can use Fire Button + Direction to swap with the item to the left or right. You can also use this to remove more tiles in one go and create chain reactions which gives you a higher score.

You mention getting the gameplay right Gzegzolka - I couldn't agree more! My template for the 'feel' of Landfill is Twintris which I think is a fantastic version of Tetris. So, for example, pulling down on the joystick speeds up the block but you can still control it as it drops. You can also briefly 'slide' off objects to manoeuvre into a space, rather than them sticking like glue.

Enough waffling - hope you like it.