Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - photonstorm

Pages: 1 ... 71 72 [73] 74 75
1441
help / Re: Best Practices - Work Flow
« on: Tue, Feb 23, 2010 »
If it's motivation you need to keep yourself going, then I would worry less about the workflow, and more about creating something really quickly. I've made a number of "games in a day", some of which have been really successful, but they are really handy motivators to keep me going.

Get your core prototype up and running as quickly as possible. By that I mean within a day or two, max. Then flesh it out, show it to friends, get feedback. You'll soon know if the idea should die right now, or evolve. Then polish it a little, tweak it some more, polish it again and keep going until it's ready for release. If you're past a month of time by this stage you've already probably spent far too long on it.

It's never really a "time thing" when making games, it's about keeping the ideas realistic - to the level where you don't sit there all depressed every time you fire up the project, wishing you could play some Team Fortress instead :)

1442
help / Re: vector vs rasterized graphics + physics
« on: Tue, Feb 23, 2010 »
Let me try to rephrase...

Flash works using a frame based system. Everything happens based off frame events. It's impossible to create a "time based loop" in Flash because you are at the mercy of the frame rate. As you said the problem with the frame rate is that its open to so many different factors - browser speed, what other crap is running on the computer at the same time, memory overhead, garbage collection, etc. All of these things cause erratic frame rates.

The problem is that this is ALL you've got to work with. Any time-based system (delta timer, etc) works by averaging out the time between frames to see how close to the desired frame rate you're actually running at, and then adjusting position/scale/etc accordingly (so if it slowed down, it moves it a bit further to compensate).

However the logic for this time-based loop is utterly dependant on the enter frame event. For example what you'd probably have is a system where you are counting milliseconds, and if you hit a certain target in your time loop then you proceed with movements, etc.

The problem is that the "counter increment" in this scenario must be controlled entirely by the frame event. It simply cannot fire independently, as there is no other internal timing mechanism in Flash Player.

If you're used to pretty much any other development language this will all sound totally alien to you, but I'm afraid that's just how Flash works! It's a legacy issue I wish it didn't have either, but alas ...

1443
help / Re: Inside flixel
« on: Tue, Feb 23, 2010 »
You're on the right track - basically there is one single bitmap* which is all that Flash Player is rendering. Everything else is copied onto this bitmap (in order) to build the display, each frame.

Objects only render when they are "on screen", but they can update whenever you like. The two actions (update and render) are not combined.

If you had a large map then only the area around the player will be copied to the buffer each frame.

* technically there are two, because Flixel double-buffers. But for all intents and purposes you only need think of it as one.

1444
help / Re: Baked Rotation and Collision after rotation
« on: Tue, Feb 23, 2010 »
I didn't look at the collision code posted the other day, but if it works how I think it does then it should handle rotation ok? It ought to be a core engine feature really though. I do have my own pixel collision system which certainly does handle scaling and rotation, so maybe I can post it up if the other one doesn't work for some reason.

1445
help / Re: Baked Rotation and Collision after rotation
« on: Tue, Feb 23, 2010 »
No it doesn't support collision on rotated or scaled sprites (it doesn't actually support pixel perfect collision on normal sprites, let alone rotated ones!).

Baked rotation means that when the sprite is loaded it will take a "grab" of the sprite rotated for every angle you need. So for a full rotation it would make copies of the sprite rotated in every possible angle* - so when you rotate the sprite in your game it just works out which angle you need and grabs back that single frame for rendering. It does this because rotating and then drawing sprites in real-time is a pretty expensive operation. However creating baked rotation for every sprite can use a lot of memory - so you have to balance out the use.

* I've not looked at the 2.x code, but I would hope that it mirrors half the rotations to save memory.

1446
help / Re: vector vs rasterized graphics + physics
« on: Tue, Feb 23, 2010 »
You'd include the renderer in the main (frame based) loop because typically you would never want your game to render at a speed *slower* than the frame rate. And as this is the fastest loop in your game (nothing can fire quicker) you may as well bundle them together.

1447
Just a suggestion - but you don't need to have the 4 directional consts, because you are extending FlxSprite - so just use the "facing" parameter it already has to save yourself a bit of hassle :)

1448
help / Re: Filxel on Flex 4 SDK for flash player 10
« on: Sun, Feb 21, 2010 »
I assume you mean that it can't compile for fp10 from flex4? Because it certainly compiles for fp10 with the current flex sdk. My last flixel game (can be found on the flixel site) uses lots of fp10 only features Inc heavy use of vector datatypes.

