next »

[J. R. Hill]

You had me at linked lists. 

[easynam]

I like the logo, aside from it being too loud. My main problem is learning the differences between AS3 and java. Does the spritemap's flipping work or am I just using it wrong?

http://flashpunk.net/forums/index.php?topic=62.0

[moi]

My main problem is learning the differences between AS3 and java.

I find these two languages to be very close to each other, furthemore you don't have to make a lot of effort when you use flashdevellop, which has the good habit of doing all the work for you (flashdevellop is written in java BTW)

[raiten]

AS2 is a massively sllugish clusterfuck. AS3 has a different, more programmer-oriented structure, but even if you don't like that it pays off a lot to learn it. I'm fairly sure nobody uses AS2 to make games anymore, and I doubt anyone has plans on supporting it. Could be wrong though.

I actually think loads of people are still using AS2 to make games (I do). I think all of the big flash-based micro transactions have support for AS2 and they're all pretty recent.

[Preachieved]

Thanks, easyname. I think I see what I was doing wrong.

[Martin 2BAM]

Let me get this straight: The maps are entirely made out of sprites?, there are no tilemaps or similar whatsoever?

Thanks

[Matt Thorson]

Here's some quick terminology:
active: executes game logic code on every frame (such as physics or checking for collisions or handling input)
visible: is drawn to the screen on every render loop
collidable: can be collided against other objects

Now let's look at some of the different entities in FlashPunk in relation to these properties:

	active	visible	collidable
Actor	YES	YES	YES
Tilemap	NO	YES	NO
Grid	NO	NO	YES

So there are tilemaps, but they are purely graphical.  There are also grids, and those are purely "gameplay" (they're invisible, but you can collide against them).

Tilemaps can be rendered very quickly because they're essentially just a huge bitmapData.  When you add tiles to one, they just get copied over onto that bitmapData.

Also, a "sprite" in FlashPunk is not equivalent to a FlxSprite.  The equivalent class to FlxSprite is Actor.  Each Actor has a sprite variable which is the image to draw to the screen on each render loop (this use of the term Sprite is taken from Game Maker).

[Martin 2BAM]

Cool, thanks for the info!

Do you know the design fact behind that decision?
Why not having a unified class that does both things? You can use a graphic-less tilemap to do as grid, or a "gridless" tilemap that you never collide-check.

Also, a big bitmap doesn't seem like the best idea:
In Flash 9, the max image size is 2048px² and Flash 10 4096px² (or around that number)
If using 32x32 tiles:
A 160x160 map wont work in Flash 10.
A 70x70 map wont work in Flash 9.
To get it in game proportions, for "Finding her" I used a 300x300/32x32 (9600px²) map.
Is this contemplated somehow?

(I'm asking you because you're probably closer to ChevyRay and you've been getting your hands into FlashPunk a lot from what I've read)

Thanks for your time
-Martín

[moi]

Do you mean that the tilemap class is just rendering a huge sprite all the time with most of it hidden outside of the screen borders?
That kind of defeats the purpose of having a tilemap in the first place (that is to just render the tiles that are visible) and it also make flashpunk much less useable for high rez games (but I know TIGSource loves big pixels)

[ChevyRay]

Yeah, that's because it was a last-minute change. FlashPunk is not really "complete" as I'd like it to be, just at a useable state. I plan on implementing changes to the tilemap that allow you to add/remove/change specific tiles that have been added to the tilemap, and work with them individually, making it more of an actual TileMap. Currently it's mostly just a canvas that you can add tiles to, so only halfway there, and only the part of the canvas that is on screen is actually rendered (because this way seems to be the fastest using AS3's bitmap functions).

I originally had it actually just render the tiles from an array, but it was much slower, so that particular class is still a WIP. If you had really huge tiles in a high-res game, then it'd probably be slower, but that seems a lot less common to me.

