DREAM BEATS OF RAGE 7.2 With VMU ICON RUMBLEPACK AND VMU SAVING

Place for discussing homebrew games, development, new releases and emulation.

Moderators: pcwzrd13, deluxux, VasiliyRS

Poll: What improvement, do you want, to see the most ?

Ported Video FMV cutscenes
20
38%
Scale Rending
9
17%
Change's from new src ported down
24
45%
Total votes: 53

User avatar
Nico0020
Sunday Shootout
Posts: 653

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#71 » Fri Jul 12, 2019 9:30 am

Wow. This is nice. I was actually thinking about BoR a few weeks back. I have been playing the M2 ports on xbox recently of Street of Rage and I got kinda nostalgic for playing Beats of Rage back in the day with my friends. Thanks for all your contributions Ian.

Ripfire
stalker
Posts: 284

.

Post#72 » Fri Jul 12, 2019 12:45 pm

.
Last edited by Ripfire on Mon Feb 10, 2020 7:48 pm, edited 1 time in total.

User avatar
Ian Micheal
Developer
Posts: 5994
Contact:

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#73 » Fri Jul 12, 2019 8:25 pm

Ripfire wrote:Ian, creo que deberías tener 2 versiones del mismo openbor, una de 8 bits con libpng v1.2.8 y la otra de 16/32 bits con libpng v1.6.19, para tener más control de la paleta diferente. ¿Sera posible? :?

Ian, I think you should have 2 versions of the same openbor, one of 8-bits with libpng v1.2.8 and the other of 16/32-bits with libpng v1.6.19, for more control of the different palette. Is it possible? :?


Yes i can do that, Also looking into geting opengl working with filters it would free up a lot of memory by using hardware rending.. I will look into very soon And have both v1.2.8 and v1.6.19 it will take some work but it seems a good idea..

Mike77154
noob
Posts: 1

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#74 » Mon Jul 15, 2019 12:17 pm

Hello friends, I came here from mugenguild ikemen project, but I was invited to share some ideas that can be useful for the openbor engine, buddies, do you know about fluidsynth, well this opensource API lets you play midi files with the musical instruments provided by any soundfont did you want, and, the idea of MangeX is to add fluidsynth to the openbor engine, this case, dreambor engine

Let me share you some information about fluidsynth

IDK if this is somepart of the basic usage of Fluidsynth but let me share you, the little things do I have:

[size=14pt]Standalone mode of fluidsynth[/size]
You can simply use fluidsynth to play MIDI files:

Code: Select all

$ fluidsynth -a alsa -m alsa_seq -l -i /usr/share/soundfonts/FluidR3_GM.sf2 example.midi

assuming than you installed soundfont-fluid.

There are many other options to fluidsynth; see manpage or use -h to get help.

One may wish to use pulseaudio instead of alsa as the argument to the -a option.


Tip: The soundfont does not needed to be specified every time if a symbolic link created for the default soundfont, e.g.

Code: Select all

ln -s FluidR3_GM.sf2 /usr/share/soundfonts/default.sf2


[size=14pt]ALSA daemon mode[/size]
If you want fluidsynth to run as ALSA daemon, edit /etc/conf.d/fluidsynth and add your soundfont along with any other changes you would like to make. For e.g., fluidr3:

Code: Select all

SOUND_FONT=/usr/share/soundfonts/FluidR3_GM.sf2
OTHER_OPTS='-a alsa -m alsa_seq -r 48000'


After that, you can start/enable the fluidsynth service. Note that you can't use root to restart the fluidsynth service, if you're using the pulseaudio driver. Pulseaudio won't allow root to connect, since the pulseaudio server is usually started by the user (and not root). You can solve it by creating a systemd/User service (replacing multi-user.target with default.target in the copied fluidsynth.service).

The following will give you an output software MIDI port (in addition of hardware MIDI ports on your system, if any):

Code: Select all

$ aconnect -o
client 128: 'FLUID Synth (5117)' [type=user]
   0 'Synth input port (5117:0)


An example of usage for this is aplaymidi:

Code: Select all

$ aplaymidi -p128:0 example.midi




SDL_Mixer
To use fluidsynth with programs that use SDL_Mixer, you need to specify the soundfont as:

Code: Select all

 $ SDL_SOUNDFONTS=/usr/share/soundfonts/FluidR3_GM.sf2 ./program




Source link
https://wiki.archlinux.org/index.php/FluidSynth
http://www.fluidsynth.org/
http://www.fluidsynth.org/api/


Now, let me share you some info about the API (the bad thing is the library is a C library)

[size=14pt]Creating and changing the settings[/size]

Before you can use the synthesizer, you have to create a settings object. The settings objects is used by many components of the FluidSynth library. It gives a unified API to set the parameters of the audio drivers, the midi drivers, the synthesizer, and so forth. A number of default settings are defined by the current implementation.

All settings have a name that follows the "dotted-name" notation. For example, "synth.polyphony" refers to the number of voices (polyphony) allocated by the synthesizer. The settings also have a type. There are currently three types: strings, numbers (double floats), and integers. You can change the values of a setting using the fluid_settings_setstr(), fluid_settings_setnum(), and fluid_settings_setint() functions. For example:

Code: Select all

#include <fluidsynth.h>
int main(int argc, char** argv)
{
    fluid_settings_t* settings = new_fluid_settings();
    fluid_settings_setint(settings, "synth.polyphony", 128);
    /* ... */
    delete_fluid_settings(settings);
    return 0;
}


The API contains the functions to query the type, the current value, the default value, the range and the "hints" of a setting. The range is the minimum and maximum value of the setting. The hints gives additional information about a setting. For example, whether a string represents a filename. Or whether a number should be interpreted on on a logarithmic scale. Check the settings.h API documentation for a description of all functions.



[size=14pt]Creating the synthesizer[/size]

To create the synthesizer, you pass it the settings object, as in the following example:

Code: Select all

