sweeet!!! Wish that there was something like this for the z80 calcs. Too hard in BASIC, though.

Who knows? Everything is possible. ;)

not that.

Pinball for the Z80 calcs is not possible? Why?

I made it in BASIC, and it worked, but I didn't upload it for three reasons:

1. It was way too slow; by the time it calced the gravity, accel, etc, it was about a frame per second.

2. With the screen size, you couldn't fit a decent table in.

3. Detection of extra obstacles and scoring made it even slower.

Of course, BASIC is just not appropriate for making fast-paced arcade games. Fortunately we have assembly to work with...

Gaa...WiFi going at 439 bytes per second...

Yeah. except that my ASM knowledge isn't good enough to do smething like this...

I think programming a pinball game would be hard... with all the angles and stuff. My problem would be getting the gravity and stuff to fit in with all of that.

Actually, gravity is so simple to implement, it is usually overlooked. I was able to get gravity (including unstable gravity) with only 6 variables, and not a single trig function!

All you need are:

>>the ball's x and y coordinates (I call them ballx and bally)

>>the ball's x and y vectors (I call them ballmovex and ballmovey; their values are added to ballx and bally to make it move). These are implemented exactly like they are in simple bouncing-ball type programs and in break-out games.

>>the x and y magnitude shift variables (I call them moveshiftx and moveshifty). You only need moveshifty for normal gravity. It is added to ballmovey, and does not change unless you want to change the strength of the gravity.

In the program, the moveshifty variable is set to 0.25, which, when added to the ballmovey vector, increases its value. Because moveshifty is added to ballmovey, the y-value for the ball constantly increases. This may seem odd if you try to plot the results, but remember: The greater the y variable in TIGCC, the lower the corrosponding object is on the screen. This means that I slowly increase the ball's y trajectory downward. When a ball hits an object, it's ballmovey vector is set to some negative number, causing it to move upward.

As you can see from this method, bally will decrease at a slower and slower rate, until it stops, and increases again. This is reflected in the ball as it moves upwards at a slower and slower rate, until falling back down faster.

That's gravity in a nutshell, but I also created a limit as to how big ballmovey could get before it stopped increasing (to prevent the ball from accelerating too fast for the user to handle), and I also slowly decrease the absolute value of the ballmovex variable to make the ball's movements seem move parabolic than hyperbolic.

I don't see why the X velocity should be adjusted. You can't have that much air resistance on a pinball table. :)

Unfortunately your source is not really commented. I'd have been curious to know what algorithm you use to detect collisions (I see the ball occasionally colliding into air) and calculate the new velocity upon collision.

The unstable gravity is based on mofifying the x velocity. The unstable gravity simply causes the ball to be repelled from the sides of the table.

I know that the ball does not quite always collide with the flipper at times...but the alternative is the ball moving though the flipper. I used a modified of the point-line distance formula to get the ball to effectively bounce off of angled surfaces. If m is the slope of a line, x1 and y1 are the cooridnates of the ball, and b is its y-intercept, then the equation is this:

distance = abs(-mx1 + y1 - b)/sqrt((-m)^2+1)

This comes from the original formula:

distance = abs(ax1 + by1 + c)/sqrt(a^2+b^2)

where a, b, and c are coefficients in a standard linear equation.

Because y increases as the object moves downward, I must subtract the c value instead of adding it. So the actual formula is

distance = abs(ax1 + by1 - c)/sqrt(a^2+b^2)

Also because I am using a y-int equation form, a = -m, b = 1, and c = the y-int.

You are using floating point numbers??? You may be able to get better performance if you were to make everything Fixed Point. -Just a thought-.

Yeah, double might work a little faster. :)

but fixed point i.e. int, unsigned it would work even faster still!

I thought that a double was an int, just with one digit moved over to the right, forcing it to only have one decimal
Um... you know, actually, you're right, I can see why int would be faster.

Double is just doubled float.

That seems to be a lot of extra work for me. I simply check the pixels on the screen, that's much faster. See link.

Forgot to add something: see link.

That's a really cool machine!

How's the project coming?

Do you know how to detect pixles in C?

Sorry, I'm not familiar with TIGCC. But as I said in the post below, you might be better off using a simple dot product instead of this expensive formula to detect zero distance.

Uh, isn't it just GetPix()? (see the documentation for all the detailed stuff)

Also, the other pinball game looks nice too.

Oh, and since I'm having a brain screw, does anybody know how to find the length of an array (particularly a string)? Sorry, JcN, either I forgot, or I never used something like that.

In Javascript, I think it's like arrayname.length;

For an array, just use the sizeof() function, and divide it by two...I think. At least, that works for int and short arrays. When I do it for a string, I get the size of the string's address (4).

Oh... I see what you mean. Hmm... could you treat the string as an array somehow to get the length of the array, which would be the length of the string?

