Giter Site home page Giter Site logo

pioneerspacesim / pioneer Goto Github PK

View Code? Open in Web Editor NEW
1.6K 109.0 360.0 1.16 GB

A game of lonely space adventure

Home Page: https://pioneerspacesim.net

Shell 0.10% C++ 57.91% C 27.71% Lua 12.54% GLSL 0.59% CSS 0.01% HTML 0.23% Nix 0.01% Python 0.53% Perl 0.06% CMake 0.28% MoonScript 0.03%
game space simulation simulator exploration elite frontier 3d newtonian physics

pioneer's People

Contributors

ae-2222 avatar brianetta avatar claudiusmueller avatar dessimat0r avatar ecraven avatar fluffyfreak avatar gizmor13 avatar gliese852 avatar gudadantza avatar impaktor avatar irigi avatar johnbartholomew avatar laarmen avatar lwho avatar mike-f1 avatar nozmajner avatar pcercuei avatar philbywhizz avatar pioneer-transifex avatar pioneerbuild avatar radius75 avatar richardpl avatar robn avatar robothauler avatar s20dan avatar shadmar avatar snaar avatar tomm avatar web-eworks avatar wkfo 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  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  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  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  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

pioneer's Issues

UI elements are difficult to see against bright backgrounds

If I fly close to eg a bright yellow star (Epsilon Eridani) I can't see various things - label text, gauge backgrounds, crosshairs, etc. It'd be good if we could do something to make them more visible - drop shadows, colour inversion, etc.

Target velocity indicator

In previous builds, the player had complete access to his velocity relative to a target. The speed was available on the dashboard, and the direction on the HUD. Now, the speed on the dashboard and the velocity direction on the HUD is relative to the nearest gravitational frame of reference.

@robn's brought half of this information back, with the speed relative to the target now available on the target reticle. What I'd like to see is the direction of the velocity of the player ship, relative to the navigation target, available on the screen. It could be in a different colour, or use a different graphic. Frame of reference speed could be white, and target speed green, to match the velocity indicators being white and green, as an example.

Use cases:

  1. Rendezvous with a space port, in orbit or on the ground. It would show the approach of the player's ship relative to the port, taking into account the movement of that port relative to the player as the port orbits, or revolves on a planetary surface.
  2. Leaving orbit. In the frame of reference of a space port in orbit, the player can't see one's orbital velocity until he has flown out of that frame. If flying manually, the easiest way away from the planet is forwards along the space station's orbit, and if returning to the planet the most fuel efficient way down is backwards along the space station's orbit. Selecting the planet will tell the player in which direction he's going, and how fast, relative to the planet; his own orbital velocity. This allows a good de-orbit burn for landing, or similar.
  3. Any time flight occurs near a frame of reference boundary. There's one velocity indicator that won't suddenly change with the gravity frame.

In case of player confusion: Put a tick-box in the options screen, allowing this feature to be toggled.

Mouse not released properly on game exit

Sometimes after the game exits the mouse is not released properly. This seems to only affect the Linux version. Right-clicking another window appears to resolve it most of the time.

Separate Ship and Player

Right now Ship has too much knowledge and too many methods that are player-specific and should live in Player. Two examples:

  • SetNavTarget & SetCombatTarget aren't required by NPCs; they're strictly UI functions. This is reinforced by the fact that these methods cause a sound to be played
  • AddMoney and friends. NPC ships don't need money; they'll be equipped as necessary by ships. Indeed, Player should probably be a MarketAgent, but Ship should not.

Someone needs to go through and check and move things out of Ship into Player as appropriate. I think a good rule-of-thumb is that if it is a UI function in any way, then it belongs in Player. Another test might be to simply remove it from Ship and see if the code compiles.

Quicksave (Ctrl-F9) in main menu causes segfault

It's not like there's anything to save...

(gdb) bt
#0  Serializer::IndexSystemBodies (s=0x0) at Serializer.cpp:61
#1  0x000000000048e72a in Pi::Serialize (wr=...) at Pi.cpp:1280
#2  0x000000000047d93a in Serializer::SaveGame (
    filename=0x1266f218 "/home/brian/.pioneer/savefiles//_quicksave")
    at Serializer.cpp:357
#3  0x00000000004902dc in Pi::HandleEvents () at Pi.cpp:627
#4  0x0000000000491b2e in Pi::Start () at Pi.cpp:921
#5  0x0000000000408c05 in main (argc=) at main.cpp:18

Separate content and code repository

