CoderHump - Latest Comments

Re: Composition vs. Inheritance

Tom Christensen — Sat, 23 Oct 2010 18:44:57 -0000

Strategy pattern-ish.

Re: The Flash Display List And Games

Ben Garney — Mon, 18 Oct 2010 12:56:39 -0000

PS I look forward to seeing your blog post!

Re: The Flash Display List And Games

wonderwhy-er — Mon, 18 Oct 2010 12:43:06 -0000

I wonder if you were trying combining vector UI with raster rendering at background. We run at some problems with combining those two together which took some time and effort to figure out and optimize, worse that in two different games different same optimizations did not work or even made things worse :) Speaking of DisplayList problems haha...

And yeah biggest problems is that you need to do a lot yourself, things that were as easy as changing few properties or applying some tween now is very hard to achieve... Sometimes feels as if after running on ground you try running in water :D

Re: The Flash Display List And Games

Ben Garney — Mon, 18 Oct 2010 12:42:36 -0000

Hmm, I am not sure 90% is true. I do agree that in the end it's about what will get your project done to spec fastest and the display list can be a powerful ally in that battle.

My quick rundown on your points:

I don't use Flash IDE and none of our artists do, there is no workflow benefit. In fact having our own art pipeline and processing steps is a big benefit for download size and performance.

Nesting is a waste of time IMHO. It just complicates rendering, updating, and hit detection.

You can transform bitmaps just fine. (Although if you need to do high quality free rotate/zoom then vector is the way to go!)

The timeline is a way for artists to break your game by introducing frame scripts, weird frame behaviors, high-overhead morphs/tweens, and so on. In the cases where I do use SWFs for animation/download reasons, I render them out to bitmap spritesheets first (either at runtime or before hand) so I have a fixed overhead render.

Filters are best rendered to bitmaps.

Filesize is always an issue; if you have vector friendly art it will be small, but all the Flash projects I have worked on have not - using vector assets would have increased file size and decreased rendering speed.

Mouse events are a crutch, and worse, they are very difficult to reason about and debug. Why can't I put a breakpoint on a global mouse input hander then step through all the event dispatch? Instead I have to play games to get listeners in the right places and there's no convenient way to see the flow of activity.

Dev time is a big one. Display list definitely solves a ton of problems right out of the gate. If you know the system you can be very effective. If you are on a 4 week project, then you need every reusable piece you can get. But more and more Flash games are going to be on bigger budgets, bigger timelines, higher art and technology standards.

Will the 2 or 4 week game go away? Probably not. But I guarantee that Flash game budgets are going up and so are timelines. Maybe Social City is a front runner (but it only had 4 months, which is insanely short by most game dev standards), but it is not going to stand out front for long.

Obviously I come from the background I come from (c++ game dev) and work on the projects I work on. I can only speak to what I know, and I don't pretend to have everything figured out. But for my little part of the development world, I feel pretty firmly. :)

Re: The Flash Display List And Games

Ben Garney — Mon, 18 Oct 2010 12:28:37 -0000

The Social City footprint is primarily art. There are a lot of frames of animation and they take up space. :)

People have gigs of RAM, when you are doing a game (not an ad) why not use it? Even my phone has enough RAM to run Social City. (Maybe not enough CPU, bandwidth, and screenspace, though. :) )

I agree that for some situations the display list is great. It is definitely preferable for building a UI. For mousing in a game, you often want custom behavior anyway so the mouse behavior built in tends to be a liability instead of a benefit.

Probably the biggest trade off is development complexity. You might also get lucky and be doing something that maps well to the display list, in which case, go nuts!

Re: The Flash Display List And Games

wonderwhy-er — Mon, 18 Oct 2010 07:52:10 -0000

Working in same space making similar games. For our main game rendering we use BitmapData.copyPixels too and for same reasons, for consistent and predictable behavior completely based on transparent code, not the black box which sometimes throws out surprises which take time to test and understand.

