I think a lot of people misunderstand what is being proposed here. He's not saying to write a whole new language, he's saying to write a byte code interpreter. You can implement one of those in about an hour.
Game Programming Patterns – Bytecode
41–50 of 73 posts
Re: Game Programming Patterns – Bytecode
#42Earlier quoted context omitted.
> Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. Don't forget low-end mobile devices.
Low-end mobile devices these days have 80+MB of RAM available to an application and the downsampled assets that I assume you're using on them 'cause you're a pro leave you with a pretty large chunk of RAM to work with. I sorta doubt there are many games targeting these devices (and, more particularly, the people who still use these devices in 2014) in the first place, but even fewer which are pushing their headroom s…
What's your market? Is it the U.S. or… India?
if you put the population of each next to each other, which would you describe as "most people" ?
Re: Game Programming Patterns – Bytecode
#43Re: Game Programming Patterns – Bytecode
#44[deleted]
Re: Game Programming Patterns – Bytecode
#45Earlier quoted context omitted.
Low-end mobile devices these days have 80+MB of RAM available to an application and the downsampled assets that I assume you're using on them 'cause you're a pro leave you with a pretty large chunk of RAM to work with. I sorta doubt there are many games targeting these devices (and, more particularly, the people who still use these devices in 2014) in the first place, but even fewer which are pushing their headroom s…
What's your market? Is it the U.S. or… India? if you put the population of each next to each other, which would you describe as "most people" ?
If you can point me towards a smartphone, with significant market share and usage numbers in 2014, that doesn't have 128MB of RAM and, like, an 800MHz Adreno or something, I would really like to see it. Because that's my defnition of "low end" and I've literally never seen crappier than that. (I'm targeting phones with at least two cores and 768MB of RAM and up, because I'm lazy and I don't think anybody with lower would be buying my game because it doesn't fit the profile of titles that make money on such devices, but I do have a couple paperweights around for idle testing.)
My market research has shown that when you get below those specs you start getting into dumbphone/J2ME platforms, where you have other constraining factors.
Re: Game Programming Patterns – Bytecode
#46Earlier quoted context omitted.
Eh, angry birds runs on Lua. Your point was?
Angry Birds is not a terribly involved or demanding game, and the hard part, 2D physics simulation, is handled in C by the Box2D library anyway. It requires no real-time control, you just aim the bird and watch the reaction. You could half or quarter the framerate and add enormous interframe jitter and the game would play exactly the same. If you tried to do the same thing with an demanding twitch action game, it wou…
Lua's been fast enough to do what you describe for years on gear much slower than even bottom-end smartphones, but if that's too iffy for you, AngelScript is a sub-megabyte runtime when run on Android via the NDK. It's historically been performant enough for use on the PS2 (with its ballin' 300MHz MIPS CPU and 32MB of RAM). It's statically typed, has a very well-defined garbage collector you can pretty easily avoid ever invoking once, and as a simple transform language generates very little (possibly even no? I don't remember) heap allocations. It will also take literally ten minutes to set up for the sort of use case we're talking about here. (If you want to bind a big honking C++ library to it, then things get interesting, but we aren't talking about that.)
You still write your perf-sensitive code in C++, of course. Just like if you embed Lua. Because you aren't dumb.
munificent hit on the one use case where this makes a ton of sense to me--when you're a basically-embedded environment, he was talking about a platform with four megabytes of RAM--but that hasn't been a serious use case in games on popular platforms for a while now. Which is why I'm confused why it's in a book that seems to basically be for novices, at least without some "you should rethink doing this unless" asterisks.
Re: Game Programming Patterns – Bytecode
#47Earlier quoted context omitted.
What's your market? Is it the U.S. or… India? if you put the population of each next to each other, which would you describe as "most people" ?
If you can point me towards a smartphone, with significant market share and usage numbers in 2014, that doesn't have 128MB of RAM and, like, an 800MHz Adreno or something, I would really like to see it. Because that's my defnition of "low end" and I've literally never seen crappier than that. (I'm targeting phones with at least two cores and 768MB of RAM and up, because I'm lazy and I don't think anybody with lower w…
it is not always about whether you can at all. Sometimes it's about power budget- That is, battery drain, etc. Run your lua engine and you have less budget for particle effects. Run all the things and your game drains the battery in 10 minutes.
It's perfectly legitimate to not care. Writing a from scratch bytecode vm is a fairly extreme last resort solution.
But on the other hand, the bytecode VM, appropriately scoped, could end up being easier than embedding lua. That is, if what you're doing is only barely more than loading and using data- not even quite crossing the boundary into turing completeness.
Re: Game Programming Patterns – Bytecode
#48Earlier quoted context omitted.
Angry Birds is not a terribly involved or demanding game, and the hard part, 2D physics simulation, is handled in C by the Box2D library anyway. It requires no real-time control, you just aim the bird and watch the reaction. You could half or quarter the framerate and add enormous interframe jitter and the game would play exactly the same. If you tried to do the same thing with an demanding twitch action game, it wou…
Lua's been fast enough to do what you describe for years on gear much slower than even bottom-end smartphones, but if that's too iffy for you, AngelScript is a sub-megabyte runtime when run on Android via the NDK. It's historically been performant enough for use on the PS2 (with its ballin' 300MHz MIPS CPU and 32MB of RAM). It's statically typed, has a very well-defined garbage collector you can pretty easily avoid e…
AngelScript seems relevant to my interests, I'll have to check it out.
I'm sure Lua is "good enough" for a lot of tasks in most games on most hardware, I was just trying to hint at scenarios where the GC overhead could be painful enough to warrant a custom approach.
>but that hasn't been a serious use case in games on popular platforms for a while now.
The DS with its 4 megabytes of RAM was still a relevant platform not that long ago. The 3DS doesn't have a whole lot of breathing room either; 128 megabytes of RAM, who knows how much of which is available to the game and not reserved for the OS.
>Which is why I'm confused why it's in a book that seems to basically be for novices, at least without some "you should rethink doing this unless" asterisks.
I haven't read too much of this book, but I got the impression that it was for programmers of other disciplines that wanted the skinny on game development practices, not for total novices. Somewhere between "Game Programming for Teens" and "Game Engine Architecture." This chapter doesn't seem that out of place to me.
Re: Game Programming Patterns – Bytecode
#49Earlier quoted context omitted.
If you can point me towards a smartphone, with significant market share and usage numbers in 2014, that doesn't have 128MB of RAM and, like, an 800MHz Adreno or something, I would really like to see it. Because that's my defnition of "low end" and I've literally never seen crappier than that. (I'm targeting phones with at least two cores and 768MB of RAM and up, because I'm lazy and I don't think anybody with lower w…
it is not always about whether you can at all. Sometimes it's about power budget- That is, battery drain, etc. Run your lua engine and you have less budget for particle effects. Run all the things and your game drains the battery in 10 minutes. It's perfectly legitimate to not care. Writing a from scratch bytecode vm is a fairly extreme last resort solution. But on the other hand, the bytecode VM, appropriately scope…
The power delta between AngelScript or Lua and your own interpreter is gonna be pretty small, though. It's a cost you pay once (in a modern implementation) to interpret into...a bytecode VM. And you totally might be a wizard beyond my ken here, but I strongly doubt it'll be easier to implement a bytecode VM of your own than calling, like, five functions. =) I'm not denying that there are cases where such a thing is valuable, don't get me wrong, but don't reinvent what you don't have to. And probably should not be the first thing you're reaching for in your toolbox. Or second.
Re: Game Programming Patterns – Bytecode
#50In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?
You saw them a lot in old games (the kind likely to be written in assembly), because not even C, let alone a general-purpose scripting language, was acceptable for performance reasons for quite some time, yet there has always been a need for greater abstraction and expressive power. Look at any Japanese RPG of the 80s and 90s, for instance, and there's probably a simple bytecode VM (or state machine, if you prefer) f…
Thank you for your answer. I do realise why it was done in the past, I was wondering about the present. Also what you're describing in the last paragraph sounds a bit like Andy Gavin's GOOL - http://all-things-andy-gavin.com/2011/03/12/making-crash-ban...