Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

a rewrite of GGPO to haxe.

License

MIT, MIT licenses found

Licenses found

MIT
LICENSE
MIT
GGPO_LICENSE
NotificationsYou must be signed in to change notification settings

lavirlifiliol/gghx

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GGHX is mostly 1:1 port ofGGPO, A P2P rollback netcode library designed for fighting games, to Haxe. Still heavily WIP, but it should be usable if you willing to dealwith some bugs and breaking changes - it still is probably less work than starting from scratch. The sole dependency is hxbit

Just like GGPO, GGHX shares the same limitations.

  • The game can only start once all players have joined, the initial state must be consistent between all players without any, communication.
  • Since this is a P2P library, you will need some form of UDP hole punching or a forwarding server for non-local multiplayer.
  • There is no interpolation done, so you need low ping to have a good experience (dropped inputs at ~280ms ping by default).

GGHX also has further limitation due to me not implementing these features yet.

  • Only 2 players (needs PollNPlayers in P2P.hx)
  • Spectators do not work (// TODO spectators)
  • No SyncTest (needs SyncTestBackend)
  • no meaningful Encapsulation

Unlike GGPO, this library does not use a C struct for serialization, and does not implement low-level networking, meaning it should be fully cross-platform. (did not test)Since low-level networking features are left to the user, the library should work on most haxe targets.

Basic usage:

You need the following capabilities for the library to work.

  • Copy your game state into a haxe.io.Bytes object.
  • Recall that game state from the same Bytes object. (Eventually this could just become a need to create a copy in any shape)
  • Run your games simulation frame-by-frame without affecting your rendering, all within the time of a single frame. (by default up to 8 times per frame)
  • Ideally run your game simulation at 60UPS - it is hardcoded in atleast one place in GGPO, possibly more.
  • A non-blocking way to send datagrams over IP (generally UDP, websockets should also be possible, will test in the future)
  • A way to pack your inputs into a Bytes object - there is a BitHelpers module in gghx which may be of use.

From a code perspective, you need to implement two interfaces:

and call the following public functions at appropriate times, once again, see the dev guide and the example. (TODO more comments in the example)

It is possible to enable logging via -D gghx_log - this creates a large number of logs (expect hundreds of MB for a short testing run). It can however help with debugging the library.

Mapping from GGPO public API to GGHX public API

GGPO APIGGHX APInote
GGPOSessionCallbacksCallbacksUsing an interface rather than function pointers
GGPOSessionSession
ggponet_start_sessionstartSessionalso needs the Networking object
ggpo_close_sessionTODO
ggpo_add_playerSession.addPlayer
ggpo_add_local_inputSession.addLocalInput
ggpo_synchronize_inputsSesssion.syncInputrather than disconnect flags, if you get null instead of bytes, that means the player disconnected - GGPO would pass you all 0 in the input
ggpo_advance_frameSession.incrementFrame
ggpo_idleSession.doPollThe timeout argument is mostly ignored, will be removed in the future

About

a rewrite of GGPO to haxe.

Topics

Resources

License

MIT, MIT licenses found

Licenses found

MIT
LICENSE
MIT
GGPO_LICENSE

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages


[8]ページ先頭

©2009-2025 Movatter.jp