Author Topic: v1.3 Planning Thread  (Read 26996 times)

darthlupi

  • Active Member
  • ***
  • Posts: 241
  • Karma: +0/-0
  • All Smiles
    • View Profile
    • LupiGames.com
Re: v1.3 Planning Thread
« Reply #80 on: Mon, Nov 16, 2009 »
Radness.  Lupi is pleased!

I can already invision some fun color changing effects for powerup getting and stuff!  Player rushes through 10 different hues when he collects the powerups!

Can't wait to toy with the fun stuff.
To take care of that not so fresh feeling: #flixel on irc.freenode.net.

Use your favorite IRC client or  http://webchat.freenode.net/

mklee

  • Member
  • **
  • Posts: 68
  • Karma: +0/-0
    • View Profile
Re: v1.3 Planning Thread
« Reply #81 on: Mon, Nov 16, 2009 »
Sweet Adam! Going to try the newest build out on a small prototype I'm working on right now.

syndrome

  • Member
  • **
  • Posts: 16
  • Karma: +0/-0
    • View Profile
Re: v1.3 Planning Thread
« Reply #82 on: Tue, Nov 24, 2009 »
Hi everyone,

About that Mersenne twister, I have something which is very light and FlxG-ready.
It's an LCG function (http://en.wikipedia.org/wiki/Linear_congruential_generator) that looks like this:

Code: [Select]
function LCG(seed:Number):Number {
  seed = int(seed * 0x7FFFFFFF);
  var nResult:Number = (69621 * seed) % 0x7FFFFFFF;
  nResult = nResult / 0x7FFFFFFF;
  return nResult;
}

The seed can be virtually any number that you think of, and you can just provide Math.random or getTimer if you want to base your seed on current time.

It even works with AS2.0!

You can learn more about LCG on the web. It's very very simple, but I was concerned with the poor distribution (resulting in patterns emerging) and possible repetitive artifacts, so here's the Math.random vs LCG visual comparison demo (source code included):

http://www.orionsyndrome.com/flash/lcg/lcg.zip (~500k because of the FLA file with component buttons in it, sry)

As you can see, I'm quite happy about it.

It's important to note that LCG is not a high-quality pseudorandom generator, but it's fast, stable, very suitable for game development (chunky noise in general, like dice, cards shuffling, and procedural generation), and ridiculously easy to use.

Also, the number 69621 (see the code above) is actually very important for this function to work. There is a series of numbers that are noise-friendly and applicable to this algorithm. Some of them I've included in the comments (within the FLA code), but you'll have to find the rest of them on the web.

For some odd reason, however, when I intentionally tried several (wrong) numbers, they didn't generate visible patterns in AS3.0 (as they did in AS2.0). I'm not sure, but there is probably some residual data in AS3.0 due to changes in Number specifications... It's either that, or it's just Godly perfect :D

Please check it out, and ask me if I can help.
A CPU benchmark wouldn't hurt either, if someone wants to do it.

(Btw, Adam, move this elsewhere if it's going to clog up the thread - I looked but couldn't find a better place.)
:: 5mnths Flixel addict :: 6yrs in the IT biz :: 9yrs AS(0/1/2/3) nerd :: 13yrs gfx :: 18yrs old nick :: 21yrs music :: 24yrs coding :: 26yrs computer gaming :: 30yrs old geek :: 31yrs+ ahead of time, and counting :: [04/30/10] ::

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v1.3 Planning Thread
« Reply #83 on: Tue, Nov 24, 2009 »
that is frickin rad!!  great research dude :D

syndrome

  • Member
  • **
  • Posts: 16
  • Karma: +0/-0
    • View Profile
Re: v1.3 Planning Thread
« Reply #84 on: Tue, Nov 24, 2009 »
thx, I'm glad I could help out
:: 5mnths Flixel addict :: 6yrs in the IT biz :: 9yrs AS(0/1/2/3) nerd :: 13yrs gfx :: 18yrs old nick :: 21yrs music :: 24yrs coding :: 26yrs computer gaming :: 30yrs old geek :: 31yrs+ ahead of time, and counting :: [04/30/10] ::

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v1.3 Planning Thread
« Reply #85 on: Thu, Nov 26, 2009 »
Just overhauled the collision system completely, I think it's improved (if definitely not perfect):

1 - Uses some kind of retarded version of hulls or verlets or something to help with the speed-related collision bugs

2 - You can now collide a group of objects along the X or Y axes individually

3 - hitFloor() and hitWall() and hitCeiling() all take a pointer to a FlxCore

4 - no need for CollideArray2() anymore, as all collision is between FlxCores and other FlxCores

5 - added a 'fixed' flag (static is a keyword sadly) that alters how collisions happen (tilemaps and blocks are automatically flagged as 'fixed')

6 - updated flx invaders, flxteroids, and mode to work with the new system

I *think* it's an improvement...there is still some order-dependency stuff (like calling super.update() before certain things or after others can alter behavior a little) but in a serial system there will always be a little bit of that i guess!  Let me know what you guys think

Titch

  • Contributor
  • ****
  • Posts: 270
  • Karma: +0/-0
  • Thing with the guy in the place.
    • View Profile