The repository is growing and will grow even larger (and so will the initial clone time) when more textures, music etc. are added. At this point it might be good to start a new pioneer-content repository and only keep the current (ideally only key) resources in the main repo. Would require some changes in the code to support reading from an external directory (and fallback to default).

Heavy duty atmospheric shielding

Weighs two tonnes. Allows ship to fly in atmospheric pressures of more than two bars (remember, space ships are designed to contain pressure, not withstand it) as well as performing regular heat shielding. Makes fuel scooping safer.

Additional change: Craft entering heavy atmospheres without shielding undergo hull damage over time, proportional to pressure above 2 bars.

Ambient sound loop not stopping

Dev build:A50fbf3-win 32
Windows vista 32 sp2
Nvidia 9600m

Background ambient sound loop does not stop after landing. An example:

  1. Land on Ross 248a
  2. Switch to external view. The ambient sound is distant thunder (nice!)
  3. Switch to cockpit and take off, fly into orbit.
  4. Thunder is still audible in the cockpit as well as external view. Does not stop even if you hyperspace to another system.

Draw depth is inconsistent

Object depth is often not computed correctly. Having shaders on or off changes the way depth is calculated, but its still wrong in certain circumstances.

Shaders on:

Shaders off (see the overlapping boxes at the back):

ships should be able to dock with each-other

  • docked ships could exchange cargo, fuel
  • tow-ships could repair other (player) ship, install drive... (as a reaction for distress call)
  • exchange crew/passengers

in the far future, some mother ship functionality could be added to this functionality... possibly useful in multiplayer, should that be implemented once

Rings around Saturn don't always appear

Rings around Saturn are inconsistent. We already know that rings are quirky, but it seems we've got people with them variously present/absent (see [http://www.spacesimcentral.com/forum/viewtopic.php?f=35&t=1579&start=140#p18384](this forum thread) for reports).

My guess is that their appearance is based on the system seed. We might just need to suck it up and add a :rings param to the custom system defs.

Ships occasionally fail to dock with space station

Sometimes, the player's ship cannot dock with a (wheel-type) space station. This is difficult to reproduce, but when it happens it's impossible to dock either manually or with the autopilot. Manual docking leaves the ship drifting down the entrance tube, while the autopilot remains stopped at the entrance.

Usually, there is at least one non-player ship already docked, although I have seen this bug exhibit on an empty station.

Build system changes

configure.ac and defines to allow the following:

  • compile with -DDEBUG
  • compile out the object viewer

(more to come)

Ground-based stations not placed on flat land

Original subject: Bentley Starport (Canqu [-2,-4]) is in wrong position.

Bentley Starport (Canqu [-2,-4]) is in wrong position. There is no possible to land in bay 2 due to collision with the planet surface. Alpha 9.01.

Logged by Mysibrat on SpaceSimCentral

Odd behaviour when quitting the game while the tombstone is rotating

To replicate:

  1. Start new game at debug point.
  2. Wait patiently for death.
  3. When the tombstone spins, press Escape.
  4. Press the "Exit this game" button. "Select file to load" appears.
  5. Press Cancel.
  6. Press the "Exit this game" button a second time.

You now have a black screen. Breaking into the app with the debugger at this point reveals it to be waiting on a Unix syscall, so this *might * not appear the same way on Windows.

This bug does not exhibit if one starts at Earth and crashes the ship to get a tombstone.

Deadzone support for Joysticks

Joystick is far too sensitive around the center, this is mainly a problem with devices that do not have sufficient driver support, which in windows7, is an inordinately high amount of devices.

I had a go, but the code makes almost no sense to me, and things that I thought did one thing in fact did not ;)

Economical autopilot

An autopilot that allows the player to use less fuel for longer journey times, by coasting through deep space rather than constantly burning. Could be an additional upgrade, such as a replacement autopilot upgrade, avoiding UI issues entirely.

A test issue

I just want to see what options are available so I can get the settings right.

Sirius fails as a system.

(Built from commit 8b53f82; not a bug in Alpha 9)

Sirius, whilst its stars are defined, is a randomly generated system. It gets a B for effort, but an F for application.

The orbits of Sirius B M's moons overlap significantly with those of Sirius B's planets. The orbits look like somebody chucked two rocks into a pond. This isn't physically possible. In the real world, they couldn't cooperate in that way, and in the game the frames of reference are so screwed up that it's actually impossible to visit most of the worlds there.

Some sort of sanity check needs to be put onto the system generator, even if it leads to slightly more boring systems.

