i am not - game maker

This entry is a bit particular. I am going to explain why I decided to use game maker, and why I finally started to use it.
In addition, I will put a link to a game done with it. I hope it doesn't get too long.

First of all, there are some events called "game jam". If you have heard about hackathons or code challenges, a game jam is the same but about gamedev. A game jam consists in making a game from scratch in a short period of time.

The ludum dare (a famous game jam) was a few days ago. And I decided to enter as a mean to practice with a short goal in mind. At the begining, I wanted to use only html + canvas, however after a day and a half, the results were far from good, awful to be honest. This made me think, and I remembered I had a gamemaker version compatible with gaymaker (a tool who lets you convert the gmx project files to vpks executables on the psVita ).

To summarize the participation, I had an interesting idea, but I hadn't use gamemaker ever before. You can see that in the alpha result. When I saw the rating comments, and sent the game to a few friends; I realized that, fixing the noise and giving a more specific aesthetic to it, could be a nice minigame to have (for a prototype at least).

I spent a week after the game jam fixing errors, adding sounds, and improving the aesthetics. Within this week, I found some problems about how to handle the program to make it work 'properly' in the psVita.  When the problems where solved, and I had everything needed (specific commands and what not) I played in my console. As a result, the game runs on the web browser (html version) and psVita.

This project means that:

- I have made a game, which you can try at: https://bunkai.itch.io/i-am-not-a-murderer-v2

 - I can, somehow, make working psVita games with game maker, a.k.a. the easy way. 

- Since I want more homebrew games for the console, and I think good knowledge can help the world, I made the folder publicly available at github.  https://github.com/Bunkai9448/vita_gamemaker

- You can find the source code and the psVita vpk version at: https://github.com/Bunkai9448/vita_gamemaker/tree/main/games%20gmz-vpk

    - Now the blog can be divided in programming/learning with the psVita api, and making user homebrew (mainly games) . This is what the blog was meant since the very begining after all.

Bmax - buttonDash 02

As an easy way to show the user what button has to press in each moment, we are going to use the SDL and the screen.c file we created before (don't worry if you don't remember, we are going to practically explain it again).

[Mind you, this entry is made after we adapted screen.c to load a bmp file. That means we can load the pictures in the cmake lists before the code explained here. Nevertheless, we have to make that modular]

Adding pictures to the CMakeLists.txt

With the previous part clear, we can start our road to load the bmp file in the psVita screen.

Note: images will be in BMP because the PNGs require another package to SDL (SDL_image). Although this package works equaly to the one we are using, there's not enough of it defined for the psVita and it won't run without a lot of extra effort.

The First thing to do is define the functions in the headers file (common.h). We are going to need four:
 - One for initializing the library. This also creates the window where the image is load.
 - One for loading the image file.
 - One for cleaning and closing the SDL
 - One (dummy) that calls the other three and print a image on screen (this will be our goodBye img for the app).

Defining the new functions in common.c

With those defined, we can proceed to make the code for them (in screen.c):

initialise SDL

Load bmp image

Clean memory and close SDL + goodBye dummy

Now it's time to focus on the buttonDash code. A good start point is to print the rules (image) on screen using SDL.

Function to load rules image in buttonDash.c

Warning: When all of this is done, it loads the rules image on screen, but it fails to load a second image (specifically fails at creating a new window). Solving this is currently our next step. [It has to be something with the sdl and the memory management]

Bmax - buttonDash 01

 
Having a selection menu means you can call differents apps or modules, now we need modules to launch.
We have decided to start with a simple and easy minigame.
[The minigame will be named buttonDash, a description is comming later]

First we need to create a new btnDash.c file to work on, and add it to the CMakeLists.txt
[Reminder : This is an specific module or game inside the main app (BMAX)]

updated CMakeLists.txt

The following is to create a function in btnDash.c, we will name it btnDashGame().
This is the function we are going to launch from common.c.

With this, we update the common.c file, in the selectedApp to launch the buttonDash:
[This line goes inside selectedApp function]

