2018-03-29 06:20:10

Hi folks. Well, we're trying to implement joystick support into battlezone. And an entry-level implementation that we've done involves this.
void main() {
joystick stick;
show_game_window("Battle Zone Pro, (build 1.0 beta 1)");
if(stick.joysticks==0)
{
alert("Error", "No joysticks seem to be attached.");
}
fast forward to where we try to implement an action button.
if(key_down(KEY_SPACE)&&using==4) shootsword();
works fine. But when I put this right below it,
if(stick.button_down(1)&&using==4)
I go to run the code and it says...
stick is not declared. What do you mean not declared, we declared it right below void main. And if you say it isn't declared, where were you when the game checked for joysticks?
Any help would be appreciated, as this clearly should not be happening.

2018-03-29 08:40:39

Several things to check when you get identifier not declared errors:

Do you have to initialize the Joystick object? I'm not sure what language this is, but it many OOP languages you must allocate heap memory for an object before using it, like this:
Joystick stick = new Joystick(...);

Next, is the Joystick type correct? In C/C++ specifically, if you provide a type that doesn't exist, the identifier itself becomes undeclared. So, in C, this code will throw a compile error saying that myVar is not declared:
someMadeUpOrIncorrectlySpelledType myVar;
myVar = 5;
This will give two errors: first, it will say that someMadeUpOrIncorrectlySpelledType could not be resolved. Then, it will say myVar is not declared.

Finally, make sure you're not unintentionally leaving the scope where the identifier was declared, by accidentally inserting an extra right-brace character.

This will give a compile error:
{
  int myVar;
}
myVar = 5; // myVar has gone out of scope here.

2018-03-29 11:23:19

It's bgt. Jack, To avoid this error declare the variable as global. It should fix your problem

---
Co-founder of Sonorous Arts.
Check out Sonorous Arts on github: https://github.com/sonorous-arts/
my Discord: kianoosh.shakeri2#2988

2018-03-29 14:19:51

Ahh yes, I was thinking something like that. That makes sense.

2018-03-30 04:10:54 (edited by jack 2018-03-30 05:03:39)

So we implemented joystick support in everything except the menus. However, Garrett wanted to revamp the enemy system, so he took out the original and threw in Scrolling Battles code to replace it. And we're getting one or compilation error per run, and it always happens to be a brace issue or unexpected token. Here's our sourcecode. P.s: I had a feeling something like this would happen.
*code removed*

2018-03-30 04:25:35

I did too, but I'm a stubborn ass and I do shit anyway, I'm just about ready to rip my hair out. These braces, I'm telling you my computers gonna be wearing a brace by the time this is all over.

Discord: dangero#0750
Steam: dangero2000
TWITCH
YOUTUBE and YOUTUBE DISCORD SERVER

2018-03-30 05:03:15

**update:** After some hard deliberation we are not revamping the enemy system. What we were trying to do turned out to be a much larger endeavor than Garrett had thought, I"m the one who came to that conclusion anyway. So, the enemy system is staying as is. IN other news, we have full joystick support, and the only bug we have is that now the spacebar repeat fires the sword and gun, like every weapon is a machinegun. Lol.

2018-03-30 09:45:01

There are many ways to prevent the rapid-fire problem. One way is to keep track of two things in every frame: what keys were pressed in that frame, and what keys weren't pressed in that frame.

Specific keys would be mapped to generic actions (GameActions.fireWeapon.) Also keep track of how much time should elapse between "fires" of this weapon (preferrably by measuring it as a function of your frame rate.) Then, when the code to execute actions is executed, depending on what weapon is selected, you can calculate delta(t1, t2) where t1 and t2 note the current time and the last execution time of the action, respectively. If this delta exceeds your fire rate, fire the weapon.

I've written some pseudo code here.

For every frame {
  Note down which keys are pressed
  Note down which keys are not pressed
  Based on what keys are pressed, queue some actions.
  for every action {
    if the action is a fire action, then {
      let delta = currentTime - lastTimeWeExecutedThisAction
      if delta is greater than or equal to the fire rate, fire the weapon and let lastTimeWeExecutedThisAction = currentTime, otherwise do nothing
    }
  }
}

One other thing you will have to do is if the fire action is not executed in a frame, execute it in the next frame if the fire action registers in that frame. This way, if they're holding down the fire button, then let go, then press it again, the weapon will fire.

if the fire action is not registered in this frame {
  let lastTimeWeExecutedThisAction = 0
}

This way, the next time you end up calculating delta, you'll get currentTime - 0 which will execute your fire action.

One other tip I have for you is to separate out your input loop from your frame code. Otherwise, if your frame rate is something like 100 milliseconds, you'll get a problem when sometimes the buttons you press won't register. To get around this in TDV, I had my input loop running on a separate thread, and I queued actions to be consumed by the next frame. The input loop was running sufficiently fast, maybe double the speed of the frame rate, so the user input became smooth. I'm not sure if you can multithread in BGT, but it's worth a look.

jack wrote:

**update:** After some hard deliberation we are not revamping the enemy system. What we were trying to do turned out to be a much larger endeavor than Garrett had thought, I"m the one who came to that conclusion anyway. So, the enemy system is staying as is. IN other news, we have full joystick support, and the only bug we have is that now the spacebar repeat fires the sword and gun, like every weapon is a machinegun. Lol.

2018-03-30 13:34:34

at Munawar battlezone is not using frame per second and stuff like these Nore most of the bgt games do!
at jack simple change the if(key_down to if(key_pressed and it should be fixed. BTW if you read the manual file you'll get it all. Language tutorial would be a good start because it discrybes almost every extreamly needed thing.

---
Co-founder of Sonorous Arts.
Check out Sonorous Arts on github: https://github.com/sonorous-arts/
my Discord: kianoosh.shakeri2#2988

2018-03-30 16:49:55

True enough that it doesn't use frames but the concept still stands, if you use the negation operator which is '!', obviously without the quotes, on key pressed, it should reverse and return if the key wasn't pressed.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2018-03-30 18:01:25

@kianoosh the problem is, if I change it to key pressed, the machine gun is no longer a machine gun, it's just a gun. Somewhere somehow I screwed something up, I just need to figure it out. I'm afraid I don't understand this frames per second stuff. I really should check out the language tutorial, I've never been able to get it before but I can always try again.

Discord: dangero#0750
Steam: dangero2000
TWITCH
YOUTUBE and YOUTUBE DISCORD SERVER

2018-03-30 21:24:42

No problem; I'll explain a bit more.

Since people are saying that your game doesn't use FPS (frames per second,) I'm assuming enemies are moved using timers, and that you're handling keys in a keyDown event. Now, if you look at the technical implementation, this still means you have a frame rate, but we'll stay away from the implementation details here.

When you hold down a key, some code that you've put in keyDown fires over and over and over in rapid succession. For our cases, how many times this code fires is our FPS. FPS generically means the times per second your game logic executes. Everything works in this way, including timers.

What actually happens in a keyDown event is that for some really high value, the keyboard is polled to see what keys are pressed. This is handled by the OS's "message loop." That information, about what keys are pressed, is then passed to your application. And your application gives you access to it either by using things like DirectInput or the keyDown event.

That's as far as I'll go with the input details, only to show you that this is your FPS: how many times per second you're notified that some key is held down.

The reason when you use key_press you're getting only one shot is that key_press is different from keyDown. KeyPressedEvent means that the key is pressed. It will stay pressed until released. When the key is released, the keyUpEvent fires, notifying your application that this key is no longer pressed.

By contrast, keyDownEvent means the key is actually being held down. Think of it like a panic mode. KeyDown is like "Key is held down! Key is held down! Key is held down!, ..." and keyPressedEvent is like "Key is pressed...we'll wait for it to be released, relax."

So, keyPressedEvent is fired once per key press, no matter how long that key is held down, whereas keyDownEvent is fired as long as a key is held down.

What you want to do is control the rapid-fire behavior in the keyDownEvent.

This is all the pointers I can give you unless I get more information on your implementation details, and I hope it helps! What you should do is consider keyDownEvent to be your "input loop" logic and then apply my previous post on this topic.

shotgunshell wrote:

@kianoosh the problem is, if I change it to key pressed, the machine gun is no longer a machine gun, it's just a gun. Somewhere somehow I screwed something up, I just need to figure it out. I'm afraid I don't understand this frames per second stuff. I really should check out the language tutorial, I've never been able to get it before but I can always try again.

2018-03-30 21:55:14

if (key_pressed and weapon.rapidfire==false) or (key_down and weapon.rapidfire) then fire
Maybe; depends on the specifics. But something like that.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2018-04-01 03:15:50 (edited by jack 2018-04-01 03:16:34)

Well now our new problem is right here in this thread
This'll be the last time we attempt to add joytsick support to dated code. Lol.