Load/generate system while in hyperspace

Right now when you're in hyperspace nothing actually happens until you hit the end of it. There's then a pause while the system is generated before you can emerge from hyperspace. This can be on the order a few seconds for a complex system (eg Sol).

It should be possible to build the system in a thread while hyperspace. Most of the time hyperspace will be long enough and the generation short enough that it would be ready by the time the end of hyperspace is reached. In the events that its not then we can just wait, as it will likely be a very short wait. An advanced implementation could actually extend the hyperspace display until the system is generated.

Control panel buttons don't always reflect current view state

Example:

  • From normal flight (eg debug start), click comms. Comms button is now highlighted.
  • Click camera. Comms button is no longer highlighted, but comms options are on screen.
  • Click comms. Comms button is now highlighted, but comms options disappear.

I've seen similar things with the multifunction buttons (equipment, messages), the labels button (F10) and inconsistencies when switching to settings (Esc) and back.

Convenient way to cancel hyperspace

Right now once hyperspace is initiated there's only one way to cancel it, which is to change the hyperspace destination. That's fiddly. What would be nice is to be able to click the hyperspace button again to cancel it.

Crew manifest, accommodation and combat

This led from a discussion with Rob a couple of weeks ago.

One should be able to hire, and retain, crew without having available crew spaces. They would occupy passenger cabins instead of crew cabins, enabling the player to find and hire crew members from many ports, instead of the Frontier-style long, long wait for crew on the BBS.

Crew should, ideally, have skills. Perhaps a good pilot can fly your ship as if it had an autopilot, even where one isn't fitted. Perhaps a good navigator can squeeze an extra half light year onto a long jump. Weapons officers could make use of your turrets for you during a fight.

Perhaps a crew can vary in number; a bare minimum required number of crew (a "skeleton" crew), then an optional complement which can bring the ship to full readiness. Perhaps a large ship with only one or two aboard can't use some or all weapons, or has limited acceleration, or cannot carry as much cargo.

Remove labels on distant non-system-body objects

It looks quite odd to look around space and see ship registration labels, "Hyperspace arrival cloud" labels and so on for things that are many AU away. Objects that aren't system bodies (ie ships, missiles, cargo, hyperspace clouds, etc) should only show labels if they're reasonably close to the player.

I don't know if that means they should not be selectable. They were in Frontier but that doesn't mean we have to do it. It could be difficult to target them any other way though.

Distance/time to hyperspace destination

During hyperspace the control panel has this huge empty space.

I'd rather like to put a "distance to destination" or "time to destination" number in there. Distance would look better (light years!), time would be marginally more useful. Straight up eye candy, but why not :)

3D thruster control with joystick

I think the 3D thruster control already available by keys on keypad should also be available from the joystick, in the following way:
The main thruster/break thruster control might be bound to custom keys, or the joy's thruster controls, but the thrusters controlling the thrusters in the plane perpendicular to the axis of the main thrusters, should be controllable by the "hat switch" of the joy. Possibly inverse config should be available for those who would like it that way...

Refactor Body inheritance tree to remove Object and CityOnPlanet

CityOnPlanet should not inherit from class Object. It makes it necessary to have special-case checks for rendering and collision detection. Instead it should be a seperate discrete class, with multiple instances attached to a planet/starport. The render and collision detection can be done as part of the planet draw.

Once thats gone, everything in the Object tree is also a Body, so Object and Body can be merged. Then there is no ambiguity - anything that inherits from Body is something that can exist in the world space.

Lua teardown is a mess

There's a few stack-allocated Lua object wrappers, such as the event handlers. It makes sense for them to be stack-allocated. The difficulty is that they are destroyed at program exit, but they require the LuaManager singleton to be available and the internal LuaObject tracking data to be valid. If either of these fail we get a crash at exit.

@f4e6c658 works around the first problem by forcing the LuaManager to be constructed early and thus destroyed after the object wrappers. This is done at the expense of some compile-time safety and abstraction, but in practice it shouldn't be a problem.

@b0112b62 takes care of the second by allocating LuaObject internal data on the heap and never freeing it. This is not great.

This needs to be fixed properly. I don't know right now what the best solution is. I suspect it would be greatly alleviated if Pioneer used correct object lifetime management throughout, but that's bordering on impossible right now. There may be an easier but still correct solution.

Crash when trying to purchase ship

In the latest dev build I can't buy a ship without getting dropped to the desktop.