if ( !strcmp(selApp,"buttonDash") ) btnDashGame ();

----

[Normally, you know what kind of modules or games you want to do before starting the project. And you do a specific menu for them. However with a launcher this part is sticked to each module. The launcher just call them, that is why we did not mention any of this before.]

We got the code ready to call our new module, it is time to decide what module is going to be.
[This part comes with idea brainstorming, but here we will go just directly to the picked idea.]

Here is a briefly explanation of what are we trying to achieve in this module:

- A minigame with highscore, and current score. Highscore will be saved in a file, for future replays.

- A game flow guided by the speed of pressing buttons correctly. A failure reset the current score.

- The button to press will be showed on screen. One button appears at a time. If no button is pressed in a specific time interval, the game will count this as a failure and, it will pass to the next button.

- An increasing difficulty based in the current score. The difficulty will have 3 stages:
   - Button image shown highlighted, 60 sec before next button appears.
   - Button will not be highlighted, 60 sec before next button appears.
   - Button will not be highlighted, 30 sec before next button appears.
[Higher difficulties with less time may be added later. Another difficuly could be show wrong button to confuse.]

- A pause menu. This screen is to be determinated.

Having the bases of the module, the next step is to draw the flowchart.
[Pseudocode could be used too, but the flowchart makes the big picture clearer. In addition, both can be done together or, done one after another.]