I dunno. Whenever I type in this:

char *string = "hello";
short size = sizeof(string);

the size is always 4, and I get a warning saying that the assignment discards qualifiers from pointer target type.

When I use this:

char *string = "hello";
short size = sizeof(*string);

the size is always 1, and I get the same warning.

Weird, isn't it? Does anyone know why this is happenning?

It is happening because you do not understand what pointers are. Char* is not a string, it is a pointer to one or more characters. The size of a pointer is 4 bytes. Thus, sizeof(char*) will always equal 4. I'm not familiar with the tigcc lib, but if there is a strlen() function, that will tell you the length of the string. The basic idea is to loop through each byte of the string while incrementing a count until you find a zero value; the length of the string is the count.

<feeling stupid>
Yeah, there's a strlen() and a *strlen() function. I feel kind dumb right now, so I'm shutting up
</feeling stupid>

BTW If you need to check for zero distance only, you should use dot product instead. And that could be done with using integers only (no sqrt needed).

Wait a minute... This game is using distance calculations for collision detection? Why??? Just use the sprite collision functions in the Extgraph library! It's fast, accurate, and easy!

I don't have an ExtGraph library...can anyone tell me where to get one?

(To above) I'm not calculating 0 distance, I'm calculating proximity (as in, within a certain # of pixels), so pixel multiplication won't work...

What's wrong with using float point? And what the heck is fixed point math?

I said dot product, not "pixel multiplication". If you don't know what it is, how can you say it wouldn't work? Anyway, you could also calculate the square of the distance just to get rid of the sqrt to gain speed.

Floating point numbers are bad, because they are slow to calculate with. Fixed point means that you are using integers, but the lower part of the number is used as fractional part, thus "simulating" floating point.

Sorry about that confusion...I was tired when I responded, so I interpreted "dot" to "pixel" and "production" to "multiplication" (I accidently assumed your usage implied multiplication). How does dot production work?

I think I'd be better off using float point for now because the program would run significantly faster than it does now...and it's already running fast enough. Actually, when I sent the program to my beta testers, their first statement was that it was too fast to be effectively played...so the manipulation of float point variables acts as a natural "delay".

Is there a place where I can download your z80 pinball game? It looks more enticing by the minute *drool*

Sorry, the test versions aren't public, only for the confirmed tester team. However, I have just enough people in that position, so you'll have to wait for the final.

Well, I am looking forward to the release. BTW, are you going to finnish Death Rally?

I am. Question is when. :)

Well, I'll be looking forward to that also. :)

To get the Extgraph Library, go to http://tict.ticalc.org/ ,look for Extgraph 1.02 (it's a few items down), and get it. All the dox for it are included in the zip. About floating point vs fixed point numbers: Fixed point numbers are much, much faster. If you are worried about your game being too fast, make the ball move fewer pixels each frame. (i.e. if you get twice the fps as before, change it so the ball goes half as far as usual per frame.) This will help with collision detection and will make your game look much smoother.

Um... I don't know the answers to the first question, but concerning floats and stuff:

Floating numbers just work really slowly in C compared to integers. Fixed point math, to the best of my understanding, is when they have a certain amount of digits _after_ the decimal point. So 5.312 would end up being 5.3, if the type was 'double', I guess. The only advantage I see to that would be increasing speed and making the game run more smoothly. But of course, this also brings down the accuracy of the coordinates of the ball. The more digits, the more accuracy.
If everything I said was wrong or didn't make sense... it's because I'm half asleep.

For the last fucking time, 'double' is just 'float' with 2 times the accuracy. For example, if float had 3 decimal places, double has 6 places.

Wouldn't it be possible to just have 1 variable which moves X and Y. It would range from 0 to 359 (angles), and you would just use tangent to figure out how much to add to the X and Y variables. This would allow for more precise angles than just 8, and it would save a little bit of memory.
I'll see if I can make an engine for it then release it.

Um...no. This algrithm can create infinite trajectories, and I don't have to deal with look-up tables. Think about it: five short-type variables vs. a huge short-type array, plus the five movement variables described above.

Array?? No, this would just be a unsigned short int ranging from 0 to 359 AS IT'S VALUE, NOT AN ARRAY. You would use tangent of the variable to figure out how much to move the X and the Y position of the ball.

I see where you're going, but that wouldn't work very well because trig functions (especially in C) are pretty slow; slow enough that I would need to use a look-up table, which is an array. Also, how do you simulate gravity movement by changing it's angular trajectory? Are you saying I should use something like this? (see below)

void moveball(short *ballx, short *bally, short *angle)
{
int change;
if(*angle < 270) change = 1;
else change = -1;
*angle+=change;
foat movey=sin(*angle),movex=cos(*angle);
Sprite8(*ballx, *bally, 8, ball, LCD_MEM, SPRT_XOR);
*ballx+=movex;
*bally+=movey;
Sprite8(*ballx, *bally, 8, ball, LCD_MEM, SPRT_XOR);
}