Re: v1.3 Planning Thread
« Reply #86 on: Fri, Nov 27, 2009 »
I'm digging the new input system. It took me a moment or two to work out, but it means I can set up local input objects which should save quite a bit of speed. Also. MORE KEY! =D
Free cake whippings every day at #flixel on irc.freenode.net.

PizzaBoy

  • Guest
Re: v1.3 Planning Thread
« Reply #87 on: Fri, Nov 27, 2009 »
I hope B-Flixel is updated to match soon, I'm using B-Flixel 1.25-C for a project, and I'm afraid of breaking too many things by trying to add these new Flixel changes in myself.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v1.3 Planning Thread
« Reply #88 on: Fri, Nov 27, 2009 »
yes new input system you can do things like declare a global string as a way of doing bindings (though to only one key).  also I just pushed up FlxG.random(), you should definitely use this in place of math.random() wherever possible as it supports seeds! (FlxG.seed = 98398)

PS - i used the algorithm that syndrome posted, only i edited it to mutate the seed automatically so that you can always generate the same string of random numbers.  it uses a getter and setter for FlxG.seed though so that you can still easily access the original seed you set (useful for save games and stuff).  FlxG.random() also gives you the option to ignore the seeded value, in which case it defaults to Math.random()
« Last Edit: Fri, Nov 27, 2009 by Adam Atomic »

PizzaBoy

  • Guest
Re: v1.3 Planning Thread
« Reply #89 on: Fri, Nov 27, 2009 »
Well, I converted my project to Flixel 1.27, and it turns out the new collision system completely destroys all of my movement code, so I'll stick with B-Flixel 1.25-C for this project.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v1.3 Planning Thread
« Reply #90 on: Fri, Nov 27, 2009 »
Yea, the new movement system can be funny about directly setting the x and y values of sprites, but there is a new reset() funciin in flxcore that will set last to the right values.  Basically if you have teleporting or respawning objcts you just need to make sure that when you manually set x and y you also set last.x and last.y

if you are not having weird tilemapping bugs with the old code, though, then pro ably not much need to update :)

Titch

  • Contributor
  • ****
  • Posts: 270
  • Karma: +0/-0
  • Thing with the guy in the place.
    • View Profile
Re: v1.3 Planning Thread
« Reply #91 on: Tue, Dec 1, 2009 »
Would it be possible to get some extra functions added to FlxKeyboard. I tried to mod them on myself but I was having trouble working out the best way to go about it.

In addition to justPressed

justTapped (Key:String)
justDoubleTapped (Key:String)

As in the player released the key very shortly after hitting it. Perhaps with some kind of sensitivity variable so you can tweak it out a bit.
Free cake whippings every day at #flixel on irc.freenode.net.

darthlupi

  • Active Member
  • ***
  • Posts: 241
  • Karma: +0/-0
  • All Smiles
    • View Profile
    • LupiGames.com
Re: v1.3 Planning Thread
« Reply #92 on: Wed, Dec 9, 2009 »
Hey titch, this is pretty easy to do by:
1. create variable to use as a time
2. store a value in array or a string for every time you press certain a button or key AND set the above timer.
3. The timer is subtracted by FlxG.elapsed and if that timer < 0  clear the array.
4. If the values in the array or string are say LEFT LEFT or 1 1 then you pressed left twice and rock on.
To take care of that not so fresh feeling: #flixel on irc.freenode.net.

Use your favorite IRC client or  http://webchat.freenode.net/

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v1.3 Planning Thread
« Reply #93 on: Wed, Dec 9, 2009 »
Ok 1.3 is up on github!

Code: [Select]
Flixel v1.3 Changes
===============================================
FlxArray
- getRandom() wrongly refers to length, not A.length
- class itself deleted and relevant functions moved to FlxG

FlxEmitter
- use reset instead of manually setting X and Y during emit

FlxTilemap
- callbacks/checks for specific tile indices etc
- accessors for altering tilemaps on the fly

FlxG
- FlxG.debug flag tells you if you're running a release build or not
- debug console updated to automatically indicate debug vs release
- calling follow sets the camera position but ignores boundaries

FlxPanel
- support panel prints a reminder to the debug console if you try to show it before it's initialized

FlxSprite
- new boolean 'antialiasing' controls quality of rotation
- fixed problems with facing, randomFrame, specificFrame and calcFrame
- facing is now a uint, with static consts for UP and DOWN

FlxText
- now extends FlxSprite and caches to BitmapData
- single lines of centered pixel text no longer blur

FlxCore
- added new array collision functionality (is reverse from FlxG's array functions)
- flicker forever bug fixed

General
- documented all functions, stopped using Array.length in loops, and made most private variables protected

flx.py, FlxInvaders, FlxTeroids and Mode have all been updated accordingly.  There is some stuff that I added that those things don't really show off though, so poke around :)  I'm going to try and put together a 1.4 release tomorrow with sprite sheet support, some collision fixes, a better sound system, and some other good stuff!

fefranca

  • Guest
Re: v1.3 Planning Thread
« Reply #94 on: Wed, Dec 9, 2009 »
Awesome, thank you Adam!

mklee

  • Member
  • **
  • Posts: 68
  • Karma: +0/-0
    • View Profile
Re: v1.3 Planning Thread
« Reply #95 on: Wed, Dec 9, 2009 »
Woah, huge update ahoy! Just in time too for Ludum Dare!