1449
help / Re: vector vs rasterized graphics + physics
« on: Sun, Feb 21, 2010 »
To answer your final question first: Flixel is fast for two reasons 1) most flixel games are running at half the display size. 320x240 typically, scaled up to x2. 2) it uses 100% bitmap system totally bypassing the vector renderer. Raw copy pixel operations are extremely fast in AS3.

Your game sounds great, and also sounds like the complete and utter opposite of what flixel is about. It sounds far more suited to a game made in standard flash (with a decently optimised game loop)

1450
help / Re: Filxel on Flex 4 SDK for flash player 10
« on: Sun, Feb 21, 2010 »
The issue is to do with compiling under flex 4. Flixel made games run just fine under flash player 10.1 (even fonts). I agree it needs to be able to compile too! But it definitely runs under fp itself.

1451
releases / Re: Flixel Iphone
« on: Thu, Feb 18, 2010 »
Can you name any Windows tools that can compile to an IPA though, other than CS5? I don't know of any. The signing part is trivial, I've just yet to see anything else that does the compilation. If it was that easy I'd have expected the Unity guys to be all over it.

1452
releases / Re: Flixel Iphone
« on: Thu, Feb 18, 2010 »
Providing it can create a fully working ipa file, I don't think Apple can even tell what created it. Only that it's valid.

1453
releases / Re: v2.5 Planning Thread
« on: Thu, Feb 18, 2010 »
One thing I've been adding to my own version of 1.57, but would like to see added to the core, is the ability to support masks. Either to a specific Sprite, or to a Layer (I guess Group now). I've added a "mask" for complex shape support (i.e. you provide it with a png that masks out what is drawn, but isn't drawn itself). But I also added a clipMask which is a rectangle area in which the current Sprite/Layer doesn't get drawn.

1454
help / Re: External Sprites for Flixel
« on: Thu, Feb 18, 2010 »
I would split this into two things: A class to download the bitmap and process it, and then your actual Sprite. I wouldn't create the sprite until the data has downloaded as Flixel will start trying to use it, and fail miserably.

A simple download class should be a few lines to write, pretty easy. Just cast the resulting file to a bitmap and pass it to your sprite as if it was embedded.

1455
releases / Re: Flixel Iphone
« on: Thu, Feb 18, 2010 »
I would have thought if anyone could do the "Windows to IPA" move next it would be Unity, but the last time I checked you still needed a Mac to do that, and I guess Rich just confirmed it.

Mind you if you're on a Mac anyway then I'd much rather use Corona! (http://www.anscamobile.com/corona) :)

1456
releases / Re: Flixel Iphone
« on: Wed, Feb 17, 2010 »
I've been using CS5 for months. I'm part of the Adobe pre-release program and installed the latest beta (Drop 13) the other day. I use it on Windows exclusively and it compiles the IPA just fine. Joining the Apple Developer program took a few minutes (and a bit of cash), and creating a developer certificate is no more complex than making a public / private key with OpenSSL.

You don't need a Mac, and I've two apps which prove it :) (one of which hits the store in a few weeks time).

1457
releases / Re: Flixel Iphone
« on: Wed, Feb 17, 2010 »
This is true of almost every program developed for the iPhone. In fact, even the few cross-platform solutions for the iPhone require that you use a Mac for actually building your game for the iPhone.

Except CS5 of course, hence why it's currently one of the only options for Windows developers who don't want to spend thousands buying over-priced under-specced hardware.

Flixel into Mono into IPA app.. sounds just as tedious / slowness prone as the way Adobe handle it atm :)

1458
help / Re: Fast pixel-precise collision detection class
« on: Wed, Feb 17, 2010 »
Nice - I ported my own collision code over to achieve the same end-result as this, using a very similar technique. However I didn't update it for the new v2 yet, so it doesn't hook into the benefits of the quad tree Adam added - does this version?

1459
releases / Re: New Website Look
« on: Wed, Feb 17, 2010 »
I don't mind these forums, I just wish to God the colour scheme wasn't white text on a black background. It makes my eyes bleed.

1460
releases / Re: Flixel Iphone
« on: Wed, Feb 17, 2010 »
The biggest problem with a "native" port is it will be Mac only to develop it. And that rules it out for me.

@haden - there is no PUBLIC beta of CS5, but the Adobe pre-release program has been running for months now.

Pages: 1 ... 71 72 [73] 74 75