Jump to content

Photo

Running a Multitude of constant timers/counters with rB+


7 replies to this topic

#1 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • 952 posts
  • Location:Charlotte, NC

Posted Sun Oct 15, 2017 11:11 PM

Hi guys. So I am working on a new project that is using a multitude of timers in order to make events occur the way I want them to. (my own little timeline) I chose to do it in this fashion because I need for certain items to appear in game behind others as in the object list the higher up the list your object is the further in the background your sprite object will appear in game and to my knowledge there is no way to swap out objects spots in the object list mid-game short of redirecting the graphics with R_sprite_gfxbase.   So far it's working good, but I'm concerned about working the hardware too much with too many constant timers running at once. Certain events trigger that reset the timers back to a value I need them at, so they never just go on for infinity. What I am curious to know is has anyone else tried using a multitude of running counters in this way in their projects, and if so were there any adverse effects? How many of those counters were you able to use?

 

I will post a little bit of the code below so you can get a better idea of what it is I'm trying to accomplish as well as a short video of it currently working.

' *******************************************************************************************************************************


	CALL player1movement

    
    
        framecounter++                                                   
	foodtimer++
        slashtimer++
	girltimer++
	coptimer++
	camgirltimer++
	
    VSYNC                                                           
LOOP
IF slashtimer=180 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF slashtimer=210 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF slashtimer=240 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF slashtimer=270 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF slashtimer=300 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF camgirltimer=30 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF camgirltimer=60 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	
	IF camgirltimer=90 THEN
	RSETOBJ(flashb, R_sprite_active, R_is_active)
	DELAY (4)
    RSETOBJ(flashb, R_sprite_active, R_is_inactive)
	hp=hp-10
	ENDIF
	

 

I'm wondering if the way I'm doing it is strange or if somebody else has thought of running events like this in a similar way. I'm going to keep adding timers (probably about 4 more...) I will see what happens. Hopefully it doesn't all come crashing down.

As always your feedback is welcome

 

 

 

I forgot to mention that the starting value on most of these timers is 500, then it changes as certain events trigger it back to 0


Edited by Jeffrey_Bones, Sun Oct 15, 2017 11:21 PM.


#2 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Mon Oct 16, 2017 1:14 AM

Well, here are a few things I can think of:

 

  1. If your slashtimer variable is between 32767 and -32768 consider using the WORD type if you haven't already. The 68000 works a tiny bit faster

  2. Avoid using rsetobject/rgetobject at all times as a lot of them can bog down your program. Use rlist as described here - also see nyandodge project for comparisons between rset/rget and rlist.

  3. I see you're simply checking for certain values of slashtimer and take action only then. In this case you can use SELECT CASE ... / CASE ... / END SELECT which will result in faster code.

  4. DELAY(x) will generally halt all of your program's execution for x vertical blanks. Raptor will update stuff in the meantime but your program will halt, as well as your timers. Is that really what you require? Maybe you could restructure that code and just have vsync give you per frame accuracy?

 

As you see nothing too different or groundbreaking but any tiny bit helps. Also since the Jaugar doesn't have any other timers we can easily use, what you do is probably the easiest way to handle things.



#3 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 952 posts
  • Location:Charlotte, NC

Posted Mon Oct 16, 2017 1:38 AM

Well, here are a few things I can think of:

 

  1. If your slashtimer variable is between 32767 and -32768 consider using the WORD type if you haven't already. The 68000 works a tiny bit faster

  2. Avoid using rsetobject/rgetobject at all times as a lot of them can bog down your program. Use rlist as described here - also see nyandodge project for comparisons between rset/rget and rlist.

  3. I see you're simply checking for certain values of slashtimer and take action only then. In this case you can use SELECT CASE ... / CASE ... / END SELECT which will result in faster code.

  4. DELAY(x) will generally halt all of your program's execution for x vertical blanks. Raptor will update stuff in the meantime but your program will halt, as well as your timers. Is that really what you require? Maybe you could restructure that code and just have vsync give you per frame accuracy?

 

