Page 3 of 7
Posted: Mon Oct 18, 2004 9:58 pm
by MarauderIIC
...offscreen...bad...
You're drawing at a nonexistant coordinate, probably, like you were with the blood. Make it so it just doesn't draw the player anymore if you want to make them go offscreen (but still keep track of the coords).
As for the bullets, no way I'm wading through your two screens of source on the forum to even localize the problem :P
Posted: Tue Oct 19, 2004 8:56 am
by Falco Girgis
Whoops, I forgot to tell JSL how much I liked his tile collision. I can't stand it when people bitch about things and forget to say the good points. I liked all of it. It's very ineteresting and it's safe to say that the collisions for that were REALLY nice. Good lord, I'd of never thought of that.
Can I ask one thing of you though, JSL? I noticed that our main game loop (t3h while(1)) was getting really big. I don't know if you didn't do it because it just isn't your style or because there wasn't a point with such a small source, but can we split lots of that into functions, then just call them from the main loop? Like maybe a DrawTiles() and a GetInput() that is called in the main loop. I don't know, I just prefer things simple there.
You can divide the source into multiple files with Dev-C++, right? When I work on big things (which this is undoubtedly going to be) I find myself splitting it into 5, even 10 different .cpp files that I include at the very beginning of the first one.
One last thing. In the player class, I noticed the variables had m_ in front of them. Like m_xvel and stuff. Is that just a habit? Is there a certain thing that m_ stands for? Same with the f_ on like f_Down.
Posted: Tue Oct 19, 2004 8:57 am
by Falco Girgis
MarauderIIC wrote:...offscreen...bad...
You're drawing at a nonexistant coordinate, probably, like you were with the blood. Make it so it just doesn't draw the player anymore if you want to make them go offscreen (but still keep track of the coords).
As for the bullets, no way I'm wading through your two screens of source on the forum to even localize the problem :P
Yeah, I'll look at the guy going offscreen. As for the bullets, I separated it into 2 small functions: UpdateBullets() and Shoot(). But don't worry, I think I can fix.
Posted: Tue Oct 19, 2004 2:47 pm
by Falco Girgis
Today, whilest sitting at home rotting, I worked a little more on the Tile thing. I just fixed the truely pathetic gun stuff that was in the previous one, and I added some of FredDibnah's kick ass music along with sfx.
You can download it with source from here:
http://thechaosrift.com/pc/sdl/Tile.zip
Posted: Tue Oct 19, 2004 4:24 pm
by JS Lemming
The player going off the screen wasn't a glitch. I simply haven't implemented that because I'm decideing on a system for storing the map data. I'm makeing a 2Darray class right now, that I think we should use throughout the game. Once completed, I will update the movement function.
Super Sonic, yeah I usually put everything in a function and have a super small main loop (makes it easier for menu systems) but I didn't in this demo because I thought it would be a little easier to learn by only having to read from top to bottom without skipping all through the code, but I probably won't do that again.
Also, I noticed you like to put all the functions at the bottom of the page and init. them at the top. Is that your prefered preference? I will switch to that method now because it is easier to simply glance at the init. to see what the paramaters are. Good call.
One more thing. I vote that we do NOT use anything from the Standard Template Library (STL) because of what I read in my massive book.
Teh Data Structures Book Yo wrote:Unfortunately, every version of STL is different in its own way, and this can cause problems. The STL implemetation that comes with Microsoft Visual C++ 6 is generally considered by most to be a slow and incomplete version (it was Microsoft's first try, after all) of the STL.
That probably explains all your blood problems SS.
I say we just make very flexible class implementations instead. Like the array class i'm working on.
Whooops, almost forgot. About the m_ thing. I find it easier to put that on all member variables of a class (m = member)... it just helps me out.
Posted: Tue Oct 19, 2004 7:40 pm
by Falco Girgis
When JSL ran my additions to his Tile Collision, he brought up a good point. He said that the midi background song was terribly quiet whereas the wave bullet sound was really loud. At first, I dismissed the problem because I wasn't having it. We have 5 computers in the house. It ran perfectly on every one of them, but for some reason, our '98 Sony Viao had the same problem. It didn't seem to have any patern with what year the computer was. (My two brothers both have old computers, then my and my dad's computers are new, so the vaio is in the middle). I have no clue what can be causing it.
Is it possible that some sound cards just play midis at different volumes than waves? What should we do?
My friends didn't have that problem either. That's only like 1 in every 8 computers that does that.
Posted: Tue Oct 19, 2004 8:17 pm
by Guest
JS LEMMING wrote:Also, I noticed you like to put all the functions at the bottom of the page and init. them at the top. Is that your prefered preference? I will switch to that method now because it is easier to simply glance at the init. to see what the paramaters are. Good call.
No offence, but thank god! I'm sorry, but functions above the main loop scare me. x.x
Anyway, I have been reading your demo's and stuff, and whats up with the brackets. Some of you do it one way, and some of you do it another way. I dunno, I don't use C++, but will that confuse anyone when working on nestix? o.o
Posted: Wed Oct 20, 2004 4:59 am
by Falco Girgis
Not at all. JSL does it like this:
and I do it like this:
You should be able to read and understand both ways. There really is no point of trying to standardize it because we both prefer different ways and understand them equally well. They're both correct and will both be used. Hey, you'll be able to see what was written by me and what was written by JSL.
Posted: Wed Oct 20, 2004 4:31 pm
by JS Lemming
About the storage of level data...
What do you guys think? Should we store level data in ASCII mode or actuall bytes? See, I can do both in blitz, but I don't know how to read certain bytes of a file in C++.
So far, the data each level file will hold is:
- tileset file
- event list file
- background file
- music file
- width of map
- height of map
- actual map data
Posted: Wed Oct 20, 2004 4:58 pm
by Falco Girgis
Wow, storing a map in "ASCII or Bytes". That's completely new to me. Are you meaning like storing it in just a .txt file or.. uhmmm.. bytes?
What're the advantages and disadvantages? Ouch, I wish I could be more helpful here, but I've never really worked with tiled levels and all.
So please, elaborate on both
Posted: Wed Oct 20, 2004 9:05 pm
by JS Lemming
Alright. What I mean by ascii mode is storing the data in the form of text. An example output file might be like.
mario.png
mariolist.evt
mariobg.png
mariosong.mid
80
15
00000000000000000000000000000000000000000000000000000000000
00012428600000000000000000000000044600000000000000000000000
0000000SDFF00000000000000000DSF000000000000000000000000000DF
(you get the picture)
In the load level function, the computer just reads in the text and in the case of the actuall level data, reads in like 2 chars at a time and converts them to the respected number for the tile. The draw back to ascii mode is that the size of the file is double that of a byte type deal. And people can open it up and screw with it (possibly corrupt it).
In the byte like mode, the data is stored in bytes. Meaning if you tried to open it in notepad, it would look like strange garbage and random blocks. The size is smaller then ascii mode and less likely to be tampered with.
Posted: Wed Oct 20, 2004 9:14 pm
by JS Lemming
Here is a demo use of my Array2D.h thingamajig. If you haven't already, get the file from the nestix file center.
Code: Select all
// Name: 2D Array Class Demo
// By: JS Lemming
// Version: 1.0
// Date: 10/20/04
#include <stdio.h>
#include <iostream.h>
//this file is required!!!
#include "Array2D.h"
int main(int argc, char *argv[])
{
//create a test array holding int type data
Array2D<int> TestArray(20,20);
//init some vars for use with loop
int x, y;
//clear the array with 0
TestArray.Clear(0);
//set cell(5,5) with 7
TestArray.Get(5,5) = 7;
//print out the size, width, and hieght of the array
cout << "Total Size: " << TestArray.Size() << "\n";
cout << "Width: " << TestArray.Width() << "\n";
cout << "Height: " << TestArray.Height() << "\n";
//print out a chunk of the array
for(y=0; y<20; y++)
{
for(x=0; x<20; x++)
{
cout << TestArray.Get(x,y);
}
cout << "\n";
}
//this just keeps the program from closing to fast
cin >> x;
return 0;
}
Posted: Wed Oct 20, 2004 9:53 pm
by Falco Girgis
Okay, as for bytes vs. ASCII, I'd have to say:
BYTES!!!111oneone
I know how you'd write to text files, but how the hell do you read and write bytes?
Next, your header is awesome. GREAT job on it.
I have a question though. I've seen things like this:
Code: Select all
#ifndef ARRAY2D_H
#define ARRAY2D_H
from time to time. I've never really known what they meant. Do you mind telling me real quick so that I won't have to bust out the C++ book?
Also, I promise that I'll finish the blood engine. I'm changing back to linked lists and I'm almost positive that using double bufferage will fix the problem. Leave that to me. I would do it tonight, but I've missed 2 days of school and have lots of make-up work.
Posted: Thu Oct 21, 2004 7:38 am
by JS Lemming
When ever you make includeable header file things, you're "supposed" to have that definition at the begining and the end the def at the end of the header file.
My book tells me to do that and I haven't seen what happens when you don't. I'm not possitive what it really does though.
About the blood engine. Buffering does not fix anything but flickerage.[/quote]
Posted: Thu Oct 21, 2004 8:57 am
by Tvspelsfreak
let's say we have a file called "header.h" which contains:
Code: Select all
#ifndef _HEADER_H_
#define _HEADER_H_
// Some code
#endif
This itself means "if _HEADER_H_ isn't defined run all the code below until you hit a #endif which ends this statement". In other words is an regular if statement done with preprocessor code.
The good part about this is...
You can include this file as many times as you want without getting a compile error.
Code: Select all
#include "header.h"
#include "header.h"
Normally you'd get an error like "function previously defined here" or something. But since _HEADER_H_ gets defined the first time it'll skip that part the second time.