Giter Club home page Giter Club logo

mupen64plus-ui-console's Introduction

===============================================================================
-------------------------------------------------------------------------------
Mupen64plus-ui-console README                                              v2.5
-------------------------------------------------------------------------------
===============================================================================

The latest documentation for this plugin can be found at:

https://mupen64plus.org/wiki/index.php/UIConsoleUsage

-------------------------------------------------------------------------------
Console Options
-------------------------------------------------------------------------------

At startup, the mupen64plus program will look for a user configuration file
called 'mupen64plus.cfg'.  If this file does not exist, it will be created and
default settings will be written. If desired, an alternate config directory can
be specified using the --configdir commandline option.

Run 'mupen64plus --help' for a complete list of commandline options: 

 $ mupen64plus --help
Usage: mupen64plus [parameter(s)] [romfile]

Parameters:
    --noosd                : disable onscreen display
    --osd                  : enable onscreen display
    --fullscreen           : use fullscreen display mode
    --windowed             : use windowed display mode
    --resolution (res)     : display resolution (640x480, 800x600, 1024x768, etc)
    --nospeedlimit         : disable core speed limiter (should be used with dummy audio plugin)
    --cheats (cheat-spec)  : enable or list cheat codes for the given rom file
    --corelib (filepath)   : use core library (filepath) (can be only filename or full path)
    --configdir (dir)      : force configation directory to (dir); should contain mupen64plus.cfg
    --datadir (dir)        : search for shared data files (.ini files, languages, etc) in (dir)
    --debug                : launch console-based debugger (requires core lib built for debugging)
    --plugindir (dir)      : search for plugins in (dir)
    --sshotdir (dir)       : set screenshot directory to (dir)
    --gfx (plugin-spec)    : use gfx plugin given by (plugin-spec)
    --audio (plugin-spec)  : use audio plugin given by (plugin-spec)
    --input (plugin-spec)  : use input plugin given by (plugin-spec)
    --rsp (plugin-spec)    : use rsp plugin given by (plugin-spec)
    --emumode (mode)       : set emu mode to: 0=Pure Interpreter 1=Interpreter 2=DynaRec
    --savestate (filepath) : savestate loaded at startup
    --testshots (list)     : take screenshots at frames given in comma-separated (list), then quit
    --set (param-spec)     : set a configuration variable, format: ParamSection[ParamName]=Value
    --gb-rom-{1,2,3,4}     : define GB cart rom to load inside transferpak {1,2,3,4}
    --gb-ram-{1,2,3,4}     : define GB cart ram to load inside transferpak {1,2,3,4}
    --dd-ipl-rom           : define 64DD IPL rom
    --dd-disk              : define disk to load into the disk drive
    --core-compare-send    : use the Core Comparison debugging feature, in data sending mode
    --core-compare-recv    : use the Core Comparison debugging feature, in data receiving mode
    --nosaveoptions        : do not save the given command-line options in configuration file
    --pif (filepath)       : use a binary PIF ROM (filepath) instead of HLE PIF
    --verbose              : print lots of information
    --help                 : see this help message

(plugin-spec):
    (pluginname)           : filename (without path) of plugin to find in plugin directory
    (pluginpath)           : full path and filename of plugin
    'dummy'                : use dummy plugin

(cheat-spec):
    'list'                 : show all of the available cheat codes
    'all'                  : enable all of the available cheat codes
    (codelist)             : a comma-separated list of cheat code numbers to enable,
                             with dashes to use code variables (ex 1-2 to use cheat 1 option 2)

-------------------------------------------------------------------------------
Cheats
-------------------------------------------------------------------------------

To list the available cheats in the rom:

mupen64plus --cheats list "/path/to/my/rom.v64"

If there are cheats in the rom, you will get (in the output console):

UI-Console: 3 cheat code(s) found for ROM 'MY ROM'
   0: [Enable All Levels] (This is needed to be able to Play all Levels of the Game)
   1: [Enable All Weapons] (This is needed to be able to Play with all Weapons of the Game)
   2: etc...

All you have to do to use this cheats is:

mupen64plus --cheats 0,1,2 "/path/to/my/rom.v64"

-------------------------------------------------------------------------------
Debugger
-------------------------------------------------------------------------------

Setup
=====

You must use a mupen64plus core library which was built with the DEBUGGER flag set.

