Lol, what ClrDraw said

Jokes apart, I don't really know if that would be doable because how do you not zoom ? By having a constant zoom, right ? But are you constantly zooming on characters which will mean a lot of camera movement (that would probably not improve motion sickness), or do you keep the camera "far" which will mean that you don't see sprites well at all, you don't know what the opponent is doing and you don't even know if the game registered your keypresses ?
Note that I am not against it, I just don't know exactly how motion sickness could be avoided without killing the gameplay.

edit
@Runer112, I tried what you said on IRC yesterday. I didn't touch what's before the main loop, but here's what's in the loop now:
    !If P-1
        While 1
            If getKey(15):Goto RET:End
            Receive()
        EndIf +1
        -1->{P xor 1+°PInput}
        Send({P+°PInput},65535)
    Else
        Send({P+°PInput},65535)
        While 1
            If getKey(15):Goto RET:End
            Receive()
        EndIf +1
        -1->{P xor 1+°PInput}
    End

It is a lot better, there's no major slowdown. I guess that the previous code actually missed some Send due to a too short delay, then waited for a frame before receiving what the other calc sends, which was not the right byte.

But there's still some desync (by desync, I mean that the movement on one calc is not the same as on the other) 
I guess that's because of errors when transmitting because sometimes the calc2 doesn't register a key that I pressed on the calc1, and sometimes the calc2 registers a key that I didn't press on calc1 -.-

edit again
I now tried this (basically sends three times and takes the majority for each bit) in the loop:
    !If P-1
        °A-2->r1
        For(3)
            While 1
                .If getKey(15):Goto RET:End
                Receive()
            EndIf +1
            -1->{r1+2->r1}
        End
        (A and B) or (B and C) or (C and A)
        ->{P xor 1+°PInput}
        For(3)
            Send({P+°PInput},65535)
        End
    Else
        For(3)
            Send({P+°PInput},65535)
        End
        °A-2->r1
        For(3)
            While 1
                .If getKey(15):Goto RET:End
                Receive()
            EndIf +1
            -1->{r1+2->r1}
        End
        (A and B) or (B and C) or (C and A)
        ->{P xor 1+°PInput}
    End
Still desyncs -.-

Any ideas ?

Thanks
I just don't agree with the "not a whole lot of stuff to do"
Just spriting one character is annoying, then creating and linking states is long

Thanks all ^^

Now make sure to add Reuben as character.

Lol, I'll make a tuto and you'll be able to make it if you want
I have some time now but when September comes, I am not sure I'll be able to do anything more so I plan on working on the engine (and I make Fox to test the engine) but I don't plan on making characters.

Especially if you use Calcnet.

Well I don't use CalcNet yet. One of the problems with it being that (if I am not wrong) it is DoorsCS dependent. And I was planning to compile as an app to save RAM (matref should work on a routine to replace the current scaled sprite routine that uses SMC), which is incompatible with the "compile as shell" option. So I'd need to get CalcNet routines in my program. Maybe someone who knows how to make Axioms could work with Kerm to package CalcNet into a standalone Axiom (of course credits will be given to everyone) ?

Thanks ^^
I am still improving the camera by the way. As you can see in that screenshot, it is no longer always centered on the characters, it also tries to get part of the map always in the field of vue. This helps a lot when you push someone off the bridge edge and try to recover after that since you still know where the map is.
(is that color better aeTIos ? )
Obviously, here, the effect is exagerated, no need to center the map more towards the map when the characters still are on the map.

Finally, this project gets a topic

So yeah, as some of you have already seen on IRC, I am working on a Super Smash Bros. Melee clone for monochrome z80 calcs. If you don't know that game, here's a link that may interest you.

Before annoying you with text, here's a screenshot of the current progress.


On that screenshot, you can only see one Fox moving. That's only because I don't want my left hand to play against my right hand but I checked, everything works with the other Fox too.
For now, they are played on the same calc (with different keys obviously) but for future versions, I was thinking about two solutions: either you use a second calculator as a pad without its screen being used or I use CalcNet as geekboy suggested. That's for future versions anyway, I have other problems to solve.

Now, why "Smash Bros. Open" ? Simply because of a play-on-words with "Open".
Those watching the tennis know that "Open" can refer to a competition, which fits a game such as Smash Bros. pretty well.
Those using Linux might think of open-source programs and other openness things.

To clarify that openness, let me give you an example. A question that I was often asked is "Will there be only Fox ?". And the answer is "Yes and no".
I will probably only make Fox. But the engine is really modular which (will) allow you to create your characters and play them ingame without even having access to the source code (they will be in appvars in other words). Even if you want to play as an invincible leek that one-shot with every hit !
As for the source code, it will probably be published (once cleaned up a bit) in order to allow people who want to add missing features (such as items) to do so.

Speaking of which, the source code is completely unoptimized, but it is done on purpose. This way, people who want to edit it can do so very easily instead of digging through my usual unreadable code (even though not necesarily more optimized ). In fact, the source code is currently 51092 bytes with comments and preproc constants, while the executable is not even 13000.

Another question people can wonder is "6MHz or 15MHz ?". And the answer is "both" for now.
What slows down the program most is drawing the map. So we can play at 15MHz with a "complicated" map, such as in the screenshot, or at 6MHz with a "simplistic" map that only contains rectangles. That's still a bit slower than the 15MHz version with the complicated map, but it is very playable in my opinion.

Credits
Badja for scaled sprite routine.
Matref for packing those routines into an axiom.
Quigibo and Runer112 for Axe.

Download
http://ti-pla.net/a110486

I think you'll easily guess the keys I use to control one of the Foxes. For the other one, the keys are the numpad, log and x².

I don't see anything else to say for now so I'd say I'll answer questions if you have any

Quote from: Zemmargorp on August 21, 2014, 07:46:46 am

Quote from: Hayleia on August 20, 2014, 11:47:43 pm

Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?

I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.

I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.

No need to install a translating app. Just temporarily install one on Wabbitemu for example, create a program with all "special tokens", send that program to your calc and then you just have to recall that program and erase useless tokens
Of course, the catalog hook is a better idea, but with the stupid solution I proposed, the release with the Catalog hook can come after the release supporting "special tokens".

Not only beginners unfortunately.
What's great with France is that 15MHz calc are (were) not many so French Axe coders seem to avoid the Full command

Is the "³" token used ? Or the "n" one ?