Dev build: f2d735f-win32
Windows Vista 32 Sp2
Nvidia 9600m

  1. Start Pioneer, select "Start new game on Earth".
  2. Use money cheat, buy ship (I tried a viper police craft and asp explorer), get dumped to desktop with following report:

Assertion failed!
file: ship.cpp
line 1015
expression f=>type==m_shipFlavour.type

Game state isn't completely reset upon new game

To reproduce:

  1. Start new game on Earth.
  2. Launch.
  3. Fire a shot.
  4. Try to doge cops, crash into floor, tombstone.
  5. Select new game on Earth.
  6. Launch.
  7. Come under fire from cops, who are still angry from the last time they killed you.

Clearly, some state here is retained when it shouldn't be.

Hyperspacing from Sol whilst on autopilot causes segfault

commit 2f3770d

To reproduce:

  1. Start new game in Sol.
  2. Target nearby star system.
  3. Launch, target any system object.
  4. Task autopilot to fly to it, orbit it, whatever.
  5. Hyperspace.

Segmentation fault will not occur from an Epsilon Eridani start, but will from a Sol start. Segmentation fault will not always occur. Segmentation fault will occur either during hyperspace star-streak, or immediately after arrival in new system. Accordingly, here are two different backtraces.

Fault on arrival at new system (seen only once):

Program received signal SIGSEGV, Segmentation fault.
0x0000000000413c40 in operator* (a=..., b=...) at matrix4x4.h:205
205         m.cell[0] = a.cell[0]*b.cell[0] + a.cell[4]*b.cell[1] + a.cell[8]*b.cell[2] + a.cell[12]*b.cell[3];
(gdb) bt
#0  0x0000000000413c40 in operator* (a=..., b=...) at matrix4x4.h:205
#1  0x000000000043181a in Frame::ApplyLeavingTransform (this=0x0, m=...)
    at Frame.cpp:120
#2  0x0000000000431e43 in Frame::GetFrameTransform (fFrom=0x132fae10, 
    fTo=0x113943e0, m=...) at Frame.cpp:166
#3  0x0000000000549592 in GetPosInFrame (frame=0x113943e0, target=0x132fae10, 
    offset=...) at ShipAICmd.cpp:607
#4  0x000000000054a575 in AICmdFlyTo::CheckCollisions (this=0x1ace0260)
    at ShipAICmd.cpp:738
#5  0x000000000054c46b in AICmdFlyTo::TimeStepUpdate (this=0x1ace0260)
    at ShipAICmd.cpp:929
#6  0x00000000004a21d8 in Ship::AITimeStep (this=0x10bb9bd0, 
    timeStep=0.0166666675) at Ship-AI.cpp:76
#7  0x00000000004216f4 in Ship::StaticUpdate (this=0x10bb9bd0, 
    timeStep=0.0166666675) at Ship.cpp:588
#8  0x00000000004274b6 in Player::StaticUpdate (this=0x10bb9bd0, 
    timeStep=0.0166666675) at Player.cpp:106
#9  0x0000000000417f62 in Space::TimeStep (step=0.0166666675) at Space.cpp:568
#10 0x00000000004b3ed4 in Pi::MainLoop () at Pi.cpp:947
#11 0x00000000004b36b6 in Pi::Start () at Pi.cpp:808
#12 0x00000000004088f4 in main (argc=1) at main.cpp:18

Fault during hyperspace (often repeated):

Program received signal SIGSEGV, Segmentation fault.
0x00000000004326fe in Frame::GetBodyFor (this=0x12b0be00) at Frame.cpp:239
239         return (*m_children.begin())->m_astroBody;
(gdb) bt
#0  0x00000000004326fe in Frame::GetBodyFor (this=0x12b0be00) at Frame.cpp:239
#1  0x000000000054a663 in AICmdFlyTo::CheckCollisions (this=0x171367d0)
    at ShipAICmd.cpp:744
#2  0x000000000054c46b in AICmdFlyTo::TimeStepUpdate (this=0x171367d0)
    at ShipAICmd.cpp:929
#3  0x00000000004a21d8 in Ship::AITimeStep (this=0x1055a030, 
    timeStep=1666.66675) at Ship-AI.cpp:76
#4  0x00000000004216f4 in Ship::StaticUpdate (this=0x1055a030, 
    timeStep=1666.66675) at Ship.cpp:588
#5  0x00000000004274b6 in Player::StaticUpdate (this=0x1055a030, 
    timeStep=1666.66675) at Player.cpp:106
