If this project is anywhere close to as neat as the screenshots, I'd bet a lot of awesome new games for the 68k calcs will follow.

I hope it is

What a nice project, i hope it be soon release!

On the subject of "Stunts", does anyone know the key combination to quit it? I can't on my PC for some unknown reason...
4D Stunt Driver was better :)
On the subject of 3D Engines, does anybody know what I should do with mine? (Click 'web page' link above). I was thinking a sort of 3D Paintballing game - but the engine's a bit slow for that (maybe with some optimisations I could get it to go faster).

Wow... those are nice graphics on your engine. It's funny, one day, I was thinking of how a golf engine (similar to that) would work. I had a basic idea, but I'm probably to lazy to try it.

Hmm. Any ideas of what to *do* with those "nice graphics"?

Did you make a game out of it already, or do you just have the 3d engine?

There's sort of a game built around it - what you see in the demo is a 3D golf game, with fairways, the green, a flag, and sprite-based 3D rendering providing the trees and bushes dotted around the course. You can hit the ball with a selection of clubs. What it will be is each level has a 'best round' stored in it - see how quickly you can complete each course! Someone gave the idea of switching to a 'top-down' view when the ball lands on the green, for accurate putting. I'll try that!

This sounds really great... I'll be looking forward to it when the game nears completion!

How do you handle the way you hit the ball? (how straight the ball goes, how much power goes into the swing... etc)

It works like an old DOS PC game I had- with a bit extra!
You select the angle by pressing left/right. This rotates the entire 3D world around your ball!
You select the strength by pressing and holding '2nd'. The swing increases in strength (indicated by a pointer rising up on the right hand side of the display). When you release it, this pointer falls and the ball moves with it.
You can also press the 'Up' and 'Down' buttons to 'zoom in and out' on your ball. This allows you to see more (or less) of the course.
Alpha toggles between a number of clubs - Driver (powerful, medium-height shot), Iron (less powerful, medium-height shot), Pitching wedge (lots of height, very little distance) and Putter (shortish along the ground shots). I'm no golfer (in the real sense) but I thought a Golf game might be quite fun.
I've added 'green detection' - so the calc knows when the ball is on the green - and plan to add the top-down view also. I will probably add 'wind' effects to the game too.

Wow!!!! All that stuff in z80? That's really great! I always thought a golfing game for TI would be fun (if it was good, like yours). I'm really looking forward to this coming out!

*I like z80* :)
Well, I'm currently working on another game with someone (for the time being) that will probably be more.. successful. But shhh, it's a secret as to what it will be!

Okay :)

I like z80 too, but I'm just not very good at coding with it. I guess I'd get better with practice, that is, if I DID practice...

I have an idea... How about Warzone or Warzone 2, 2 java games at javagameplay.com? They're pretty sweet 3d games, but not too advanced. I think 68k calcs could handle them, especially the original version.

P.S.
I am new here...

Since we don't have a lot of 3D games for the calcultors now, it would be nice to see a variety of them. I think we've worn out all the TRON varieties by now ;-)

It would be nice to see a 3D game for the 86, after all the 86 does have better resolution than the 83 series.

Morgan, since you're such an ASM prog and an 86-phile, why don't you go port Gemini? ;o)

I've actually been working on a 3D game for the TI-86 for quite a while now. It's a helicopter game (AH-64 Apache). It'll have conservative graphics (mostly wireframe, small blobs/dots for ground objects, and some sprites for the cockpit), but the physics simulation will be, I hope, very impressive.

The physics simulation is probably also the sticking point of my project, because I need to do more "research" (playing an Apache simulation) before I can implement a good working version of the physics engine. (I'm also constrained by limitations of the platform, like the 8-bit word size, small amounts of memory, etc., but that's a different problem in itself)

I should probably release the source so I can get help from anyone who is interested in it.

BTW, I've stated some time ago that I'll release it under the GNU GPL, but now I don't think that will be feasible, as I need to use code written by other people; I can't get permission from everyone whose code I will use. (I have nothing against the GPL; I just can't use it in this case. I will use it for other programs and/or function sets, though)

That sounds very cool. I take it your "research" will be very extensive. :-) Anyway, I hope the program turns out as great as I imagine it.