instead of

void moveball(short *x, short *y, short *movex, short *movey, short *gravity) {

Sprite8(*x, *y, 8, ball, LCD_MEM, SPRT_XOR);
*x+=*movex;
*y+=*movey;
*y+=*gravity;
Sprite8(*x, *y, 8, ball, LCD_MEM, SPRT_XOR);

}

The first function would be pretty slow, and I don't think the gravity-altered trajectory would be very accurate. My function (second function) seems to be faster (even though that is not the whole function above). I'll try it out, though.

Sorry, I forgot how slow trig functions were in C. But what I was thinking was more along the lines of...

*ballx+=cos(*angle);
*bally+=sin(*angle);

Just to save you the ballmovy and the ballmovx

Your idea would work, though, but the curve of the ball wouldn't be parabolic...the trajectory would resemble the contour of half a circle. That's fine, I guess, but it doesn't give me much gravity flexibility nor trajectory flexability.

I see what you mean about gravity, but I never thought they had much of it in Pinball games because the ball has so much momentum(sp?) and weight that it didn't really matter. You still could add on a gravity variable to my thing.

I think that I see a major flaw here. Velocity is a vector, and vectors designate both direction and magnitude. For polar coordinates, you would need both direction AND speed. Or I suppose that you could always have the ball moving the same speed, but what kind of a pinball game would that be? So… you are stuck with two values anyways. I have used polar coordinates in some computer programs that I hacked together, but they are far less efficient than rectangular coordinates considering that they have to be converted to rectangular coords in order to be added. (which would be required for gravity.) Don’t they teach this stuff in your ordinary trig class?

Not really...I had both Geometry and Trigonometry in the same year by the same teacher in the same period (the classes and the curriculum were accelerated). I did, however, ask my teacher how to use polar math to calculate a vector based on the radius of a circle and the angle measurement formed from the x axis (or the circle's horizontal axis) and the radius. This algrithm, however, is best used in games that require some sort of rotation (i.e. asteroid clones), not to simulate gravity. I don't see why you need to convert polar values to rectangular values, though. From the angle and the radius length, you can easily calculate a vector. The direction is computed from the center of the circle at (h,k) and the point on the circle where the radius intersects the curve (cos(angle)+h, sin(angle)+k). The magnitude equals the length of the radius.

In programming, you can get an object to move via this sort of vector by adding radius*cos(angle)to the x coordinate (x=h) and radius*sin(angle) to the y coordinate (y=k).

Hmm… I use a math curriculum that sort of blends everything together. (It diffidently does make sense to learn geometry with trig.) … So I don’t quite know what is standard. (I reviewed integration by partial fractions while preparing for a standardized test that only covered first semester Calculus!)

When I mentioned the need to convert from polar to rectangular, I was pointing out the fact that, as you said, polar notation does not work as well in a simulation that requires a large about of vector addition. But then again, maybe polar would make collision response easier. On the other hand, gravity is added much more often than collision is handled. Oh! I don’t know! I have never tried programming pinball before. My point was that polar coordinates would not decrease the amount of variables needed to represent velocity.

Your game looks great, by the way. It kind of makes my wish that I hade a 68k calc.

Look-up tables can be extremely fast. I saw a great idea on a programming site (can't remember where) that had something where you got all the fixed-point number into an array of 360 numbers (one for each integer degree angle) by using the actual sin, cos, etc. functions... then, you call from the array to get your sin/cos/tan instead of using the slow sin() and cos() functions. It sounds like a great idea to me... and the speed would increase SO much.

I have even seen that done in computer games!

I can't remember where I saw it, but I think it was a C (for computer, not calc) programming site. I liked the idea. :)

I think that I first saw it on nehe.gamedev.net.

CoBB has been working on a z80 game for quite some time... see URL

http://www.joepnet.com/
cgi-bin/ib3/ikonboard.cgi?
s=759ac984cdb64c60b16c2697
69907718;act=ST;f=8;t=354;
st=0

I'm making a text pinball for the 83+ in B.A.S.I.C.
Just need a good physics routine for gravity and bumpers

See my comment above

B.A.S.I.C. is too slow, and I doubt you could get a good pinball game made in BASIC.

Though, JcN has also made a BASIC pinball game, if I'm not mistaken...

...which was exceptionally crappy.

I did, however, make a prototype of this program for the TI-83+ SE, but it is incomplete.

Ah, for BASIC, it wasn't that bad. :) But, it doesn't compare to this at all.

Not really, I've played a Pinball game programmed in TI-83+ Basic befor, look in either 83/83+ basic games or basic (misc.) programs, It's there, I can almost garrentee it, although, It looks like CRAP!(its the speed, graphics are fine, for an 83)