You are not logged in.
Lost Password?

All Posts (DaVince)




#31
Re: Insect Combat
Posted on: 2014/10/23 16:24
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
Quote:
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.
Top

Topic | Forum


#32
Re: Super Mario Bros, Virtual Boy
Posted on: 2014/10/23 15:23
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
Quote:

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:

Open in new window

Dammit, how did we not notice that?
Top

Topic | Forum


#33
Re: Insect Combat
Posted on: 2014/10/23 15:01
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
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...
Edited by DaVince on 2014/10/23 16:25
Top

Topic | Forum


#34
Re: Insect Combat
Posted on: 2014/10/23 0:06
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
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.
Edited by DaVince on 2014/10/23 0:16
Top

Topic | Forum


#35
Re: Insect Combat
Posted on: 2014/10/22 23:59
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
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.
Top

Topic | Forum


#36
Re: Insect Combat
Posted on: 2014/10/22 21:35
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
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!


Notes of interest

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.

Attach file:


zip Insecticide-DaVince.zip Size: 26.06 KB; Hits: 106

png  ic6a-davincenotes-0000.png (11.91 KB)
1280_544806c23a10b.png 384X224 px
Edited by DaVince on 2014/10/22 22:09
Edited by DaVince on 2014/10/22 22:10
Top

Topic | Forum


#37
Re: Insect Combat
Posted on: 2014/10/22 21:17
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
All right. I did it. I edited a bunch of code, and I left tons and tons of comments and information on what I did and why I did it.


To be honest, I think it would be so much better for you if you brush up on a few basic coding concepts. Things like:
- Functions and function arguments (http://www.learncpp.com/cpp-tutorial/14-a-first-look-at-functions/, http://www.learncpp.com/cpp-tutorial/ ... parameters-and-arguments/)
- The importance of avoiding duplicate code (http://en.wikipedia.org/wiki/Duplicate_code)
- The usefulness of arrays (http://www.tutorialspoint.com/cprogramming/c_arrays.htm)
- Tips for naming variables (http://www.makinggoodsoftware.com/200 ... ips-for-naming-variables/)
- Global and local variables (http://www.codingunit.com/c-tutorial- ... nd-global-local-variables)
- Why indentation is important (http://www.cs.arizona.edu/~mccann/indent_c.html#One)
- Separate your code! Instead of one huge function where everything happens, chop it up into pieces that do their own job. (http://en.wikipedia.org/wiki/Separation_of_concerns)
- Commenting your code (http://www.hongkiat.com/blog/source-code-comment-styling-tips/)
I've done this a few times to add little descriptive bits above the code of which it's not immediately straightforward what it does. Helps people who see it for the first time a TON.

As well as:
- avoiding to check the same condition over and over. Check it once, nest the rest in there.
- How to prevent a loop from simply running as quickly and as much as it can. This is what causing almost *all* of the timing issues in your game (besides the bottlenecks).
This is common in game programming: you WANT to limit the amount of loops run to 50 per second. Luckily, the VB has vbWaitFrame() and WaitForVIP() to do that for you! (I used WaitForVIP() in the code)

It's a lot of reading and learning, but it will help immensely. Plus you're already halfway there - you've managed to write a working program. Even if that program is an unmanageable mess that breaks if you touch it too much.

Next up, the code.
Edited by DaVince on 2014/10/22 21:36
Edited by DaVince on 2014/10/22 21:37
Edited by DaVince on 2014/10/22 21:37
Top

Topic | Forum


#38
Re: Insect Combat
Posted on: 2014/10/22 17:27
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
Oh, I know why it happened. It's because you told the game to be that slow. Instead of locking the frame rate, you tell the game to do something 16 times and then progress a single frame.

You know... That's really unpredictable. You really won't know how much time the VB (or emulator!) has in order to do that. The more you do in a loop, the slower that gets. It'll be too fast, but you can't really tell how much too fast. You'd have to make a guess at slowing it down that will change every time you touch the code.

So that's why it's a good idea to limit the frame rate. Rely on using vbWaitFrame(0); or WaitForVIP() to make the game forcibly wait until it's time to display the next frame. You'll get a solid 50 FPS (once you remove the code that does the unnecessary counting to 16 and stuff of course).
Top

Topic | Forum


#39
Re: Insect Combat
Posted on: 2014/10/22 14:30
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
I hope you don't mind if I make some additions/changes to the code (mainly cleanup and separating things into functions, and adding many helpful notes for you) and then upload the new file.

Edit: by the way, it seems like the game moves at such an inconsistent pace because the frames aren't limited, causing them to move at the max possible speed. That would explain why it's too fast sometimes, but it doesn't explain the slowness in some situations. Especially the standard "wait for drawing to finish" code from the demo games makes the intro slow down to a crawl.

The only possible clue I have for that is that the VB is getting worked too hard, but in that case it should've been slow regardless... so that's probably not it.
Edited by DaVince on 2014/10/22 15:01
Edited by DaVince on 2014/10/22 15:20
Edited by DaVince on 2014/10/22 15:22
Top

Topic | Forum


#40
Re: Super Mario Bros, Virtual Boy
Posted on: 2014/10/22 13:52
VUE(xpert)
Joined 2010/2/15
Netherlands
250 Posts
Long Time User (10 Years)
I might not be an expert with the VB, but this screams "video editing" to me. Everything is too accurate, from the physics to the way it looks to the way it sounds. Especially the sound. I don't think you could make a VB sound exactly like the NES version, and this sounds exactly like the NES version.
Top

Topic | Forum