• [Axe] Super Smash Bros. Open 5 9
Currently:

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

0 Members and 1 Guest are viewing this topic.

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [Axe] Super Smash Bros. Open
« 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

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: [Axe] Super Smash Bros. Open
« 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
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [Axe] Super Smash Bros. Open
« 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

• Moderator
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: [Axe] Super Smash Bros. Open
« 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).
• 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).

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

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55823
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: [Axe] Super Smash Bros. Open
« Reply #19 on: August 23, 2014, 01:04:53 pm »
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.
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.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: [Axe] Super Smash Bros. Open
« Reply #20 on: August 23, 2014, 02:52:46 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

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).
• 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).
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")DispGraphWhile 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-QClrDrawText(0,,"You are P",P++>Dec)DispGraphPause 3600Pause P*20+1That 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}   EndAnd 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 1Text(0,,port>Dec)EndIf getKey(54)2->portWhile 1Text(0,,port>Dec)EndIf getKey(15)0->portAnd 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]
« Last Edit: August 23, 2014, 02:57:33 pm by Hayleia »
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### annoyingcalc

• LV10 31337 u53r (Next: 2000)
• Posts: 1950
• Rating: +140/-72
• Found in Eclipse.exe
##### Re: [Axe] Super Smash Bros. Open
« 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?
This used to contain a signature.

#### ClrDraw

• LV7 Elite (Next: 700)
• Posts: 627
• Rating: +61/-2
##### Re: [Axe] Super Smash Bros. Open
« Reply #22 on: August 23, 2014, 08:17:10 pm »
BUT THE ZOOM IS THE COOLEST PART
Visit my GitHub for all my TI programs as well as other projects.
Also check out my website.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: [Axe] Super Smash Bros. Open
« 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}    EndStill desyncs -.-

Any ideas ?
« Last Edit: August 24, 2014, 04:17:10 am by Hayleia »
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### ben_g

• Hey cool I can set a custom title now :)
• LV9 Veteran (Next: 1337)
• Posts: 1002
• Rating: +125/-4
• Asm noob
##### Re: [Axe] Super Smash Bros. Open
« 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. My projects - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project] - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic) - An android version of oxo (java) ACTIVE - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper) Spoiler For inactive: - A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot) - A java MORPG. (pc) DEEP COMA(read more)(screenshot) - a minecraft game in axe DEAD (source code available) - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version) This signature was last updated on 20/04/2015 and may be outdated #### DJ Omnimaga • Former TI programmer • CoT Emeritus • LV15 Omnimagician (Next: --) • Posts: 55823 • Rating: +3151/-232 • CodeWalrus founder & retired Omnimaga founder ##### Re: [Axe] Super Smash Bros. Open « 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. In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify #### Hayleia • Programming Absol • Coder Of Tomorrow • LV12 Extreme Poster (Next: 5000) • Posts: 3367 • Rating: +393/-7 ##### Re: [Axe] Super Smash Bros. Open « Reply #26 on: August 24, 2014, 02:00:49 pm » 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.

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 -.-
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### zeldaking

• LV4 Regular (Next: 200)
• Posts: 197
• Rating: +15/-0
##### Re: [Axe] Super Smash Bros. Open
« 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

• LV6 Super Member (Next: 500)
• Posts: 458
• Rating: +23/-0
• Self-unpaid intern
##### Re: [Axe] Super Smash Bros. Open
« Reply #28 on: August 24, 2014, 02:06:27 pm »
*applause*
This looks really cool!
 Projects:Sorcery of UvutuGateway to LegendSpoiler For Completed: Calc Sites Links:Cemetechticalc.orgGitHub Images:Spoiler For Because of Size:

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: [Axe] Super Smash Bros. Open
« Reply #29 on: August 24, 2014, 02:08:04 pm »
Lol zeldaking
And thanks both of you ^^
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.