We're using cookies to ensure you get the best experience on our website. More info
Understood
@davinceRegistered February 15, 2010Active 4 months, 2 weeks ago
250 Replies made

Wow, I can’t believe I missed all this talk about sound and music engines. And you say it’s tracker-based? That’s awesome, trackers are totally what I use already to make music! (If you need any feedback on the GUI design, I’ll be on the ready. 😉 )

Looking forward to it seeing it! 😀

That was an interesting read. I was kinda hoping for some ARM-specific details, like possible hurdles because of the difference in the different CPU instruction sets, or nice speed-ups because of matches in the instruction sets.

But, well, now I understand what recompilation really does just a little bit better. And heck, the Wii can do Virtual Boy emulation at a good speed, and as I understand it the 3DS is more powerful than the Wii, so that leaves some leeway to be able to handle two screens too.

For the past few days the site had occasionally been acting up for me, too – usually in the form of the site simply showing me a 500 server error with the picture of a VB doing a >_< face. That's normally indicative of something being temporarily wrong with the site, not your ISP, and sure enough it's working just fine now. I've seen a "database connect error" a few times too, which is also obviously a server error, not a client one. But if the site isn't loading at all and showing your browser's default "This webpage is not available" or "can't connect to server" messages, then something is wrong between your system and the site, yes.

My less supporting friends said it was a sign that VB is bad for me

Sounds like some kinda joke to me? There isn’t any kind of strange addition factor to this site, now is there? Just a friendly community of enthusiasts. o_O

EDIT: OH, I get it. I thought they said Planet VB is bad for you. Haha. But yeah, there’s no way a VB is going to be worse for you than any other game system out there. What are we supposed to imagine with “bad for you” anyway?

I don’t know why, but that link isn’t displaying any pictures for me in Chrome. Luckily there’s a zip of the files at http://www.planetvb.com/modules/games/?u022i

Though there are a lot of typos in the Japanese transcription (like かてきる which should be ができる), it still helps a lot since it makes the kanji characters easy to look up.

Is anyone working on this yet? Otherwise, I’m giving it a look-through now. It’s fairly complex for me since there’s a lot of unfamiliar kanji though, so if someone else is already working on it, that might be preferable.

I hope this turns out legit

It’s legit. Smea posted about it on their Twitter. It’s also really cool.

Cool. I had enough trouble finding a regular DC and here you have all these shiny interesting ones. 🙂

I really enjoyed the super cheesy plot and acting. Hilarious camera work, and nice shots of the unit. 😀

I’m also impressed you got such a nice and complete store unit. Freakin’ cool.

It seems like there’s more supply than demand, then. (I can read a fair bit of Japanese.) 😛

Tough. I don’t know if I like the SNES or the Playstation more, so I picked Playstation since it’ll probably tip the scales a little bit more. 🙂

I didn’t manage to compile this on VBDE, either. I wouldn’t mind designing some levels and playtesting the game if you can get it to compile. 🙂

I’d like to revisit this topic, since random numbers are mighty useful in games. So I did a search for random number generators and found this page:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html

Specifically, this .c file:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c

This is a random number generator based on the Mersenne Twister, which is supposedly reliable and fast. It requires you to either give it a seed to start with, or set up an array with some seed numbers. From there on it will give you nice random numbers.

Now, the C file linked above will error out horribly if you try to include it in a VB project. Thing is, the genrand_real functions contain stuff that will not compile on VB. The thing also has an stdio.h include and a main() that we’ll want to remove.

Luckily, this file has a very liberal license, so it can be modified to our wishes. Attached is a modified mt19937ar.c that properly gives you pseudo-random numbers on VB! (I tried it on one of the demo files, and it seems to be returning random numbers quite nicely!)

Usage:

//On init:
init_genrand(18293); //Or any number you like

//Whenever you need it:
int randomnumber = genrand_int32()%10; //%10 means between 0 and 9
Attachments:

The way you have set it up, it sounds like the pattern would be very predictable: press L or R, and you will most guaranteed see the enemy jump, then punch, then try a special.

Here’s my tip: randomize it, and randomize it based on a timer (that counts up by 1 each frame) and your character’s proximity to the opponent. Actually, have two randomized timers: one determining the enemy’s movement, and the other their actions.