@nitram_cero: Yeah, 4096 isn't that small though. If you're going to use bigger tilemaps than that, you could always just use Actors or multiple TileMaps; it's just that it seems, to me, that such large tilemaps aren't as common, so the current method I'm using, while not supporting the largest of sizes, at least runs the most efficiently. It wouldn't be difficult for me to create another class for the alternative purpose, but a choice between the two seemed to favor smaller + faster tilemaps instead, because I figured they'd be more common (as Flash is notorious for one-screen games, etc.)

Why not having a unified class that does both things? You can use a graphic-less tilemap to do as grid, or a "gridless" tilemap that you never collide-check.

This is because I haven't quite decided how I want collisions to work on TileMaps. Currently tiles are not locked to a grid, so I'm not quite sure of the most efficient way to check for collisions on what could be a set of arbitrary sized rectangles placed freely on a canvas. The Grid class is meant specifically for grid-locked, static-sized rectangles, so making it part of the TileMap class is kind of odd considering this conflict.

So yeah... design decision for tilemaps was ultimately: faster + more useful for a larger group of people. But I could be wrong, though I see no problem in creating an alternate TileMap class with an array-approach that supports collisions. From where I come from and how I develop my games, though, the current approach is extremely useful for me.

[moi]

OTOH, a game like "levelup" for example would be extremely difficult to make in FP , wouldn't it?

[ChevyRay]

I don't know lots about the game, I think I played an early build of it. But I don't know what about it would be so difficult to make in FP, I haven't played the finished version of the game though.

[Martin 2BAM]

Considering what you told me, it's sort of cool to have them separated.
The graphical part will be the only one affected by flash's limitations, while the collisions can be centralized and checked against just one structure.

Perhaps, eventually, a wrapper could be made so that it automatically configures and maintains several tilemap "slices" and one grid structure.
It will be more intuitive to work with, I believe.

And by no means I wanted to demoralize you, I know for a fact that maintaining and upgrading a "public" framework (utility in my case) is a hard task.
Just wanted to have the key concepts in mind in order to know how to better integrate it to Flan in the future.

Thanks!

[ChevyRay]

Perhaps, eventually, a wrapper could be made so that it automatically configures and maintains several tilemap "slices" and one grid structure.
It will be more intuitive to work with, I believe.

Oooh, that sounds like a good idea. Definitely works within the structure that I've started to lay out already, and it sounds both efficient and nice to work with at the same time. I will note this down and play around with the idea on my next iteration of updates.

And by no means I wanted to demoralize you, I know for a fact that maintaining and upgrading a "public" framework (utility in my case) is a hard task.
Just wanted to have the key concepts in mind in order to know how to better integrate it to Flan in the future.

Thanks!

No problem dude I appreciate the input, and know where you're coming from, which is why I took the time to explain why it's currently set up how it is. But yeah, some things are left a bit ambiguous right now (could go either way) because I wanted to get user's reactions and suggestions first, before I took a strict direction with the library's structure. And already I'm getting good ideas.

 

[moi]

"Levelup" has a HUGE map.
I coded a tilemap display in my engine and it makes no difference in performance if I display a 5000X5000 map or a 100x100 one, that's the beauty of tilemaps.

[ChevyRay]

But the same goes for using one big bitmap and rendering just the visible region of it. No matter how big the bitmap is, there's no different in performance, the screen stays the same size and thus the amount of rendering remains the same. So I just don't quite get what part I'm missing here.

EDIT: Oh nevermind, by performance you mean that you don't have to keep one gigantic friggin bitmap in memory. Right. Perhaps I'll rename the current TileMap class to "TileCanvas" or something, or just settle for the usual tile method and just get rid of the current one completely. Sorry for the confusion, I've been up all night and probably should be sleeping

[ChevyRay]

There's now an IRC channel going, and also a forum topic I started with the plans for the next update. I've already got an improved TileMap class coded with all the suggestions as made here, which can check for collisions and is not restricted by Flash's bitmap size. There's also some other plans at the moment, but I'm open for suggestions if anybody has 'em at this point.