Sparks: A Vectorial Shooter

[gruso]

Good stuff I gave it a run, it starts up but when I select 'arcade' then a level number, it crashes (exits to desktop) before loading the level.

And another minor thing - it's not hiding the XFCE mouse pointer when it starts up.

Looking forward to playing it!

 

[hal9000]

Good stuff I gave it a run, it starts up but when I select 'arcade' then a level number, it crashes (exits to desktop) before loading the level.

And another minor thing - it's not hiding the XFCE mouse pointer when it starts up.

Looking forward to playing it!

Is it possible to start a pnd from the console? Then you could send me the error messages and I could see what went wrong.

 

[WizardStan]

Is it possible to start a pnd from the console? Then you could send me the error messages and I could see what went wrong.

pnd_run /media/SD_CARD_NAME/pandora/apps/APPNAME.pnd
Running PNDs from the desktop or menu as normal, however, dumps all logs into /tmp/pndrunappname_run.out so I would suggest checking there before resorting to command line execution.

 

[Tempel]

After more testing on vminko's Pandora, I found that the PND seems to work inconsistently without an icon, so it has an icon now. As for terminal output, the traceback ends with:

  File "sparks/Sparks/Engine.py", line 125, in LifeImage
    pygame.draw.aalines(surface,(255,255,255),1,points,1)
ValueError: unsupported bit depth for aaline draw (supports 32 & 24 bit)

hal, I'm going to leave this up to you

 

[hal9000]

Thanks for the feedback. Bug solved, fix uploaded. Please repackage and retry...

I have to say that the fact that SDL default depth on Pandora is 16 bits does not sound good to me... Sounds like SDL is still working 100% software. But I could be wrong (hopefully).

 

[Tempel]

Version number bumped and repackaged here. vminko's Pandora is offline for now, so I'll have to rely on others to test it.

 

[tony11]

Version number bumped and repackaged here. vminko's Pandora is offline for now, so I'll have to rely on others to test it.

hi, i am no expert on this, but the main two things that really stuck out for me were the mouse pointer sitting in the middle of the screen, and having to turn the pandora up to 800mhz to get the first few levels to run at any speed, i did try level 14 at 800mhz and no chance, sooo slow. Is there anything else you would like me to keep an eye out for on this game?

 

[hal9000]

hi, i am no expert on this, but the main two things that really stuck out for me were the mouse pointer sitting in the middle of the screen, and having to turn the pandora up to 800mhz to get the first few levels to run at any speed, i did try level 14 at 800mhz and no chance, sooo slow. Is there anything else you would like me to keep an eye out for on this game?

I am not sure you realized that you are probably the first one that ran this game on Pandora. The problems you are poining out were known to no one so far.

The good news is that it seems that it works.
The bad news is that it seems that it does not run very fast.

I have developped this game on a high-end recent PC and tested it only on this kind of hardware so far. It reaches 500 fps (locked at 60) on it, which basically tells nothing about how it could run on a Pandora. I was not very optimistic, but I did not expected it to be as bad as what you say.


The game is slow for two reasons:
- It is written in Python, and therefore several order of magnitude slower than the same game written in C (with similar algorithms). CPU intensive part of the game are already quite optimized, therefore I don't think that I could make it run much faster using additionnal optimization.
- It uses SDL, which dos not seem to currently be able to use hardware acceleration on the Pandora.


There is something I can try, which could significantly help. There is a major optimization in the game, which basically precompute spirte and blit them, instead of just drawing them on real time. On my pc, it is very efficient. It could be that without hardware acceleration, it actually makes the game run slower.

I can also reduce the maximum number of displayed sprites. It is clear that the gameplay will change and eah level will probably have to be retuned. It will also imply that the gameplay will be different on pc and on pandora.

I change that and fix the mouse cursor bug, and update the game in a minute. Tempel, could you repackage please?

 

[Tempel]

Version 0.3 is available now.

 

[tony11]

hi, i am no expert on this, but the main two things that really stuck out for me were the mouse pointer sitting in the middle of the screen, and having to turn the pandora up to 800mhz to get the first few levels to run at any speed, i did try level 14 at 800mhz and no chance, sooo slow. Is there anything else you would like me to keep an eye out for on this game?

I am not sure you realized that you are probably the first one that ran this game on Pandora. The problems you are poining out were known to no one so far.

The good news is that it seems that it works.
The bad news is that it seems that it does not run very fast.

I have developped this game on a high-end recent PC and tested it only on this kind of hardware so far. It reaches 500 fps (locked at 60) on it, which basically tells nothing about how it could run on a Pandora. I was not very optimistic, but I did not expected it to be as bad as what you say.


The game is slow for two reasons:
- It is written in Python, and therefore several order of magnitude slower than the same game written in C (with similar algorithms). CPU intensive part of the game are already quite optimized, therefore I don't think that I could make it run much faster using additionnal optimization.
- It uses SDL, which dos not seem to currently be able to use hardware acceleration on the Pandora.


