Lostcast episode 65...


  • Patron

    I’ve been postponing this post for a while, thanks to school stuff…
    But now I finally get to write it, so, let’s go.
    First, a couple of corrections:

    • Matt said that Cave Story+ was a 3D remake.
      I’m sorry, but I can’t help myself: I’m a Cave Story fanboy!
      Cave Story+ is just Cave Story with remastered music and higher-res graphics. It was originally released for WiiWare and later on Steam, with Humble Bundle IV.
      Cave Story 3D is what you probably were talking about.

    • BoI Rebirth will also be released for PC and PS4, in addition to Vita.

    Now, into the main subject of the episode, the first thing that I would like to point out is that, for some reason, I usually like your “awful decisions”, IDK why.
    Probably because they require more work, which requires more time which will lead into more posts/tweets/videos etc…
    Also, don’t ever talk about Djinn on the podcast before releasing it. As my notion of what a game architecture should look like comes mainly from Flixel and Flashpunk, I have no idea of what you’re talking about when you say scenegraph or view or model or anything like that.
    I know you don’t want to release Djinn before making documentation for it, but I don’t care. I don’t want to use Djinn, I want to study Djinn. I wanna dig through the source code and see how you do stuff.

    For example, I don’t understand why you had problems to implement UI with PixiDjinn, because, in my head, the rendering code for the UI would be very far away from the UI logic code. But I probably won’t understand until I see the code.

    Also, if contracts are probably only going to pay for themselves, why don’t you take more time to finish the contract but also add new stuff to Djinn? Why is that a bad decision? Sure, you’ll probably lose money with that, but you weren’t going to make much money with the contract in the first place.

    In this case, however, I think integrating Pixi wasn’t a good decision.
    I mean, performance shouldn’t be much of a problem in the future, so, I guess you should focus on making a more powerful engine instead of a faster one.

    But being an indie isn’t all about doing what you feel like doing after all?

    I have a question @geoffb: what can you optimize in canvas?
    Sure, there are the best practices, like batching all canvas transformations together, prevent sub-pixel rendering by rounding coordinates etc…
    But being so far away from the hardware, these best practices won’t make your game run much faster, unless you’re doing a lot of stuff wrong, right?

    Also, I hated the philosophical tangent in this episode.
    It made me think about how much time I’ve been wasting, and that makes me very nervous.

    @richtaur I don’t see the reason why you complained about Chrome not being “the fast browser” anymore.
    Google focused on making Chrome fast (and it is still pretty effin’ fast), now they’re focusing on making it fully featured.

    Oh, also, you seriously NEED to make those “devil’s advocate” business cards!

    Also, it took me a embarassingly long time to figure out what Matt was talking about when he said Djinn was a “console game engine”.

    Overall, I’ll give this episode a 9. It was rather informative and philosophical, but also had some funny tangents.


  • Patron

    P.S: Oh, don’t worry guys, I’ll give 113.59953% of myself to create Lostcast threads.


  • LDG

    Cave Story 3D is what you probably were talking about.

    Oops, indeed!

    Now, into the main subject of the episode, the first thing that I would like to point out is that, for some reason, I usually like your “awful decisions”, IDK why.

    Sounds like a TV show “Awful Decisions of the Week” with Matt 'n Geoff ;)

    I don’t want to use Djinn, I want to study Djinn. I wanna dig through the source code and see how you do stuff.

    That’s an interesting point. We’ll think about that.

    Also, if contracts are probably only going to pay for themselves, why don’t you take more time to finish the contract but also add new stuff to Djinn? Why is that a bad decision?

    That’s what we were trying to do from the beginning – Geoff wanted to push forward on both the contract and our game engine. However, doing too much at once can be detrimental. It held the whole project back and overwhelmed Geoff.

    But being an indie isn’t all about doing what you feel like doing after all?

    Absolutely. We struggle with this daily!

    It made me think about how much time I’ve been wasting, and that makes me very nervous.

    Sometimes time needs to be wasted :) I’ve found that I’m most productive when I have a game I’m playing, or another distraction of some kind. Giving the mind a little room to play can be healthy.

    @richtaur I don’t see the reason why you complained about Chrome not being “the fast browser” anymore.

    I like products with a singular focus.

    Also, it took me a embarassingly long time to figure out what Matt was talking about when he said Djinn was a “console game engine”.

    I still don’t know what that means! ;)

    Overall, I’ll give this episode a 9

    Yay, thanks!

    113.59953%

    ARGH!!! ;)


  • Tiger Hat

    I’ve also been interested with all of the comments about Djinn what it’s all about. I’ve been able to glean a bit from watching some of the coding session recordings on twitch and looking at the source of Retreat to the Jeep (sorry for snooping). I can tell that it’s a requireJS based thing, the View is basically a “Scene”. I don’t think that there is a “Model” class, but more that it’s just a term referring to data, coming from the web dev MVC background. (Though I could be wrong, haven’t invested too many hours digging). A scenegraph isn’t really something they made up, http://en.wikipedia.org/wiki/Scene_graph it’s just a hierarchical way to organize all of the elements in the scene. PIXI also uses a scenegraph. Djinn has support for a lot of stuff, and looks kinda like a cleaner version of ImpactJS. Funny, there is a ton of code in the Jeep version from what at the time was prolly Crypt Run.

    BTW, I just recently started listening to your podcast, I’ve found it to be informative, fun, and inspiring. Thank you for doing it!


  • LDG

    Welcome to the forum @warspawn! Djinn is RequireJS based yeah, no worries about snooping :) True about scene graphs, it’s more an industry thing than something specific to Djinn. In fact in Djinn, there’s a “Scene” which has some sugar and transition helpers.

    Glad you’re enjoying Lostcast! Really motivates us to keep recording.


  • LDG

    @Josue said:

    I have a question @geoffb: what can you optimize in canvas?
    Sure, there are the best practices, like batching all canvas transformations together, prevent sub-pixel rendering by rounding coordinates etc…
    But being so far away from the hardware, these best practices won’t make your game run much faster, unless you’re doing a lot of stuff wrong, right?

    Batching canvas transforms together is a big one and the main difference between Pixi’s canvas rendering and ours. It wasn’t too hard to change, though. I recently refactored our rendering so that each scene graph node only calls setTransform, instead of calling save, translate, rotate, scale, restore. It’s slightly faster, but when you’re talking about lots of nodes, it can make a bigger difference. I’ve known that I needed to revamp Djinn’s canvas transforming code for a while, but just got around to it recently.

    Other stuff that can make a difference (so I’ve heard) is batching draw calls with the same images. That’s a good use case for sprite atlases. I’m pretty sure that’s an optimization for WebGL, but possibly for canvas, too. We are getting to the point where most of our “bottlenecks” are in setTransform and drawImage. Since we can’t optimize those particular functions, we can try to call them less. For example, for a View (our scene graph node) that isn’t translated, rotated or scaled. we might be able to skip the transformation calculations and transform call all together.

    Anyway, even small gains in the “hot spots” of the rendering pipeline can be beneficial at scale.

    EDIT: Also, there’s always work to be done with regards to optimizing particles, lighting, and other such effects. For AWL, we cache the canvas radial gradients in hidden canvas elements since those particular canvas methods are super sloooooooow (especially in Firefox, for some reason). It mostly comes down to trying to limit calls to canvas methods as much as possible.


  • LDG

    @Warspawn said:

    I don’t think that there is a “Model” class, but more that it’s just a term referring to data, coming from the web dev MVC background. (Though I could be wrong, haven’t invested too many hours digging).

    We sometimes refer to this class as the “Sim” or “Simulation”, but it’s very much a core concept to our games. I like to design our games such that the model/sim is a separate set of classes which only deals with the game logic and data. The View layer (scene graph) is a separate thing which observes the model/sim and creates sprites for each game entity and other visualizations.

    BTW, I just recently started listening to your podcast, I’ve found it to be informative, fun, and inspiring. Thank you for doing it!

    \o/


  • Patron

    @richtaur said:

    Now, into the main subject of the episode, the first thing that I would like to point out is that, for some reason, I usually like your “awful decisions”, IDK why.

    Sounds like a TV show “Awful Decisions of the Week” with Matt 'n Geoff ;)

    Sounds like a cool idea for a Lostcast sub-show =P

    I don’t want to use Djinn, I want to study Djinn. I wanna dig through the source code and see how you do stuff.

    That’s an interesting point. We’ll think about that.

    Don’t think, do it! >:(

    Also, if contracts are probably only going to pay for themselves, why don’t you take more time to finish the contract but also add new stuff to Djinn? Why is that a bad decision?

    That’s what we were trying to do from the beginning – Geoff wanted to push forward on both the contract and our game engine. However, doing too much at once can be detrimental. It held the whole project back and overwhelmed Geoff.

    Well, pushing the engine forward is obviously a great thing, but integrating Pixi probably wasn’t the best choice for doing that, I think.

    It made me think about how much time I’ve been wasting, and that makes me very nervous.

    Sometimes time needs to be wasted :) I’ve found that I’m most productive when I have a game I’m playing, or another distraction of some kind. Giving the mind a little room to play can be healthy.

    Tigsource Forums, LDG Forums, Twitter and youtube just nuke my productivity away!
    Argh!

    @richtaur I don’t see the reason why you complained about Chrome not being “the fast browser” anymore.

    I like products with a singular focus.

    We know pretty well that Google isn’t the best company in regards to focusing on one thing…
    But now that Chrome is pretty freaking fast, why shouldn’t they focus on other stuff?
    Their dev cycle sound like this to me:
    Add new features --> Optimize --> Repeat

    Also, it took me a embarassingly long time to figure out what Matt was talking about when he said Djinn was a “console game engine”.

    I still don’t know what that means! ;)

    Just to mention, I would totally play a dev console LDG game.


  • Patron

    @Warspawn said:

    the View is basically a “Scene”.

    I’m pretty sure Matt mentioned that some entities have more than one “view”, so, I think that wouldn’t make much sense.
    @richtaur @geoffb, can you clarify that?

    I don’t think that there is a “Model” class, but more that it’s just a term referring to data, coming from the web dev MVC background.

    I think they’re talking about the simulation model of an entity when they say “model”, but I’m not sure.
    Also not sure why should you separate the simulation model from the rendering model…

    A scenegraph isn’t really something they made up, http://en.wikipedia.org/wiki/Scene_graph it’s just a hierarchical way to organize all of the elements in the scene. Pixi also uses a scenegraph.

    Hum… Interesting.
    It sounds like Djinn’s scenegraph doesn’t have much to do with the “industry definition” of this term, as it looks like it’s used more in 3D graphics.
    But what does Djinn’s scenegraph do exactly, and why do you need it?


  • Patron

    @geoffb said:

    Batching canvas transforms together is a big one and the main difference between Pixi’s canvas rendering and ours.

    In an ideal world, browsers would figure out which calls them can batch together and do it automatically…

    I recently refactored our rendering so that each scene graph node only calls setTransform, instead of calling save, translate, rotate, scale, restore.

    AWL with new rendering code, please?
    My PC is pretty slow, so, any optimizations are welcome!

    We are getting to the point where most of our “bottlenecks” are in setTransform and drawImage. Since we can’t optimize those particular functions, we can try to call them less. > For AWL, we cache the canvas radial gradients in hidden canvas elements since those particular canvas methods are super sloooooooow (especially in Firefox, for some reason). It mostly comes down to trying to limit calls to canvas methods as much as possible.

    Yeah, that was what I was trying to say.
    If it was WebGL, you could optimize those functions, and that would make a heck of a difference, but in Canvas you can’t.

    Anyway, even small gains in the “hot spots” of the rendering pipeline can be beneficial at scale.

    The game ideas I have usually are very heavy on the CPU but very simple graphically, so, it wouldn’t make much sense for me having a complex rendering pipeline as yours.
    But on AWL, it certainly comes handy.


  • LDG

    My understanding is that a Scene Graph is really just any system of layering visuals. In Photoshop, there’s layers, In DOM, there’s divs and stuff ;) In Djinn, there are Views, which can have any number of children. These are all in the 2d space. 3d sounds about the same, but with another dimension.


  • LDG

    @Josue said:

    I’m pretty sure Matt mentioned that some entities have more than one “view”, so, I think that wouldn’t make much sense.
    @richtaur @geoffb, can you clarify that?

    It sounds like Djinn’s scenegraph doesn’t have much to do with the “industry definition” of this term, as it looks like it’s used more in 3D graphics.
    But what does Djinn’s scenegraph do exactly, and why do you need it?

    A scene graph is simply a way of organizing drawable objects in a scene. A 2D scene graph is a lot like the DOM, if you’re familiar with that. It’s basically a tree structure made up of nodes. Each node can have N children, which are also nodes and can have their own children. Again, much like the DOM. Think of the nodes in a scene graph as div elements in an HTML page. For the sake of argument, let’s say the root of the DOM is document.body. This element contains some number of child divs. Each of these divs have their own display properties, relative to the root. So, a div with style.left = 10 and style.right = 10 would be 10 pixels from the top and left of the parent. In turn, each of these divs can have any number of children with properties relative to their parent.

    In Djinn, a View is similar to a div. When we talk about multiple Views per entity is just means that some entities have a root View with several children underneath. Our “Dolls” are a good example of this: each “part” (head, arm, leg, sword, etc) of a Doll is its own View, but they are all part of a root View which can be moved around the screen while the children maintain their relative positioning.

    This tree structure is pretty powerful and has several advantages. One of the main advantages is that any View can be set to invisible which will cause the renderer to skip rendering of that View and any of its children. Another is that scaling and rotation effects on a View also affect its children.


Log in to reply