For the movement timer:
Once it reaches its max value, it is time to perform a movement action. Then do a check how close/far the opponent is from the player.
– If they’re further than, say, 200 pixels away, then always move the enemy closer by, say, 100 pixels.
– If they’re between 100 and 200 pixels, randomly decide if they should be moving a random amount forward, do nothing, or move backward a tiny bit (you can influence the chance this happens by comparing their HP, too).
– If they’re closer than that, randomly decide whether they should move forward a random amount, do nothing, move backward a (larger) random amount, or jump.

For the action timer:
This timer needs to be a little bit shorter (so moves are attempted more often), but still at random intervals. When it’s time to decide on an action:

– Check whether the player is in, say, a 50 px proximity. If they are, attempt one of the moves (or do nothing). This way, might try to attack even when it’s not close enough this way, but it’ll just look as if the enemy attempted and failed at an attack, which gives you, the player, a chance to retaliate.

Outside of both:
– If the enemy is jumping and near you, it could randomly try to do its special move right afterward.

You can add to this, and add more conditions that specifically change the behavior based on which bug it is, how aggressive/cowardly they are, if they’re almost out of HP, etc.

The issue
Now, there is one big problem. All of the logic above relies on randomization. That is, the kind of logic that looks like this:

int random_number = (select a random number between 0 and 10);
if (random_number < 5) {
  //Perform action of type 1
}
else {
  //Perform action of type 2
}

The big problem is that the VB doesn't seem to have a function to create such a random number! There's no rand() function (like in traditional C) to rely on to give you a random number. That's going to complicate things. I've found a potential random number generator you could use but I need to test it first. In the meantime, think about the fighting logic like the above a bit more, try to expand on it, and carefully consider how you would start implementing it. 😉

Edit: and now we have a solution. 🙂
http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3723&post_id=30500#forumpost30500

  • This reply was modified 9 years, 6 months ago by DaVince.

Nice work, glad it functions. I still have suggestions though! 🙂

Most of the work came from the fact that I don’t want the fighter and opponent to be the same insect. So that took a whole lot of time to sort that out.

Well, about that, I actually explained how you can solve that by using function arguments:

int charselect(int hidecharacter) {
  //In your code, use the value of int hidecharacter to hide
  //the specific character you don't want to appear in the list
}

And during the function call:

fighter = charselect(-1);  //All bugs visible
opponent = charselect(fighter); //The bug the player selected is not visible

This way, you can get rid of the remaining use of the “fighter” variable in the function (like if1 showchar++;).

You can even give the function several arguments, for example to set the default character to show:

//The charselect function:
int charselect(int startingcharacter, int hidecharacter) {
  showchar = startingcharacter;
}


//Inside main():
fighter = charselect(1, -1);
//1 means start by showing bug 1,
//-1 means don't hide any from the possible options

opponent = charselect(fighter+1, fighter)
//fighter+1 means start by showing the bug right after the one the player selected,
//fighter means hide the bug the player selected from the possible options

Function arguments are super useful and will save you a few headaches, I think. 🙂

VirtualChris wrote:
Despite the lot of stupid, needless warnings

Did my suggestion above work to fix these? Over here they did. You just put that stuff right above int main(). (Oh, and void charselect(); has become int charselect(int startingcharacter, int hidecharacter); if you implement my above code).

Guy Perfect said it. 😉

VirtualChris wrote:
I can’t figure out how to solve the problem that is posed by using the same code twice in fighter selection code. I tried and can’t come up with anything.

The key thing is the variables “opponent” and “fighter”.

The thing is, the variables “opponent” and “fighter” really only contain a number that represents the current fighter and opponent throughout the game. That’s completely fine. The main thing we need to do is to detach those from the actual character select function.

Why? Well, it’s because we want this one function to be able to handle multiple different situations. One has everything to do with the fighter, and nothing to do with the opponent. The other one has everything to do with the opponent, and nothing to do with the fighter. So that’s why we need to make the functionality itself more generic – usable over more situations.

Now, the best way to do that is by replacing any occurrence of fighter in your character select code with a different variable. For example, a local variable called selected_character:

//inside the selection screen function:
int selected_character = 1;

Next, you make the function charselect return this value. So the void charselect() we have right now becomes this:

int charselect() {
  int selected_character = 1;

  //...All the character selection code that determines the
  //final value of selected_character...

  //And at the very end, when the function should be closed:
  return selected_character;
}

int charselect() indicates we’re going to make the function charselect return a number to us. And “return selected_character” actually gives us that number.

Now you call the function charselect() twice and store the result of the character select screen into the appropriate variables:

fighter = charselect();  //The value that is returned will be stored in fighter
opponent = charselect();  //Same, except it's stored in opponent

Of course you don’t run that code in charselect() itself; that would make it open itself infinitely recursively. You could put it in main():

case STATE_PREFIGHT:
  fighter = charselect();
  opponent = charselect();
  prefight();
break;

And that’s the basics of that. And the cool thing is, if you ever have even more characters on the screen, it’s a cinch to just add a third variable that calls characterselect(). 🙂

Now the only thing left to do is ensure that the character you selected isn’t selectable again. You can do that by adding an argument to the function declaration:

int charselect(int hidecharacter) {
  //In your code, use the value of int hidecharacter to hide 
  //the specific character you don't want to appear in the list
}

And during the function call:

fighter = charselect(-1);  //All bugs to be visible, so any value outside 1-8 works
opponent = charselect(fighter); //We want the character the fighter selected to not be visible

PS. It’s a good idea to also give variables like changefighter, fighterxsight and fightery more generic names, like changecharacter, characterxsight, charactery. And make those local variables (that is, variables declared inside the function) since that function is the only place they’ll be used.

Guy Perfect wrote:

How did I know it was doctored before I proved it? Take a good long look at the video title and don’t look away until you figure it out:

Dammit, how did we not notice that? 😀

I see, that’s interesting, because there’s no need at all for those functions to be ints. They don’t return an integer value…. They don’t return any value at all (which is why I changed the functions to type void in the first place).

…I just tried declaring the voids before int main, and it’s not complaining at all?

void initgame();
void preintro();
void intropart();
void titlescreenpart();
void charselect();
void prefight();
void fightscreen();

Don’t forget to use the right type, I guess? If your functions are all voids, it’d be weird to declare them as ints at the beginning of your code…

  • This reply was modified 9 years, 7 months ago by DaVince.

Oh, also, HorvatM actually mentioned WaitForVIP (twice, but not really what it does. That was exactly the solution you needed, though.

The six VB demo games also use vbWaitFrame(0), which does pretty much the same thing. I’m kind of surprised you didn’t find this earlier – maybe because it’s the VB with its limited processing power. On a PC you would have found out pretty much immediately that your game runs at a limitless FPS, which can’t just be solved by saying “slow it down with this counter please”. Especially since PC processors are all different speeds. 🙂

Edit: sorry all the tabs turned into double spaces, by the way. Hope you can live with that. 😡

  • This reply was modified 9 years, 7 months ago by DaVince.

Ah, the warnings are actually no big deal. They are there because we’re calling functions in main() that don’t even exist yet at that point (they are defined later in the code), so it’s warning and telling you it’s declaring them for you. You can actually fix that by defining them before int main, like this:

//This is what I'm talking about! The function "foo" is now declared properly and explicitly before main:
int foo(int arg);
void initgame();
void preintro();

//Then the main function comes
int main() {
  //Code that refers to foo, initgame, preintro...
}

//And then the *actual* function definitions.

int foo(int arg) {
  // code
  return 0;
}

void initgame() {
  //code here...
}

void preintro() {
  //You get the gist of it
}

Is it actually erroring out or not? Let’s find out once you get rid of the warnings. 🙂

I zipped up my version of the source code, along with a modified sounddat.h.

Do a ctrl+F for “DaVince note”. You’ll find a lot of results that I hope will be really helpful for you improving your coding skills! 😀

:vb: Notes of interest :vb:

The font never compiled/looked the way it should for me. (See attached screenshot.) (Edit: I was told it’s because the game is compiled with gccvb 1.0 and since I use VBDE with a newer gccvb it expects the font to be slightly different. So that’s that I guess.)

The timing of some things is off, but that’s because I completely fixed the timing in most screens. Except for the second character selection screen, because that’s a huge 250 line chunk of duplicated code (I’m not fixing things twice and there’s no point to having the same 250 lines twice in your source. Check my code comments to learn more on that!).

I hope none of this actually offends you in any way. I spent hours upon hours going through the source, thinking of any tips and helpful additions/changes I could make. In the end, this is all so you can become a better coder, so you can make a better program that’s easier for you to change and add things to in the future. Which means we get to see increasingly better versions of it more quickly. :thumpup: 😀

  • This reply was modified 9 years, 7 months ago by DaVince.
  • This reply was modified 9 years, 7 months ago by DaVince.
  1. fighter==showchar []