Reimagining 2D graphics and game development with Ruby
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 69 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/37792 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
Ruby Conference 201725 / 69
2
5
8
11
13
19
20
21
32
33
34
35
37
40
43
44
52
54
55
56
57
58
62
64
65
67
00:00
Coxeter-GruppeVerschlingungCodePhysikalische TheorieProdukt <Mathematik>StichprobenumfangCodeBitCodierungDatensatzXMLUMLComputeranimation
00:39
SpieltheorieVollständiger VerbandMultiplikationsoperatorQuick-SortHilfesystemCode
01:24
Quick-SortNeuroinformatikProgrammierparadigmaRadikal <Mathematik>Mustersprache
01:51
PixelMapping <Computergraphik>Quick-SortDifferenteVisualisierungEinsMaschinenschreibenEin-AusgabeGraphfärbungSondierungComputeranimation
02:48
QuadratzahlHilfesystemResultanteBildverstehenInteraktives FernsehenTypentheorieReelle ZahlSpieltheorieProgrammierumgebungKonstruktor <Informatik>Quick-SortWechselsprungTouchscreenProgrammbibliothek
03:41
SpieltheoriePrototypingBitDifferenteMixed RealityProdukt <Mathematik>ComputerarchitekturHypermediaBridge <Kommunikationstechnik>ComputeranimationVorlesung/Konferenz
04:27
SystemplattformInstallation <Informatik>Fundamentalsatz der AlgebraReelle ZahlFlächeninhaltDifferenteMixed RealityNegative ZahlQuick-SortOrtsoperatorBenutzerbeteiligungWorkstation <Musikinstrument>Prozess <Informatik>MereologieComputerspielFundamentalsatz der AlgebraLesen <Datenverarbeitung>Computeranimation
05:57
QuadratzahlQuick-SortKartesische KoordinatenLokales MinimumMereologieHardwareFontComputeranimation
06:27
Physikalisches SystemDatensichtgerätKlasse <Mathematik>ProgrammbibliothekTouchscreenBildschirmfensterBeobachtungsstudieApp <Programm>Computeranimation
06:57
Formale GrammatikFramework <Informatik>BildschirmfensterFunktion <Mathematik>ProgrammbibliothekGüte der AnpassungComputeranimation
07:28
EreignishorizontKontextbezogenes SystemSchnelltasteSpezialrechnerGamecontrollerPhysikalisches SystemDatenverwaltungBildschirmfensterMultiplikationsoperatorQuellcodePhysikalisches SystemKontextbezogenes SystemDatensichtgerätComputeranimation
08:06
ThreadVideokonferenzInformationSystemplattformAbstraktionsebeneRückkopplungKraftEin-AusgabeEreignishorizontTVD-VerfahrenFehlermeldungSoundverarbeitungProjektive EbeneBildschirmfensterQuick-SortSoftwareentwicklerEinsHypermediaSpieltheorieDifferenzenrechnungWiderspruchsfreiheitGlättungMultiplikationsoperatorComputeranimation
09:28
Inklusion <Mathematik>SchlussregelSpieltheorieQuick-SortMAPBildschirmfensterSystemplattformGüte der AnpassungDemo <Programm>ZahlenbereichComputeranimation
10:03
Formale SpracheWeg <Topologie>QuadratzahlWeb-ApplikationNetzbetriebssystemKartesische KoordinatenHardwareEinfach zusammenhängender RaumMAPQuick-SortPerfekte GruppeStandardabweichungBildschirmfensterGrundraumMultiplikationsoperatorPhysikalisches SystemSchnittmengeArithmetisches MittelDatenstrukturKategorie <Mathematik>Interaktives FernsehenGruppenoperationXMLComputeranimation
11:47
SystemplattformGraphikprozessorPixelPerspektiveProgrammierungMereologieKnotenmengeNetzbetriebssystemRenderingEreignishorizontRuhmassePunktDatensatzÄußere Algebra eines ModulsGruppenoperationGraphFormale SpracheProgrammbibliothekProjektive EbenePhysikalisches SystemFunktionalDatensichtgerätAbstandSystemaufrufQuick-SortWeg <Topologie>WellenpaketStörungstheorieZahlenbereichRichtungKoordinatenSystemplattformDreieckInterface <Schaltung>GraphikbibliothekShape <Informatik>PerspektivePortabilitätOffene MengeComputeranimation
14:01
PerspektiveAxonometrieGraphRechter WinkelOrdnung <Mathematik>CASE <Informatik>MatrizenrechnungMathematikMinkowski-MetrikAbstandWürfelDimensionsanalyseQuick-SortArithmetisches MittelComputeranimationDiagramm
14:48
PixelPunktRahmenproblemRationale ZahlHardwareQuick-SortGraphfärbungShape <Informatik>Figurierte ZahlInterpolationMathematikZwischenwertsatzFunktionalBitmap-GraphikComputeranimation
15:18
PixelPuffer <Netzplantechnik>HalbleiterspeicherBildbearbeitungsprogrammMultiplikationsoperatorDreieckDatensichtgerätRahmenproblemWasserdampftafelComputeranimation
15:46
PunktSchnittmengeVersionsverwaltungComputeranimation
16:26
LoopEreignishorizontCodeCodeSystemaufrufKartesische KoordinatenQuick-SortEreignishorizontNichtlinearer OperatorElektronische PublikationNetzbetriebssystemBildgebendes VerfahrenPhysikalisches SystemWort <Informatik>GruppenoperationSichtenkonzeptComputeranimation
17:20
VolumenvisualisierungWinkelDreieckDreieckSystemplattformVolumenvisualisierungFunktionalBildschirmfensterRechter WinkelDatenstrukturImplementierungPunktCASE <Informatik>MaschinenspracheLesen <Datenverarbeitung>Grundsätze ordnungsmäßiger DatenverarbeitungHalbleiterspeicherElektronische PublikationComputeranimation
18:12
QuadratzahlBenutzerfreundlichkeitFlächeninhaltLemma <Logik>App <Programm>Byte-CodeRegulärer GraphElektronische PublikationArithmetisches MittelMereologieKontextbezogenes SystemVirtuelle MaschineComputeranimation
18:52
ViereckObjektorientierte ProgrammierspracheViereckFunktionalDifferenteMaßerweiterungVolumenvisualisierungMereologiePunktGesetz <Physik>HalbleiterspeicherMusterspracheComputeranimation
20:19
MaßerweiterungSystemplattformMaßerweiterungKartesische KoordinatenWort <Informatik>AusnahmebehandlungPortabilitätComputeranimation
20:48
BrowserBrowserVersionsverwaltungBenutzerbeteiligungQuick-SortGruppenoperationMinimumComputeranimation
21:39
BrowserQuadratzahlBrowserCompilerMobiles InternetProgrammbibliothekDatenstrukturComputeranimation
22:06
ViereckVolumenvisualisierungBrowserMaßerweiterungRadikal <Mathematik>FunktionalViereckReelle ZahlMultiplikationsoperatorMaßerweiterungBrowserInterface <Schaltung>MaschinenspracheRechter WinkelKlasse <Mathematik>DialektAlgorithmische ProgrammierspracheProzess <Informatik>Grundsätze ordnungsmäßiger DatenverarbeitungTermElektronische PublikationTopologieComputeranimation
23:46
PunktGrenzschichtablösungSoftwareAusnahmebehandlungPhysikalisches SystemQuick-SortVollständigkeitMaßerweiterungNichtlinearer OperatorProgrammiergerätBrowserComputeranimation
24:23
SystemplattformViereckRechteckBildschirmfensterDreieckQuadratzahlSpezialrechnerKartesische KoordinatenPortabilitätReelle ZahlMAPDatenfeldPhysikalische TheorieComputeranimation
24:56
Objekt <Kategorie>CliquenweiteRechteckQuadratzahlImplementierungKlasse <Mathematik>SystemaufrufLoopEreignishorizontAttributierte GrammatikBildschirmfensterGruppenoperationQuadratzahlRechteckImplementierungGraphfärbungComputeranimation
25:31
ZeitbereichFormale SpracheUmwandlungsenthalpieDomain <Netzwerk>Rechter WinkelMereologieProdukt <Mathematik>ProgrammierungProblemorientierte ProgrammierspracheBitComputeranimation
25:57
HypercubeSkriptsprachePhysikalisches SystemFunktion <Mathematik>Nichtlinearer OperatorHilfesystemBrowserFormale SprachePartikelsystemObjekt <Kategorie>
26:33
HypercubeCursorCursorAttributierte GrammatikBildschirmfensterWort <Informatik>FehlermeldungComputeranimation
27:12
HypercubeMinkowski-MetrikEreignishorizontZeitrichtungEreignishorizontSchlüsselverwaltungQuick-SortSymboltabelleBildschirmfensterApp <Programm>Rechter WinkelKartesische KoordinatenComputeranimation
27:50
QuadratzahlEgo-ShooterApp <Programm>BildschirmfensterBitSpieltheorieSoftwaretestErwartungswertGüte der AnpassungProzessautomationKartesische KoordinatenMereologieComputeranimation
28:34
GamecontrollerServerSelbst organisierendes SystemEinsMultiplikationsoperatorEreignishorizontRechter WinkelMapping <Computergraphik>
29:02
GamecontrollerInterface <Schaltung>GenerizitätMapping <Computergraphik>DifferenteEin-AusgabeGamecontrollerComputeranimationFlussdiagramm
29:49
SimulationSystemplattformApp <Programm>HypermediaAutomatische HandlungsplanungGebäude <Mathematik>Ein-AusgabeComputeranimation
30:17
SimulationMaßerweiterungCodeSoftwaretestDienst <Informatik>DatenstrukturKartesische KoordinatenElektronische PublikationVirtuelle MaschineMaßerweiterungEinfache GenauigkeitRechenschieberSchlüsselverwaltungComputeranimation
30:48
Framework <Informatik>AbstandVerschlingungRepository <Informatik>SpieltheorieGüte der AnpassungInformationsspeicherungEinsFlächentheorieAutomatische HandlungsplanungQuick-SortOffene MengeMAPGanze FunktionSchnittmengeZellularer AutomatGebäude <Mathematik>Framework <Informatik>Kontrast <Statistik>Computeranimation
31:53
GraphfärbungWort <Informatik>ProgrammierumgebungSimulationMinkowski-MetrikGravitationKette <Mathematik>VerschlingungGeschwindigkeitPhysikalismusPunktGemeinsamer SpeicherSpieltheorieQuick-SortSchaltnetzEinfache GenauigkeitCursorTVD-VerfahrenDemo <Programm>Computeranimation
33:33
COMXML
Transkript: Englisch(automatisch erzeugt)
00:11
My name's Tom Black, I'm a developer, designer, product strategist, a little bit of everything to try to make this happen. You can find me online, most places at BlackTM,
00:22
GitHub, Twitter, and I use Ruby for both work and fun, but I'm gonna talk about it later. So before we get started also, I'm gonna put notes up for this. It's gonna be code samples and links, and so just so you don't have to heat trap all this stuff, it'll be in one place afterwards. Today I'm gonna talk about
00:41
some of my experiences and thoughts about how we can reimagine, rethink, 2D graphics and game development. And so for me this journey started here in New York City, particularly in the Flatiron District, I was spending a lot of time. And I was new to the city, sort of taking it all in, meeting people,
01:02
and this whole, around 2012, this Learn to Code movement was like at its peak, so the mayor was about to learn to code. But it was exciting for me, despite all kind of the hype, it was tough for me to learn, and I was really excited to share that experience with others, help them out, be a mentor,
01:21
all the things I kind of didn't have to get back in the way. And so I've got meetups, after school programs, bootups, pants, like this one, Flatiron School. This is the first pant that's talked about for me too, I think, in this talk, so long ago. In the teaching, I sort of noticed something. This is just sort of the pattern that everybody's doing,
01:41
this is the paradigm, it's terminal and keyboard, and it's pretty familiar to us, and that's how we make software, but when you're learning, it's sort of kind of limiting, like this is all computers can do, it's kind of this whole paradigm. It reminded me of like computers of yesterday, the ones that you kind of grew up with. And it kind of seemed like not a lot has sort of changed, but in many ways, things have changed a lot.
02:02
We've got much better visuals, we can see millions of colors, pixels we can't even discern anymore, rich audio, speakers built in, we've got still the keyboard of yesteryear, which we'll probably have forever, but also speakers, real sound.
02:23
And we can have all sorts of different input devices to connect things, and so there's a lot you can do, and this is what's nice about this is it maps well to real learning styles. This is how people actually learn. Visual auditory, things people can see, hear, touch.
02:45
That's how real learning takes place. So I was really interested in figuring out how do we take that experience, all of those sort of senses, and bring that into something that could teach using grouping to make people more accessible.
03:00
So in 2012, I made this demo, it's kind of a vision. I imagined you could go to the terminal, kind of still like you usually do, type in some stuff, and see results happen on the screen. And maybe build up some skills, and use more kind of constructs there, and see things happen, maybe make some mini games or something, and then plug in other device controllers,
03:24
and kind of jump around. This is a Ruby impaired person. So just a much more interactive learning environment. And so that was sort of the vision. It was built with real code, and real Ruby's libraries actually, to just sort of help validate this idea.
03:41
But like every good prototype, it's really a facade, a trick. It's there to validate idea for that idea, but it'd be really nothing more. So I kind of tested it out, plate tested it, see how people would learn, and just kind of get to feedback. And that was enough to convince me to kind of dig in, and see if I can build something a little bit more.
04:01
So I did some research to see just sort of what was out there. Was anybody else thinking about this stuff, or people developing graphics and stuff broadly in the Ruby community? And it turns out that they are. Actually, I'm going back to like 2000, so a pretty rich history. And there's a lot of ideas in here. There's things that are kind of used for just graphics, some for do-y things, a lot of different approaches.
04:23
There's a kind of a neat mix of these. So I kind of thought, well, what would be my must-hats if I were to choose one of these, or mix it up, or take ideas? What would that sort of look like? Well, we probably want to have cross-platform, native and web, make this stuff easy
04:42
to understand internally. That's kind of nice. You could learn, you could do something, and then see how it might work on the inside. Make real things, so it's not just like a lot of sandboxes that we would see. Could be good for a lot of different things, not just education, but you could make a real game, or you could kind of like throw your own skills there.
05:01
And it would just be easy to get started. The quicker you get to having an idea, to seeing it, interacting with it, is pretty critical. And so, and just making it inviting it. So I thought, this is kind of a hefty list, but starting something new, thinking about how we could
05:20
take some existing ideas and mash them together. There's a lot of positives to that. You get to build on many ideas, incorporate new tech and methods, and so forth. Revisit these fundamentals, you can kind of say, like, do these things need to exist, or is this kind of an outdated approach? You've got the freedom to experiment. For me, it was nice, because I wanted to gain new skills.
05:40
This is a weird, I think a lot of stupid web stuff. That's probably how we got into Ruby, so I wanted to get delved into this new area. But the downside is, there's a lot to learn to do. That's a big negative. But I persevered here, and thought, well, where do I start? And I thought about this simple,
06:02
starting at the end of mine, what experience would you want in just this minimal case? And so I thought of this MVP, minimal viable product, just like a square dot new sort of application. And then what would it take to really build that? I know there's some hardware at the bottom somewhere, but what goes sort of in the middle?
06:22
I imagine a lot of stuff. First thing I did is just kind of broke it down and said, well, what if we just start with a window? That's pretty much the most fundamental thing that you have. And if you go around and you Google it, you'll find most operating systems provide some low-level library that you can access
06:41
to make those things. And so this is, on Mac you have all these NS classes. This is NS window, and if you read it, it just says a window that an app displays on the screen. So I thought, okay, that's pretty good. So if you go and do some study in trial and error,
07:00
you can actually build a window. And this is really all you need to do that. This is written in Objective-C. And you talk with this COCO class, you just kind of say what you want and run it, and you can file it first, linking to the COCO libraries there, and we'll just output it as window. And if you want to run it, this is what you get.
07:22
Basically, a window that does nothing. But it's a good start, and it works. From there, there's a lot more to do. So it's not just a window, but you gotta put a graphics context in. You gotta think about, well, how are you gonna get inputs in from all the different sources, manage it. Maybe you're gonna talk to other system things,
07:41
display and system timers, all this. You start to think about all the things you need to develop this experience looking ahead, and a lot goes into that. And I am on a Mac, but I want to include all operating systems. You gotta do that for everywhere. So that's what basically does look like other platforms.
08:04
And a lot of stuff, you're gonna have to go in. And pretty much, it starts to become pretty overwhelming, and you have to do this. And you think about all the variations and all the rest. It's just, it gets to be where you might be stuck, and you start feeling like this. Like there's no end in sight, and this could be a dead end.
08:22
But what is it? Well, it turns out that, thankfully not, game developers have been thinking about these issues for a long time. A lot of these efforts started back in the 20 years ago when they were porting games to Linux. And so trying to think of the inconsistency between Windows and Linux and other operating systems,
08:42
weird things, making these things work everywhere, was a pretty big effort to walk their games through everywhere. And so these are called media libraries, or media layers, sort of. Because that's exactly what it does. It puts a smooth layer on top of all these different operating systems, so you can root out all these inconsistencies
09:01
to just have a nice, clean API. When I looked at, those are the three major ones, I found SDL to be, which stands for the simple direct media layer, to be the most well-rounded for this project. There's a lot out there, and they're good for different things, but for what we were trying to do, this doesn't make sense. And it supports a lot,
09:21
and there's over 500 cross-platform functions, so you could really do just about anything. And it just so happens that it's used by triple-A titles and indie games alike, so my general rule of it, if it's good enough for Half-Life, it's probably good enough for whatever it would be.
09:42
So this is what it looks like. This is written in C. And this is all it takes, basically, build a window on every platform. And now we don't have to think about any of these inconsistencies, it's sort of like Jamming, Jamming to the demo level. And I have a talk linked about game developer, being involved with SDL, getting that to each other.
10:03
Good. So I think we're back on track there. We have a path forward. At this point, we might be wondering, why are we talking about C so much? This must be like a Ruby conference. And isn't it maybe old and crufty and all the rest of it? But it turns out that C is very contemporary.
10:22
The standard is always evolving. People are building really amazing tools and infrastructure. And if you haven't used it, it's a beautifully simple, efficient, and precise language. And while you might not want to build your next web application in C, that you'd probably have a bad time, it's perfect for programming systems,
10:42
and exchange, and all these lower level things. It's really good for it. And it just so happens that Ruby loves C. It's primary implementation, MRI, but I guess we'll probably have to see Ruby now, is written in C. And so does mRuby. And so Ruby has this nice connection with the native world.
11:02
It means that just because it's an interpretive language, it's not sort of just labeled. So then if we go back to our red square application here, square.new, where are we right now? What do we have? Kind of reviewing what we just talked about.
11:21
We have an operating system. We know that it provides essential access to hardware and Windows and all the rest. We know that we don't have to think about all operating systems like that. We can use SDL to kind of make that a cool experience. And we can sort of move the hardware out of the way because we don't need to think about it too explicitly. So that's really nice.
11:40
But what else? What else might we need to make this possible? Because we're not quite there yet. Well, one of the things we haven't talked about is these graphics. How do you actually make things visual? Well, it turns out, again, we don't have to talk directly to hardware. There's a lot of these cross-platform graphics APIs.
12:01
OpenGL is a common one. It stands for the Open Graphics Layer. And it's for rendering 2D and 3D, maybe sort of direct 3D or direct 2D, or Metal is the new hot thing on Apple platforms. These are all just APIs to talk to graphics and kind of take a hand over
12:20
some of those low-level things and provide you a nice interface to do that. So from your perspective as a programmer, it looks like writing your C program. You'll make OpenGL calls. Usually it's GL blah, blah, blah, something. And in orchestration with the operating system and the graphics libraries on there,
12:42
it'll talk to the GPU, and then finally that is all on display. So that's a massive oversimplification, but that's just sort of the experience. And we can dive into it and talk about the rendering pipeline as it's known. This is how rendering works in modern graphics programming. And it's important to talk about, is we actually have to program these things.
13:03
Sort of not hand it to us. The first thing you have to do is take actual points into one of the drawers. This is a triangle. This is the simplest 2D shape you can basically draw. And all the vertex data, all these points, are described in just floating point numbers. So that's what a C array would look like.
13:23
The next thing we have to write a vertex function. This is just a function, and it sort of looks like a C language with a few extra things in there. And that's where we can actually take those points and map them to a coordinate system, put it anywhere we want. We can even do any kind of manipulation that way, but it's just about the coordinate system.
13:43
Then also we're gonna need a projection. It's like how we see the world. And so in the world that we live in, we have perspective. We can see train tracks fading into the distance to a vanishing point. But we don't actually do anything 2D. We wanna see things in kind of this orthographic way,
14:02
which means it's a world with no depths. You can imagine everything you see in the world is being jammed right in front. So this is kind of what I'm looking for. And if we implement that in the graphics world, we need to write a orthographic matrix, which is not too complicated. It's described here.
14:21
It's math. And that's a means of representing 3D dimensions basically in this 2D space. And it's a distance. It's the distance from the camera. You can see that in the cube there. And also we can do things in this vertex arena, like move the origin to the upper left corner,
14:42
which is kind of nice is when you expand it as it goes and change some corners there. Then after that, we have this sort of shape, but it's still represented sort of mathematically. We actually have to apply it integrally. What pixels do we shade in? And that's called rasterization. And a lot of that's sort of done for you, which is nice.
15:02
But then you get to write a fragment function to fill in the colors, think about those intermediate values. Those, that interpolation that happens is actually done by the hardware and then the rest of it will do it for you. But you can choose those points and then it'll kind of figure out what the rest of it looks like. Finally, you add a nice triangle in this.
15:23
So, oh, and the last step is you write this to your memory frame buffer, which is what gets displayed. Write that to the back, but then it gets swap buffers and it gets a book floor and then it happens like 60 times a second, if you're lucky. So it seems pretty easy, I guess, or at least clear, but the graphics program experience is pretty wild.
15:43
So you feel all of these things at various times, but even when you screw up pretty badly, I don't actually know what this was supposed to be, but it looks like a wallpaper, or PNGs or something. I don't know what the rest of it is, but it looks pretty cool. Maybe you could even do art somewhere.
16:01
You can't do that. I don't know. I don't see how it works. Like an exhibit, just broken graphics. So this is cool. This approach works and now we implemented it in OpenGL, the legacy versions, the more modern approaches, which I described in the pipeline, and then also for mobile and embedded,
16:21
this is the pocket chip. So basically we can drive it. So if you go back to our stack, you see we've got the operating system, SDL. We learned about OpenGL that kind of sits there a little bit. The operating system provides these things where they're kind of over the concert. And then we have this application code for SDL,
16:43
event loops, other things, a lot of other things, OpenGL calls. Well, that's a lot to kind of just be scattered around. So we can package those things to make it a little nicely. And that's kind of what we ended up doing is creating this little side project, which makes that easier. We'll call it what it's supposed to be. The simple layer of written in C to do those things.
17:03
That looks nice, that's the way. And all the files, if you kind of look at it, everything's very explicit in C. Shapes and images and all of these things. You can kind of look at each file and see what's sort of essential there. And I'll just point out the GL, the OpenGL code that we were talking about, that's contained in there. So you can kind of check it out.
17:21
And it's really simple. So all you need to draw across platforms is something like this and really three functions. So you create a window, you show it, and that'll go in this render to draw a triangle. You should describe what you want it to look like. Basically, it works everywhere, which is pretty amazing.
17:40
So now we're at this point where we can add Ruby, finally, after we put our simple 2D layer on top of that. We've got MRI, or C Ruby, and also M Ruby. And are folks familiar with M Ruby or have used it before? Not too much, okay.
18:02
Well, you should be familiar with it because it's pretty awesome. It's basically the small, lightweight implementation of Ruby, and it's designed for embedded use cases. And for us, it's really important because we can compile Ruby down to machine code. And so there's a lot of ways to do that. But if we take our squared out new application, which is important to us, and we run the MRV compiler,
18:22
we can actually generate this byte code. This might look crazy, but it's basically this compiled Ruby for the M Ruby virtual machine. And then this is an example. It's actually contained in a C array, which is really good for us because that means we can embed it places. And all you need to do to actually run that
18:41
is open a context and basically run that, so just pass it over. It's a really simple way to finish this one. So that's great. So we have then, we'll need to write a native extension because if we're gonna talk at the Ruby layer, we need to push those things down.
19:02
And we might think that we would need two, but fortunately, we don't actually. So we can just do this together. And this was some work, but oops. But let me figure that out. Worked twice, I really didn't wanna do it. So there are differences in the MRI native API
19:25
and the M Ruby, and so because of these differences, we kinda have to account for them. But in C, I think this'll get easier or maybe more consistent in the future. But for now, what we did is just map these things.
19:42
So like if we're in the M Ruby world, we just kinda like, that's what these defined things are. This is C stuff, but it makes it nice so you can just choose which one you want here. So just call out that in the bottom, you'll see defining module, class, and method, and that works for both. And then when you call this quad.render,
20:01
because we're gonna need a square eventually on, so we have like a quad class, I mean, then you call render on that. You would run this function that we'd have defined somewhere else and it calls that simple to the draw function. So it works, and it's pretty simple.
20:21
So going back to our stack here, we can finally add our Ruby layer, we'll put the native extension in the gem, and we can sort of celebrate because now we can actually, we have everything we need in the stack to actually do the simple application.
20:41
Well, we did say earlier that we wanted cross-platform and web, so we're not quite done, but that's okay. We can persevere. So what would we actually need to do that? Well, at the very bottom left there, we don't need OpenGL sort of explicitly, or SDL because we have a browser, and the browser sort of does a lot of those things.
21:03
So JavaScript APIs, you can get images, you can load them, you can do all these things. It's really provided by the browser. And then WebGL is a version of OpenGL that is designed just for the browser there, and we don't need simple to the, but we kind of need its port in JavaScript, and we can then also cross off both Rubies here
21:24
because in Ruby community, we also have Google, which is Ruby for the web here, and we don't need the native extension, but we do need an open extension, and that's what it looks like sort of simplified there. And if you haven't done any OpenGL before,
21:43
like I said, it's Ruby in the browser. What does that mean? Well, if we take our simple square.new application, we can compile this to JavaScript by using a simple OpenGL command. This is the gem, so you can then get access to this command tool, and then you run this,
22:01
and it's basically just saying, don't give me the whole library, but just focus on this, and then compile it to JavaScript, and we'll get this thing, which looks kind of ugly, but it's real JavaScript, and it works, and it's actually somewhat readable, but we don't need to read it because it's gonna, we can compile it, push it in, and import it. And instead of writing this native extension,
22:21
like I mentioned, we have a local extension, which basically will include these things. What's really nice about this as opposed to the native world is that it's kind of like a foreign function interface built in in FFI, that's basically a way of talking to another language, and so if you just put backticks in,
22:40
instead of it sending to the terminal, because it's really not a terminal when you're on the web, they just go out to it, and then use it for just writing kind of explicit JavaScript. So that simple 2D.js thing, you can put in your draw quad right in there, and you're kind of reopening that quad class, and just kind of adding those things to it,
23:01
and then what it'll do. So this is what this looks like. We didn't have time to do this, but there is this thing called WebAssembly on the horizon, and we could employ that, I think, pretty easily, which is by using the native extensions using mRuby,
23:23
because we can compile it, and so WebAssembly is this thing which will take, for now, C and C++, and compile it to this new format, which you can basically run in your browser. So it's like running kind of like a native application in your browser, and then that's built in with just the,
23:42
and there might be some other things, but these are some of the key pieces that we'll actually add. So if we look at the complete stack here, we've got the operating system, the SQL, the browser kind of filling the same thing, the two layers that kind of make this even more simpler
24:00
are Ruby stuff layered on top, and then finally, this Ruby2D native extension. So that is what the complete sort of package looks like, and it might seem a little complex, but it's got nice separation. Everything does what it's supposed to do, and that's kind of what we want as programmers too, the right stuff in the right places, and they're all kind of doing it together.
24:21
So we haven't really talked about this Ruby2D thing. What's that all about? Well, this is gonna be the Ruby experience for all of this. This is a gem we're working on, and we're kind of pitching it as interpretive, interpretive native web. Whatever you wanna do, you can build cross-platform to the applications of Ruby.
24:41
And so what's inside that? Well, it's got classes, as you'd probably expect, but here we have the real opportunity to build concepts from these low-level interfaces, so now we can build up these tangible things. So what does one of these classes look like? Well, the central one is the window. We saw some window examples earlier.
25:02
This is what it would look like in Ruby. This is just kind of abbreviated by the way. Get or set attributes in the window. It'll be in this update loop where you can do things, events that you can call upon, show, close, kind of those things. And here's an example with a square. This is actually the full implementation for now.
25:22
So you can see squares inheriting from a rectangle. We've got size and color, and it's updating coordinates. So it's pretty simple. And the most fun part for me, and probably creative, is finding opportunities to design
25:41
this programming experience, this domain-specific language for a new domain, like in graphics, it's kind of a little bit of a first. But there are some prior examples of folks that really put effort into thinking what that looked like. And one that was very inspiring to me was HyperCard.
26:02
So is anybody familiar with HyperTalk or HyperCard or those things? Yeah, some people, cool. HyperTalk is a scripting language for HyperCard. And this came out in 1987. And HyperCard, I'm gonna explain it for you later, but it was like a stack-based thing, and you could kind of like early web browser stuff.
26:20
And you can read about it, and you can teach me about it. But I was looking at the references and just kind of seeing what these experiences were like. There's actually a HyperCard that Ruby talked later today. So that's, I'll be going back to the beforehand. But the kind of idea here was that you could say things that were very English-like, you know, on, mouse up, play something, sound.
26:42
And it just happened. It was a very conscious effort to think about what that intuitive, expressive experience looked like. So taking some of that inspiration, what could this look like for our Ruby world? Well, if we're setting like a cursor to arrow, for example, maybe we could,
27:04
well, we actually don't have cursor implemented yet, but say it's a window, setting those attributes would kind of look the same. This is the mouse example we just saw. Maybe that would look like this, where maybe it's the sound that it's just singing about. So kind of a Ruby tribe doing that.
27:22
And then key events or other kinds of events, we could capture those simple, sort of filter them out. Everyone would say, okay, we've got an event. And then you could kind of crack it open and see what's inside and then figure out where you want to do that. So pretty nice. So here's the simplest 2D app you can really write in Ruby 2D.
27:41
And this will just create a 640 by 480 window. Just require it and show it. And that's pretty darn simple. Can't think of anything else to remove, really. And this is what our square.new app looks like. If you want this, you can get that. The window's a little bit bigger than the previous examples, but 640 by 480.
28:01
But again, you can set it to be whatever you want. Here's a test card, which you might be familiar with. I like test cards because you can quickly see if kind of everything's working. We like to write unit tests, but if you're going to do games and graphics, there's not a whole lot of, testing is interesting in people's lives, so I'll just leave it at that. Because you kind of have to play test things. You have to see things work and things will fail
28:22
in ways that you kind of didn't expect. You do have to catch them in kind of automated ways. So we wrote a test card for a little Ruby 2D application here. Kind of see things working. No more crazy, no more shards, you can write things everywhere, so that's good. And all this, this gem can do a lot.
28:41
It can automatically detect virtually any controller, even ones that you can hot plug in. So the wired, wireless, whatever. And I'd love to take credit for figuring all of that out, but really that's from like SDL. They're all motivated to do this. They want their controllers working. And so there's a giant community of people who are like, oh, who bought this controller? Let's make sure that it works.
29:00
All the mappings are correct, the rest of it. So we can take advantage of that and then write a really simple interface to do that. So you can do something awesome here. And this maps too. So even if you have a crazy controller, and I always travel now with like the Insta 2, which makes me look a little crazy at the airport, but controllers all look different.
29:21
And some have whatever they're called, different joysticks, buttons, things are laid out differently. This is a iBuffalo brand name that you're all aware of. And this one's kind of used for iOS devices and things. And so you can all,
29:41
what we do is we map them to a common generic Xbox interface, or at least that's what SDL does normally. So that's what we do. The other things we do are we can build for, build this native platform. So if you write your Ruby app, app.rb or something,
30:00
you can say build it as a native app, or for the web, or for iOS, or GBMS. Have the same experience. So that's what this looks like on iOS here. Build it. And from the same command, you can launch it as well. So when that goes through, you'll see, this is not the full test card,
30:21
but it's something that we can modify it. So basically it's stretching weird ways, but you can see, at least it works. So how's that possible? Well, all of this gets put in a single C file. Well, we have our native extension. We have your application's bytecode that's been written, piled down. And then this Ruby2D gem's bytecode in there,
30:40
all in a single file. It's in C, which means it's still not machine code, which is what we want, because then you can basically put it in an Xcode project, get the right libraries, and they're linked to the right things, and so forth. And you can see here, if you look at the frameworks, we actually have another repo
31:00
where we can build mRuby into a framework, and then we have this. So those are the only two ones that are not. And we don't really have a good publishing plan there, but you can basically open this, open Xcode, and publisher after the app store.
31:21
I mean, I think that the distance there is two degrees. So as we've sort of seen here, Ruby can really help us rethink what's possible, reimagine everything, not just at the DSL level, which is what it's, I think, really good at, but even the entire stack, and that was surprising to me. We just scratched the surface here,
31:41
but there's links to, there's been a lot of talks that are run in various places, run game development, Ruby and all these topics, and so I've linked to all those. And, but yeah, this is, I think, really the beginning. And, you know, I think we've talked about
32:01
how we can really, education, gaming, graphics, all these kind of tie together, and so there's one more demo that I wanna show that kind of combines it all here. And to do that, we're gonna have to put Ruby into this space, and I'll show you a little,
32:20
this is an N-body simulation, if any of you like physics or astronomy nerds out there. So these are celestial bodies that are interacting in space, and their gravity is kind of attracting one another, and their color is actually mapped to velocity here. Here's another example where the cursor is actually a single point of gravity,
32:40
and we're just sort of directing it across. I tried all these different, like, variations and things. So I think there's many possibilities for Ruby. And I think we'll hear a lot about that. I'm really excited about this Ruby on the Fringe track,
33:02
as I think we'll hear a lot of new ideas. This is a small but growing, supportive community, people who are messing around with graphics and games and all the rest of it. So please join us, hang out, I'll share some links and ways that you can do that. And overall, I think the future is bright for us here.
33:20
So thanks so much for having me. The notes will be here.