But it has it's own pitfalls. Firstly if you have thousand of animated objects on screen your app will probably eat a lot of memory. Taking Social City as an example my browser memory jumps from 20mb to 250mb when game starts. And I have small city (haven't played much) and suspect that with larger one and neighbors it would get a bigger memory footprint. It's still fine, I noticed that some popular FB games take up to 400 and I seen some games in beta that were taking almost a GB of memory(probably they do something wrong) and most of them use raster pipelines. On other hands games that do use displaylist (as far as I can say Frontierville uses displaylist) are not that much smaller. Frontierville is 250mb too.

Another problem is that you loose lot of flexibility and interactivity that is already built in to Flash rendering system like that it automatically detects what areas of screen to redraw. This is hard or even impossible to do with BitmapData approuch.

So in my view you just exchange one things for another:
CPU for memory(may be not that much though)
Transparency of code(no blackbox) for lack of features some of which probably are not possible to do at all.

Re: The Flash Display List And Games

Iain Lobb — Mon, 18 Oct 2010 05:25:09 -0000

Hi Ben, I think that for 90% of cases, even games, display list is the way to go. There are too many reasons to list quickly, so I will follow up with my own blog post, but consider: workflow, nesting, transformations, timeline animation, filters, filesize, mouseEvents and dev time. I have made many Flash games, and very rarely is rendering speed an issue if you know what you are doing with the display list. Consider that many Flash games have to be turned around in 2-4 weeks. Big games like Social City are definitely the exception rather than the rule.

Re: The Flash Display List And Games

Ben Garney — Mon, 18 Oct 2010 00:12:34 -0000

