Author Topic: [Axe] Super Smash Bros. Open (Read 381442 times)

chickendude · « **Reply #15 on:** August 23, 2014, 11:12:30 am »

Hayleia, this is amazing. I've often thought that SSB would be perfect for the calc, especially if you've only got two or three characters there's not a whole lot of stuff to do. But i never even thought about adding in zooming, that's a great idea and i'm surprised how well it really turned out. I hope you keep working on this, great work so far!

Hayleia · « **Reply #16 on:** August 23, 2014, 11:15:47 am »

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

chickendude · « **Reply #17 on:** August 23, 2014, 11:43:43 am »

I didn't mean much work, i meant much processing time. There are only a couple objects on screen and the maps are relatively small. There should be enough processing time left over for all the fancy stuff you were talking about, like grabs, items, etc. I imagine the zoom changes all that, though

Runer112 · « **Reply #18 on:** August 23, 2014, 12:22:51 pm »

Suggestion for a (very simple) protocol to establish one calculator as a master and the other as a slave:

Wait for a pseudorandom amount of time (to mitigate the chance of both calculators entering the next steps within microseconds of each other).
Read the link port.
- If in its default state (0b11), pull one line low and wait. This calculator will become the master (or the slave).
- If not in its default state, unless the other calculator is running some other code, this should mean the other calculator is waiting in the state above. Pull the other line low and wait for at least 100 microseconds to make sure the signal is received. This calculator will become the slave (or the master).
Release the link lines.

All further transmissions can then be guided by each calculator knowing its role in the transmission (sender or receiver).

DJ Omnimaga · « **Reply #19 on:** August 23, 2014, 01:04:53 pm »

Quote from: Hayleia on August 23, 2014, 12:18:44 am

Thanks all ^^

Quote from: DJ Omnimaga on August 22, 2014, 03:08:31 pm
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.

Good luck! Hopefully you can finish the engine and main stuff such as menus before you have to put the axe into the project so that hopefully people can make their own characters. Maybe this could be submitted to the OPRT thing to gather more interest. That said, there will definitively be a news about this if it gets further so it could result into more interest.

Hayleia · « **Reply #20 on:** August 23, 2014, 02:52:46 pm »

Quote from: DJ Omnimaga on August 23, 2014, 01:04:53 pm

Good luck! Hopefully you can finish the engine and main stuff such as menus before you have to put the axe into the project so that hopefully people can make their own characters. Maybe this could be submitted to the OPRT thing to gather more interest. That said, there will definitively be a news about this if it gets further so it could result into more interest.

Thanks

And yeah, if I don't finish it, I submit it to the OPRT with a todo list

Quote from: Runer112 on August 23, 2014, 12:22:51 pm

Suggestion for a (very simple) protocol to establish one calculator as a master and the other as a slave:

Wait for a pseudorandom amount of time (to mitigate the chance of both calculators entering the next steps within microseconds of each other).
Read the link port.
If in its default state (0b11), pull one line low and wait. This calculator will become the master (or the slave).
If not in its default state, unless the other calculator is running some other code, this should mean the other calculator is waiting in the state above. Pull the other line low and wait for at least 100 microseconds to make sure the signal is received. This calculator will become the slave (or the master).
Release the link lines.
All further transmissions can then be guided by each calculator knowing its role in the transmission (sender or receiver).

I am still having problems.

Here's what I have before the main loop to decide who is who (basically what your code is for):

Code: [Select]

Text(0,,"Waiting for other calc")
DispGraph
While 1
   randplotdot1->P
   Text(0,,P>Dec)
   Send(P,°Delay)
   While 1
      If getKey(15):Goto RET:End
      Receive()
   EndIf +1
   -1->Q
   Send(P,°Delay)
EndIf P-Q

ClrDraw
Text(0,,"You are P",P++>Dec)
DispGraph
Pause 3600
Pause P*20+1

That works sometimes, but this is not the problematic part.

Here's what I have in the main loop:

Code: [Select]

   !If |port
      1->|port
      While 1
         If getKey(15):Goto RET:End
         Receive()
      EndIf +1
      -1->{P xor 1+°PInput}
      Pause 20
      Send({P+°PInput},°Delay)
   Else
      Pause 20
      Send({P+°PInput},°Delay)
      While 1
         If getKey(15):Goto RET:End
         Receive()
      EndIf +1
      -1->{P xor 1+°PInput}
   End

