iOS Gles

[xArtx]

Hi,
I just got Box2D working with Ball Physics, and now realise Angry Birds could
have been done by anyone..

http://www.youtube.com/watch?v=UOwlxy8v6b0

... well anyone with some great ideas, levels that work, and very fancy graphics!

So my next App doesn't let the user know that every button and display
panel is a physics object until such time as it transitions between modes
or orientation.

I can print to the images that are used to texture the bodies, and by changing
the texture (like Angry Birds do), it is possible to do a live display on a physics body.

What I'm having trouble with is altering at a pixel level with GLES.
I can compose my own image for every frame, but this is still a long way round.
Are there any very raw examples of how to draw just a pixel to a layer?
Ideally, I think I'd be set to see a pixel who's colour value is changed for
every frame (a proper direct way).. then I think I could do the rest of what I want to do.
Cheers, Art.

 

[Duncan C]

Hi,
I just got Box2D working with Ball Physics, and now realise Angry Birds could
have been done by anyone..

http://www.youtube.com/watch?v=UOwlxy8v6b0

... well anyone with some great ideas, levels that work, and very fancy graphics!

So my next App doesn't let the user know that every button and display
panel is a physics object until such time as it transitions between modes
or orientation.

I can print to the images that are used to texture the bodies, and by changing
the texture (like Angry Birds do), it is possible to do a live display on a physics body.

What I'm having trouble with is altering at a pixel level with GLES.
I can compose my own image for every frame, but this is still a long way round.
Are there any very raw examples of how to draw just a pixel to a layer?
Ideally, I think I'd be set to see a pixel who's colour value is changed for
every frame (a proper direct way).. then I think I could do the rest of what I want to do.
Cheers, Art.

OpenGL divides the work between the CPU and GPU, and the hardware architecture makes it fairly expensive to communicate between them.

The idea is that the CPU describes the geometry (polygons, points, shading, perspective, etc.) and hands it to the API, which uses the GPU to translate that into pixels and draw them to the screen.

it's designed around NOT manipulating pixels as pixels.

You can have a large texture that you use as a tile map to render frame-based animation quite quickly, but that means having all the frame data in graphics memory at once.

You can also use approaches like rag-dolls, where you make articulated characters and move them at their joints, then render the result with a texture mapped on top of it.

If you want to manipulate pixels directly, the most direct way to do that is with a custom shader. However the shader language isn't designed for it, so you end up fighting against the architecture.

I wish Apple would release OpenCL for iOS. OpenCL is a programming language that lets you run code directly on the GPU, and share data structures directly between your CL program and your GL renderer. You can do pixel manipulation in OpenCL, then treat those pixels as a texture in OpenGL without having to copy any data.

 

[xArtx]

Ok, I understand.. It is counter intuitive that a spritesheet would be faster,
but Angry Birds certainly does fine.
I can get away with printing some text to a small png every frame
just to a display panel that is a boring most of the time,
but if a custom spritesheet is going to be faster, that's even better news.

I do feel like a leash has been taken off me..
I added more physics bodies than the screen can accommodate, and it's still 60FPS.
Massive change from using UIkit/Quartz2D for everything.
I think there will be no turning back.

 

[Duncan C]

Ok, I understand.. It is counter intuitive that a spritesheet would be faster,
but Angry Birds certainly does fine.
I can get away with printing some text to a small png every frame
just to a display panel that is a boring most of the time,
but if a custom spritesheet is going to be faster, that's even better news.

I do feel like a leash has been taken off me..
I added more physics bodies than the screen can accommodate, and it's still 60FPS.
Massive change from using UIkit/Quartz2D for everything.
I think there will be no turning back.

Why is the speed of sprite sheets counter-intuitive? You are playing to the strengths of the graphics engine. The graphics engine is happiest when you use textures that are a power of 2 in size. That's wasteful if your source image is not a power of 2, so you divide up a large texture into tiles.

Rendering a texture onto your screen is blindingly fast. mapping a different part of the texture onto the screen for each frame is just as fast.

 

[xArtx]

It's counter intuitive coming from the dark ages where dynamic drawing is fast, and block image transfer isn't free.

You can also use approaches like rag-dolls, where you make articulated characters and move them at their joints, then render the result with a texture mapped on top of it.

That's interesting, I can already do that with Box2D, you can join the bodies
for more complex objects.
A better demo than the one in the video is rotating gravity about centre origin
at a constant rate (as if spinning the phone around perfectly) for a
tumble dryer effect.
Now I think maybe the rag doll man would look better in the tumble dryer,
with the tumble dryer graphic around it.

 

[1458279]

I've heard, but haven't confirmed myself, that the engines like Box2d and others are now built in. Meaning that Apple now has their own engines.

Can anyone confirm this?

Anyways, if Apple now has it's own engines, I'd look into using those.

 

[Duncan C]

I've heard, but haven't confirmed myself, that the engines like Box2d and others are now built in. Meaning that Apple now has their own engines.

Can anyone confirm this?

Anyways, if Apple now has it's own engines, I'd look into using those.

Apple has included some new APIs like sprite kit into the OS. They offer some of the features that cocos2d offer. I haven't done a comprehensive comparison however.