Hi all, want some Prizm Game ? I publish here a first demo of Gravity Duck on Prizm.
I write this version in November 2011 and since I wait a way to overclock the Prizm. I never published it before because I hoped to publish directly the final version, but KermMartian with his great Tetrizm convinced me.

I still have to make the menu, and animations when the duck appear/disappear or explode.
The big problem is the speed, I have no Prizm so I work on emulator, and the game run with 50FPS, but on-calc, it's only 15FPS. That's why I need overclock.




Update 04/04/2012 - Beta 2
I've added the main menu and the pause menu, and also overclock (thanks to Ashbad).
Overclock is fixed on 94.3MHz, but if you have already a higher frequency, it will be retained.


Update 04/07/2012 - Final version
Finally, I tottaly completed Gravity Duck.
Just missing the "growing duck" animation and the fade in/out between levels, but there is not enough memory to load the animation.
More informations on the download page

Download Gravity Duck

Looks really nice! On my fx-CG 20, the FPS number shows 14 and sometimes 15. At this speed, it's easy to play

Are you sure everything related to the graphics is optimized to the maximum? I'd rather have a game that works moderately fast at the standard CPU clock, than a game that works very fast with an overclocked CPU.

(Oh, and the game doesn't work after returning from Menu, but I guess that's because it is not finished...)

Yes, I think it's well optimized, but I have a lot of sprites to draw each frame, and a 320*216 background image (which is copied as long data for speed, using a color swatch to economize memory).

The graphics are GREAT! I didn't want a PRIZM up til today. Are you planning on becoming a casio salesman? XD

Wait, how did you take that beautiful screenshot? Did you use the Prizm Manager emulator for that? I am sure we can help you figure out how to optimize the game.

@KermMartian : Yes, I use the Casio fx-CG Manager (I have no Prizm). If you find any idea to improve the speed, it will be awesome (sources are included)

I've looked through your code quite a bit, and I'm afraid I'm not seeing much to optimize at all. Your drawing routines in particular (with their clever palette-based method) is rather tight code.

about the background image, do not forget that the backup VRAM can be accessed to save your background and not waste space. I am not sure if swapping is done by copying or if memory mapping is done

I was testing the demo on my calculator - fx-cg20

the graphics of the game is very good, just needs more speed only ;(

due to low speed, some levels of the game is not playable

I made a video of the impossible level, -> http://videobam.com/ZRApn

I already finished the game 3 or 4 times, the game is really finishable...

in emulator yes, in calculator is almost impossible, the space between the two seeds is of size of the duck

moreover, if try to do 2 jumps followed, past one seconds, sometimes the duck does not jumps

Wow, that is a beautiful game =) Nice work!

Very nice work I've already played to the impossible level, but up until there, I was rather impressed by how good it was (not to say I was uninpressed with the small occurance I can't pass that everyone is pointing out -- that's not your fault really)



I assume the reason is that he's using the RTC for a seconds delay to tell when to shoot the bullets; because it's running at 1/3rd speed on the actual calculator, the bullets move slower, but they get generated just as fast, leading to unintended gaps like that. Correct me if I'm wrong, but it seems the only viable reason.

the game has really good quality, I was impressed not only with this game, but with all those made by Pierrotll for fx9860

he is an excellent programmer, one of the best in casio community! Even without a Prizm, he made this game, just using the emulator

The cause you have spoken, is likely to be the cause of the seeds appear close together

To fix it I think the best would be overclocking the prizm! If it is not possible, we will confine ourselves to optimize the game

The seed level is ACTUALLY possible. I played it for about 10 minutes before i could get the hang of getting between the seeds it is EXTREMELY difficult, requiring precise time, but nonetheless, is possible. ALSO, after about 20 minutes of playing, a system error comes up telling me to reboot... So i dont know what thats about... but it is a great game

@AHelper: There is a way to copy the 0x88000000 VRAM to 0xA8000000 ? Have you any informations about utility of the cacheable VRAM?

@helder7: yes, I'm aware of this problem, it's exactly what ashbad said, the game use RTC_GetTicks for timing movements. In fact, I use exactly the same engine than in Gravity Duck for fx-9860, but on Prizm, due to low FPS, some object move each frame, so the duck can't move faster. If I delete background, the game is faster (but uglier) and more playable. Maybe I overvalued the Prizm, I hope we'll find some tricks to improve graphics management.

@pokemonrules9: A system error? When ? Can you reproduce it?


For this game, the RAM size was a real problem, I needed to use a palette method to put all sprites in RAM (I won't store them in ROM in the g3a, because a lot are just a symmetry or a rotation of another sprite. e.g I store the duck animation in only one orientation, and manipulate it to have it in 8 different orientations).

Another trick is to increase the allocable RAM. I saw in a few years ago on fx-9860 that you can allocate more memory after allocating a lot of small buffers (and freeing them), and it's similar on Prizm. To illustrate that, I made this little program which allocate/free buffers and increase their size while no error occurs. And with it, we easily see how to increase allocable RAM :
First I request 1 buffer, it can allocate 65528 bytes max (65524 for the buffer, 4 for the pointer array).
After, I request 8000 buffers, it can allocate 96000 bytes max (8 bytes each buffers, 32000 for the pointer array).
If I request 1 buffer again, it can allocate 131056 bytes max !
Strange, it isn't ?

I have succeed in this difficult level, but a system error also appeared.
I don't remember which level it was.

it says
"System ERROR
REBOOT :[EXIT]
INITIALIZE:[EXE]
ADDRESS(R)
TARGET=47181466
PC =881EE5B8"
Do you want a picture of it?

I know what is a system error, to solve it I need to know when it appear, in which level, on doing what (dying, move somewhere, touch an object, finish the level ...) ?

PierrotLL, with that PC and your current executable, you should be able to figure out where in your executable the segfault happened. Actually, hmm, I wonder if there's a such thing as a cross-platform GDB for inspecting executables for "foreign" architectures.