This is where the "gullible and trusting" part of my tweet comes in (I didn't really deeply explore it in the blog post).

That is to say, the API temptingly lures you off the fast path, putting you in a situation where you have to start doing these exhaustive workarounds to suppress normally invisible behavior. The problem isn't any single issue, it's that you're working in an idiom where you have given up control. Certainly, you can deal with all the issues and get your app working, but I find it problematic that I'm even in a situation where the issues come up at all!

I would greatly prefer a concise API that did one thing well and quickly (like presenting a framebuffer to the user). It would be harder to use but there are plenty of middleware developers to deal with it for people. Then you end up with the ability to write a system appropriate for what you are doing, rather than having to bend an existing complex and ad hoc system to fit.

Realistically, we're both going to be developing display list oriented applications for years to come. :) But sometimes it is fun to explore what could be.

Re: The Flash Display List And Games

Josh Tynjala — Sun, 17 Oct 2010 22:33:32 -0000

I found that setting both mouseEnabled and mouseChildren on absolutely everything will do the trick for the mouse CPU issue. Just loop through every child of some common parent, and keep going down until you hit every InteractiveObject you can reach. You'd think mouseChildren on the common parent would do the trick, but it doesn't (or at least it didn't a few years ago when I actually had a use-case for that many objects displayed at once). To interact, put mouse events on a different display object and use the coordinates to figure out what was touched. I went from a mostly unusable SWF with 20,000+ display objects that maxed out CPU to one that ran nice and quick.

In that case, only a few things would be animating at one time, though, and I can still imagine that rendering might be a problem for your particular use case with a lot more animation. However, I just wanted to point out that the mouse CPU issue can be addressed, if not quite so obviously.

Re: Published (Twice)

liutao — Mon, 19 Jul 2010 02:35:50 -0000

The download URL is bad.

Re: Working with the Apple Remote on Boot Camp

Gable — Mon, 21 Jun 2010 14:35:45 -0000

Has anyone figured out how to get this display on Win 7? (probably the same as Vista)

Re: Composition vs. Inheritance

gaminghorror — Sat, 12 Jun 2010 17:26:15 -0000

Thanks for picking this up! Someone must be using Google Alert. :)
I took the opportunity to follow up on PBE progress, gratz for the v1.0 release!

Re: Working with the Apple Remote on Boot Camp

congsdfsdf — Tue, 20 Apr 2010 05:13:25 -0000

my +/- button are all HID 000000000000 how do i change it?

Re: PushButton Engine 101 Talk Video Now Available

johnhattan — Sun, 11 Apr 2010 08:07:44 -0000

Yeah, I enjoyed FGS more than GDC. I saw as many worthwhile presentations in one day of FGS than I in three days of GDC. Especially disappointing were the iPhone sessions, which were largely about how to game the app store. Saw two Android presentations that were basically the same, only one was slightly better. Weird.

FGS could've used a better location for the expo tables, as it did get crowded around 'em. OTOH, they got more exposure that way. I was able to locate a couple of quiet corners for interviews, so I was happy.

Re: I Wrote A Book: Video Game Optimization

Konrad Kiss — Mon, 05 Apr 2010 02:58:05 -0000

Congratulations to both of you, Ben. I'll be sure to pick this up.

Re: 3D in Flash 10 & Git

Pedram Pourhossein — Sun, 14 Mar 2010 04:44:01 -0000

Hi Ben,
I just found your blog, It's really cool, I like it. ;-) thanks for your good blog.

Re: ActionScript 3 Reflection: list fields on an object with ClassFieldCache

Ben Garney — Sat, 13 Feb 2010 16:28:53 -0000

Yup - except that sometimes you don't want to rely on the Flex SDK. DescribeTypeCache also doesn't store out all the field/accessor type information. Other than they are comparable.

Re: ActionScript 3 Reflection: list fields on an object with ClassFieldCache

joony — Sat, 13 Feb 2010 13:36:38 -0000

Sounds a lot like DescribeTypeCache
http://www.adobe.com/livedo...

Re: Flash on iPhone: My Experience

wazoo — Fri, 12 Feb 2010 06:54:11 -0000

much appreciate the sharing on this Ben! great stuff and damn interesting to boot.

Re: Adobe, Please Buy HaXe.

$1758069 — Fri, 29 Jan 2010 19:16:18 -0000

I've switched to HaXe one year ago and I don't regret it! It's stable, it's production proof (used it in a couple of commercial games), the language is simple, fast and updated often. My only concern is the poor documentation and the lack of a (really) good IDE. Also AS3 <-> HaXe interoperability works fine, my co-workers actually use HaXe SWC files in their AS3 projects.

Re: Flash on iPhone: My Experience

Ben Garney — Mon, 25 Jan 2010 05:02:39 -0000

Glad it was useful to you! :)

Re: 3D in Flash 10 & Git

Ben Garney — Mon, 25 Jan 2010 05:01:41 -0000

I saw your blog post. Demo runs nice and fast. Look forward to hearing what you think of PBE. :)

Re: 3D in Flash 10 & Git

Ben Garney — Mon, 25 Jan 2010 05:01:17 -0000

Thanks for sharing your numbers. I look forward to hearing what you come up with. :)

Re: Flash on iPhone: My Experience

shaderbytes — Sat, 23 Jan 2010 09:32:13 -0000

The company Im employed at is asking me to keep my ears to the ground concerning publishing to iphone from CS5 , so this post is great ;)

Re: 3D in Flash 10 & Git

shaderbytes — Sat, 23 Jan 2010 08:55:51 -0000

Hi Ben

Great experiments and revalations , I have just started getting into writing 3D code in flash. I noticed posts here from Away3d folk , I love that they have an open source engine available but I love it even more to learn how to do things for myself and to understand how it all works , if i didnt do that I dont think I would be interested in my occupation any longer ;) I will be following your blog and code samples as you have way more experience than me and I seem to share a love for coding game engines. I recently just took my own Tile engine experiment off of the "unfinished experiments self" a month ago and gave it a solid month of development in my spare time knowing nothing about PBE existing and been open source, I will have a look under the hood and see where i could learn some more there too.