Release Beret

[ptitSeb]

Here is Beret, an action/puzzle game.

Video of the gameplay on the Pandora from @ingoreis

The game use SDL, and have a lot of trasparencies, and a fixed framerate of 60fps. Even with the omapdss driver and all the neon optim inside SDL, the game cannot sustain that framerate, so I put a fixed frameskip to lower fps to 20. Game speed seems ok now.


That game is played using Key+Mouse, so it is setted up as an fps, with Right Nub as mouse, and shoulder buttons as mouse button (or you can use Left Nub too). Touchscreen is also working on the game (threre are 2 modes for the mouse, switcheable with 'M', and one is more touchscreen friendly than the other).


History log
=========
Build 04
-------------

• Version using DSP from M-HT. Is now fullspeed on Gigahertz model
• Use GL is DSP is not available

Build 03
-------------

• Recompiled, with some simplification and speedup
• Some optimizations from M-HT

Build 02
-------------

• Fixed writing of save data on the NAND

Build 01
-----------

• Initial build
• Some Pandora customization (Keymap, Shoulder as button)
  
• Forced frameskip of 3 (fps 60 -> 20).

Sources are in the PND.

 

[ptitSeb]

New build on the repo, I have noticed that this game save things on the NAND (it use getpwuid(getuid()) instead of a simple getenv("HOME") to get home folder for user.
So I fixed that (and put some script in the launch script to automaticaly move the save data from the NAND if any is found).

Build 02
-------------

• Fixed writing of save data on the NAND

 

[FBnil]

I tried this puzzle game. Its not bad, but somehow it couldnt hold my attention. But as always: thanks for the port. I did not find it laggy. So "just 20 fps" is more than good enough for a smooth game.

 

[ptitSeb]

The new build is out of beta and is on the repo.

Build 03
-------------

• Recompiled, with some simplification and speedup
• Some optimizations from M-HT

 

[levi]

I gave this a quick test, but it took me a while to realise I needed to use the right nub to move a pointer about to even get into the first level. Managed to complete the first level, but haven't managed to kill anything yet.

 

[FBnil]

Well, tried it again. I am amazed at the gameplay. Let me explain:

So your "beret" can cross certain transparencies that blocks can not, and vice versa.
You can stack blocks diagonally to reach hard-to-get-to spots.
You can smash a rock onto a robot, or smash a robot onto the ground.. either will kill them.
Once you have completed the level by collecting all collectables... there is a speedrun you need to go through, where you run through all rooms of the same level, but if you die, you continue from the last room you came into and with the same time you got into first. So very fair.
Forget about the nubs: Use the stylus. So you can jump, place a block under you, so you do not fall....

So my bad for "not getting it" the first time...

thnx petit Sebastian.

 

[M-HT]

So I spent some time (a lot ?) to see if I could get this game running faster on Pandora and here are the results.

The game uses SDL surfaces and blitting to render the screen at resolution 780x600, which on Pandora is then scaled down using hw scaler.
A small speedup can be gained by using double buffering instead of single buffering.

I tried changing the rendering to OpenGL (using glshim on Pandora - ptitSeb's fork) - using textures instead of SDL surfaces and drawing textured quads instead of blitting.
The result was not faster than SDL version and contained minor artifacts because instead of scaling down the final screen, individual quads are scaled down on Pandora. It may be possible to fix the artifacts, but I didn't look into that.
I tried enabling batching in glshim and the result was faster than SDL version, but wasn't rendered correctly (wrong textures were used, ...). I tried looking into glshim to fix it, but the code is kind of complicated, so I let it be.

Next try was changing the rendering to DSP - putting surfaces to shared memory with DSP, using DSP for blitting and copying the final screen to SDL screen.
The result was not faster than SDL version as such, because I batched the blits for the DSP, but I was then waiting for the result to copy it to SDL screen.
Since Pandora version uses frame skipping (to make it playable) I let the CPU run the code for the skipped frames while the DSP was doing the blits and then I waited for the result to copy it to SDL screen. This version showed noticable speedup (even faster than batched OpenGL version).

Here are some number on CC Pandora in one level - probably not the most complicated level, so the number could be lower in some levels.
(Fullspeed rendering would be 60fps, but since Pandora version uses frame skipping fullspeed would be 20fps - meaning drawn frames per second)
SDL version using single buffering: 13.6 fps
SDL version using double buffering: 15.4 fps
OpenGL version: 14.2 fps
OpenGL version - batched: 18.4 fps
DSP version: 14.3 fps
DSP version - final: 20.5 fps

I also tried using less frame skipping (so 30fps would be fullspeed) and the result for the final DSP version was 26.5 fps, so it's better to keep current frame skipping (at least on CC Pandora, I don't know what the speed would be on 1GHz Pandoras).

Before I clean the code a bit and post it, question is if I should keep the OpenGL version in there, since it's slower and contains minor rendering artifacts ?

 

[ptitSeb]

@M-HT Impressive!

I know Batch mode is sometimes buggy, so I'm interested in the opengl code so I can try to fix it there (I know I miss some state changes regarding textures, but I still haven't located where / how it occurs). Also, to fix the rendering artifacts, I think it would be better to render in a full-sized FBO, then blit the FBO at the swapbuffers to avoid the littles gaps between blocks.

But I'm more impressed by the DSP version. It's a real multitasking rendering now, with the CPU working on next frame while the DSP render current one

 