There is something I can try, which could significantly help. There is a major optimization in the game, which basically precompute spirte and blit them, instead of just drawing them on real time. On my pc, it is very efficient. It could be that without hardware acceleration, it actually makes the game run slower.

I can also reduce the maximum number of displayed sprites. It is clear that the gameplay will change and eah level will probably have to be retuned. It will also imply that the gameplay will be different on pc and on pandora.

I change that and fix the mouse cursor bug, and update the game in a minute. Tempel, could you repackage please?

Well i can confirm the cursor bug has gone, this looks like a good game, i do like the twin joystick controls

 

[hal9000]

Well i can confirm the cursor bug has gone, this looks like a good game, i do like the twin joystick controls

And what about speed? Is it acceptable?

 

[tony11]

Well i can confirm the cursor bug has gone, this looks like a good game, i do like the twin joystick controls

And what about speed? Is it acceptable?

At 500 mhz sparks runs really slow, not acceptable on level one. At 600 mhz Sparks runs a bit better but the more sprites on the screen the worse it slows down on level one again. At 700 mhz Sparks runs faster, but still not at an acceptable speed as soon as more sprites appear the slow down starts again (again on level 1)

I also made a small vid of it running at 500mhz and 800mhz:

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

 

[CPUnltd]

wonder if DSP would improve things...

 

[Tempel]

Well, hardware-accelerated SDL would improve things. I think SDL would benefit more from access to the graphics hardware than from access to the DSP, but who knows, maybe the DSP would be applicable. Regardless, there's nothing that can be done to Sparks to achieve that short of rewriting the whole thing with GLES instead of pygame. Sparks just needs to be optimized as best it can (and hal says he's already done a lot) and after that we just wait for SDL to be improved.

 

[hal9000]

At 500 mhz sparks runs really slow, not acceptable on level one. At 600 mhz Sparks runs a bit better but the more sprites on the screen the worse it slows down on level one again. At 700 mhz Sparks runs faster, but still not at an acceptable speed as soon as more sprites appear the slow down starts again (again on level 1)

I also made a small vid of it running at 500mhz and 800mhz:

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

This is terrible, even the very beginning. It is suppose to run at least 4 times faster.

I will try to see what I can do.

 

[hal9000]

Well, hardware-accelerated SDL would improve things. I think SDL would benefit more from access to the graphics hardware than from access to the DSP, but who knows, maybe the DSP would be applicable. Regardless, there's nothing that can be done to Sparks to achieve that short of rewriting the whole thing with GLES instead of pygame. Sparks just needs to be optimized as best it can (and hal says he's already done a lot) and after that we just wait for SDL to be improved.

This would not be too much work if there were an available openGL ES interface to Python. The last time I checked, there were none.

Of course, an option would be to rewrite all that in C++. Quite boring task, I think.

 

[Tempel]

This would not be too much work if there were an available openGL ES interface to Python. The last time I checked, there were none.

As a matter of fact, chris_c has been working on one. But I still wouldn't recommend a GLES rewrite just because it would hinder cross-platform usability, and I can't imagine it would be easy (then again, I know nearly nothing about GLES). So yeah, I would recommend simply hoping that improved SDL comes soon (or contributing to it if you have the skills! I don't), though I guess you could try a GLES rewrite if you're feeling adventurous.

 

[WizardStan]

But I still wouldn't recommend a GLES rewrite just because it would hinder cross-platform usability

GLES is a subset of GL. If it's written for GLES it'll run on machines with just GL.

 

[Tempel]

It wasn't a strict subset of GL until version 4.1, which is too new for many current graphics cards to support. You could stick to the common subset between GL and GLES (which wouldn't even be that hard, I've heard), but even then you're constrained to systems with some form of OpenGL. It's not a terrible constraint, but SDL, on the other hand, works everywhere.

Yeah, a rather pointless argument. It really boils down to what kind of work hal wants to do on this.

 

[hal9000]

Yeah, a rather pointless argument. It really boils down to what kind of work hal wants to do on this.

No time consumming work, for sure.

Actually, there are two things I can easily do:
- An 8 bits version. The fact that SDL default to 16 bits on Pandora sounded wrong to me from the beginning, in terms of performances.
- Increasing global speed (independantly of fps). The problem right now is that when the frame rate goes down, the speed goes down as well. This is because each sprite make the same move at each steps, whatever is the length of this step. The game was written to run at 60 fps, if it runs at 20 fps, it runs 3 times slower. This is a well known problem.

I will see what I can do for this second problem. Solutions are not obvious, because if steps become too big, this cause the collision engine to fail (for example, bullet could go through enemies without touching them). Anyway, I think that under 20 fps, the gameplay would be crippled anyway.