Did I Reach The Limit Of Fenix, Is Sdl Faster?

[jaysalmon3]

I been working on a game – osprek - and decided to write it using fenix, mainly because I like trying new things. (I know fenix isn’t new but I never heard of it till I got my GP2X.) I ran in to a problem, a boss at the end of the first level shoots lasers. To make it so the laser can reflect and bounce around I created a process that draw a blue laser 4x10 px and moves it forward at any angle and reflect and bounce accordingly. Then I created a process that starts the laser process after the laser process travels 10 px. Voila, a laser looking object. Here’s my problem it slows down a lot. I removed my reflecting and bouncing logic to save instructions, but it’s no good. I just can’t get rid of it either it’s to damn cool looking.

Options:
1. Dump the laser.
2. Switch to SDL.

If I switch to SDL is it that much faster then fenix?

EDIT:
BTW I know Fenix is built on SDL, is Ruby killing FPS?

 

[sam fisher]

Do you know C or C++

If yes, then use SDL.

If no, don't use SDL.

 

[jaysalmon3]

Do you know C or C++

If yes, then use SDL.

If no, don't use SDL.

Yes I know C and ++, here’s the problem I wish my imagination let me to this problem earlier, easy fix; but is the speed increase great enough for a total rewrite? I have 1200+ lines of code and the engine is included with fenix. Also is there a lib that’s similar to the fpg’s.

-Malic

 

[sam fisher]

I'm sorry, im only just starting out in C

However, are you referring to the performance of the game on a GP2x?

Also, is it possible that there may be a more efficient way to do what you are trying?

 

[Moogle]

Also, is it possible that there may be a more efficient way to do what you are trying?

I suppose that is what he wants to know

Of course I don't know your implementation, but here are some things that might work:
- Use the least amount of angle functions possible. This includes advance, get_distx, get_disty, get_dist, etcetera. They use floating point math which is slow.
- Avoid calling the collision function too often, though I doubt you are even using it at all.
- Maybe you are blitting a lot of rotated graphics? Maybe a version with only multiples of 45 degrees(so you can prerender them) could help speed blitting up.
-

Anyhow, this is all pretty global, put up the relevant snippet and we can look at it more carefully. If the choice really is dump the laser or move to SDL I'd say remove the laser and come up with some other fantastic special effect

 

[ledro]

I guess u use cos/sin/tan functions to calculate directions. These functions are very slow. You can use arrays with precalculated values of these functions.

 

[Goity]

I been working on a game – osprek - and decided to write it using fenix, mainly because I like trying new things. (I know fenix isn’t new but I never heard of it till I got my GP2X.) I ran in to a problem, a boss at the end of the first level shoots lasers. To make it so the laser can reflect and bounce around I created a process that draw a blue laser 4x10 px and moves it forward at any angle and reflect and bounce accordingly. Then I created a process that starts the laser process after the laser process travels 10 px. Voila, a laser looking object. Here’s my problem it slows down a lot. I removed my reflecting and bouncing logic to save instructions, but it’s no good. I just can’t get rid of it either it’s to damn cool looking.

Options:
1. Dump the laser.
2. Switch to SDL.

If I switch to SDL is it that much faster then fenix?

EDIT:
BTW I know Fenix is built on SDL, is Ruby killing FPS?

Fenix may be slower than SDL, but it should be perfectly fast enough for what you're trying to do.

 

[torpor]

Try integrating the laser-draw in your main process, instead of creating a new process for the job .. you see, you're suffering the Task-Switch overhead for each stage of the laser draw, so obviously this is going to be slow ..

Put the calculation of the laser in your main process, in other words, and draw the laser there ..

 

[Moogle]

It's not too much work, switching instances, it's just a couple of internal data pointers. But yeah, try putting the 4x10 laserpart moving/drawing in one process, creating and deleting processes, especially when you are using a lot at the same time, can take up significant cpu time, so that's a good tip.

 

[WarmFluffyUK]

Try the latest runtime for the GP2X, when I was developing Myriad I had a lot of slow down, especially on the space screens which didn't appear to be doing much at all. Puck sent me an updated fxi and things were incredibly fast after that.

The latest fxi is included with Myriad.

 

[Goity]

Try the latest runtime for the GP2X, when I was developing Myriad I had a lot of slow down, especially on the space screens which didn't appear to be doing much at all. Puck sent me an updated fxi and things were incredibly fast after that.

The latest fxi is included with Myriad.

The one released for the GP2x.co.uk compo increased performance a lot, especially for stuff like Mode7