Wow, thanks for this news !! Really great :)
Just wait now for next releases, with other players and better game play ;)

DAMN them are some good graphics!! Who new that programming would evolve to involve both programming talent and artistic ability! Both of the very present in your game and I would literally bow to you if I met you! WELL DONE!!

Why do I have the strange feeling that Flavien released this game in January for a reason? Can anyone say "Game of the Year"?

He's got my vote!!!

mine too!!!

The graphics are great! But what I'm most impressed about is that the author wrote this game entirely in assembly! You don't see that too often anymore. Most games are written completely in C. Great job!

Yeah, Flavien Racine was the maker of many great 68k games in the days of DoorsOS, and still is. Bomberman68k, TurboBreakOut, the list goes on and on...

I never knew he was still a part of the TI programming community, though.

Just a small come back :)

Why Texas? Aren't you French?

I would guess it just refers to Texas Instruments.

Is it sad that that did not even occur to me?

Yes. Very sad. Now stop adding a question mark to the end of your posts.

Because Texas is the best state in the Union, and generally well known (or so we like to think) worldwide. Duh.

(of course this is all said tongue in cheek)

Texas is a pretty cool place. Ti, Dell, Motorola, Sun, and tons of other tech companies have headquarters there (most of those are in Austin, the weirdest city in the world)!

<<But even better, the entire game was written in pure assembly language>>

Why is that better? (other than the uncommoness about it) As far as I can see, writing in Assembly is pointless, open to more dangerous bugs, harder to write, harder to read, and impossible to port to another processor.

This isn't to say I'm not quite amazed by this game, and the fact that it was written in ASM. I think more people should try to write assembly games so they can realize how difficult it is, and it also helps people understand what's actually going on under that plastic casing. My hats off to the hardcore assemblers. And the game itself is awesome, it appeared in the archives just as I was searching for something to do during Econ last Friday.

<<As far as I can see, writing in Assembly is pointless, open to more dangerous bugs, harder to write, harder to read, and impossible to port to another processor.>>

The game would not be as optimized in speed, memory requirements and code size if it was written in C.

For the most part, that is true and I agree, but I believe the limitations of writing ASM outweigh the benefits.

Hopefully this thread won't sink into the depths of the BASIC vs ASM threads.

I've got three letters for you... WTF

Back in the day EVERYTHING was written in pure assembly. You didn't have TI-GCC to make people lazy. I'm not saying TI-GCC isn't great, because it is... but seriously, are you kidding?

I mean, maybe I'm showing my age, but writing in assembly wasn't too uncommon back when I was around...

Limitations of assembly? There are none. I don't think you honestly know what you're talking about. The only downside to assembly is it's tougher to learn, harder to read, and takes longer to code. Benefits? Speed and size. You decide what really matters. On calculators, it's the latter.

We used to have coding contests on ticalc.org (between programmers, not sponsered) to see who could get their programs to be the smallest and fastest. Whatever happened to great coding like that?

FlashZ has been coding in assembly 68k for a very long time (longer than in C). For him it isn't a limitation.

Well, so much for the no ASM vs C thread...

I always programmed in 68000 language, because this one is really powerfull, and VERY FUNY ! And when I started programming, TIGCC didn't exist.
And I just want to make 89 games, and 68k language is the best to optimize a lot of things. And this one is really EASY.
The only one of my games writtened in C was BallRace3D, a very very small project "aborted"... (and very bad code I suppose...)
I do not have time to spend to learn C language... I have also got a job in my life...