Running
=======

Use the --debug command-line option to enable the console debugger.

The emulator mode should be set to "interpreter", as the dynarec seems to cause
issues when interacting with the debugging API. This can be done with the R4300Emulator
config setting or with the --emumode flag.

Usage
=====

Once the emulator boots, it will be paused by default. You will be presented
with a prompt as follows:

(dbg) 

The following commands can be entered:

run
  Unpauses the game.

pause
  Pauses the game.

step <num-steps>
  When paused, instructs the emulator to make a single step, or a series of
  steps if num-steps is provided.

regs
  Prints out general purpose register values.

pc
  Print current value of Program Counter register

pc-1
  Print previous value of Program Counter register

asm
  Print assembly language instructions. Several forms are supported:

  asm                     Print one instruction at the Program Counter register

  asm <addr>              Print one instruction at <addr>

  asm <addr> <n>          Print <n> instructions starting at <addr>

  asm <addr> <n> <flags>  Print <n> instructions starting at <addr> with flags
    - If flags bit-3 is set (i.e. & 0x04): also print binary instruction data
    - If flags bit-2 is set: prefix each instruction with its memory address
    - If flags bit-1 is set: prefix each instruction with a counter from <addr>

mem
  Print memory values. Several forms are supported:
  
  mem <addr>        Print one 32-bit word at <addr>
  
  mem /N <addr>     Print <N> 32-bit words at <addr>
  mem /Nb <addr>    Print <N> 8-bit bytes at <addr>
  mem /Nh <addr>    Print <N> 16-bit half-words at <addr>
  mem /Nw <addr>    Print <N> 32-bit words at <addr>
  mem /Nd <addr>    Print <N> 64-bit double-words at <addr>

  mem /NxM <addr>   Print <N> rows of <M> 32-bit words at <addr>
  mem /NxMb <addr>  Print <N> rows of <M> 8-bit bytes at <addr>
  mem /NxMh <addr>  Print <N> rows of <M> 16-bit half-words at <addr>
  mem /NxMw <addr>  Print <N> rows of <M> 32-bit words at <addr>
  mem /NxMd <addr>  Print <N> rows of <M> 64-bit double-words at <addr>

write
  Write values to memory. Several forms are supported:

  write <addr> <value>    Write a (1) byte value to <addr>

  write <addr> b <value>  Write a (1) byte value to <addr>
  write <addr> h <value>  Write a half-word value (2 bytes) to <addr>
  write <addr> w <value>  Write a word value (4 bytes) to <addr>
  write <addr> d <value>  Write a double-word value (8 bytes) to <addr>

translate
  Translates virtual memory addresses to physical memory addresses. Memory
  read/write breakpoints must operate on physical addresses, in contrast to the
  memory read/write commands and execution breakpoints that operate on virtual
  addresses.

  translate <virtual address>  Print the 32-bit physical address for the
                               provided <virtual address> argument.

bp add
  Adds a breakpoint at a given address. Several forms are supported:

  bp add pc                  Add a breakpoint at the Program Counter, triggered
                             on EXEC, READ, and WRITE.

  bp add <addr>              Add a breakpoint at <addr>, triggered on EXEC,
                             READ, and WRITE.

  bp add <addr> <n>          Add a breakpoint starting at <addr>, extending <n>
                             bytes, triggered on EXEC, READ, and WRITE.

  bp add <addr> <n> <flags>  Add a breakpoint starting at <addr>, extending <n>
                             bytes, with specified trigger flags.
    - M64P_BKP_FLAG_READ = 0x02
    - M64P_BKP_FLAG_WRITE = 0x04
    - M64P_BKP_FLAG_EXEC = 0x08

bp trig
  Prints the reason for the most recently activated breakpoint trigger. Memory
  read/write breakpoints will indicate the hit address.

bp rm <addr|index>
  Removes a breakpoint by address or number.

bp list
  Lists all breakpoints.

exit|quit
  Stop emulator and quit debugger

-------------------------------------------------------------------------------
64DD Support
-------------------------------------------------------------------------------

Some compatibility with the 64DD disk drive unit has been implemented, but there
are a few small usability issues of which users should be aware.

