It's been a few weeks since my last HTML5 post and I've learned even more. I know I seem wishy-washy on the language, but that's not really the case. HTML5 is destined to be a big player in the games space at some point. The problem is that the some-point in question is not today...and that sucks.
Being that it's JavaScript makes it rather accessible, not to mention easy. The fact that it's distributable to many platforms is awesome too. But the fact that it's slow as crap on tablet devices, not fully supported on various browsers, has sound-sync issues, and a few other key bits makes it difficult to embrace fully.
Remember, I'm talking about the CANVAS here, not just the standard HTML5 elements.
Once all of these things (or at least a goodly number of them) are resolved, it will be a highly used platform for development.
But there are some pretty kick-ass games out there using it! How can it be said that it's slow? I mean, have you seen the Aves engine??? I have seen the Aves engine, yes, and it is quite impressive. Clearly there are some developers out there that, as we used to say during our heady development meetups, "are fed raw meet under a locked door" because they were amazingly good at development.
But more than that, it shows that there ARE ways to get HTML5 to power through a lot of its current limitations.
That's not the point though. The point of this ongoing review of the language is to see where the state of affairs is now, for the average developer. Can a person take HTML5, in its current state, and build something as speedy as said person can with Flash or Corona, without having to tweak and hack stuff to get that speed? And that's just the speed question. There are still questions of sound, image rotation/scaling/etc., and so on.
I'm bummed about this because it's much more fun to code in HTML5 than it is in some other languages. I guess I like the nerdy element to the fact that you have to hack in order to get it to do what you really want it to do. But, again, it's not about those of us who enjoy the hack, it's about those who aren't all that good at the hack and therefore must rely on the essentials that come with the language.
Still, I anxiously and optimistically await the day that HTML5's Canvas is a rollicking (and blisteringly fast) solution to games.
Showing posts with label Coding. Show all posts
Showing posts with label Coding. Show all posts
Monday, September 12, 2011
Tuesday, June 21, 2011
About Objects class part 1 - Complete
I finished up part 1 of the About Objects ( http://www.aboutobjects.com ) class on Friday and am hoping to take part 2 in July.
For the most part is was terrific. I learned a ton of stuff about C that I didn't know (or thought I knew, but I was wrong) and the teacher was really good at conveying everything in a clear manner. Plus, he was a pretty cool dude.
The one thing I was a little disappointed in was that all day Thursday was a review of the things we learned Monday through Wednesday. This is because we had a few new people show up on Thursday that were there for the start of the Objective-C course, which follows the ANSI C one. Also, it was because a TON of information was presented through the ANSI C course and was therefore reviewed to the folks in the class that just went through it.
Unfortunately, this only left one day for Objective-C training. I know that the point is to lead the Obj-C into the following week (part 2) of the training course. So I'm sure for everyone that was staying for part 2 it was a great thing to have as a review. For me, though, I would have quite preferred two solid days of Obj-C. That's no fault to the About Objects folks. If I could have stayed the second week I'm sure I'd have a different view on things. :)
Regardless, the day of Obj-C that I did get taught me a number of nifty little bits. For example, one thing I was unaware of was what the NS stood for at the beginning of all the foundation class stuff. So, NSArray, NSObject, NSString, etc. In case you don't know, NS = NeXTStep. This is because OS X is really a descendant of the NeXTStep OS. Now that may not seem like it's all that helpful to know, but when you're coming from a Windows background and you're seeing all this weird Objective-C stuff (NSObject and the like), it's a bit confusing.
Also, the syntax of Obj-C is weird. To me anyway.
NSString *desc = [[NSString alloc] initWithFormat:@"Class: %@, Name: %@", [self class], @"Test"];
That looked really strange to me when I first saw it, but now I'm getting the hang of it.
Anyone interested in learning this stuff should consider About Objects. They were very nice and extremely helpful the entire way.
Other good things that I've picked up since have been a couple of iPad books (that were free!). They are:
- The Objective-C Programming Language
- Object-Oriented Programming in Objective-C
Both of them are available on the AppStore, again, for free.
Wednesday, June 15, 2011
Learning iOS Development at About Objects
Since Monday I've been at a training seminar to start getting iOS development under my belt. I've played around with Flash CS5 to make pointless little apps that go through the Adobe porting process and spit out iOS code. I've also tried a few different 3rd-party tools to get a handle on how things work. But it just wasn't enough to really get a grip on things.
I just finished up a lab and we're on a 10 minute break, so here is a quick blip about the class.
So AOL hooked me up with a training course at a company called About Objects ( http://www.aboutobjects.com ). It's in Reston, Virginia, located in the downtown area (called Reston Town Center). The area is very nice and there are a lot of restaurants and shops right here. The point is that you don't have to worry about where you're going to eat lunch or pick up supplies, etc. There's even an Apple store a block away in the event that you need something to support your learning.
Of all the companies out there that I could find doing OS X/iOS development training, About Objects was the only one that had ANSI C. Thus, the first class in the series is ANSI C on OS X. While I've coded numerous apps in C since the late 80's, I haven't done anything in C for about 10 years. Plus, I've not done anything really deep on the Mac or iOS platforms, so starting out with a lower level language like C seemed to be a smart move. As the instructor (Jonathan Lehr, owner of About Objects) points out, it's better to get a solid understand of what's going on under the hood before you start working with the higher Objective-C language. I couldn't agree more. After spending a month banging my head on Objective-C, I finally gave up and just considered it a lesson that I needed to stick with the Windows environment. This is because I couldn't seem to find anything that really helped me get to an area that I was comfortable *before* going into an area I'm not.
Things are moving quickly in this class, but in a good way. As an example, this is supposed to be a "learning C" course. On day 2 we were working with pointers. Today we move into structs, function pointers, etc. But, to me, this is the way to learn. Get a fast dump of relevant information, skip all the crap that you're not really going after, do a number of labs to help the knowledge sink in, sleep on it, and move on to the next section. I've gotten more out of two days on C than I probably did in the years I was coding in C. Jonathan conveys the information clearly and his level of knowledge about the language and OS make for numerous tidbits that have made me say, "Oh...cool" numerous times.
Now keep in mind that the point of this ANSI C class is not so that you walk out knowing all there is about C. The point is that you have a solid understanding of C's strengths, quirks, and weaknesses. This is because day 4 is the start of learning Objective-C and in order to understand why Obj-C does things as it does, understanding its base component (C) is very valuable. I sure hope so because I'm hoping to finally understand Obj-C by the end of this week!
So AOL hooked me up with a training course at a company called About Objects ( http://www.aboutobjects.com ). It's in Reston, Virginia, located in the downtown area (called Reston Town Center). The area is very nice and there are a lot of restaurants and shops right here. The point is that you don't have to worry about where you're going to eat lunch or pick up supplies, etc. There's even an Apple store a block away in the event that you need something to support your learning.
Of all the companies out there that I could find doing OS X/iOS development training, About Objects was the only one that had ANSI C. Thus, the first class in the series is ANSI C on OS X. While I've coded numerous apps in C since the late 80's, I haven't done anything in C for about 10 years. Plus, I've not done anything really deep on the Mac or iOS platforms, so starting out with a lower level language like C seemed to be a smart move. As the instructor (Jonathan Lehr, owner of About Objects) points out, it's better to get a solid understand of what's going on under the hood before you start working with the higher Objective-C language. I couldn't agree more. After spending a month banging my head on Objective-C, I finally gave up and just considered it a lesson that I needed to stick with the Windows environment. This is because I couldn't seem to find anything that really helped me get to an area that I was comfortable *before* going into an area I'm not.
Things are moving quickly in this class, but in a good way. As an example, this is supposed to be a "learning C" course. On day 2 we were working with pointers. Today we move into structs, function pointers, etc. But, to me, this is the way to learn. Get a fast dump of relevant information, skip all the crap that you're not really going after, do a number of labs to help the knowledge sink in, sleep on it, and move on to the next section. I've gotten more out of two days on C than I probably did in the years I was coding in C. Jonathan conveys the information clearly and his level of knowledge about the language and OS make for numerous tidbits that have made me say, "Oh...cool" numerous times.
Now keep in mind that the point of this ANSI C class is not so that you walk out knowing all there is about C. The point is that you have a solid understanding of C's strengths, quirks, and weaknesses. This is because day 4 is the start of learning Objective-C and in order to understand why Obj-C does things as it does, understanding its base component (C) is very valuable. I sure hope so because I'm hoping to finally understand Obj-C by the end of this week!
Thursday, November 11, 2010
Mochi ZIP integration issue resolved
It took a couple of weeks working back and forth with the tech folks at Mochi, but we finally uncovered an interesting ooopsie.
There are three ways (that I'm aware of) to build a game for Mochi distribution:
1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.
2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.
3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.
The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.
The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:
The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.
The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.
If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.
Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.
There are three ways (that I'm aware of) to build a game for Mochi distribution:
1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.
2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.
3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.
The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.
The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:
var loader:Loader;
var resourceURL:String;
var request:URLRequest;
loader = new Loader();
resourceURL = loader.contentLoaderInfo.loaderURL;
resourceURL = resourceURL.substring(0,resourceURL.lastIndexOf("/") + 1);
resourceURL = resourceURL + "tempflashfile.swf";
request = new URLRequest(resourceURL);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteHandler, false, 0, true);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler, false, 0, true);
loader.load(request);
The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.
The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.
If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.
private var gLoader:Loader;
private var gResourceURL:String;
gLoader = new Loader();
gResourceURL = gLoader.contentLoaderInfo.loaderURL;
gResourceURL = gResourceURL.substring(0,gResourceURL.lastIndexOf("/") + 1);
Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.
Saturday, September 18, 2010
HTML5 is nifty
I've been coding primarily in AS3 for a few years now, but I was tasked to do some research into HTML5.
While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.
Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.
While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.
Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.
Thursday, August 26, 2010
Algorithms are fun
I've been working on a persnickety (yes, I actually just used that word) little algorithmic issue for a new game I'm working on. The game is kind like Phlinx and Bubble Town, so there is a little projectile that flies up toward the board and, upon matching three or more, causes the pieces to explode and disappear.
That matching bit was fun in and of itself, but I got that one sorted out. The challenge now is the line-of-sight check for spotting where the projectile is allowed to land.
The problem is a little tougher because the board is staggered (Row 0 starts at pixel 45 and Row 1 starts at pixel 90...for example), so you can't just simply check on an array basis. You use the array, of course, but you have to kind of treat it a bit differently.
For example, consider:
Since the row offsets match, we can immediately see that the projectile (P) can not get to the open position (O) because there is a piece (X) in the way.
But, if we stagger the board:
...and if we imagine an line drawn from P to O, then the piece CAN hit that spot.
But how far can it go?
...looking at this board, an imagining that line draw up, the projectile can find its way all the way to the top of the board here.
Those are just a couple of the issues associated with this. Either way, it's a fun challenge (so far), but I'm certainly finding myself brooding more than coding at times. :)
That matching bit was fun in and of itself, but I got that one sorted out. The challenge now is the line-of-sight check for spotting where the projectile is allowed to land.
The problem is a little tougher because the board is staggered (Row 0 starts at pixel 45 and Row 1 starts at pixel 90...for example), so you can't just simply check on an array basis. You use the array, of course, but you have to kind of treat it a bit differently.
For example, consider:
[ ][ ][O][ ]
[ ][ ][X][ ]
[P]
Since the row offsets match, we can immediately see that the projectile (P) can not get to the open position (O) because there is a piece (X) in the way.
But, if we stagger the board:
[ ][ ][O][ ]
[ ][ ][X][ ]
[P]
...and if we imagine an line drawn from P to O, then the piece CAN hit that spot.
But how far can it go?
[ ][ ][ ][O]
[ ][ ][ ][O]
[ ][ ][O][ ]
[ ][ ][X][ ]
[P]
...looking at this board, an imagining that line draw up, the projectile can find its way all the way to the top of the board here.
Those are just a couple of the issues associated with this. Either way, it's a fun challenge (so far), but I'm certainly finding myself brooding more than coding at times. :)
Wednesday, August 4, 2010
Flash Debugging
So as I (and seemingly tons of other Flash devs) continue to struggle with memory and CPU issues, I searched for ways to help pinpoint issues. I found two items that I'm planning to try out today to help:
1 - De MonsterDebugger -- an AIR app that allows you to realtime debug on many fronts.
2 - EventController Lib - a library that manages events to make sure you don't end up with lingering event managers in your code.
With any luck I'll have good news on these two items soon. Either way, I'll post up how things are turning now.
**UPDATE:
Wow. The two items listed above are AWESOME. I highly recommend this to anyone serious about developing Flash apps/games. The bug I've been hunting forever has been found and (hopefully) squashed. And, yes, it was my fault.
I fell into the trap of expecting Flash's garbage collector to be more intelligent the larger system gc's because it is smaller world. Unfortunately, it's not. So, just like C's new and delete, so it goes heavily with Flash. If you want more details, check out this great article by Tom at Gabob.
It was in the comments of that article that I found the EventController Lib and from that I found the Monster Debugger.
Even though I was removing the event listeners from everything, I wasn't nulling things properly. I *thought* I was, but with the Monster Debugger I was able to see a lot more than I was getting from the Flash debugger. What I saw with Monster was how I was missing quite a few of nulls, and a couple of deletes too. Oops.
Anyway, now CPU usage is now quite nice (when the GC decides to kick off) and memory is staying low too.
I will likely integrate the EventController Lib too since it seems to be really intelligent in how it works. First, though, I want to see how things go now that I'm nulling/deleting in (again, hopefully) all the right places.
With my luck I'm probably still not 100% solved on this issue, but it's GOT to be better!
** Update Part 2:
Integrated EventController Lib. Nice. It was simple to integrate and it gives a simple interface for controlling events. Plus it can be easily set to log information over to Monster Debugger, so that's sweet.
So far I'm liking these new toys!
1 - De MonsterDebugger -- an AIR app that allows you to realtime debug on many fronts.
2 - EventController Lib - a library that manages events to make sure you don't end up with lingering event managers in your code.
With any luck I'll have good news on these two items soon. Either way, I'll post up how things are turning now.
**UPDATE:
Wow. The two items listed above are AWESOME. I highly recommend this to anyone serious about developing Flash apps/games. The bug I've been hunting forever has been found and (hopefully) squashed. And, yes, it was my fault.
I fell into the trap of expecting Flash's garbage collector to be more intelligent the larger system gc's because it is smaller world. Unfortunately, it's not. So, just like C's new and delete, so it goes heavily with Flash. If you want more details, check out this great article by Tom at Gabob.
It was in the comments of that article that I found the EventController Lib and from that I found the Monster Debugger.
Even though I was removing the event listeners from everything, I wasn't nulling things properly. I *thought* I was, but with the Monster Debugger I was able to see a lot more than I was getting from the Flash debugger. What I saw with Monster was how I was missing quite a few of nulls, and a couple of deletes too. Oops.
Anyway, now CPU usage is now quite nice (when the GC decides to kick off) and memory is staying low too.
I will likely integrate the EventController Lib too since it seems to be really intelligent in how it works. First, though, I want to see how things go now that I'm nulling/deleting in (again, hopefully) all the right places.
With my luck I'm probably still not 100% solved on this issue, but it's GOT to be better!
** Update Part 2:
Integrated EventController Lib. Nice. It was simple to integrate and it gives a simple interface for controlling events. Plus it can be easily set to log information over to Monster Debugger, so that's sweet.
So far I'm liking these new toys!
Friday, July 23, 2010
Ice Breakers: Penguin Pirates
Finally released Penguin Pirates on games.com. It's in beta right now, so I'm sure there are still a few bugs to contend with, but it's looking pretty good.
Check it out at http://www.games.com/game/ice-breakers-penguin-pirates/
Check it out at http://www.games.com/game/ice-breakers-penguin-pirates/
Monday, July 12, 2010
"Book" to roots
I have been a developer since the early 80's and have coded on a VIC-20, C-64, C-128, TRS-80 (I, III, and IV), PC (DOS, 95, 98, XP, and now 7...skipped Vista), Mac (OS/X only), iPod Touch/iPhone (thoroughly hated coding on these), and now the Droid. I have used Assembler, BASIC, COBOL, Pascal, Prolog, C, C++, C#, Objective C, Java, JavaScript, PHP, PERL, HTML, ActionScript (3.0)...and likely more. I've also written numerous game development articles and had two books published on 2D game development as well.
Well, after all of this I had finally gotten to the point (about 5 years ago) where coding started losing the same level of excitement that it used to have. I still love coding games, but just plain coding, tinkering, and hacking is not all that thrilling anymore.
Fortunately, I picked up the book "Code", by Charles Petzold last week and I have suddenly realized the problem. I miss the days of the VIC-20, C-64, and all the other nerdy machines made! There is so much abstraction now that the tinkering and hacking just doesn't have that same draw. At least not for me. Mr. Petzold really brought me back to my roots with his excellent book.
I'm planning to order a NerdKit (http://www.nerdkits.com) later this week, and will eventually like snag a Tower System (http://www.towergeeks.org/page/the-tower-system) before I finally join up for the Game Institute class on creating your own video game console and game (http://www.gameinstitute.com/Video_Game_Console_Design.html).
I've never been much into electronics, so it will also be an exciting new jump into a technological area. Building stuff and the coding to it just sounds so cool that I must give myself a +2500 geek points immediately upon completion of my first project. Sadly this stuff is not cheap and in this economy there is a lot of penny-pinching going on. So it's going to take some time to get things going, but that's cool. There are loads of FREE sites out there and plenty of cheap used books to read at nights and on the weekends when there is time.
I loved tinkering with the old Commodore's and TI's back in the day and I'm already excited about the potentialities of these little kits. But (those of you who know me) this is not a take-over-the-world situation for me. I'm going to treat this as nothing but a hobby. No deadlines, no next-biggest-thing projects...just nerdy learning and geeky fun. That's it.
It's like a technological breath of fresh air to go back to a point where abstraction is minimal. Many of these kits offer C as the connection point, and I'll likely utilize that on tougher projects, but wherever possible I'm using Assembler (or ML, if at all possible!). I can already imagine spending hours and hours fiddling with a project whereby I toil and toil using Assembler and various schematics to satisfy a project that simply makes an LED blink once. Yes, it's essentially pointless, but damn if it ain't cool!
So, if you're looking to get that old-skool interest again, check out Petzold's book. It's an interesting read and it may serve re-spark your nerdiness too.
Well, after all of this I had finally gotten to the point (about 5 years ago) where coding started losing the same level of excitement that it used to have. I still love coding games, but just plain coding, tinkering, and hacking is not all that thrilling anymore.
Fortunately, I picked up the book "Code", by Charles Petzold last week and I have suddenly realized the problem. I miss the days of the VIC-20, C-64, and all the other nerdy machines made! There is so much abstraction now that the tinkering and hacking just doesn't have that same draw. At least not for me. Mr. Petzold really brought me back to my roots with his excellent book.
I'm planning to order a NerdKit (http://www.nerdkits.com) later this week, and will eventually like snag a Tower System (http://www.towergeeks.org/page/the-tower-system) before I finally join up for the Game Institute class on creating your own video game console and game (http://www.gameinstitute.com/Video_Game_Console_Design.html).
I've never been much into electronics, so it will also be an exciting new jump into a technological area. Building stuff and the coding to it just sounds so cool that I must give myself a +2500 geek points immediately upon completion of my first project. Sadly this stuff is not cheap and in this economy there is a lot of penny-pinching going on. So it's going to take some time to get things going, but that's cool. There are loads of FREE sites out there and plenty of cheap used books to read at nights and on the weekends when there is time.
I loved tinkering with the old Commodore's and TI's back in the day and I'm already excited about the potentialities of these little kits. But (those of you who know me) this is not a take-over-the-world situation for me. I'm going to treat this as nothing but a hobby. No deadlines, no next-biggest-thing projects...just nerdy learning and geeky fun. That's it.
It's like a technological breath of fresh air to go back to a point where abstraction is minimal. Many of these kits offer C as the connection point, and I'll likely utilize that on tougher projects, but wherever possible I'm using Assembler (or ML, if at all possible!). I can already imagine spending hours and hours fiddling with a project whereby I toil and toil using Assembler and various schematics to satisfy a project that simply makes an LED blink once. Yes, it's essentially pointless, but damn if it ain't cool!
So, if you're looking to get that old-skool interest again, check out Petzold's book. It's an interesting read and it may serve re-spark your nerdiness too.
Thursday, May 13, 2010
Blackbox coding
I'm in the middle of a big project for work that is very geeky and fun. I'm having a blast coding it up.
Essentially I have a bunch of APIs that I have to integrate a game into each time one comes in.
As anyone who codes knows, this is a tricky proposition because it takes time to understand someone else's code. Once you understand the code then you have to start working the API hooks into it. Then you do your testing and get others to help test. Finally, you ship that version of the product and then do the next integration point for the same game (hook in another API for a different launch portal). Currently we have three portals to launch out of, but there will be another 3-5 over the course of the year. This puts me in the position of each game taking like a month to do. With 15 games looming, anyone can see that's not gonna happen quickly.
So I thought about it and decided to write a blackbox interface for all this junk that I can turn over to the game developer and allow them to do the integration themselves.
It looks something like this:
So the blackbox is essentially an interface. It has a list of all the available functions that the developer can code to. The developer doesn't have to worry about the Platform specific code. I do.
I know that this isn't a novel idea at all, but it sure is freakin' fun to code! :D
Essentially I have a bunch of APIs that I have to integrate a game into each time one comes in.
As anyone who codes knows, this is a tricky proposition because it takes time to understand someone else's code. Once you understand the code then you have to start working the API hooks into it. Then you do your testing and get others to help test. Finally, you ship that version of the product and then do the next integration point for the same game (hook in another API for a different launch portal). Currently we have three portals to launch out of, but there will be another 3-5 over the course of the year. This puts me in the position of each game taking like a month to do. With 15 games looming, anyone can see that's not gonna happen quickly.
So I thought about it and decided to write a blackbox interface for all this junk that I can turn over to the game developer and allow them to do the integration themselves.
It looks something like this:
So the blackbox is essentially an interface. It has a list of all the available functions that the developer can code to. The developer doesn't have to worry about the Platform specific code. I do.
- When the SWF is loaded, I set the distribution argument in the embed tags flashvars section, which tells the black box what platform to connect to.
- The developer builds once on a generic platform, hand the code+build to me.
- I create multiple .html files that have different distribution arguments, and then launch the game.
- The blackbox handles the routing to the appropriate platform and the platform communicates with the appropriate server.
- All the data that comes back into the game is identical regardless of the platform selection because the blackbox handles the translation.
I know that this isn't a novel idea at all, but it sure is freakin' fun to code! :D
Monday, April 19, 2010
AS3 memory management part II
I went through and did the plan from my previous AS3 memory management post and things are looking better. By just allocating things one time at the beginning of the game and pushing them to the display list once as well, I'm now at about 1/2 the amount of memory hogged by the time I reach level 20 of the game.
This should be sufficient to solve the problem of game slowdowns.
At this point I could pull all of the frames and such from the game, but I don't think I'm going to do that. If a person runs back and forth in the menu and such 100x, it'll likely bump up the memory usage a bit but not nearly as badly as the game frame is and it's frankly an edge-case anyway.
The bottom line is that if you're coding up a game or application that has a number of levels to it, and is full of tons of graphical elements and such, you'll probably want to:
This should be sufficient to solve the problem of game slowdowns.
At this point I could pull all of the frames and such from the game, but I don't think I'm going to do that. If a person runs back and forth in the menu and such 100x, it'll likely bump up the memory usage a bit but not nearly as badly as the game frame is and it's frankly an edge-case anyway.
The bottom line is that if you're coding up a game or application that has a number of levels to it, and is full of tons of graphical elements and such, you'll probably want to:
- Do all of your allocation at the start of your game
- Use addChild(...) as you allocate and then just write a little function that "hides" your graphics by altering their x and y to be something like: -999,-999
- Show your graphics by setting the new x and y to wherever they should actually be
- Make sure you don't undercut the number of graphics you'll need when doing your initial allocation
Tuesday, April 13, 2010
AS3 memory management
...is a pain in the butt.
I've known for years that the AS3 GC (Garbage Collector) runs through and cleans junk up when it is ready to, but this is somewhat crazy.
Let's say you have a Sprite all set up called "Ship", and you blow it up on the screen and then want to remove the ship.
The problem gets worse if you use the Flash frames, apparently. (I'm kind of guessing on this one). If you use Flash frames, everything you have populated onto the frame is going to be allocated. So any images, text-fields, etc. Now, when you're done with that frame and move onto the next--assuming you have set everything on the previous frame to null--it should all disappear. Visually, it does, but just like the aforementioned "ship", all the elements are still in memory until the Flash GC nukes them.
So, now, imagine this:
Frame 1: Splash screen
Frame 2: Game Screen
Frame 3: Level Complete screen
Frame 4: Game Over Screen
The game starts and we show Frame 1 for a couple of seconds and then jump over to Frame 2. Frame 2 starts up your game with all its nifty little sprites and such. You play through the level and win (yay!). Now the game moves on to Frame 3 to show you how you did, and asks you if you're ready for the next level. Stop...
1 - Show Frame 1 (Splash)
2 - Show Frame 2 (Game)
3 - Remove elements from Frame 2
4 - Show Frame 3 (Level Complete)
5 - Remove elements from Frame 3
6 - Go back to item #2 in this list
See a problem here? All of the elements in Frame 2 are still sitting in memory (unless Flash's GC cleaned them up...highly unlikely), and then Frame 3's are as well. We could be 20 levels into a game and ALL of the prior data is still sitting in memory. UGH!
And this doesn't even touch the fact that if you have any event listeners tied to these items they'll keep firing until the GC deletes them. Even if you remove the even listener, the reference will stay there unless you set the useWeakReference to true.
When creating an event listener, instead of:
Until then, guess what happens? Yep, all the stuff you created from levels 1-19 will still be in memory firing until the GC snags it. Why? I honestly don't know. It seems rather silly to me.
Oh, one more thing to note: Even if you create a symbol that has a bunch of frames sitting inside of it, and you're using gotoAndStop(...) or next() to pulse through, etc., you'll see your memory go up. This is because it's not until you actual hit a particular frame that the frame is loaded. This is actually understandable and fine, but it is something to note as you're doing stuff so you don't pull you hair out.
So what is there to do?
Well, that's the $1M question. What I'm going to *try*, is the following:
1 - Remove the whole frame concept entirely.
2 - Create all my assets at the start of the project
3 - Instead of removing them from the child list and nulling them, I'm going to create a little (throw me off the screen) function that effectively does the same thing, but only retains ONE element in memory through the life of the game, no hundreds. I'll just stick the items at -999,-999 or something.
4 - I already reuse the majority of my elements in arrays, but it seems the child list is a part of the problem (at least from my testing). So I want to have a fixed set of addChild calls instead of numerous ones. Again, this is accomplished by creating the elements at the start of the game and reusing them throughout.
Will this solve the problem? That's the question I hope to answer tomorrow.
I've known for years that the AS3 GC (Garbage Collector) runs through and cleans junk up when it is ready to, but this is somewhat crazy.
Let's say you have a Sprite all set up called "Ship", and you blow it up on the screen and then want to remove the ship.
// remove the child from the display list...I'm using GameElements hereNow, the ship should be deleted and done, right? Wouldn't that be super? Turns out that you can no longer reference the ship, but Flash still has it sitting around in memory until it decides the time is right to remove it. This could take seconds or hours (or it may never remove it).
// could just as easily be the root
GameElements.removeChild(ship);
// and set the actual ship var to null
ship = null;
The problem gets worse if you use the Flash frames, apparently. (I'm kind of guessing on this one). If you use Flash frames, everything you have populated onto the frame is going to be allocated. So any images, text-fields, etc. Now, when you're done with that frame and move onto the next--assuming you have set everything on the previous frame to null--it should all disappear. Visually, it does, but just like the aforementioned "ship", all the elements are still in memory until the Flash GC nukes them.
So, now, imagine this:
Frame 1: Splash screen
Frame 2: Game Screen
Frame 3: Level Complete screen
Frame 4: Game Over Screen
The game starts and we show Frame 1 for a couple of seconds and then jump over to Frame 2. Frame 2 starts up your game with all its nifty little sprites and such. You play through the level and win (yay!). Now the game moves on to Frame 3 to show you how you did, and asks you if you're ready for the next level. Stop...
1 - Show Frame 1 (Splash)
2 - Show Frame 2 (Game)
3 - Remove elements from Frame 2
4 - Show Frame 3 (Level Complete)
5 - Remove elements from Frame 3
6 - Go back to item #2 in this list
See a problem here? All of the elements in Frame 2 are still sitting in memory (unless Flash's GC cleaned them up...highly unlikely), and then Frame 3's are as well. We could be 20 levels into a game and ALL of the prior data is still sitting in memory. UGH!
And this doesn't even touch the fact that if you have any event listeners tied to these items they'll keep firing until the GC deletes them. Even if you remove the even listener, the reference will stay there unless you set the useWeakReference to true.
When creating an event listener, instead of:
SayAgainButton.addEventListener(MouseEvent.CLICK,SayAgain);Use:
SayAgainButton.addEventListener(MouseEvent.CLICK,SayAgain, false, 0, true);Again, it'll still hang out until the GC picks it up, but at least it *will* pick it up eventually.
Until then, guess what happens? Yep, all the stuff you created from levels 1-19 will still be in memory firing until the GC snags it. Why? I honestly don't know. It seems rather silly to me.
Oh, one more thing to note: Even if you create a symbol that has a bunch of frames sitting inside of it, and you're using gotoAndStop(...) or next() to pulse through, etc., you'll see your memory go up. This is because it's not until you actual hit a particular frame that the frame is loaded. This is actually understandable and fine, but it is something to note as you're doing stuff so you don't pull you hair out.
So what is there to do?
Well, that's the $1M question. What I'm going to *try*, is the following:
1 - Remove the whole frame concept entirely.
2 - Create all my assets at the start of the project
3 - Instead of removing them from the child list and nulling them, I'm going to create a little (throw me off the screen) function that effectively does the same thing, but only retains ONE element in memory through the life of the game, no hundreds. I'll just stick the items at -999,-999 or something.
4 - I already reuse the majority of my elements in arrays, but it seems the child list is a part of the problem (at least from my testing). So I want to have a fixed set of addChild calls instead of numerous ones. Again, this is accomplished by creating the elements at the start of the game and reusing them throughout.
Will this solve the problem? That's the question I hope to answer tomorrow.
Tuesday, April 6, 2010
Coding
I had a little fun working up a Flash system that snagged and XML file and an .MP3 file, mushed about inside of them and churns out a little soundtrack with text running along at the same time.
Unfortunately, I have no way of getting the XML to be smart enough to load up everything on the .MP3's timing. This just means that I have to use a tool (I use Audacity) to find the start points of each each text portion and tell the XML file where those are.
The tricky bit is that Flash doesn't have a way to reset its start timer. Not a huge deal, but doing the pause and resume stuff gets a little wacky while trying to keep tabs on the location on the .MP3 and the story itself.
The trick is to make sure to have a timer offset that you set when the story actually starts. And you set your start time to zero. Now you can compare safely, like:
When you pause, make sure to set a time paused variable using the getTimer(), and also pause the .MP3 and get its current position.
Then when you're ready to resume, you'll have all the junk you need to set your timers and your .MP3 start point accordingly.
Nifty, no?
Unfortunately, I have no way of getting the XML to be smart enough to load up everything on the .MP3's timing. This just means that I have to use a tool (I use Audacity) to find the start points of each each text portion and tell the XML file where those are.
The tricky bit is that Flash doesn't have a way to reset its start timer. Not a huge deal, but doing the pause and resume stuff gets a little wacky while trying to keep tabs on the location on the .MP3 and the story itself.
The trick is to make sure to have a timer offset that you set when the story actually starts. And you set your start time to zero. Now you can compare safely, like:
timeElapsed = (timeElapsed + (getTimer() - timeOffset)) / 1000;
if (timeElapsed > storyTime)
{
....
}
When you pause, make sure to set a time paused variable using the getTimer(), and also pause the .MP3 and get its current position.
soundPausePoint = storySoundChannel.position;
storySoundChannel.stop();
timePaused = getTimer();
Then when you're ready to resume, you'll have all the junk you need to set your timers and your .MP3 start point accordingly.
storySoundChannel = storySound.play(soundPausePoint);
timeOffset = getTimer() + (timeOffset - timePaused);
Nifty, no?
Friday, April 2, 2010
BlitzCoder / Blitz Basic
Old BlitzCoder Tutorials are up - I've recently received a bunch of requests for my old Blitz Basic tutorials (from the BlitzCoder era). Fortunately, Charles 'Specis' McCrimmon retains a copy of everything known to man. So he packaged it all up and sent them over. I got everything working today so anyone who's interested can check out the old tutorials and grab the old source code.
NOTE: I'm not supporting this stuff anymore, but if you're interested: BlitzCoder Tutorials
NOTE: I'm not supporting this stuff anymore, but if you're interested: BlitzCoder Tutorials
Subscribe to:
Posts (Atom)