IMHO, both sides of the debate are lacking objectivity. Before I start: I have coded programs in both C and assembly, and I now choose whatever I believe to be more appropriate for the task (which is not necessarily always correct either, you can't always know everything in advance). I am also the current maintainer of the TIGCC port of GCC. While this might make me look biased towards C, it actually also makes me aware of the limitations of the compiler, and maintaining a compiler is a good way to improve assembly skills as well.

So here are the facts. First the obvious (but still forgotten way too often):
* Code generated by a compiler is (almost) never optimal. Assembly code generated by a compiler is only as good as the compiler generating it.
* Code generated by a human programmer is (almost) never optimal. Assembly code written by a human is only as good as the programmer writing it.

Now to the more serious (but also more debatable) ones:
* From experience, for the TI calculators at least, code hand-written by good assembly programmers is generally better than whatever GCC outputs. Beginners in assembly, however, tend to write code which is worse than what GCC can give you with appropriate flags.
* The gains obtained by using assembly directly also depend on the concrete piece of code. If you can use operations which don't have an equivalent in C, such as rotates or uses of the carry flag, assembly is always a win. But sometimes, you can also outsmart the compiler even with only basic instructions. (But of course, you'd better know what you are doing!)
* The quality of the code generated by GCC is improving over time. Both the GNU people and myself are hard at work trying to get better code out of GCC. And this means "better" both as in "faster" and as in "smaller" (though you often have to pick one, or to make compromises, the 2 goals often aren't compatible, unfortunately). The GCC 4.0 prereleases I've started to produce improve code quality a lot.

* Here, I (almost inadvertently) mentioned another important point: some code really needs to be fast more than small, for other code, it is the opposite. If you are coding in C, picking one for a chunk of code is as easy as picking a compiler switch. If you are hand-writing your assembly, you need to learn different optimization techniques depending on what you want to optimize for. If you want to be able to choose according to the situation, you need to master both. Even excellent assembly programmers tend to specialize in one type of optimization. For example, Patrick Pélissier is known for being much more into speed optimization than into size optimization. Speaking for myself (though it is up to you to judge whether I'm worthy of the label of "excellent assembly programmer"), my specialty is size optimization. A good compiler such as recent GCC knows how to do both. (Older GCC releases admittedly weren't that good at size optimization. But there has been work done within the GCC project to improve that which has shown its fruits, and I also added a few minor patches to improve it.)
* While small programs can be written in assembly pretty quickly, huge programs tend to quickly become pretty time-consuming to maintain, because of: 1. Debugging time: issues like typos in register names can be a pain in the neck to debug. 2. Comments: this definitely varies from programmer to programmer, but I tend to get lost pretty quickly in huge portions of uncommented assembly, whereas I can do just fine with few to no comments in C. And writing comments takes time.

>For example, Patrick Pélissier is known for being much more into speed optimization than into size optimization.

Maybe. But I am still better than you on size optimization :p

So, to sum up, using assembly is a good idea if you want optimal code (under whatever measure of optimality), and have sufficient knowledge to actually write optimized code (for the measure of optimality which is needed for the program). Using C is a good idea if you aren't that skilled in assembly, or if you want to save time programming. Good-quality assembly is better than good-quality C, but also harder to write. And I definitely prefer good-quality C to low-quality (buggy and unoptimized) assembly.

Well said, Kevin and elbarto. Took the words right out of my mouth.

I'd also like to add that assembly programming gives you the greatest control over program throughput. That is a must-have in any time-critical application (ie: sound and linking progs) where a microsecond or two could make all the difference.

Like elbarto said, it all gonna translate into machine code in the end--whether ASM or C++. Optimized ASM means smaller code. Smaller code means fewer wasted Tstates. Fewer Tstates equals a more powerful program. Limitations of assembly language? Hogwash! If anything, it's the *ultimate* language.

Be warned that there is a difference between small code and fast code though. In some cases, it can be a very big one. That's why GCC has different optimization switches for different needs (-Os, -O2, -O3).

It depends on the exact situation...sometimes you can optimize for maximum speed and minimum size at the same time. It's nice to be able to choose between optimizations in assembly, though, so that code that only gets called a few times can be small, and the high-frequency stuff can be fast.

Gah.. you typed that all over the span of 2-3 minutes!!! That's FAST!!!

Or rather he posted it in that amount of time!

He probably typed it in a text editor and pasted & posted in 2-3 minutes. That's what I do in my "treatises".

I typed it over a few minutes, and wanted to post it as a single message, but it was exceeding the maximum size by a lot, so I had to split it. ;-)

Just like the calc file size limit.

P.S. Can someone PLEASE answer my ASM->PPG on ti-89 question? All other compressions that I've tried are glitchy, and nonexecutable. An email, a comment, a link in either, anything, anyone, anykey! (sorry, couldn't resist puting that in there)
}:O>
Help please?

I know nothing about compression. Sorry.

Oh, well. *sigh*

Then why respond?

A. I snuck his name in there as a joke, and
B. Confusion loves sympathy.
BTW, That problem has been resolved.