First doubts for game developing

[nandius_c]

Hi all,

I'm new to this forum and, first of all, I want to say thanks to Photon for his amazing tutorial on Youtube. I'm starting to develop for the Amiga in asmOne and trying to make a very simple game. I would like to ask a couple a questions, and would be very grateful for any help given:

- Which is the best approach for doing things during the VBI? I mean: is it better waiting for the raster or using the VBL interrupt?

- Right now, my main problem is how to handle key presses. I think there are two options for this: interrupt or a device handler? Am I right?

Which are the best options for both points (VBI waiting and handling key presses) considering that I'm developing a game?

Thanks in advance!!!

[alkis]

Welcome,
I am very much noob myself at this but I'll try to answer.

First, you second question...Read this thread http://eab.abime.net/showthread.php?t=70691 In it, you'll find two zip files. On the first zip, I've implemented reading the keyboard with an interrupt. On the second zip, I've implemented reading the keyboard with an input handler. (Bear in mind the fist zip is buggy, but not cause of the keyboard handling

Now, you first question.
Most of the time, you can freely choose, I guess. But say, as the topic of the thread I linked was, you want to do data background loading from disk while your game still runs, you have to put the game stuff on VBL (and handle the loading in the main loop code)

[Mrs Beanbag]

Personally I just read the keyboard status directly using the CIA registers. It might not be the proper way to do it but it's simple and it works.

[nandius_c]

@Alkis Thanks for your answer. In fact, 2 or 3 days ago I spent some hours trying to understand the code of your second example (input handler) but I was unable to get very far. A little bit too complex for me at this moment. I will have a look at your other file (interrupt) and try to compare both .

@Mrs Beanbag I didn't know this third way of looking at this problem. Thanks!

Still looking for the simplest possible to handle key presses for a game.

Thanks again and, please, keep on posting replies!

[phx]

First you have to make a decision if you want to write your game with or without using the OS. Mixing direct hardware banging with OS calls is a bad idea.

You can do the VBL and keyboard handling as you like, as long as it works. I decided to run the whole game's main engine during a VERTB interrupt, as I want to run it at full 50 fps anyway.

For keyboard handling I decided to install a Level 2 interrupt handler, because key presses occur very rarely. So I don't want to spend any cycles polling the CIA-state when not necessary.

[nandius_c]

Can anyone explain briefly the differences (pros and cons) between handling key presses as an interrupt and using an input device handler, please? @alkis?

@phx Thanks! You say you do all the game stuff in the VERTB interrupt so to have the game running at 50 fps, I love that! But I have a question: what would happen if the instructions executed during the VBI take longer than the VBI iteself? What would be the effects?

[phx]

Originally Posted by nandius_c

@phx Thanks! You say you do all the game stuff in the VERTB interrupt so to have the game running at 50 fps, I love that!

Works best when you take over hardware and disable the OS.

But I have a question: what would happen if the instructions executed during the VBI take longer than the VBI iteself? What would be the effects?

Good question. I'm not 100% sure as I didn't try it, but I guess that the behaviour depends on whether you already acknowledged the interrupt request (resetting the VERTB-flag in INTREQ) or not. In the first case your routine will be interrupted again and restarts, although it didn't finish yet. In the second case you will miss an interrupt and a whole frame.

But there is also the IPL mask in the CPU's SR register, which might still mask all level 3 interrupts. It is not reset before RTE. This would mean that you will never be interrupted again, but an already cleared VERTB interrupt request will be reset at the end of your routine and the next interrupt happens directly thereafter. Otherwise (flag was not cleared), the interrupt is lost.

Sorry, I'm a bit confused without any documentation here at work. Please, anybody correct me...

[Mrs Beanbag]

Originally Posted by phx

In the first case your routine will be interrupted again and restarts, although it didn't finish yet.

Could this end up overflowing the supervisor stack?

[Toni Wilen]

New interrupt starts only if new interrupt level is higher than current SR stored interrupt level. Only level 7 interrupt can interrupt another level 7 interrupt.

[phx]

Thanks Toni. So probably my second paragraph is right?

IPL is 3 when a VERTB IRQ happens, until I lower priority with RTE.

If I cleared the VERTB-flag in INTREQ, at the beginning of my routine, and the next VERTB happens before RTE, then the interrupt is caused directly after it? Otherwise it is lost. Is that correct?

[alkis]

Originally Posted by nandius_c

Can anyone explain briefly the differences (pros and cons) between handling key presses as an interrupt and using an input device handler, please? @alkis?

Umm, I really wish I could :-)
Unfortunately, I don't have the knowledge for this. Let's hope someone with the know-how steps in....

[Apollo]

Commodores' input.device 'knows' about all the different keyboards you find within the Amigas. See http://eab.abime.net/showthread.php?t=71099

[nandius_c]

Wow, thank you so much for all your answers!

After getting so much information I've decided to enter for a while in "guru meditation" mode and think about all the possible options available:

• After reading this thread I have absolutely no idea about which is the best way to wait for the VBL At this moment, my code is not using any buffering .I guess the best way is to wait for the last displayed line as it gives you more time to do all the VB stuff before the next frame begins But I'm not sure about which of the many ways I've seen for waiting for a raster lines is the best and which of them execute in a raster line time or less (so that the line you are waiting for is not skipped). Right now, I'm doing all the VBL stuff using the VBL interrupt.

• Keyboard: now I'm using a keyboard interrupt but I still have to give the input device handler a try. I see that with an IDH your code doesn't have to care about the different types of keyboards, etc. Also I'm trying to guess how to keep doing something as long as a key remains pressed. With the code I have now every time I press a key the action is done once and then I have to release and press again that key for that action to be repeated.

Hope we can summarize here different answers for these questions. Thanks again!

[Mrs Beanbag]

you could use a copper interrupt, there is an interrupt assigned for the copper to use which you can trigger from the copper list on any raster line you want.

[phx]

Originally Posted by nandius_c

Also I'm trying to guess how to keep doing something as long as a key remains pressed. With the code I have now every time I press a key the action is done once and then I have to release and press again that key for that action to be repeated.

The keyboard transmits an up/down flag with each key-code (called IECODE_UP_PREFIX in the Input Handler). It is set when the key was released. This helps you to keep track of the current state of each key you are interested in.

[Toni Wilen]

Originally Posted by phx

Thanks Toni. So probably my second paragraph is right?

IPL is 3 when a VERTB IRQ happens, until I lower priority with RTE.

If I cleared the VERTB-flag in INTREQ, at the beginning of my routine, and the next VERTB happens before RTE, then the interrupt is caused directly after it? Otherwise it is lost. Is that correct?

Yeah. If IPL is still 3 when RTE executes (=INTREQ VERTB bit is set), new level 3 interrupt starts immediately after RTE finishes. (This is also the place where 68040/060 "issue" can happen, there is short delay, 1-2 color clocks, before IPL line change after INTREQ write, cached RTE may finish very quickly, IPL lines have still old interrupt level -> interrupt retriggers unexpectedly)

What do you mean by lost? You only "lose" interrupts if you clear INTREQ at the end of routine and your routine took longer than 1 vblank. (and yuo can only lose/miss interrupts that are not caused by external devices like CIA or HD controller)

[phx]

Originally Posted by Toni Wilen

(This is also the place where 68040/060 "issue" can happen, there is short delay, 1-2 color clocks, before IPL line change after INTREQ write, cached RTE may finish very quickly, IPL lines have still old interrupt level -> interrupt retriggers unexpectedly)

IIRC a NOP instruction can be used to make sure all write cycles have been completed. As I understand you now the 1-2 color clocks delay takes place although the write-cycle to INTREQ has been completed (for the CPU)?

What do you mean by lost? You only "lose" interrupts if you clear INTREQ at the end of routine and your routine took longer than 1 vblank.

Yes. That's what I meant.

(and yuo can only lose/miss interrupts that are not caused by external devices like CIA or HD controller)

What does that mean? CIA-A or CIA-B?
I would say that the VERTB IRQ is the only one I could miss. Even a level 2 CIA-A interrupt would still occur, as soon as RTE lowers the IPL-mask in SR below 2.

[Toni Wilen]

Originally Posted by phx

IIRC a NOP instruction can be used to make sure all write cycles have been completed. As I understand you now the 1-2 color clocks delay takes place although the write-cycle to INTREQ has been completed (for the CPU)?

Any extra custom register access is also slow enough.

What does that mean? CIA-A or CIA-B?
I would say that the VERTB IRQ is the only one I could miss. Even a level 2 CIA-A interrupt would still occur, as soon as RTE lowers the IPL-mask in SR below 2.

I meant "external" (external to Paula, level 2 and 6 lines) interrupt sources that have separate interrupt acknowledge register and clearing INTREQ clears it for few cycles and then it becomes set again.

(There are some programs that do it wrong, clear INTREQ first and then clears CIA interrupt register and have extra code that handles and ignores the extra interrupt!)

[TheDarkCoder]

Originally Posted by phx

IIRC a NOP instruction can be used to make sure all write cycles have been completed. As I understand you now the 1-2 color clocks delay takes place although the write-cycle to INTREQ has been completed (for the CPU)?

I did several experiments years ago and I seem to remember that on a or more NOPs are not enough. The NOP, as you say, ensure that the CPU has completed all write cycles, but it can not ensure that the reset of the INTREQ bit has propagated to the IRQ line. With my Cyberstorm 060 MkIII 3 NOPs are not enough.
To be sure, you need to access a custom register or a CIA register (read accesses are enough) *after* the write to INTREQ.

[nandius_c]

Thanks again for all your help!

Could anyone please tell me the number of the last visible line in a low resolucion / non interlaced PAL display? Amiga HRM says that total number of lines in that case is 312, 256 of which are really visible. That means there are 56 non visible lines. Does that mean there are 28 lines before the first visible line and 28 after the last visible line? In that case line 28 + 256 = 284 would be the last line visible.

Thanks in advance!