Good luck on your research into a physics engine. I applaud all who know how to make one that are close to real life.

My physics engine actually won't be real-life; I'll make some shortcuts to simplify the engine, but I'll try to make it as real-life as I can. For example, I won't deal directly with forces and masses. Forces and masses are usually large and the magnitudes cancel each other out (remember F=m*a from physics? a=F/m, which is a large number divided by another large number, resulting in a small number). Besides, I need to avoid division wherever possible, since division is slower even than multiplication. Therefore, I will use accelerations directly; this will also allow me to use more constants for various accelerations that I get from my research.

WARNING: The following is just my venting (letting off steam). You don't need to read it if you don't want to.

This is a really complicated program, since I need to test the 3D graphics by "flying" around, but I have to test the physics (needed for "flying") by watching the graphics. Hmmmm... sticky situation.

I think I can solve this by writing a stub physics module, one that moves the helicopter directly by pressing the keys instead of dealing with forces, accelerations, and velocities. This will allow me to focus on the graphics and then focus on the physics once I know the graphics work well.

Another problem I have is strange behavior I've noticed in the Apache game I'm using for research. I don't know if I should copy it closely or just find a simpler, cleaner solution. Maybe I'm just stressing myself on all of these details too much.
</rant>

Well, that's all for now.

"I am a man,
but I can change
if I have to
I guess."
-- The man's prayer, Red Green Show

Well it is pretty much impossible to make a real life engine for these calcs, but anything that properly does the basics is good enough. Good luck on your progress.

I know it's mostly impossible, as I've really learned after figuring out two equations (on my TI-92+, of course) for finding the helicopter's new orientation based on its current orientation. Although I haven't taken every variable I need to into account, they're quite long (several multiplications, additions, a square root, and some sines/cosines).

I don't need to use long equations like that for my game. The calculations it makes now are accurate enough when the aircraft's pitch is close to zero (almost level, which is most of the time), but they become very inaccurate as the pitch increases (e.g., in a vertical loop).

I could limit the helicopter's pitch to a reasonable range which would ensure the calculations are relatively accurate (say, 90% or more). I think arcade simulations do this too, though probably not for the same reason. The limit would mean the pilot cannot do any fancy flying, but it would be a little easier to fly. Does anyone oppose this idea?

If your using trig based physics there shouldn't be too much of a problem. I can help you out with equations and such if you need it. Right now I'm trying to figure out the mathmatics/physics of a trebuchet (Medieval catapult) and I've achived about 98% accuracy w/o friction.

Yeah, I'm using trig for physics (trig and physics are just two of my favorite subjects, among other sciences). Thanks for offering me help, but I don't think I'll need help with the math; I've already figured out most of the equations I need for spherical trigonometry and such (and I haven't even taken any spherical trig. classes in school ;-).

What I need help with most is writing and testing it. I think the math will be the most difficult part, because I'm using fixed-point (as opposed to floating-point) numbers, and it can be easy to forget how to handle the result of a math operation (e.g., shift right or left and by how much).

Also, I need to figure out how to write lean and mean code so it gets a decent framerate (at least 8, preferably 12-15), but the code (physics engine) won't care about the framerate because it uses a time variable which is incremented once per interrupt, and I have a small routine to find the time that has elapsed since it was last called (used for dt, or change in time), and the physics math is based on dt.

BTW, are you trying to write a Medieval game that uses catapults or something? :-)

Actually no, i'm not writing a game, I am just extremely curious. I plan on building one but to get the most effecient design I need to optimise each variable. I've found stuff online that will give me results but not the actual equations. I've tried to get help from some of the top math teachers at school but they couldn't offer any assistance.

I've always been unclear on what floating point numbers are. Can yougive me an example? Also if you want a game with a fps rate that high you definitely need to sample time and preform the calculations at least a tenth of a second or faster or you will get funky results. BTW I'll be tester if you want, and I can also help you with writing the math code.

Floating point numbers are just the way computer processors represent real numbers. Basically, they're stored in scientific notation with a mantissa and an exponent. They're usually stored such that the number it represents is (mantissa * 2^exponent). Mantissa m is 0.5 <= m < 1.0.

This is the best I can explain it.