[M-HT]

OK, I'll keep the OpenGL version as it now is.

It's a real multitasking rendering now, with the CPU working on next frame while the DSP render current one

Well, the CPU is working in parallel on frames which won't get displayed, but yes. Currently the CPU is not working in parallel on next displayed frame - that requires a bit more code and I'm kind of tired of the code right now, maybe I'll look at it later.

Also I forgot to mention, that I was making the DSP version work on 16-bit and 32-bit screens, but the 32-bit version is not implemented on DSP side.

I'll clean the code and post it later.
[doublepost=1464554987,1464531006][/doublepost]Here is the code (in the attachment).

Some notes:
komp.sh is used to compile the CPU part, it also contains short explanation of available preprocessor definitions
tiles_dsp_area3.out is the compiled DSP part - put it together with the main executable
dsptiles directory contains sources needed for the DSP version (CPU and DSP part)
dsptiles/dsp directory contains sources for the DSP part

To compile the DSP version (CPU part), you need some includes and the compiled library from c64_tools (the library is included on Pandora).

 

[Farox]

Really impressive!

 

[ptitSeb]

Thanks @M-HT , I'll take a look at all that soon.

(and I think I was not super clear when I spoke about multitasking. I was thinking that the CPU was doing the game logic of next frame while DSP was doing the rendering of the current frame, not that both CPU and DSP were doing concurent rendering. And I think it's fine like that.. mmmm, I'm not even sure I'm much more clear now).

 

[notaz]

Meanwhile I've sped up the SDL blits a tiny bit (4% or so) with some more strategic placement of preloads.
Not that it's going to compete with the DSP improvement, good to finally see it giving noticeable impact to some released PND!

 

[M-HT]

Meanwhile I've sped up the SDL blits a tiny bit (4% or so) with some more strategic placement of preloads.
Not that it's going to compete with the DSP improvement, good to finally see it giving noticeable impact to some released PND!

All it needs is a project where the DSP can be used (to run things in parallel), where it actually makes a difference in speed (some of my projects could use this, but they are fast enough without it) and someone to implement it

Currently the CPU is not working in parallel on next displayed frame - that requires a bit more code and I'm kind of tired of the code right now, maybe I'll look at it later.

I thought about this and it should be pretty simple - I'll implement it when I get home and we'll see if the game gets some more speedup.

 

[M-HT]

Here is the updated code.

There's a small speed gain - with less frame skipping (30fps would be fullspeed) the result is now 27.7 fps - still not fullspeed, so it's better to keep current frame skipping.

I also fixed a bug in the DSP code, when blitting large alpha surfaces.

I also checked the OpenGL version and noticed that font surfaces don't work on Pandora (I didn't have them when I last tested OpenGL) - I guess that's probably because of large texture size.

 

[ptitSeb]

Thanks @M-HT .
I'm starting with the easiest part: the OpenGL.

To have correct font, use LIBGL_SHRINK=8 to handle large font (shrink 4096 & 8192 fonts).

I have capture the title screen whithout and with BATCH mode.
Title screen has 644 drawing calls without batch mode, and ... 8 with Batch mode!
I had an issue with textures, that I fixed, but the tiles are still garbled. It seems that I mess the Texture coordinates when I concatenate display list. I should be able to fix this.
I'll look at the dsp version tomorow probably (tonight if it's not too late), as this is the most interresting part .
[doublepost=1464643863,1464638935][/doublepost]Found the issue. It was a problem with NPOT (non-power of two) texture, where in batch mode, the texture coordinates were adjusted 2 times for most triangles instead of 1. It's fixed and pushed on my github (and one day, I'll have to redo that steam machine of BATCH Mode).
On my gigahertz, I get a solid 60fps (with a non SKIP_REFRESH build). Not bad (but the mouse doesn't go to the bottom of the screen, small residual bugs). I'll build the DSP version tomorow, it's too late now for me.

 

[M-HT]

Good with the OpenGL version.

I noticed, that in the DSP version I forgot to implement parallel working of DSP an CPU when SKIP_REFRESH is not defined, but that should be easy to fix if necessary.

 

[ptitSeb]

I have compiled the DSP version. The fullspeed version is mostly as fast as the GL one. On the level 2, I get 59 fps with GL and 55 fps wit DSP. Very impressive stuff @M-HT ! I'll probably package a version with 2 binaries. One without frameskip for the Gigahertz and one with frameskip for CC and Rebirth and put that in the beta thread for testing.

 

[M-HT]

The 55 fps with DSP, that's without frame skipping and with fixed parallel working of DSP and CPU, right ?

 

[ptitSeb]

The 55 fps with DSP, that's without frame skipping and with fixed parallel working of DSP and CPU, right ?

Yes.

#if defined (SKIP_REFRESH) && defined (USE_PANDORA_DSP)
      if (dsptiles_flip_finish(screen, skiprefresh) == -1) return 1;

      if(skiprefresh==0) {

became

#if defined (USE_PANDORA_DSP)
#if !defined (SKIP_REFRESH)
      if (dsptiles_flip_finish(screen, 0) == -1) return 1;
#else
      if (dsptiles_flip_finish(screen, skiprefresh) == -1) return 1;

      if(skiprefresh==0) {
#endif

I assumed it was enough?

 

[M-HT]

Yes, I think that's OK.