Just saying, F-Zero all the way people! For those of you that have played it on the Gameboy advanced, you know it's amazing and the replication is great!

You're right, it's really a great game!

Except it's very memory-hungry (to the point where you can hardly fit anything else on the calculator if you have it - it could be a lot smaller if the tile format was size-optimized), the menu/GUI system is awful (ever tried "entering" a name for a highscore? You can't use the letter keys! You have to select the letters as with a cursor + 2 keys gamepad, which is completely inappropriate for the calculator's keyboard), and the structuring of the program is ridiculous (almost all the code is in interrupt handlers, which is also why he never got USB linking to work). And he won't let anyone fix his mess.

I voted for MulTI. Much higher technical accomplishment, and it's GPL so anyone can improve it.

As usual, you are bashing this program because it goes against your size optimization obsession.

F-Zero is designed with speed in mind, that's why he had to use his tile format and that's why it's memory hungry.

You criticize the program's structure, but when he asked you if there were other ways to avoid wasting cpu power with a waiting loop and still have a constant game speed, you gave no solutions. I am led to conclude that having a big interrupt handler is the only way to do what he does.

Also, F-Zero is not only a big technical achievement, it's also on of the most complete game there is for the 68k.

<< F-Zero is designed with speed in mind, that's why he had to use his tile format and that's why it's memory hungry. >>

He could have used a more compact format, but he wasn't willing to due to his speed optimization obsession.

<< You criticize the program's structure, but when he asked you if there were other ways to avoid wasting cpu power with a waiting loop and still have a constant game speed, you gave no solutions. I am led to conclude that having a big interrupt handler is the only way to do what he does. >>

He could have both achieved synchronization in a clean way and saved a lot of battery power by simply putting the calculator into low-power mode until an interrupt happens (which can be detected with a simple flag or counter, i.e. minimal code within the interrupt handler). (And I told him that multiple times.) But instead, he designed for speed at all costs, not caring about not eating all the memory nor about not consuming batteries needlessly.

And again, this structure is also why he couldn't get USB linking to work, so it's not just a theoretical problem.

As for the crappy way to input letters, there is no excuse and in fact you gave none.

Yes, the input method is indeed bad.

PS: The reason his code structure is wasting batteries for nothing is simple: it's pointless to compute more frames than you're ever going to display or the other way round.

>>Except it's very memory-hungry (to the point where you can hardly fit anything else on the calculator if you have it - it could be a lot smaller if the tile format was size-optimized)
I made the best compromise speed/size to get enough fps for the game to be playable (I didn't want to make a 60k game with 3 fps :p)

>>the menu/GUI system is awful (ever tried "entering" a name for a highscore? You can't use the letter keys! You have to select the letters as with a cursor + 2 keys gamepad, which is completely inappropriate for the calculator's keyboard)
It was easier to code (I admit it was because of laziness but it's not like if we have to input letters all along the game, you have to input your name once at the beginning and it is memorized when you set a highscore) (ok it is bad)

>>and the structuring of the program is ridiculous (almost all the code is in interrupt handlers, which is also why he never got USB linking to work). And he won't let anyone fix his mess.
I released the source code and I said it is possible to try to fix the problem if you ask me, so don't tell things which are wrong please :)

>>I voted for MulTI. Much higher technical accomplishment, and it's GPL so anyone can improve it.
good for you, you didn't vote for a program you don't like (or is it just because it is not compliant with your size standards, have you ever played a game for pleasure without taking care of its size or the way it is coded?) \o/

>>As usual, you are bashing this program because it goes against your size optimization obsession.
>>F-Zero is designed with speed in mind, that's why he had to use his tile format and that's why it's memory hungry.
that is exactly true :)

>>You criticize the program's structure, but when he asked you if there were other ways to avoid wasting cpu power with a waiting loop and still have a constant game speed, you gave no solutions. I am led to conclude that having a big interrupt handler is the only way to do what he does.
I did have the same conclusion ;)

>>Also, F-Zero is not only a big technical achievement, it's also on of the most complete game there is for the 68k.
Thank you very much JF

>>He could have used a more compact format, but he wasn't willing to due to his speed optimization obsession.
It is not an obsession, it was necessary (Hey, it's F-zero, not backgammon ! It is a game that requires speed)

>>He could have both achieved synchronization in a clean way and saved a lot of battery power by simply putting the calculator into low-power mode until an interrupt happens (which can be detected with a simple flag or counter, i.e. minimal code within the interrupt handler). (And I told him that multiple times.) But instead, he designed for speed at all costs, not caring about not eating all the memory nor about not consuming batteries needlessly.
>>PS: The reason his code structure is wasting batteries for nothing is simple: it's pointless to compute more frames than you're ever going to display or the other way round.
There is absolutely no CPU time wasting, all the mode7 frames are displayed and there is no time for idling. The only thing which is calculated and not displayed is the race environment and this is for having a fast response to the command input, I couldn't sacrifice the gameplay. Furthermore the interrupt handlers are used to get the same game speed on all calculators (10Mhz, 12MHz and even HW4 16MHz's) the only difference you can notice on these different calcs is the amount of fps.

