Onee-sama Tasukete!

[darkblu]

If I were converting the project to OpenGL the rule of 8 wouldn't help me much unless I went down to 16 pixels or up to 32, both of which don't look good (or 15 or 31 if I want to be able to use any type of filtering) because for instance 24 wouldn't fit neatly into a power of 2 texture atlas.

in case you're referring to wrap-around artifacts, you can use clamp-to-edge addressing mode to avoid that. it's part of the ES core spec thus is universally supported.

 

[Eniko]

Correct me if I'm wrong but clamp-to-edge only works for the actual edges of the texture, not the edges created by the UV coordinates which is why this doesn't help when you pack multiple textures (or tiles/sprites) inside a single texture to reduce texture state changes.

 

[darkblu]

Correct me if I'm wrong but clamp-to-edge only works for the actual edges of the texture, not the edges created by the UV coordinates which is why this doesn't help when you pack multiple textures (or tiles/sprites) inside a single texture to reduce texture state changes.

correct. but with clamp-to-edge you can still use the end rows/columns of your atlases, which is what i originally assumed your concern was with. my bad if i misunderstood that.

 

[Eniko]

Stopped being so excruciatingly hot out here, so I finally managed to sit down and do some work. Yay moar art!

 

[Exophase]

TI has written before that non-power of two textures are much, much, much slower than power of two (non-square is OK), something like 10 or 20 times slower. I don't know if this has since been fixed but you should watch out...

 

[Eniko]

Well that would be a problem. I guess I'll find out soon enough. I don't suppose sticking the tiles into a power of two texture atlas and only blitting parts of the surface would get around that?

 

[Exophase]

Well that would be a problem. I guess I'll find out soon enough. I don't suppose sticking the tiles into a power of two texture atlas and only blitting parts of the surface would get around that?

Should be fine with texture atlasas, just saying you should probably make them power of two.

 

[darkblu]

Stopped being so excruciatingly hot out here, so I finally managed to sit down and do some work. Yay moar art!

lovely. may i suggest that the henchman currently holding the little sister (correct?) on that fishing pole, actually held the end of a rope going over a gallows pole leaning over the edge of the roof, with the little sister tied head-down on the other end of the rope (a pack of ragin rottweilers underneath being entirely optional)? just for a tad more dramatic effect.

 

[Bosbeetle]

Wow I love this stuff hope to meet you sometime on one of the dutch meets the first one was kind of low on people.

*engels accent opzet en zegt :"Vooral doorgaan"

 

[God Ginrai]

Stopped being so excruciatingly hot out here, so I finally managed to sit down and do some work. Yay moar art!
[awesome image]

That Panda Graffiti is the best part of the image, IMHO. ^_^

-God Ginrai

 

[Eniko]

So I've set up the basic framework for the game. It loads a "level" which right now is just a list of points where the floor will be, then draws a line between the points and lets you scroll the camera around. I've tested blitting two separate 440x280 layers onto a buffer, then scaling that to the screen and it's chugging along at 62 FPS on my Pandora. Since my target is 30, I would say that parallax scrolling is in.

Of course I don't know if this might not go down due to some stealthy RLE optimization in Pygame, but since you have to specifically set that for surfaces I'd guess that the performance is going to stay the same regardless.

In other words; good times!

EDIT: That's ~62 at 500mhz, ~87 at 800mhz.

 

[darkblu]

nice! did not expect Pygame to handle blitting so well.

 

[Eniko]

Pygame has no way to draw images mirrored? Seriously? I have to flip the entire surface and keep an extra copy in memory? Seriously?? <_<

 

[sebt3]

Pygame has no way to draw images mirrored? Seriously? I have to flip the entire surface and keep an extra copy in memory? Seriously?? <_<

For what it worth : http://forums.libsdl.org/viewtopic.php?p=24801&sid=15c2941c065348f618ea1d0696b2db1f

 

[Eniko]

So it's an SDL thing, not a Pygame thing then. I'm probably not putting enough effort to understand the reasons for this not being a feature, but it's pretty irksome that SDL lacks a feature that I recall even DirectDraw managed to have.

 

[wardred]

Eniko,
Love the screen shots so far. Looking forward to seeing what you do with this.

Cheers!

 

[Eniko]

Seems I finally cracked the physics engine problems. It only took like 8 rewrites, a whole lot of brushing up on math and realizing that I was never going to make line-line collisions work and that I had to switch to circle-line collisions instead.

Last time I code a game that needs real time physics, gah! Oh well at least now I know how to use the dot product and how to project one vector onto another and all sorts of other jummy related stuff.

 

[traylorpark]

Eniko! I wanna send you a good luck, excited to see more message. So, good luck! I'm excited to see more!

 

[Eniko]

Thanks for all the motivational messages, I really appreciate it and it helps me keep working on this!

Got bored today and made this:

Don't make her angry.

...You wouldn't like her when she's angry.

 

[God Ginrai]

Thanks for all the motivational messages, I really appreciate it and it helps me keep working on this!

Got bored today and made this:

Don't make her angry.

...You wouldn't like her when she's angry.

You should continue that animation and make her fall over backwards after looking all menacing. (that's what happens when you lean too far back )

-God Ginrai