Warning: There are some "steps" that can be omitted, if the knowledge of the rendering were farther (which won't be done in this module).

Button dash flowchart

Bmax part 3.2

This entry is about making the main loop to follow the flowchart. The code will be on the main.c file, and it will (most probably) be the last one done in this file. After this, the code will be done particularly to each module, and a few lines in common.c to launch each module.
[Remember that, we are using this flowchart]

We will want to add a confirmation screen, when the user wants to exit. Right now, we have done a dummy function for that.

dummy to know if the user wants to exit

To create the flow in code, we are using a do while loop. The reasons of this are:
 - The app should, at least, show the menu at the begining.
 - We want to show this menu every time the user close any inside module (app).

To control the loop, we will need a variable which changes when the user ask to exit.
Everything else is just directly follow the flowchart.

Note: the chooseLang must be asked before the loop once, if we don't want to ask the user constantly.

main loop in main.c file

With this, it comes the first official release, go to https://homebrew-psvita.blogspot.com/2020/08/main-projects-plan-000.html and check it out.

Bmax part 3.1

In this entry we are making the functions of the main loop.

First, we declare the functions in common.h:

declare new functions in common.h

Now to code the appSelect() function, we are using the same idea of chooseLang() explained here. However, the options offered have changed. Options now:
 - help (default answer in bracket)
 - chooseLang
 - button_dash
 - exit

After doing that, we should check everything is ok, and we don't have made any typo or something. This is made by doing the main just launch it, and printing the answer (launching nothing afterwards).

main.c to check appSelect()

With this assured, we can go to implement selectedApp():

This function is basically a column of ifs with string comparison, where each option launch a function.
It will also receive two arguments, the selected app and the language to use.

selectedApp()

If everything is correct (which it is), now we have our selection menu up and running. We can do a test with:

main.c with code to check our main menu

The only thing left now is to make the loops to keep the game running, until the user wants to exit.

Bmax part 3

Up to now, we have some basic required funtions for the app. It is time to give it another essential feature, we will implement the main flowchart. To do that, we will use the one we did here.

To implement the flowchart, we need to decide a few things:

 - How are we going to get the user input?
   The user will write what he wants to do.

 - Where will the main menu go? after or before chooseLang?
   Better chooseLang right away the app init, and then main menu with option to changeLang again.

 - Which text are going to show on the selections screen?

 - Some flow decissions, that are made on the flowchart, will be explain directly on the code.
   [This should be writen in the draft with the flowchart on more official documents.]



Note 1: To make things easier, the selection menus will only have the default english ime. However we will try to make the sentences short and globally known.

Note 2: After making these selection menus, we can delete previous functions on main, and leave only these two new ones. With this, in theory, we won't have to modify main.c file again.

Note 3: To implement this, we will use one loop in each decission triangle. This will be BMAX's main loop, from there it executes other modules, or it just wait the user input.

Bmax part 2.6

 

 This is the third entry of the Bmax help, here we are going to explain two new functions (help and echoFile). Besides we have done a few fixes here and there to improve the code and the understanding of the project files.

First of all, we need the txt files on the vpk package, so we are adding those to the project, in the CMakeLists.txt

adding txt files to the project in CMakeLists.txt

Next, we have change the name of main.h to common.h because it is a more adecuate name. After that, we have added declarations for the new functions we are going to create and use this time.

new functions in common.h

Now to the coding part: for the help function we need the language (which we have previously got), and the help printing, but the printing will be used with more texts so we will better have an specific function for that.

We have name the printing funcion, echoFile, as it is going to echo the file on screen.
Any specific explanation of the code is in its comments as a good programming practice.

echoFile function

 Note: In the future should be desirable to upgrade it, and make here the font size bigger to make the text easier to read (this is because, on the contrary with the debug log and other normal prints it is specific for user in-app reading).

Note 2: there is a known bug in japanese text files, caused by the codification. This bug affects to other languages too.

Having done the echoFile function, we need the help function to choose the right txt file (remember that we have one with each language).

Last but not least, we want the help to print the file, it is time to use the echoFile function with the datapath obtained for the language.

help function

Moving forward. We have the basics of an app, it is time to create a github to upload all the code and files of this project. In addition, a re-read and update of some of the previous entries with some fixes will be made. When this is done, we will add the github link on https://homebrew-psvita.blogspot.com/2020/08/bmax-part-0.html to have a quick access to it.

Clarification: this is not the end of the project, it is "only" the point when it goes fully public, and maybe collaborative (if people on github make pushes to the code).

Bmax part 2.5

 This is the 2nd entry of the BMAX help function. After thinking about that, we have decided that is easier to choose the language with the IME as it lets you write the language directly with the ps vita api.

As we are using the ime and the ime will be used again, we have decided to make another file to have the ime variables and functions easy to find and modify (using the ime sample code).
We will call it (keyboard display -> ) kbDisplay.h

kbDisplay.h

To do the function ChooseLang, we are going to ask the user to introduce the language with the initials (e.g. ENG for english), using the ime to get the input. After that we are returning it as a result, to have it outside. Currently, we have 3 languages included, but we can add any simply repeating the if statements with each lang.

Note: more info about the initials here https://iso639-3.sil.org/code_tables/639/data

Note: as a base code we have used the ime sample.

chooseLang function

Bmax part 2

 In this next 2 entries we are going to make the function to call the help, in order to make it able to read different files depending on the language chosen by the user. [This will be divided in 2 functions, one to chose the language and another to trigger the help]

First we need to define (in main.h) and create the function (in common.c).

With that done, we have to make it read the buttons to know the user election.

We make that using the sceCtrl functions. as an entry point we write a function
that prints a text to let the user know how to stop it. And then keeps checking in loop
until the user stop it. Code below:

function definition

function code

* Note: we have made a new file (screen.c) to have everything related to the rendering (currently with sdl) and functions in common.c separated.

adding screen.c to the CMakeLists.txt

After that we have to put a way to give the different options for him to choose. This should be a visual option (graphics rendered on screen or ime dialog) which will see in the next entry.

Bmax logo

 It is not a good app if it doesn't have a good logo, we had one for testing, today i wanted to make a representative one.

For that, i decided to use all the name letters and create a face for him in paper:

first draft in paper

And after that i give him the colors i used in the screen of the app to give him his own personality:

computerized logo with representative colors

Bmax part 1.5

Now that we have the basic estructure, we will create a mini function to print errors and dump the text into a readable file for future debugging purposes. we are going to call this function when we check for bad results.

Although a good debugger would be desirable, we use this as a temporal patch.

The function will be declare in the main.h and written in the "common.c" file.

debugLog function

Bmax part 1

 In the previous entry we got the basic environment of the homebrew, now we want to make it modular. This will make the project easier to mantain and upgrade.

For this goal, we have to make separate files for the headers and the main module (main.h and main.c). From now on, we are also going to do something similar for each "Bmax's function" (sub module).

At the end of this point we will have 4 files created/updated, but in the future will be adding more files.

In the main.c file we only leave the main function with: init, program_loop (currently redrectangle), and quit.

main.c step

In the main.h we will have definitions of data types, function prototypes and C preprocessor commands.
(How to write your own header file in C). (we surely need more files like this)

main.h step

In the common.c we will write the generic functions we are going to call (we surely need more files like this).

common.c step

In the makefile we are adding the new c files that we want to add to the compile process, in the "add executable" section

makefile step

Note: debugScreen is added for future debuggin purposes. also a function for that goal has been created.

Bmax part 0.5

 In this entry we will create the basic folders and files. For that goal we are going to copy and modify the pretty_livearea and the sdl/rectangle.

 From the pretty_livearea we are going to copy the whole folder. After that, we modify the makefile, and later the pictures, and the template.xml to adapt to our homebrew.

 The changes to the makefile consist in changing: project name, app name, app title, and link libraries (to add the sdl since we are using the make file from the pretty live area).

Modifying the makefile step 1

Modifying the makefile step 2

The changes of the template.xml consist on changing some texts with our data:

Modyfing the template.xml

From the sdl/rectangle we are going to copy the src/main.c file to ours.

Since it is the first entry of the project, and creating new picutures is not part of the blog, we stop here for today.

In the next entry we will have those pics changed acording to their needs, and we will start with the new code.

As a prologue of the following entries of this project, we are going to use this tutorial as a helper for the sdl library:
http://lazyfoo.net/tutorials/SDL/index.php

Note: also we may need the sdl part of the game controller and the joystick mapping:
https://wiki.libsdl.org/CategoryGameController

 ---

Screenshot from the project in the current state running on the vita

Bmax livearea

 

Bmax part 0

 Here we will write the initial flowchart of the Bmax project.

The main program will be the one who start with the app and with the list of modules to load.
Each module will be like a mini app inside the main one.

draft idea

 

With that idea in mind, we have created a basic flowchart to implement later.

 

 

flowchart

The modules though at this moment are:

  - a help file (will be multilingual in the future)

  - button_dash minigame

  - whack-a-mole minigame (touch controlled)

  - a clock (it will have some events hour dependent). it may be included in the main as secondary image in the future

  - more TBD (To Be Determined)


Link to Source files: https://github.com/Bunkai9448/BMAX

Link to VPK: https://github.com/Bunkai9448/BMAX/releases

main projects plan 000

After all these time, we have read almost all the samples and we have a brief understanding of the basics, now we have to plan ahead.

We have some "big" options to develop for the vita:
  - Unity for ps vita (we will talk about this later)
  - PSM (Play Station Mobile) .
  - Game Maker Studio (with gmx to vpk)
  - c/c++ as we have been reading
  - sdl (which we introduced with the rectangle sample).

With this in mind, we have decided to make 2 projects:
  - ice_puck which will be the one about hockey. Long term.
  This project will be probably made in unity because, we want it to be easy to port/help, and as widely known as posible.

  - Bmax which will be a launcher with a fakebot look. Short term to unknown.
    This project will be made with sdl because we want something in c/c++ but with graphic libraries. To practice
  coding and keep learning about everything. In this project we can also insert other simpler ones (and we will do).

For the blog, we will write each project in its own lables and entries.

Note: although we will explain everything about the progress of each project, the files will be always found in Bmax, and Ice_Puck.

Basics on the code PART 13

In this entry we are going to read about the microphone options on the vita. For that we are using the vitasdk audio section and more specificly the audioin library.

Note: With this entry we are finishing the samples reading for now, and will start with the next step in the future one.

There is not much new to say appart to comment that the info received in the mic port is save in a buffer.

SAMPLE "microphone"

microphone: Demonstration of microphone features.

/*
    Simple microphone test program
    - displays audio in data
    - displays small VU meter based on
      an average of the audioIn buffer
    - increase or decrease the sensitivity
      of the VU meter with up/down buttons
    - exit with select
    Enjoy,
        -pyroesp
*/


#include <psp2/kernel/threadmgr.h>
#include <psp2/kernel/processmgr.h>
#include <psp2/audioin.h>
#include <psp2/ctrl.h>

#include <stdlib.h>
#include <string.h>

#include "debugScreen.h"

#define printf psvDebugScreenPrintf

#define SEC_MULTIPLIER 1000000
#define MAX_WORDS_PER_LINE 23
#define MAX_VU 32

/* Tested sample rates - grain */
/* 16kHz ; 256 */
/* 48kHz ; 768  (= 16kHz*3 ; 256*3) */

int main(int argc, char *argv[]){
    int exit = 0;
    /* sample rate */
    int freq = 16000;
    /* grain */
    int grain = 256;
    /* audio in port */
    int port = 0;

    /* If size > grain */
    /* audio buffer will be filled only up to [grain - 1] */
    int size = 256;
    short *audioIn = NULL;

    psvDebugScreenInit();
    printf("Microphone test:\n\n");
    printf("Press up/down for VU sensitivity.\nPress select to quit.\n\n");

    audioIn = (short*)malloc(sizeof(short) * size);
    memset(audioIn, 0, sizeof(short) * size);
    /* Open port */
    port = sceAudioInOpenPort(SCE_AUDIO_IN_PORT_TYPE_VOICE, grain, freq,
                SCE_AUDIO_IN_PARAM_FORMAT_S16_MONO);

    printf("Port value 0x%X - buff size %d\n", port, size);

    /* Check for SceAudioInErrorCode enums */
    if (0 > port){
        exit = 1;
    }

    printf("Audio buff address = 0x%X\n\n", audioIn);
    sceKernelDelayThread(2 * SEC_MULTIPLIER);
    printf("Read audio:\n");

    int i, j;
    int average;
    int audioInMax;
    int sensitivity = 3;
    int retVal;

    SceCtrlData ctrl, oldCtrl;

    printf("\e[s");  // save cursor position
    while (!exit){
        average = 0;
        audioInMax = 0;
        printf("\e[u");  // return to saved cursor position
        /* Read audio */
        retVal = sceAudioInInput(port, (void*)audioIn);
        if (retVal){
            exit = 1;
            break;
        }

        /* Print all values in audio buffer, 23 WORDs per line */
        for (i = 0; i < size; i += MAX_WORDS_PER_LINE){
            for (j = 0; j < MAX_WORDS_PER_LINE && size > (i + j); j++){
                /* remove unwanted values < 0 */
                if (0 > audioIn[i + j])
                    audioIn[i + j] = 0;

                printf("%04X ", audioIn[i + j] & 0xFFFF);
                average += audioIn[i + j];

                if (audioInMax < audioIn[i + j])
                    audioInMax = audioIn[i + j];
            }
            printf("\n");
        }

        average /= size;
        average = ((average * sensitivity) * MAX_VU) / audioInMax;
        /* Get microphone status */
        /* Other values than 1 in GetStatus returns 0x80260106 */
        printf("\nYour microphone is %s\n\n", sceAudioInGetStatus(1)?"disabled.": "enabled. ");
        printf("\nSimple VU meter: (sensitivity = %3d)\n\n\n", sensitivity);
        for (i = 0; i < MAX_VU; i++){
            printf("\e[7G");  // set cursor to column 7 (for 8x8 font)
            if (i < average){
                if (MAX_VU/2 > i)
                    psvDebugScreenSetBgColor(0xFF00FF00);
                else if (MAX_VU*3/4 > i)
                    psvDebugScreenSetBgColor(0xFF00FFFF);
                else
                    psvDebugScreenSetBgColor(0xFF0000FF);

            }else{
                psvDebugScreenSetBgColor(0xFF000000);
            }
            printf("   \n");
        }
        psvDebugScreenSetBgColor(0xFF000000);

        sceCtrlPeekBufferPositive(0, &ctrl, 1);

        if ((ctrl.buttons & SCE_CTRL_UP) && !(oldCtrl.buttons & SCE_CTRL_UP))
            sensitivity++;
        else if ((ctrl.buttons & SCE_CTRL_DOWN) && !(oldCtrl.buttons & SCE_CTRL_DOWN))
            sensitivity--;
        else if (ctrl.buttons & SCE_CTRL_SELECT)
            exit = 1;

        if (0 >= sensitivity)
            sensitivity = 1;

        memcpy(&oldCtrl, &ctrl, sizeof(SceCtrlData));

        sceKernelDelayThread(10000);
    }

    free(audioIn);
    sceAudioInReleasePort(port);
    sceKernelExitProcess(0);
    return 0;
}

-----------

Screenshot from the sample running on the vita:

And that's all for this sample.

Samples common files & code PART 2

In today's entry we are going to read about the net conexions and the ps vita (sockets). For that matter, we are using the Vita SDK documentation, network section.

This section gets into net modules on the vita, and its conections with everything related to sockets and HTTP.

Our project doesn't involve any of that, that is why this is a brief entry of the samples that cover this modules. If we need some of this code later we can go back and take a more deep aproach.

Note: the samples download the data in the ux0:data/ directory.

SAMPLE "socket_ping"

socket_ping: ICMP ping using raw sockets.

In its main.c you can read mostly about structs with the icmp datagrams and the ping data.

Note: These are to test if your connexion is active, and if the dns you are trying to connect is on (the sample use the google dns because is public, wide and "always" online). You can read more about this on their wikipedia pages: wikipedia icmp, wikipedia ping.

SAMPLE "net_http"

net_http: A minimal HTTP download sample.


In its main.c it shows how to load the module and download an html file from its web

Note: this is the basic function of a web browser.








SAMPLE "net_http_bsd"





net_http_bsd: A minimal HTTP download sample using BSD sockets.





This sample does the same as the net_http but using Berkeley Software Distribution Sockets. and shows the results on screen (the downloaded result generated a core dumped error to us tho).

SAMPLE "net_libcurl"





net_libcurl: A libcurl download sample.

Its main.cpp again shows how to load the module and use it to download a file from a webpage (specificaly the "vita_cord.vpk"), but this time use libcurl for the process.

Note: libcurl is a free and easy-to-use client-side URL transfer library.

-----------

Some screenshots from the samples running on the vita: 

net_http

net_http_bsd

net_libcurl

Basics on the code PART 12

In today's entry we were going to read and compile the prx_loader and the prx_simple, which is about the PRX or Playstation Relocatable Executable. Those are about plugin creation (start and stop modules).

For that goal, you can also look into https://tai.henkaku.xyz/ . And also recommended to read about the SceDisplay  (handles management of the framebuffers), and the SceKernelModulemgr (is in charge of loading both user modules and kernel modules)

However, after reading the sample and trying to compile it (for a whole day with breaks), receiving some errors, warnings and whatnot (yes we check other samples to see if the sdk was gone or something, and we tried to solve some of them). We have decide it to just speak about the failure and let that sample appart.

Explanations: Why let it appart? Are you giving up? Are you doing the same with future similar failures? No, we are not giving up, we let that appart because it is about plugins and we don't need that currently. We can go back there in the future when need it, and we have the taihenkaku web for a more clarified way to do them (also we can figure them out with actual plugins if we need to).

Note: While trying to solve the problems, we look other resources and the other big SDK for the vita. Those are the cbps web (currently with an error 523, Origin is unreachable), and the dolce sdk forum a.k.a cbps forum.

Note 2: The vita sdk and the dolce sdk will be appart in time, but currently (as one is a fork from the other) they have the same samples (they only have different cmakelists to differentiate one sdk name with the other). This is useful to know if we want to make a transition or something (more deep knowledge in the sdk will be used when creating the main project of the blog).

Note 3: It must be stated, that the errors found may or may not be caused by us or by the samples' coding.


Having said that, we want to give a brief overview with 2 images of the compiling:

First we tried to read, understand and compile the prx_loader sample. It gaves us, several errors:

   - Lot of them where undeclared functions
     (caused by the lack of a/some include/s, which should be in one of the header files already included).

prx_loader compiling errors

And Then, we decided to compile the prx_simple as it uses the loader as base and goes further.
That means it should give similar errors and/or we can use it to solve some of them. This one gave less errors, nonetheless it gave them:

   - The first time it gave us only three.

prx_simple with 3 compiling errors

 - we reduced them to two adding one include,  #include <psp2/display.h>

prx_simple with 2 compiling errors

 - After this, it seemed easy to solve (giving types to those variables)
   We look in other files what where their types and added them.

prx_simple with errors on the link part

 - Yet again, although it compiled the first part, it gave us more errors, this time, on the link part.
   Knowing this is mostly kernel related we didn't want to take any risk and stop after more fruitless investigation.

Samples common files & code PART 1

We have seen many code samples about the ps vita's handlement of inputs. and some more about how to show info on screen. Although there are still a few samples with functions unseen, in this entry we are going to review some of the basics. To do this we are going to use some samples we have not seen before, because they would have been overlapped with others samples needlessly.

Note: they may be overlapped with others, but that does not mean they are less important. Many people may have started with them instead.

The specific samples we are going to use for review are:

    common: Common functions for samples.
    debug_print: A minimal debug print sample.
    debugscreen: Debug text printing sample.
    pretty_livearea: A minimal hello world sample with example livearea styling and features.

Note: As we did with the first sample entry, we are going to review the files primarily.

Without further ado, let's start!


SAMPLE "common"

// headers and functions for the screen output. Data formats, and its memory control.
 debugScreen.h
 debugScreen.c

//Like the name says it has the font properties at low-level.
 debugScreenFont.builder.html
 debugScreen_custom.h
 debugScreenFont.c


SAMPLE "debug_print"

 // it basically shows you a printf like the hello_world sample, but with more details (foreground/background colors)
 // to make your debugging more appealing with colors in your printed messages.
 main.c


SAMPLE "debugscreen"

 //  test functions to check stuff on the vita, it has a lot of info about what is shown on screen.
 main.c

SAMPLE "pretty_live area"

// it has the same code as in the hello_world sample. But here you have other 2 images, to know how to make your homebrew more atractive.


-----------

Some screenshots from the samples running on the vita:

pretty_live area

debug_print

debugscreen

And that's all for this entry.

Basics on the code PART 11

In this entry we will see how the vita generates sounds. This could be useful when we want warnings or similar things to have sound.

Note: The VM we were using was setup without enough space and "broke", so we will be using another one with ubuntu 20 from now on. The reason of the firmware change is explained in this entry. If your machine have enough space, it is not required to change it.

To help us to understand the functions of this sample, we have to use the vitasdk documentation, for this specific sample we will use the audio section. Also, the the audioout header section.


SAMPLE "audio"

audio: Simple audio wave generator.


#include <stdint.h>
#include <math.h>

#include <psp2/ctrl.h>
#include <psp2/audioout.h>
#include <psp2/kernel/processmgr.h>

#include "debugScreen.h"

// functions to control the frequency changes
#define countof(A) sizeof(A)/sizeof(*A)
#define MIN(A,B) ((A)<(B)?(A):(B))
#define MAX(A,B) ((A)>(B)?(A):(B))

#define printf psvDebugScreenPrintf

// frequency function and its variables based on the button input to change accordingly
double gen_sqr(double p){return p>.5?-1.:1.;}
double gen_tri(double p){return p*2;}
double gen_nul(double p){return 0.;}
double gen_sin(double p){return sin(2*M_PI*p);}

typedef double (*wav_gen)(double);

// audio wave generetator function
void wave_set(int16_t*buffer, size_t size,  wav_gen generator){
    for (size_t smpl = 0; smpl < size; ++smpl)
        buffer[smpl] = 0x7FFF*generator((float)smpl/(float)size);
}

// main program

int main(void) {
    psvDebugScreenInit();


// audio and wave variables during the execution
    int freqs[] = {8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000};
    int size = 256;
    int freq = 8;
    int mode = SCE_AUDIO_OUT_MODE_MONO;
    int vol = SCE_AUDIO_VOLUME_0DB;


// current running wave variable
    int port = sceAudioOutOpenPort(SCE_AUDIO_OUT_PORT_TYPE_BGM, size, freqs[freq], mode);
    sceAudioOutSetVolume(port, SCE_AUDIO_VOLUME_FLAG_L_CH |SCE_AUDIO_VOLUME_FLAG_R_CH, (int[]){vol,vol});


// wave data and its control functions based on the input button in execution time
    int16_t wave_buf[SCE_AUDIO_MAX_LEN]={0};
    wav_gen gen=gen_nul;
    SceCtrlData ctrl_peek, ctrl_press;
    do{
        ctrl_press = ctrl_peek;
        sceCtrlPeekBufferPositive(0, &ctrl_peek, 1);
        ctrl_press.buttons = ctrl_peek.buttons & ~ctrl_press.buttons;

        if(ctrl_press.buttons == SCE_CTRL_CIRCLE)
            gen=gen_sin;
        if(ctrl_press.buttons == SCE_CTRL_SQUARE)
            gen=gen_sqr;
        if(ctrl_press.buttons == SCE_CTRL_TRIANGLE)
            gen=gen_tri;
        if(ctrl_press.buttons == SCE_CTRL_CROSS)
            gen=gen_nul;
        if(ctrl_press.buttons & (SCE_CTRL_CROSS|SCE_CTRL_TRIANGLE|SCE_CTRL_SQUARE|SCE_CTRL_CIRCLE))
            wave_set(wave_buf,size,gen);
          
        if(ctrl_press.buttons == SCE_CTRL_RIGHT)
            freq = MIN(countof(freqs)-1, freq+1);
        if(ctrl_press.buttons == SCE_CTRL_LEFT)
            freq = MAX(0, freq-1);
        if(ctrl_press.buttons == SCE_CTRL_RTRIGGER)
            size = MIN(SCE_AUDIO_MAX_LEN,size+1000);
        if(ctrl_press.buttons == SCE_CTRL_LTRIGGER)
            size = MAX(SCE_AUDIO_MIN_LEN,size-1000);
        if(ctrl_press.buttons & (SCE_CTRL_RIGHT|SCE_CTRL_LEFT|SCE_CTRL_LTRIGGER|SCE_CTRL_RTRIGGER)){
            sceAudioOutSetConfig(port, size, freqs[freq], mode);
            wave_set(wave_buf,size,gen);
        }

        if(ctrl_press.buttons == SCE_CTRL_UP)
            vol = MIN(vol+1024,SCE_AUDIO_VOLUME_0DB);
        if(ctrl_press.buttons == SCE_CTRL_DOWN)
            vol = MAX(vol-1024,0);
        if(ctrl_press.buttons & (SCE_CTRL_UP|SCE_CTRL_DOWN))
            sceAudioOutSetVolume(port, SCE_AUDIO_VOLUME_FLAG_L_CH |SCE_AUDIO_VOLUME_FLAG_R_CH, (int[]){vol,vol});

        sceAudioOutOutput(port, wave_buf);
        printf("freq:%-5i size:%-5i vol:%-5i  wave:{%+6i..%+6i..%6i..%+6i }\r",
                freqs[freq], size, vol, wave_buf[0*size/4], wave_buf[1*size/4], wave_buf[2*size/4], wave_buf[3*size/4]);//\e[H
    }while(ctrl_press.buttons != SCE_CTRL_START); // // sample loop for testing until start button is pressed


    sceAudioOutReleasePort(port);
    sceKernelExitProcess(0);
    return 0;
}


-----------

Some screenshots from the sample running on the vita:

Basic screen before any input

Wave stopped (after being running)

One posible running wave

And that's all for this sample.