>>And again, this structure is also why he couldn't get USB linking to work, so it's not just a theoretical problem.
Are you sure that it is true? when I started to think about the USB linking there was not enough info on it and even you didn't know if it wasn't able to work my way.. I sort of gave up the USB problem to concentrate on the game itself.

>>As for the crappy way to input letters, there is no excuse and in fact you gave none.
see above for the excuse :p

>>Yes, the input method is indeed bad.
^^

wasnt the letter input working that way in the original F-zero games anyway? It make the 68k game feel more like the original

mmmh I think there is a virtual keyboard displayed on the screen (except for F-ZERO on snes (I don't remember correctly but I think there wasn't even a letter input for highscores on this game))
My bad letter input is better than nothing ^^

<< I released the source code and I said it is possible to try to fix the problem if you ask me, so don't tell things which are wrong please :) >>

You also said several times you won't be happy if someone tries to reverse some of your design decisions, like the tile format or like replacing your menu system with some AMS menus/dialogs, so it's "please fix my problems, but only fix them my way, no matter whether it makes sense and is even possible or not".

The main reason why I decided not to choose GPL licence for F-Zero is you..
You wanted to replace my beautiful menus with awful AMS dialog boxes :s
If you want to change the design of the tile format and interrupt handler code, you can do it under the condition that the gameplay, the game speed (on every calc) and the frame rate stay as they are in my version. (and for what I saw in your solutions, it is not possible to keep all of these features).
If you can do so with 1 bit per pixel etc.. I will accept your version and you will have my apologies (but I don't think this can happen ;))

Simplifying your boolean expression:
"If you want to change the design of the tile format and interrupt handler code, you can do it under the condition that [FALSE]."
-> You don't allow any modifications, it's exactly what I said. So don't be hypocritical and claim the contrary.

As for the AMS dialog boxes, they actually allow ENTERING LETTERS as opposed to your broken piece of sh*t!

Are you nuts? Do you not comprehend what others say to you? Are you so incredibly stuck up in your strict little world that others' opinions mean absolutely nothing to you? How can you call his work what you did, do you have no respect for his efforts?

Let me bring you up to speed, Kevin Kofler. You're not even half of what you claim to be. You're not the one who made TIGCC what it is, and you are in no position to so brutishly dictate your views on other people's personal projects. The way you continue to act makes you an outright embarrassment to the 68k community.

You show absolutely no respect for the creativity and personal choices of other programmers. Lionel kept the artistic integrity of his game, and refused to compromise its style in order to save a few of your precious bytes. Imagine if every video game out there used the default OS menus and input methods, everything would be extremely boring and frustrating. Just like you.

- Alex

Just to clarify: the "broken piece of sh*t" referred to the menu/dialog system only (and the letter input in particular), not the entire game.

As for the "artistic integrity", he's destroying the "artistic integrity" of the calculator by refusing to use the system menus and dialogs. It's also damaging for usability because what he's replacing them with is worse. (Who wants to enter the name that ridiculous way on a calculator keyboard which has a lot more keys than the gamepads said method was designed for?)

You completely missed my point, intentionally of course. Using standard dialog menus would break the game's heavy graphic style, and would literary look patchy, unprofessional, and inconsistent.

Sometime designs has to overcome "technical perfection", in order to enhance user experience, especially for such trivialities where the gained technical advantage brings nothing to the end user.

- Alex

LOL, "enhance user experience"?! Do you really think having the user enter letters using the cursor keys is "enhancing the user experience"??? If so, I'd recommend you read something about usability RIGHT NOW... :-/

The game he produced closely mimics the clean, professional style of older handheld/console games, and he carried that out through to the last detail, key input included. Quit being so picky about such trivialities, after all you didn't pay him any money that would justify your rather absurd and pretentious demands.

- Alex

> and he carried that out through to the last detail, key input included

LOL, have you read his messages? Not even the author himself tried to use that lame excuse.

Oh, and about your (completely off-topic) personal attack: I don't agree with that statement! Don't take me wrong, I think my predecessors and former codevelopers on TIGCC did a lot of good work, e.g. I consider Zeljko Juric to be one of the best programmers TI calculators have seen, and TIGCC would not have been possible without them either. But do you realize how much I actually did in the TIGCC project? (Hint: TIGCC 0.95 was essentially the work of 2 people: Sebastian Reichelt and me. The current TIGCC 0.96 development is almost exclusively my work. Now look at the list of new features since 0.94. Another hint: The version numbers don't tell the full story.) What did YOU do to advance TIGCC? (Hint: Nothing!) And what do you think would happen to TIGCC if I left? I think it would most likely never get any updates again.

My point was that nothing gives you the right to put down other's work the way you do. Now I'm not just talking about this specific example in this thread, but on a larger scale, where you made blanket statements about certain people in the community, and put down their efforts simply because you disagreed with things such as their program design, speed vs size, or the programming language they used to carry out their ideas.

You should understand that most people program on these platforms solely for the fun of it, not to reach a certain benchmark imposed for the sake of imposing it...

- Alex

>> My point was that nothing gives you the right to put down other's work the way you do.

Maybe not in general, but when it comes to programming in general and specifically heavy optimization, I'd say Kevin has every right. He's one of the best programmers I know of ... especially on the 68k series calcs.
He also has very specific ideas and beliefs (the Free Software/Open Source movement, etc.), and everything he says and does comes from that. Nobody is any different in that respect - I am a Mac user (and an Applescript programmer), so if I were telling people how to write programs, I would emphasize a Mac version, Applescriptablilty, and Recordabilty. It's what's important to me. You have other ideas, beliefs, and agendas. They're what are important to you and they're where you come from.

I don't really find his comments to be unreasonable. They represent how he would have programmed the program, had he been the programmer. In that note, go read Wil Shipley's blog (linked). He is one of the longest-programming-Cocoa Mac OS X programmers. Sometimes, people will send him code for him to tear apart and criticize. Go read the linked page, then say that Kevin was harsh. The biggest difference is that Kevin's advice was unsolicited (though I'd say that if you release the source, you're soliciting code criticism).

There are good and bad ways to deliver feedback or criticism.

You may choose to focus only on the negative feedback. This method usually provokes anger and/or resentment. In extreme cases, it may kill all creativity or the desire to program. This is NOT the best method to deliver feedback.

You may choose to focus only on the positive feedback. This method may provide a false sense of greatness -- "I can do nothing wrong" attitude. This may ultimately result in real downer when the truth comes to light. Again... In extreme cases, it may kill all creativity or the desire to program. This is NOT the best method to deliver feedback.

May I suggest that the best method to deliver feedback is to provide a balance between the positive and the negative feedback.

And when you must give negative feedback, do it in a tactful manner. Be persuasive with suggestions. Do not lord it over them -- this is the best way to gain an enemy. Hopefully, we do not participate in this community to gain enemies.

Just my 2 cents. ;)

A lot of Wil's comments are very subjective, by the way.

In particular, don't EVER put an underscore as the first character of ANY identifier you write in a TIGCC program, these identifiers are reserved for use in TIGCCLIB. (Yes, the C standard allows some uses of identifiers starting with a single underscore followed by a lowercase letter (they're only reserved for file-scope or global identifiers), but if you don't know what you're doing, better leave your hands off identifiers starting with an underscore altogether. Also, despite what the C standard says, TIGCCLIB uses some of these identifiers for internal macros too, so being pedantic won't help you in the real world.)