And this works sometimes too, which is annoying in the main loop. Try (with the attachement) to short hop (tap up and quickly release it) several times for example, you'll see that there will be a moment where the Fox on the other calc doesn't jump (and I don't even talk about the major slowdown).

There is also a problem with port commands. I made that sstupid program:

Code: [Select]

While 1
Text(0,,port>Dec)
EndIf getKey(54)
2->port
While 1
Text(0,,port>Dec)
EndIf getKey(15)
0->port

And it outputs "3" then "1", then quits and the calc works. Now replace the "2->port" with a "1->port", and the "0->port" with a "3->port". It outputs "3" then "2" then quits and the calc is slowed down.
It seems like when doing ->port, there's an implicit xor 3 being done.[/code]

annoyingcalc · « **Reply #21 on:** August 23, 2014, 06:41:12 pm »

Wow, this looks great!

Do you have any plans for options to disable the camera zoom (I know a few people who might get motion sick from that) when two calculators are linked together?

ClrDraw · « **Reply #22 on:** August 23, 2014, 08:17:10 pm »

BUT THE ZOOM IS THE COOLEST PART

Hayleia · « **Reply #23 on:** August 24, 2014, 02:05:20 am »

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:

Code: [Select]

    !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:

Code: [Select]

    !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 ?

ben_g · « **Reply #24 on:** August 24, 2014, 07:40:49 am »

So, if I understand it correctly, you send keypresses to the other calc and hope that the movements stay synced on both cacls, right?
I think it would be better to send actions to the other calc when the player does them, together with the coordinates at which the actions were started. For example: jump: first send a byte that represents the jump action (for example $0C (just a random number)), and then the coordinates, for example (5,10). That way, if the calcs aren't fully synced, they should resync because it now knows the coordinates.
But I haven't tried something like this yet, so I don't know how well it would word, or how slow it would be.

DJ Omnimaga · « **Reply #25 on:** August 24, 2014, 12:07:45 pm »

Btw will there be single player support? In North America it's very rare to see more than 1 student in one single school who care about calc games, so by being multiplayer-only the game would basically be out of reach from most of North America, especially Canada.

Hayleia · « **Reply #26 on:** August 24, 2014, 02:00:49 pm »

Quote from: ben_g on August 24, 2014, 07:40:49 am

So, if I understand it correctly, you send keypresses to the other calc and hope that the movements stay synced on both cacls, right?
I think it would be better to send actions to the other calc when the player does them, together with the coordinates at which the actions were started. For example: jump: first send a byte that represents the jump action (for example $0C (just a random number)), and then the coordinates, for example (5,10). That way, if the calcs aren't fully synced, they should resync because it now knows the coordinates.
But I haven't tried something like this yet, so I don't know how well it would word, or how slow it would be.

The problem is that "actions" are not in a finite number. I can put as much "actions" in Fox as I want (and in fact, an "action" is often divided in several ones). Which means that an error when transferring will stiil lead to a wrong action.

Quote from: DJ Omnimaga on August 24, 2014, 12:07:45 pm

Btw will there be single player support? In North America it's very rare to see more than 1 student in one single school who care about calc games, so by being multiplayer-only the game would basically be out of reach from most of North America, especially Canada.

Well, same here in France, but I am probably not able to produce an interesting AI -.-

zeldaking · « **Reply #27 on:** August 24, 2014, 02:05:23 pm »

This.
Is.
F*cking.
Great.
Amazing job Hayleia. SSB is one of my favorite games of all times, kudos to you for being awesome.

123outerme · « **Reply #28 on:** August 24, 2014, 02:06:27 pm »

*applause*
This looks really cool!

Hayleia · « **Reply #29 on:** August 24, 2014, 02:08:04 pm »

Lol zeldaking

And thanks both of you ^^

Author Topic: [Axe] Super Smash Bros. Open (Read 381442 times)

chickendude

Re: [Axe] Super Smash Bros. Open

Hayleia

Re: [Axe] Super Smash Bros. Open

chickendude

Re: [Axe] Super Smash Bros. Open

Runer112

Re: [Axe] Super Smash Bros. Open

DJ Omnimaga

Re: [Axe] Super Smash Bros. Open

Hayleia

Re: [Axe] Super Smash Bros. Open

annoyingcalc

Re: [Axe] Super Smash Bros. Open

ClrDraw

Re: [Axe] Super Smash Bros. Open

Hayleia

Re: [Axe] Super Smash Bros. Open

ben_g

Re: [Axe] Super Smash Bros. Open

DJ Omnimaga

Re: [Axe] Super Smash Bros. Open

Hayleia

Re: [Axe] Super Smash Bros. Open

zeldaking

Re: [Axe] Super Smash Bros. Open

123outerme

Re: [Axe] Super Smash Bros. Open

Hayleia

Re: [Axe] Super Smash Bros. Open