When using the 64DD, you need to pass a path to a cartridge rom, even if none is
strictly required.  The IPL boot rom will execute first and select the disk if
you have one inserted, or just show the boot menu otherwise.  We can remove this
requirement at a later time. For now all we need to remember is to use a Japanese
ROM (otherwise some region check will fail) with same features as the 64DD game
you want to play (think RumblePak, TransferPak, otherwise, they won't be available).

There is a sibling issue also with 64DD games in that there are no entries in the
game db (mupen64plus.ini) for them, and the core currently only relies on the cart
ROM loaded to fetch the ROM infos.


mupen64plus-ui-console's People

Contributors

bentley avatar bsmiles32 avatar bugfood avatar charlemagnelasse avatar ecsv avatar fprimex avatar ghostlydark avatar gillou68310 avatar jj0yzl5nvj avatar littleguy77 avatar loganmc10 avatar narann avatar nebuleon avatar npepinpe avatar orbea avatar paulscode avatar richard42 avatar thyth avatar wnayes avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mupen64plus-ui-console's Issues

SDL1.2 internal state is not initialized before calling SDL_ functions

It seems 87ef789 from pull request #14 broke the SDL1.2 initialization. On parts of the platforms the main function must be replaced and instead the private SDL-main (parachute) function has to be called first. This is the only use of this SDL_main.h include. The programs main function is redefined as SDL_main and the main function is included using a special static library. The normal startup will therefore be main(SDLmain.a) -> SDL_main(previously known called main in the actual program source code). Of course, main() is not always called main() but I just use it here as placeholder for the real name.

This special indirection is required to initialize the internal state of SDL before the actual program calls any SDL function.

A similar problem already caused the windows builds to break (in a very hard to debug way) in the past.

Unrecognized UI-Console commands

Hello everyone! I have noticed that some string arguments of the --set parameter are not working properly. The pre-release 2.5.9 build works fine, but not the latest nightly-builds.
I'll explain better... I use several mupen64plus.cfg (to be exact, one for each game), and I try to keep them in the same directory as the emulator. That way I can make each game run with a unique configuration for it.

Going to my Mupen directory "C:\mupen64plus" through the Prompt, I run, for example, San Francisco Rush 2049:

mupen64plus-ui-console.exe --configdir "romconfig\San Francisco Rush 2049 (U) [!]" "roms\San Francisco Rush 2049 (U) [!].z64"

It's all right...
1st: My mupen64plus.cfg will be created in the folder "C:\mupen64plus\romconfig\San Francisco Rush 2049 (U) [!]", and no longer in default "C:\Users\ (User) \AppData\Roaming\Mupen64Plus".
2nd: I close the game
3rd: I change my new mupen64plus.cfg as I want
4th: I run exactly the same command mentioned above so that the emulator continues reading my new mupen64plus.cfg when I want to play again.

The problem I reported happens when I want to quickly configure some parameters of my new mupen64plus.cfg using the prompt. I could do this by editing my new mupen64plus.cfg with a text editor (as I've explained), but I can speed things up like this.
For example: to define a new path for my screenshots, I would do:

mupen64plus-ui-console.exe --configdir "romconfig\San Francisco Rush 2049 (U) [!]" --set core[ScreenshotPath]="romconfig\San Francisco Rush 2049 (U) [!]\screenshot" "roms\San Francisco Rush 2049 (U) [!].z64"

As a result, in my mupen64plus.cfg:
[Core]
(...)
ScreenshotPath = "romconfig\San Francisco Rush 2049 (U) [!]\screenshot"
(...)

But this is what I get now :(
ScreenshotPath = ""romconfig\San" (It's three quotes, I wasn't wrong)

And I still get a pile of unrecognized commands that I get later:
UI-Console Warning: unrecognized command-line parameter 'Francisco'
UI-Console Warning: unrecognized command-line parameter 'Rush'
UI-Console Warning: unrecognized command-line parameter '2049'
UI-Console Warning: unrecognized command-line parameter '(U)'
Etc.....

I'll avoid theories here so this text doesn't get too long.
Goodbye!

[SOLVED] Bad value during make

Debian Stretch 9.0 (1.9) ASUS Tinkerboard RK3288 ARMv7 Mali T764

make NEON=1 VFP_HARD=1 all

    CC  _obj/cheat.o
    CC  _obj/compare_core.o
    CC  _obj/core_interface.o
    CC  _obj/main.o
    CC  _obj/plugin.o
    CC  _obj/osal_dynamiclib_unix.o
    CC  _obj/osal_files_unix.o
    LD  mupen64plus
/usr/bin/ld: /tmp/ccSs1UeW.ltrans0.ltrans.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccSs1UeW.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:315: recipe for target 'mupen64plus' failed
make: *** [mupen64plus] Error 1
    LD  mupen64plus
/usr/bin/ld: /tmp/ccBHpyWe.ltrans0.ltrans.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccBHpyWe.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:315: recipe for target 'mupen64plus' failed
make: *** [mupen64plus] Error 1

-fPIC seems to be required during compilation of ld.

I tried with setting the PIC option during make

make NEON=1 VFP_HARD=1 PIC=1 all
make NEON=1 VFP_HARD=1 PIC=0 all

but still the same error

Finding the line in projects/unix/Makefile

ifeq ($(OS), LINUX)
  LDLIBS += -ldl
endif

and adding

ifeq ($(OS), LINUX)
  LDLIBS += -ldl
  CFLAGS += -fPIC   #THIS LINE
endif

used to fix the problem, it's not working now

Adding PIE=1 to make fixed the problem. thanks loganmc10.

Unable to install mupen64plus on BananaPi (ARM)

Hi guys,

When I try to install mupen64plus:
sudo apt-get install mupen64plus
from my BananaPi (using Raspbian for BananaPi), I have the following error:

Depends: mupen64plus-ui-console but it is not installable or
mupen64plus-ui but it is not installable

Any idea how I can solve it?

Build error after #61 merged

#61 seems to cause a building error on ubuntu 20.04.

/usr/bin/ld: /tmp/mupen64plus.7qvaaK.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status

If I revert this commit, the error has gone.

High Dpi awareness

High DPI awareness is missing for the windows version of the ui console. I had problems using it on Windows 10 and setting to my native 1920x1080 desktop resolution in fullscreen mode...

gcc9 build failure

OS: gentoo
compiler: gcc-9.3.0
mupen64plus-ui-console: ae2d353

The build fails with gcc-9.3.0 on gentoo.

/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/cheat.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/compare_core.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/core_interface.o: relocation R_X86_64_32 against symbol `CoreHandle' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/debugger.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/plugin.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_dynamiclib_unix.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: _obj/osal_files_unix.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status

Full log: mupen64plus-ui-console.txt

I tried this both with and without OPTFLAGS=-fPIE without any differences. The build does succeed with clang-11.0.0 and the gcc-9.3.0 shipped with Slackware64-current, I am not sure what is different about gentoo in this case? I was also not able to reproduce this problem with any other mupen64plus plugin.

Setting position of window (...+%d+%d)

I have been trying to figure out where the position of the WM gets set (centered, it seems), but have not gotten much further than adding a dummy --position argument to the console/config.

I do not really know which of the many Glide plugins is being used (only that it is Glide64mk2), but whether this is the module responsible for setting the position of the physical window, I have no idea.

Where should I be looking?
Glide64?
Glitch64/OGLES?
Glitch64/OGL?

my use case is programmatically spawning several instances spread out rather than all in one centered pile
there already is a window size parameter, so initially I thought finding the position would be straightforward but apparently not

using Linux

2.5.9: Missing config API change

The ui is currently depending on config api 2.0

src/version.h:#define CONFIG_API_VERSION 0x020000

The ui-console program is using following new functions from newer API versions:

  • 2.1
    • ConfigSaveSection
  • 2.2
    • ConfigHasUnsavedChanges
  • 2.3.1
    • ConfigExternalOpen

Setting default parameter values at build time

When users run mupen64plus for the first time or if they delete their mupen64plus.cfg file then mupen64plus will auto-generate a new cfg file. This cfg file may not have default values that are compatible with some unofficial ports.

Users can of course change these, either on the command line, manually editing the file or copying in a good cfg file.

However for inexperienced users, perhaps a method to set these defaults at build time should be considered.

I would like to suggest that such a method used is similar to how COREDIR and PLUGINDIR are used within the makefile system. Then maintainers of unofficial ports could customize official plugin defaults from within their build scripts. (This would remove the need to fork and maintain updates where only these defaults are changed).

Note: This change would have to be applied to all mupen64plus repositories else an inexperienced user may still need to do something with the cfg file.

As a side note I would like to add that I have not seen many comments/questions about how to change the mupen64plus configuration on the raspberry Pi forums, given the aims of the device is to be educational and so has a higher proportion of inexperienced users of linux, I feel this 'Issue' is of low importance and more of an enhancement.

COREDIR and PLUGINDIR should default to a value derived from PREFIX

As a new user, I only set PREFIX for all the mupen64 builds. This placed everything in the right paths, but I needed to put full plugin paths to the .cfg file, and start the console ui with a --corelib arg. It would be useful if the core and plugin paths had defaults derived from PREFIX, the same defaults that the parts get placed in.

mupen64plus don't show the list of roms

I'm user of Debian I'm not sure if it's a problem only on Debian or maybe mupen64plus could have a way to fix it...

I only write: sudo apt-get install mupen64plus-qt and the list of roms it's impossible to show any rom

there anyone know some steps to fix it,I'd like to try some textures in those games and without a list of roms it cannot be done

Thanks in advance

Screen disappears when focus lost during fullscreen

Running mupen64plus-2.5.9 on OpenBSD -current.

I have a dual screen setup. If I run a game fullscreen or windowed, it generally plays just fine.

In fullscreen mode, if I move the mouse to the other (non‐mupen64plus) screen, mupen64plus’s graphics output disappears completely, and I can see and interact with the windows behind it. The game continues to play in the background (evidenced by the audio, anyway). I can’t find any way to get the window back. There’s no additional output in the terminal window, except for normal gameplay messages (“Initializing SDL audio subsystem,” etc.).

Nothing of the sort happens in windowed mode; I can move the cursor anywhere with no repercussions.

Tested with both glide64mk2 and rice, with identical results.

How to view osSyncPrints?

I'm doing some Ocarina of Time development and Mupen is the only emulator I can get on NixOS.

How can I view the various calls to osSyncPrint in the game, and the ones I've added?

Thanks.

Missing definitions of m64p_media_loader and M64CMD_SET_MEDIA_LOADER

Commit 5b9eba4 (as I write, current master) is missing definitions for m64p_media_loader and M64CMD_SET_MEDIA_LOADER, resulting in build errors.

    CC  _obj/main.o
../../src/main.c:830:8: error: unknown type name ‘m64p_media_loader’
 static m64p_media_loader l_media_loader =
        ^~~~~~~~~~~~~~~~~
../../src/main.c: In function ‘main’:
../../src/main.c:1028:26: error: ‘M64CMD_SET_MEDIA_LOADER’ undeclared (first use in this function)
     if ((*CoreDoCommand)(M64CMD_SET_MEDIA_LOADER, sizeof(l_media_loader), &l_media_loader) != M64ERR_SUCCESS)
                          ^~~~~~~~~~~~~~~~~~~~~~~
../../src/main.c:1028:26: note: each undeclared identifier is reported only once for each function it appears in
Makefile:321: recipe for target '_obj/main.o' failed
make: *** [_obj/main.o] Error 1

Screenshots not all taked from command line

I realize, in some situation, every requested screenshots (argument --testshots) are not all generated.

I have a test suite that open a rom with a save state and save some screenshots. Generated command line looks like this:

./mupen64plus --resolution 640x480 --audio dummy --configdir ./ --nosaveoptions --testshots 2,5 --savestate mupen64plus-regression-test/save_state/1080sb-charselect.st0 --sshotdir mupen64plus-regression-test/screenshot /home/narann/code/repo/mupen64plus/mupen64plus-regression-test/rom/1080sb.z64

The second screenshot is never generated. Interestingly, I have around hundred tests and only 4-6 have this problem. It's not game related, maybe more save state related.

Looking at the code where the console ask for the screen shot:

https://github.com/mupen64plus/mupen64plus-ui-console/blob/master/src/main.c#L141

And how the core handle it:

https://github.com/mupen64plus/mupen64plus-core/blob/b9765eca453ed46773655c44bc86fbcdeb33ab7c/src/main/main.c#L725

As I understand the code, the core ask for a screenshot "next time" the video plugin reach video_plugin_render_callback. But the console ask for M64CMD_STOP as soon the last frame+1 is reached. This mean, the frame callback M64CMD_SET_FRAME_CALLBACK is executed before the video plugin reach video_plugin_render_callback and take its screenshot.

I will do some test to know if wait few frames after the latest screenshot before close the emulator could help...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.