Kevin, can you not find anything positive to say about F-Zero -- like how cool the overall gaming experience is?

All I know, is it's fun!

My vote is still in the air, when does voting stop?

As usually, the 68k POTY voting ends up in a flame war :(

And you have no idea how a game is usually written. Most arcade and console games do the majority of their work in the interrupt handler(s). That's how they stay in sync with real time. F-Zero is written like a console game, and it plays like a console game. If you don't like it, don't put it on your calc.

It's possible to stay in sync with real time by:

volatile unsigned char flag=0;
DEFINE_INT_HANDLER(timerint) {
flag=1;
}

while (1) {
flag=0;
read_keys();
compute_frame();
render_frame();
while (!flag) pokeIO(0x600005,SOME_INT_MASK);
}

That pokeIO will put the CPU to sleep until the interrupt happens, saving power (assuming you get SOME_INT_MASK right, but that's what we have hardware docs for). And if it gets woken up by some other interrupt, the flag loop will put it back to sleep until the right one happens.

If the problem is that you can't render the frames as fast as you compute them, then:
1. fix some frameskip value n (It makes no sense to use variable frameskips on machines which all have about the same speed.) and
2. change compute_frame(); so it computes n frames at once. Don't blindly call compute_frame(); n times, instead try to rearrange your formulas so the n frames are computed as one (by algebraic manipulation).
And then you end up with one frame to compute for each frame to render again, because the n frames are now 1 frame with the optimized computations. Computing more frames than you can render is a bad idea from a battery consumption point of view.

Yes, computing more frames than you need to render does waste power. You're perfectly right on that one.

Oh, and you can also use GrayGetNSwitches for syncing and thus avoid installing a custom interrupt handler altogether.