#6  0x0000000000417f62 in Space::TimeStep (step=1666.66675) at Space.cpp:568
#7  0x00000000004b3ed4 in Pi::MainLoop () at Pi.cpp:947
#8  0x00000000004b36b6 in Pi::Start () at Pi.cpp:808
#9  0x00000000004088f4 in main (argc=1) at main.cpp:18

Invert mouselook

Mouse up/down currently maps to pitch backward/forward, which is the opposite of what most people expect. Some people like it that way though, so this should be configurable.

Pioneer doesn't run on 64-bit Linux.

It gives

"./pioneer: error while loading shared libraries: libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory".

zbias for "sub-models"

since i know pioneer we have zbias sometimes in front of a models call.
but that didn't works, it works only from within the actual model.
means i can set zbias for a .obj or for a created shape, but it's useless for "call_model" (somehow i understand, how should it be set in which direction of normals? so maybe it's simply not possible).

i would like to have the setting working for the sub-model to, because else you have to set the zbias very high for some models, because you don't know in advance how they will be used in future.

Trade ships module extensions

TradeShips.lua is fairly simple right now - some ships spawn already docked, others fly to a starport and dock.

The following is needed for Alpha 10:

  • Ships should leave the dock after some random (but realistic) amount of time. This is actually quite important. Without it gets hard for the player to find a place to land.
  • After leaving the dock, ships should either hyperspace away or should fly to another port in the same system.
  • Ships should load/unload cargo as appropriate to the system
  • Ships should spawn (via hyperspace coulds) at regular intervals, not just when the player enters the system.
  • Ships will save/load since they are active in the system. The module should save their current state also so it can hook them up after game load.

Can fly through near vertical cliff faces

Pioneer 771cbcc win 32
Vista 32
Nvidia 9600m

On Io, in one of the many steep vertical cliff valleys, it is possible to fly the ship through the walls and underground. Once you fly through the cliff you can see through the planet and eventually start taking damage.

gravitational effects on hyperjump

I think the following enhancement would make the game more "realistic" (well, for a fictional physical phenomenon this is funny :)) :

So: as one could have read in Isaac Asimov's novels, gravity interferes with hyperspace-travel. I think some penalty should be applied when one is attempting hyperjump from:

  • higher gravitational potential (near a planet, gas-giant, close from a star)
  • the line from the hyperspace entry position to the target system is through a giant, a star, or other great potential-well

from the above, i think the following gameplay enhancement could come:
emergency hyperjump could have a use from this point: when one is near crashing a star, emergency jump would.. say, put it to random place in system, when gravitational potential is great enough, but not greater then a critical value (hyperdrive can't escape from anywhere...). This would trash the drive, but the planetary drive could take you to safe harbour. Or you could make a distress call...

Disabled Ctrl-F11 does quicksave instead of nothing

Ctrl-F11 is the full-screen key. Its code is commented out, including a break, which makes it fall through to the Ctrl-F9 case. I have un-commented that break. I've removed the commit link, since there's a pull request, and it went ahead and logged the issue again.

Crash when the is no user input for a while

I hear that this has been noted in alpha 9x. The game crashes with the red screen of death stating that a station hasn't the proper approach vectors or something. Anyway this time I got the following message;

Assertion failed!

Program: ...it 2010\pioneer-5d61822-win32\pioneer.exe
File: SpaceStationView.cpp
Line:859

I was flying around Earth and had the autopilot set to dock at LA leaving my ship to fend for itself for about 10 minutes when this occurred. Hope this helps!

distress call should have some effect

It should result in some (positive?) effect:

  • "I'm under attack" should make a police go for your rescue?
  • some repair/tow ship could be launched for broken down ships... even into interstellar regions.
  • might attract pirates!

Ship not giving up frame of reference after autopilot flight

Pioneer dev build 771cbcc win 32
Windows vista 32
Nvidia 9600m

After autopiloting to a planet using the "fly to vicinity of..." or "enter high orbit around..." command, the frame of reference is not always the planet/moon I set as my destination. An example:

  1. Take off from Earth and autopilot to "vicinity of mars" (the frame of reference eventually changes from Earth to Mars as you get closer and stop)
  2. Select Phobos as a navigation target and use the autopilot to fly to the vicinity of Phobos (the ship stops a distance away from Phobos, but the frame of reference is still Mars-even though I am closer to Phobos) If you activate the set speed control, the ship will begin accelerating relative to Mars. Entering high orbit around Phobos also doesn't change the frame of reference. Not until I enter a low or medium orbit does the frame of reference finally change to Phobos.

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.