Jump to content
IGNORED

Running a Multitude of constant timers/counters with rB+


Recommended Posts

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

 

 

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.

Link to comment
Share on other sites

  • 3 weeks later...

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
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...