As you see nothing too different or groundbreaking but any tiny bit helps. Also since the Jaugar doesn't have any other timers we can easily use, what you do is probably the easiest way to handle things.

 

 

 

1 I'm not sure what you mean by WORD type? I would love to utilize the 6800 for these, is there a particular tutorial thread that covers using WORD type? (haven't seen it thus far)

 

 

4 I knew about the delay stopping EVERYTHING already, I chose to do it this way because I wanted the players controls to briefly freeze when damage is taken. If everything freezes so does your controls for a split second. The issue however I come across is the effect is not really that noticeable, If I restructure the code completely as you suggested I will need to figure out another way to briefly make the players controls unresponsive. It looks like I may have to do that anyway though as like I said the effect isn't quite how I wanted it. 



#4 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Mon Oct 16, 2017 5:08 AM

 

 

 

1 I'm not sure what you mean by WORD type? I would love to utilize the 6800 for these, is there a particular tutorial thread that covers using WORD type? (haven't seen it thus far)

 

 

4 I knew about the delay stopping EVERYTHING already, I chose to do it this way because I wanted the players controls to briefly freeze when damage is taken. If everything freezes so does your controls for a split second. The issue however I come across is the effect is not really that noticeable, If I restructure the code completely as you suggested I will need to figure out another way to briefly make the players controls unresponsive. It looks like I may have to do that anyway though as like I said the effect isn't quite how I wanted it. 

 

1. WORD is an alias for "signed 16bit". So you can use

dim x as short

or

dim x as WORD

 

4. This is completely up to you. You might want to have a second counter to keep track of when to update your crosshair etc. But generally I wouldn't recommend using delay(x) as you might want to use those spare cycles somewhere else.



#5 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 952 posts
  • Location:Charlotte, NC

Posted Mon Nov 6, 2017 12:13 AM

Heres a question I dont think has been asked yet. Is there a way to FREEZE all of my timers? Like all at once for example a pause function or suppose something takes place and you want everything to stop until there is an input? Lets say you approach a character and a block of text pops up that you must read. You would want the flow of all the timers to stop until you read it and pressed whatever button to continue. Or heck just a PAUSE function in general. How can I stop all the timers that are already rolling without altering their current values? I know ++ makes it continue to count, there must be a stop function?

Edited by Jeffrey_Bones, Mon Nov 6, 2017 12:14 AM.


#6 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,317 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Mon Nov 6, 2017 12:23 AM

Heres a question I dont think has been asked yet. Is there a way to FREEZE all of my timers?

 

 

Yes. They are your variables. Just don't update them.



#7 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Mon Nov 6, 2017 12:26 AM

dim timers_running as short
dim mytimer1 as short
dim mytimer2 as short
timers_running=1
mytimer1=0
mytimer2=0

...

do
    vsync
    'Increment timers
    if timers_running then
         mytimer1++
         mytimer2++
    endif
...
    if <condition that checks for pause or whatever you wish>
        timers_running=0
    else if <condition that checks for unpause or whatever you wish>
        timers_running=1
    endif
loop
In other words, since you have a software timer outside of the system it's your responsibility to manage it as you wish.


Hope this helps.

[EDIT] Damn, beat by 2 minutes!

Edited by ggn, Mon Nov 6, 2017 12:27 AM.


#8 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 952 posts
  • Location:Charlotte, NC

Posted Mon Nov 6, 2017 12:33 AM

Ah!!!! I get it duh!!! That makes sense. So instead of constantly having them tick put a variable that sets an on or off flag first. Wow that was pretty damn simple.

In fact now that you put it that way it IS just another variable. (Whichever timer) and there are probably several different ways I could do a pause then.

Edited by Jeffrey_Bones, Mon Nov 6, 2017 12:38 AM.

  • ggn likes this



Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users