#include <fluidsynth.h>
int main(int argc, char** argv)
{
    fluid_settings_t* settings;
    fluid_synth_t* synth;
    settings = new_fluid_settings();
    synth = new_fluid_synth(settings);
    /* Do useful things here */
    delete_fluid_synth(synth);
    delete_fluid_settings(settings);
    return 0;

For a full list of available synthesizer settings, please refer to FluidSettings Documentation.


[size=14pt]Creating the Audio Driver[/size]

The synthesizer itself does not write any audio to the audio output. This allows application developers to manage the audio output themselves if they wish. The next section describes the use of the synthesizer without an audio driver in more detail.

Creating the audio driver is straightforward: set the audio.driver settings and create the driver object. Because the FluidSynth has support for several audio systems, you may want to change which one you want to use. The list below shows the audio systems that are currently supported. It displays the name, as used by the fluidsynth library, and a description.

jack: JACK Audio Connection Kit (Linux, Mac OS X, Windows)
alsa: Advanced Linux Sound Architecture (Linux)
oss: Open Sound System (Linux, Unix)
pulseaudio: PulseAudio (Linux, Mac OS X, Windows)
coreaudio: Apple CoreAudio (Mac OS X)
dsound: Microsoft DirectSound (Windows)
portaudio: PortAudio Library (Mac OS 9 & X, Windows, Linux)
sndman: Apple SoundManager (Mac OS Classic)
dart: DART sound driver (OS/2)
opensles: OpenSL ES (Android)
oboe: Oboe (Android)
file: Driver to output audio to a file
sdl2*: Simple DirectMedia Layer (Linux, Windows, Mac OS X, iOS, Android, FreeBSD, Haiku, etc.)

The default audio driver depends on the settings with which FluidSynth was compiled. You can get the default driver with fluid_settings_getstr_default(). To get the list of available drivers use the fluid_settings_foreach_option() function. Finally, you can set the driver with fluid_settings_setstr(). In most cases, the default driver should work out of the box.

Additional options that define the audio quality and latency are "audio.sample-format", "audio.period-size", and "audio.periods". The details are described later.

You create the audio driver with the new_fluid_audio_driver() function. This function takes the settings and synthesizer object as arguments. For example:

Code: Select all

void init()
{
    fluid_settings_t* settings;
    fluid_synth_t* synth;
    fluid_audio_driver_t* adriver;
    settings = new_fluid_settings();
    /* Set the synthesizer settings, if necessary */
    synth = new_fluid_synth(settings);
    fluid_settings_setstr(settings, "audio.driver", "jack");
    adriver = new_fluid_audio_driver(settings, synth);
}


As soon as the audio driver is created, it will start playing. The audio driver creates a separate thread that uses the synthesizer object to generate the audio.

There are a number of general audio driver settings. The audio.driver settings define the audio subsystem that will be used. The audio.periods and audio.period-size settings define the latency and robustness against scheduling delays. There are additional settings for the audio subsystems used. For a full list of available audio driver settings, please refer to FluidSettings Documentation.

*Note: In order to use sdl2 as audio driver, the application is responsible for initializing SDL (e.g. with SDL_Init()). This must be done before the first call to new_fluid_settings()! Also make sure to call SDL_Quit() after all fluidsynth instances have been destroyed.


[size=14pt]Using the synthesizer without an audio driver[/size]

It is possible to use the synthesizer object without creating an audio driver. This is desirable if the application using FluidSynth manages the audio output itself. The synthesizer has several API functions that can be used to obtain the audio output:

fluid_synth_write_s16() fills two buffers (left and right channel) with samples coded as signed 16 bits (the endian-ness is machine dependent). fluid_synth_write_float() fills a left and right audio buffer with 32 bits floating point samples. The function fluid_synth_process() is the generic interface for synthesizing audio, which is also capable of multi channel audio output.


[size=14pt]Loading and managing SoundFonts[/size]

Before any sound can be produced, the synthesizer needs a SoundFont.

SoundFonts are loaded with the fluid_synth_sfload() function. The function takes the path to a SoundFont file and a boolean to indicate whether the presets of the MIDI channels should be updated after the SoundFont is loaded. When the boolean value is TRUE, all MIDI channel bank and program numbers will be refreshed, which may cause new instruments to be selected from the newly loaded SoundFont.

The synthesizer can load any number of SoundFonts. The loaded SoundFonts are treated as a stack, where each new loaded SoundFont is placed at the top of the stack. When selecting presets by bank and program numbers, SoundFonts are searched beginning at the top of the stack. In the case where there are presets in different SoundFonts with identical bank and program numbers, the preset from the most recently loaded SoundFont is used. The fluid_synth_program_select() can be used for unambiguously selecting a preset or bank offsets could be applied to each SoundFont with fluid_synth_set_bank_offset(), to try and ensure that each preset has unique bank and program numbers.

The fluid_synth_sfload() function returns the unique identifier of the loaded SoundFont, or -1 in case of an error. This identifier is used in subsequent management functions: fluid_synth_sfunload() removes the SoundFont, fluid_synth_sfreload() reloads the SoundFont. When a SoundFont is reloaded, it retains it's ID and position on the SoundFont stack.

Additional API functions are provided to get the number of loaded SoundFonts and to get a pointer to the SoundFont.



[size=14pt]Creating a Real-time MIDI Driver[/size]

FluidSynth can process real-time MIDI events received from hardware MIDI ports or other applications. To do so, the client must create a MIDI input driver. It is a very similar process to the creation of the audio driver: you initialize some properties in a settings instance and call the new_fluid_midi_driver() function providing a callback function that will be invoked when a MIDI event is received. The following MIDI drivers are currently supported:

jack: JACK Audio Connection Kit MIDI driver (Linux, Mac OS X)
oss: Open Sound System raw MIDI (Linux, Unix)
alsa_raw: ALSA raw MIDI interface (Linux)
alsa_seq: ALSA sequencer MIDI interface (Linux)
winmidi: Microsoft Windows MM System (Windows)
midishare: MIDI Share (Linux, Mac OS X)
coremidi: Apple CoreMIDI (Mac OS X)

Code: Select all

#include <fluidsynth.h>
int handle_midi_event(void* data, fluid_midi_event_t* event)
{
    printf("event type: %d\n", fluid_midi_event_get_type(event));
}
int main(int argc, char** argv)
{
    fluid_settings_t* settings;
    fluid_midi_driver_t* mdriver;
    settings = new_fluid_settings();
    mdriver = new_fluid_midi_driver(settings, handle_midi_event, NULL);
    /* ... */   
    delete_fluid_midi_driver(mdriver);
    return 0;
}


There are a number of general MIDI driver settings. The midi.driver setting defines the MIDI subsystem that will be used. There are additional settings for the MIDI subsystems used. For a full list of available midi driver settings, please refer to FluidSettings Documentation.


[size=14pt]Loading and Playing a MIDI file[/size]

FluidSynth can be used to play MIDI files, using the MIDI File Player interface. It follows a high level implementation, though its implementation is currently incomplete. After initializing the synthesizer, create the player passing the synth instance to new_fluid_player(). Then, you can add some SMF file names to the player using fluid_player_add(), and finally call fluid_player_play() to start the playback. You can check if the player has finished by calling fluid_player_get_status(), or wait for the player to terminate using fluid_player_join().

Code: Select all

#include <fluidsynth.h>
int main(int argc, char** argv)
{
    int i;
    fluid_settings_t* settings;
    fluid_synth_t* synth;
    fluid_player_t* player;
    fluid_audio_driver_t* adriver;
    settings = new_fluid_settings();
    synth = new_fluid_synth(settings);
    player = new_fluid_player(synth);
    adriver = new_fluid_audio_driver(settings, synth);
    /* process command line arguments */
    for (i = 1; i < argc; i++) {
        if (fluid_is_soundfont(argv[i])) {
           fluid_synth_sfload(synth, argv[1], 1);
        }
        if (fluid_is_midifile(argv[i])) {
            fluid_player_add(player, argv[i]);
        }
    }
    /* play the midi files, if any */
    fluid_player_play(player);
    /* wait for playback termination */
    fluid_player_join(player);
    /* cleanup */
    delete_fluid_audio_driver(adriver);
    delete_fluid_player(player);
    delete_fluid_synth(synth);
    delete_fluid_settings(settings);
    return 0;
}


A list of available MIDI player settings can be found in FluidSettings Documentation.



[size=14pt]Fast file renderer for non-realtime MIDI file rendering[/size]

Instead of creating an audio driver as described in section Loading and Playing a MIDI file one may chose to use the file renderer, which is the fastest way to synthesize MIDI files.

Code: Select all

fluid_settings_t* settings;
fluid_synth_t* synth;
fluid_player_t* player;
fluid_file_renderer_t* renderer;
settings = new_fluid_settings();
// specify the file to store the audio to
// make sure you compiled fluidsynth with libsndfile to get a real wave file
// otherwise this file will only contain raw s16 stereo PCM
fluid_settings_setstr(settings, "audio.file.name", "/path/to/output.wav");
// use number of samples processed as timing source, rather than the system timer
fluid_settings_setstr(settings, "player.timing-source", "sample");
// since this is a non-realtime szenario, there is no need to pin the sample data
fluid_settings_setint(settings, "synth.lock-memory", 0);
synth = new_fluid_synth(settings);
// *** loading of a soundfont omitted ***
player = new_fluid_player(synth);
fluid_player_add(player, "/path/to/midifile.mid");
fluid_player_play(player);
renderer = new_fluid_file_renderer (synth);
while (fluid_player_get_status(player) == FLUID_PLAYER_PLAYING)
{
    if (fluid_file_renderer_process_block(renderer) != FLUID_OK)
    {
        break;
    }
}
// just for sure: stop the playback explicitly and wait until finished
fluid_player_stop(player);
fluid_player_join(player);
delete_fluid_file_renderer(renderer);
delete_fluid_player(player);
delete_fluid_synth(synth);
delete_fluid_settings(settings);


Various output files types are supported, if compiled with libsndfile. Those can be specified via the settings object as well. Refer to the FluidSettings Documentation for more audio.file.* options.

[size=24pt]So, taking on mind the function of the Fluidsytnh API, now its time to understand the go bindings[/size]

[size=14pt]So, From squeeky Fluidsyhnth binding, we will take on: Driver.go[/size]

Code: Select all

package fluidsynth

// #cgo pkg-config: fluidsynth
// #include <fluidsynth.h>
// #include <stdlib.h>
import "C"

type AudioDriver struct {
   ptr *C.fluid_audio_driver_t
}

func NewAudioDriver(settings Settings, synth Synth) AudioDriver {
   return AudioDriver{C.new_fluid_audio_driver(settings.ptr, synth.ptr)}
}

func (d *AudioDriver) Delete() {
   C.delete_fluid_audio_driver(d.ptr)
}


type FileRenderer struct {
   ptr *C.fluid_file_renderer_t
}

func NewFileRenderer(synth Synth) FileRenderer {
   return FileRenderer{C.new_fluid_file_renderer(synth.ptr)}
}

func (r *FileRenderer) Delete() {
   C.delete_fluid_file_renderer(r.ptr)
}

func (r *FileRenderer) ProcessBlock() bool {
   return C.fluid_file_renderer_process_block(r.ptr) == C.FLUID_OK


Greetings fom Mexico

User avatar
Anthony817
Shark Patrol
Posts: 4009

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#75 » Mon Jul 15, 2019 1:38 pm

And most informative introductory post goes to Mike77154!

Welcome to the forums and greetings from Texas!
Image

Alexislight
minority
Posts: 67

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#76 » Tue Jul 16, 2019 1:59 pm

Ian Micheal wrote:
Ripfire wrote:Ian, creo que deberías tener 2 versiones del mismo openbor, una de 8 bits con libpng v1.2.8 y la otra de 16/32 bits con libpng v1.6.19, para tener más control de la paleta diferente. ¿Sera posible? :?

Ian, I think you should have 2 versions of the same openbor, one of 8-bits with libpng v1.2.8 and the other of 16/32-bits with libpng v1.6.19, for more control of the different palette. Is it possible? :?


Yes i can do that, Also looking into geting opengl working with filters it would free up a lot of memory by using hardware rending.. I will look into very soon And have both v1.2.8 and v1.6.19 it will take some work but it seems a good idea..


are you going to use the Phenom's opengl?
for you, what is the best unoffcial version in DC, beta 5 or beta 6?

User avatar
Ian Micheal
Developer
Posts: 5994
Contact:

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#77 » Tue Jul 16, 2019 4:26 pm

beta 6 no menu has 8,16,32 bit correct rending.. beta 5 uses old rending less memory might be faster for 8bit palette games.. beta6 with menu only loads 8 bit palette games. has over head in memory of the menu so less memory.. I have a faster double buffer version coming soon.. opengl i will be using is new and the fastest.. https://gitlab.com/simulant/GLdc GLDC it powers nuquake opengl.. :) I have to port functions and names to SDL opengl From KLGX.

User avatar
Ian Micheal
Developer
Posts: 5994
Contact:

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#78 » Wed Jul 24, 2019 12:39 am

Development has been slow due to dealing with my whole dev system crashing 2 times and having to reset it up 2 times.. Im back to it.

User avatar
Ian Micheal
Developer
Posts: 5994
Contact:

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#79 » Fri Jul 26, 2019 1:46 pm

Minor update Beta 6.1 changes less memory trys limt mapped sprites smaller video delta buffer malloc has new buffers and trims bins added.
8 16 32 bit palette modes still new png. not png1.2.8.. some games need the old png lib
Source code update https://drive.google.com/open?id=17fX5w ... FTXhcJTRz6
Bin plainfiles with new builder just drop your bor.pak in the data_hb directory and click build image that it creates a selfboot cdi.
openborBuilder.rar
(1.8 MiB) Downloaded 727 times

Thanks to Thanks to
Sizious and mrneo240, for the tool for the builder.


New games using it are here
GoldenAxe-Remake(480x272) Beta6.1 openbor
viewtopic.php?f=52&t=11899
Street Fighter II Champion Edition VS mode OB Beta6.1 16bit
viewtopic.php?f=52&t=11898

There is up to 2meg less memory used then beta 6 it could help some games load.
Last edited by Ian Micheal on Sat Jul 27, 2019 8:15 am, edited 1 time in total.

User avatar
fafadou
Gold Lion
Posts: 1652

Re: New Updated OpenborDC Engine Beta6 with Pc menu

Post#80 » Sat Jul 27, 2019 3:10 am

It's great there are still some update :-)

  • Similar Topics
    Replies
    Views
    Last post

Return to “New Releases/Homebrew/Emulation”

Who is online

Users browsing this forum: Google [Bot]