English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 19 October 2013, 17:57   #1
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
First doubts for game developing

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!!!
nandius_c is offline  
Old 19 October 2013, 20:55   #2
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 49
Posts: 569
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)
alkis is offline  
Old 20 October 2013, 00:19   #3
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 20 October 2013, 16:40   #4
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
@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!
nandius_c is offline  
Old 21 October 2013, 12:18   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
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.
phx is offline  
Old 21 October 2013, 14:27   #6
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
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?
nandius_c is offline  
Old 21 October 2013, 15:13   #7
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
Quote:
Originally Posted by nandius_c View Post
@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.

Quote:
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...
phx is offline  
Old 21 October 2013, 16:50   #8
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by phx View Post
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?
Mrs Beanbag is offline  
Old 21 October 2013, 17:18   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,547
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.
Toni Wilen is offline  
Old 21 October 2013, 18:14   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
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?
phx is offline  
Old 21 October 2013, 18:39   #11
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 49
Posts: 569
Quote:
Originally Posted by nandius_c View Post
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....
alkis is offline  
Old 22 October 2013, 15:02   #12
Apollo
Registered User

Apollo's Avatar
 
Join Date: Sep 2008
Location: Germany
Age: 46
Posts: 127
Commodores' input.device 'knows' about all the different keyboards you find within the Amigas. See http://eab.abime.net/showthread.php?t=71099
Apollo is offline  
Old 23 October 2013, 01:27   #13
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
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!
nandius_c is offline  
Old 23 October 2013, 01:37   #14
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 23 October 2013, 12:17   #15
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
Quote:
Originally Posted by nandius_c View Post
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.
phx is offline  
Old 23 October 2013, 12:19   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,547
Quote:
Originally Posted by phx View Post
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)
Toni Wilen is offline  
Old 23 October 2013, 15:59   #17
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
Quote:
Originally Posted by Toni Wilen View Post
(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)?

Quote:
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.

Quote:
(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.
phx is offline  
Old 23 October 2013, 22:07   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,547
Quote:
Originally Posted by phx View Post
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.

Quote:
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!)
Toni Wilen is offline  
Old 24 October 2013, 13:23   #19
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by phx View Post
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.
TheDarkCoder is offline  
Old 25 October 2013, 10:43   #20
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
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!
nandius_c is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
some doubts on the rom (kickstart) management in rommgr.cpp pucci support.WinUAE 2 11 September 2011 15:42
Developing a versus fighter for the OCS CMA Death Adder Coders. General 41 15 April 2011 17:16
Playpower - 8 bit learning games for the developing world girv Retrogaming General Discussion 5 24 March 2009 23:00
[Found: Biplane Duel] Plane Flying Game, 2D, Shoot each other (Compilation game?) EssKung Looking for a game name ? 7 19 May 2007 00:37
Who are developing games for Amiga platform at the moment? oldpx Amiga scene 65 06 October 2002 18:41

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.15017 seconds with 13 queries