B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Tue Apr 17, 2018 7:53 pm

tricky wrote:That is running.
Is there an easy way to get the "beeb" layout keyboard?
@ is *
# is ]
actually, it looks like it might only be those two.
That is a quirk of Allegro 5. For some strange reason it uses the keymap for the keyboard you actually have on Linux and OS/X but the keymap for the US Keyboard on Windows. There's a bug in for it. In the mean time you could do Settings > Keyboard -> Remap Keyboard, click on those keys in turn and tap the correct keyboard key. Until the Allegro Guys work this one out we could always ship a b-em.cfg file with that keymapping in place with the Windows version.
tricky wrote:Is there a way to redefine the BREAK key?
Not at the moment, but I don't think it would be that hard to add.
tricky wrote:It doesn't recognise my joystick (HORI Fighting stick - PS3) and there doesn't seem to be an option to enable joysticks.
In my version of b-em, I support mapping joystick directions and buttons to keys so that even games without joystick support can work. I also allow a button to be mapped to exit to allow playing in a MAME cab etc. (I have a post somewhere about my launcher).
PS No flashing line here ;)
It is supposed to recognise the stick automatically. As I can;t test this I may have to enable debug messages in that module and perhaps you can see what it reports.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Tue Apr 17, 2018 7:55 pm

tricky wrote:Oops, teletext colours are wrong, maybe NuLA isn't implemented correctly! - not that Centipede uses it!
Testing with the attached centipede build.
I've found the bug. Fixed in https://github.com/stardot/b-em/commit/ ... 61bbdf83a4

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Tue Apr 17, 2018 9:56 pm

Coeus wrote:
pau1ie wrote:when I run it. It seems to be looking for b-em.cfg, but it doesn't look in the current directory (I am running it out of the directory where I compiled it). If I copy the file into ~/.config/b-em it fires up OK. I assume if I did an install it would find stuff OK, but I didn't check.
Yes, if you installed it as a package the default b-em.cfg file would be installed as /usr/share/b-em/b-em.cfg and B-Em knows to look there is it can't find ~/.config/b-em/b-em.cfg. That would provide the initial set of models and would then save back to ~/.config/b-em/b-em.cfg
I did a ‘make install’ after ‘make’ and everything was put in the right place. I did it without thinking but I guess that needs to go in the updated doc.

User avatar
pau1ie
Posts: 525
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: B-Em

Post by pau1ie » Wed Apr 18, 2018 7:58 am

I opened a bug for the disc drive noise. I can't reproduce the flickering line at present.I will try again this evening, and if I still can't reproduce it I will put it down to solar radiation or something!
I'm working on http://bbcmicro.co.uk

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Wed Apr 18, 2018 9:22 am

pau1ie wrote:I opened a bug for the disc drive noise. I can't reproduce the flickering line at present.I will try again this evening, and if I still can't reproduce it I will put it down to solar radiation or something!
If people try it today there is low risk of solar flares

https://www.spaceweatherlive.com/en/solar-activity

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Wed Apr 18, 2018 4:04 pm

Built a B-em allegro5 image for linux x86 now, was much harder getting it to work than the old version (on a base minimal ubuntu install). Building it was easy getting it to run was a pain but there now. Currently building the linux arm version. Could take a while.

Picture below is the Parallax Demo running in a Docker container on a RPi, using B-em (Allergo5 version) compiled from source displayed on a Mac.
Attachments
192_168_1_30_5920__f3a90ac3fb3c_20__-_VNC_Viewer.jpg

User avatar
tricky
Posts: 2558
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: B-Em

Post by tricky » Wed Apr 18, 2018 4:58 pm

That scrolling demo seems to be missing NuLA.

For joysticks, I did add support to beebem and b-em in my launcher app and the emulators that it runs.

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Wed Apr 18, 2018 5:16 pm

tricky wrote:That scrolling demo seems to be missing NuLA.
Hmmm. I hadnt noticed. Had a quick look and it is switched on by default. I wonder if that is spectic to that build or in general. Will look later.
tricky wrote: For joysticks, I did add support to beebem and b-em in my launcher app and the emulators that it runs.
Not seen that, will have a look at that.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Wed Apr 18, 2018 6:33 pm

tricky wrote:That scrolling demo seems to be missing NuLA.
Is it the NuLA version? I first saw this as a NuLA demo but I have since discovered there is a version on the B-Em demo disc that came with version 2.2 and is still in the discs directory which does not attempt to make use of NuLA. Interestingly the NuLA version doesn't seem to have the bottom scrolled area. Here's what I get:
2018-04-18-sotb.png

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Wed Apr 18, 2018 8:29 pm

Coeus wrote:
tricky wrote:That scrolling demo seems to be missing NuLA.
Is it the NuLA version? I first saw this as a NuLA demo but I have since discovered there is a version on the B-Em demo disc that came with version 2.2 and is still in the discs directory which does not attempt to make use of NuLA. Interestingly the NuLA version doesn't seem to have the bottom scrolled area. Here's what I get:

2018-04-18-sotb.png
Was the version that comes B-Em demo disc, I wasnt expecting it to be Nula. So that clears that up then. I will have to find the Nula version then, although possibly run even slower then on the Pi.

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Wed Apr 18, 2018 9:15 pm

Found the Nula version and rebuild the image so it get pushed into the discs directory.

So in all its glory running at full speed on a raspberry pi via VNC (which isnt very fast but it works)

Edit: 4 flavours of B-Em here in Docker Hub now for anyone that wants ot play with it. Allegro 4 & 5 in both Linux x86 and RPI ARM. Still Work in Progress.
Attachments
192_168_1_30_5920__e5f9023355b6_20__-_VNC_Viewer_and_VNC_Viewer_and_1__pi_cnat____bem_build-DEV__ssh_.jpg

User avatar
pau1ie
Posts: 525
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: B-Em

Post by pau1ie » Wed Apr 18, 2018 10:32 pm

I did get the flickering again. It seems to be the first two runs after rebooting (weird), so it might be library or hardware related. I raised a bug anyway and linked to a rather rubbish video taken with my mobile. You can always close it if you don't think it is b-em.
I'm working on http://bbcmicro.co.uk

User avatar
pau1ie
Posts: 525
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: B-Em

Post by pau1ie » Sun Apr 22, 2018 9:34 pm

I see the bugs I raised have been fixed, but I don't know enough about git to test it.

If I clone the repository the last commit I get is from 31 March, but the commit for the bug I raised was "4 days ago", which I assume means 18 April.

How do I download this version of the code to test it?
I'm working on http://bbcmicro.co.uk

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Sun Apr 22, 2018 9:59 pm

pau1ie wrote:I see the bugs I raised have been fixed, but I don't know enough about git to test it.

If I clone the repository the last commit I get is from 31 March, but the commit for the bug I raised was "4 days ago", which I assume means 18 April.

How do I download this version of the code to test it?
Paul, cloning clones the whole repository but leaves you on the master branch. The Allegro 5 branch you want is currently sf/allegro5 so after cloning:

Code: Select all

git checkout sf/allegro5
Once we're happy that this version is generally usable then I can swap so master points to it and the allegro4 version is a branch if anyone wants to work on it.

User avatar
hoglet
Posts: 7250
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Mon Apr 23, 2018 9:27 am

Steve,

I'm currently trying to build the sf/allegro5 on Windows using the MinGW environment I previously used for B-Em and Atomulator.

I need to add allegro5 to this.

Do you know which version of allegro5 is needed?

The latest MinGW allegro5 binary is for 5.0.10:
https://www.allegro.cc/files/?v=5.0
(Edit: It's possible I'm looking in the wrong place here, and this site is unofficial)

With this installed I get build errors:

Code: Select all

gui-allegro.c:41:1: error: unknown type name 'ALLEGRO_MENU'
As far as I can tell, ALLEGRO_MENU is part of the native diaglogs but it not defined in Allegro 5.0.10.

What version are you using in your Windows snapshots?

Are these built using MinGW?

Which version of GCC is being used?

I'd like to crease as similar build environment as possible, and none of this seems to be well documented yet.


Dave

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Mon Apr 23, 2018 9:35 am

hoglet wrote:Steve,

I'm currently trying to build the sf/allegro5 on Windows using the MinGW environment I previously used for B-Em and Atomulator.

I need to add allegro5 to this.

Do you know which version of allegro5 is needed?

The latest official MinGW allegro5 binary is for 5.0.10:
https://www.allegro.cc/files/?v=5.0

With this installed I get build errors:

Code: Select all

gui-allegro.c:41:1: error: unknown type name 'ALLEGRO_MENU'
As far as I can tell, ALLEGRO_MENU is part of the native diaglogs but it not defined in Allegro 5.0.10.
I acutally hit this issue on Linux had me scratching my head for a while.

The Ubuntu 16.x Allegro 5 packages are missing some bits for Allergro 5 Menu's and doesnt work.
In Ubunti 17.x is works out of the bo with apt-get

The package to make it work on 17.x are.

liballegro5.2 liballegro-acodec5.2 liballegro-audio5.2 liballegro-dialog5.2 \
liballegro-video5.2 liballegro-image5.2 liballegro-physfs5.2 liballegro-ttf5.2

I will see if I can spot the missing packages. And what files they had in 16.x Possibly no help to you but might remind people to upgrade to Ubuntu 17.x before using Allegro5 (or compile Allegro form source).

User avatar
Elminster
Posts: 2413
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: B-Em

Post by Elminster » Mon Apr 23, 2018 9:41 am

Those are the run times packages. The build packages were

apt-get install -y gcc g++ make cmake \
liballegro5-dev \
libopenal-dev \
libalut-dev \
zlib1g-dev \
automake1.11 \
git wget unzip \

From what i remember it built fine, then fell over with the allegro_menu error when you tried to run it as not all the llegro5 distro was avaialble as packages via apt on ubutu 16.

Edit: Looks like the missig package on Ubunu 16 was the video one, here is the list of files in that package, probably not any help at all, i havent trid building any form of windows version yet.

/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/liballegro_video.so.5.2.2
/usr/share
/usr/share/doc
/usr/share/doc/liballegro-video5.2
/usr/share/doc/liballegro-video5.2/copyright
/usr/lib/x86_64-linux-gnu/liballegro_video.so.5.2
/usr/share/doc/liballegro-video5.2/changelog.Debian.gz

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 11:22 am

hoglet wrote:Steve,

I'm currently trying to build the sf/allegro5 on Windows using the MinGW environment I previously used for B-Em and Atomulator.

I need to add allegro5 to this.

Do you know which version of allegro5 is needed?
https://github.com/liballeg/allegro5/re ... ag/5.2.2.0

I have updated the README.me to mention this. It has to be this version as it needs native dialogues but needs to avoid a later bug which affects checkboxes.

I am using MingW, though a slightly later version. I'll check out which when back home and have access to the Windows VM I have it installed on.

User avatar
pau1ie
Posts: 525
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: B-Em

Post by pau1ie » Mon Apr 23, 2018 11:46 am

Coeus wrote: Paul, cloning clones the whole repository but leaves you on the master branch. The Allegro 5 branch you want is currently sf/allegro5 so after cloning:

Code: Select all

git checkout sf/allegro5
Thanks. That is what I was missing. I will give it a go (hopefully) tonight.
I'm working on http://bbcmicro.co.uk

User avatar
hoglet
Posts: 7250
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Mon Apr 23, 2018 12:49 pm

Coeus wrote: https://github.com/liballeg/allegro5/re ... ag/5.2.2.0

I have updated the README.me to mention this. It has to be this version as it needs native dialogues but needs to avoid a later bug which affects checkboxes.

I am using MingW, though a slightly later version. I'll check out which when back home and have access to the Windows VM I have it installed on.
Thanks Steve.

I've just built on Ubuntu 16.04 with Allegro 5.2.4 and don't see any evidence of an issue with checkboxes.

Can you say a bit more about it? Was it on Windows or Linux or both?

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 1:11 pm

hoglet wrote:I've just built on Ubuntu 16.04 with Allegro 5.2.4 and don't see any evidence of an issue with checkboxes.
The issue with check-boxes is Windows-only. On Linux, the native dialog extension uses GTK which handles the checking and unchecking of check-box menu items internally. On Windows this doesn't happen so the Allegro native dialogue extension includes code to do it so that the behaviour would be the same across all platforms.

As originally written, the native dialogue extension expected the ID assigned to each menu item to be unique across all the items on all the menus, i.e. exactly what a developer would do if ever having worked with the old-school, pre-c++ Windows API (as B-Em on Allegro 4 did). That was not documented, though and someone raised a bug https://github.com/liballeg/allegro5/issues/816 and the Allegro developers decided to have two IDs associated with each menu item, a unique one used internally within Allegro, and the one used on the API between the program and Allegro. Unfortunately that broke the code that does the check-box checking and unchecking on Windows. There is a bug in for that too: https://github.com/liballeg/allegro5/issues/898

Personally, I would have closed the first bug (#816) as wont-fix and said that just the way it works. The suggested work around of DIY checking/unchecking but only on Windows and only on that version is a non-starter as far as I am concerned. The whole point of employing a cross-platform library is to avoid that kind of nonsense so the solution, for now, it to use the last version before the fix to bug 816 went in and hope they get round to fixing it properly. That's OK for the Windows version as we include Allegro with B-Em so we have control over the version.

KaleviKolttonen
Posts: 5
Joined: Mon Apr 23, 2018 12:16 pm
Contact:

Re: B-Em

Post by KaleviKolttonen » Mon Apr 23, 2018 2:05 pm

Hi guys!

First of all, I do not know that much about emulators, videos, ORIC or BBC Micro, but please bear with me. I am a Fedora Linux user.

I use B-em emulator to get to know BBC Micros and I intend to play Manic Miner on this computer, because the BBC Micro port contains two unique rooms and I would like to record my room completion attempts. Using Oricutron (ORIC emulator) I could take video captures of each room getting completed. I actually just completed all 32 ORIC rooms individually, using infinite lives. Unfortunately B-em does not support video captures. :o

I wondered whether the ORIC AVI RLE video encoder could be taken from Oricutron and placed into B-em source tree. Sure enough, avi.c and avi.h were pretty easy to take, and the good news is that I can call the Oricutron AVI API from B-em. It creates valid AVI videos and API is dead simple: just four simple calls.

The bad news is that I cannot do the complicated parts:

1) I do not understand how Oricutron fills oric->scr buffer, it seems to involve lots of bit fiddling
2) I do not know ORIC computer internals, I only packaged the emulator for Fedora Linux 27 and use it
3) I do not know BBC Micro computer internals
4) I cannot make avi_addframe() calls properly, because I don't know how to get the srcdata before making the call

Recording sound I haven't even tried yet.

I tried to study Beebem for Windows, but could not get help from that. I just don't know how it records AVI videos. I guess it uses Windows AVI API.

My minimal code is here:

https://github.com/KaleviKolttonen/b-em ... eo-capture

But of course it does not work. I edited avi.c to change resolution to 320x200 and it seems to produce videos at that resolution now. But BBC Micro has several graphics modes, maybe it should be determined which one is in use, and encode the video resolution accordingly? I don't know!

Would it be possible to add a video capturing feature to B-em? Using Oricutron RLE encoder could be good at least in theory, because, as far as I know, it stores the video (and audio) data uncompressed. So the Oricutron video captures are very nice and clear, and mplayer playes them fine on Fedora Linux! :D

Oh yeah, there is also a dependency on SDL library with that video-capture branch. Oricutron AVI code uses some helper functions from there even though I removed some of the SDL stuff.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 4:23 pm

KaleviKolttonen wrote:I wondered whether the ORIC AVI RLE video encoder could be taken from Oricutron and placed into B-em source tree
...
My minimal code is here:

https://github.com/KaleviKolttonen/b-em ... eo-capture
I had a quick look at that, looking specifically where I'd expect you to grab the video output, i.e. pretty much the same place as a screenshot is saved and I found:

Code: Select all

if (do_video_capture) {
         /* How to feed data to avi_addframe() like Oricutron does??? */
         avi_addframe(&vidcap, &ram[0x3000]);
    }
and I think you will run into trouble with that approach. Even in the normal, Acorn-defined modes the BBC Micro memory is not a linear framebuffer where it is simply a case of working out how a pixel is encoded - instead it is in a non-linear format as determined by the order in which the M6845 CRTC generates addresses. There is some discussion on that and links to the data sheet in the Video Timing thread. Then there is the issue that some games re-program the CRTC partway through the frame, i.e. the whole screen is not necessarily in the same mode.

If you want to capture video frames from within B-Em you would do much better to save snapshots of the bitmap that B-Em blits onto the real screen in a very similar way to the screenshot code which is just above where you added your code. That means you can completely dodge the complexity of how the RAM on the BBC Micro is turned into a bitmap for display but it does then mean you need to understand the format of bitmaps in Allegro, the library B-Em uses. That is different between Allegro 4, which is used by the master branch, and Allegro 5, which is the new version of B-Em (branch sf/allegro5). In Allegro 4 a bitmap is basically an array of line pointers each of which points to an array of pixels. In Allegro 5 a bitmap is an array of pixels in some format with metadata to enable you to calculate where the pixel for a particular x/y position would be. To see this in action look at:

Code: Select all

static inline void putpixel(BITMAP *bmp, int x, int y, int colour) {
    uint32_t *l = (uint32_t *)(bmp->line[y]);
    l[x] = colour;
}
from video.c for the allegro4 version. This is writing a pixel into the bitmap but it demonstrates the calculation. The Allegro 5 version looks like this:

Code: Select all

static inline int get_pixel(ALLEGRO_LOCKED_REGION *region, int x, int y)
{
    return *((uint32_t *)(region->data + region->pitch * y + x * region->pixel_size));
}

static inline void put_pixel(ALLEGRO_LOCKED_REGION *region, int x, int y, uint32_t colour)
{
    *((uint32_t *)(region->data + region->pitch * y + x * region->pixel_size)) = colour;
}
here you can see both put/get functions. Allegro does provide get_pixel/put_pixel functions to hide this detail but they are not really fast enough to run sequentially on every pixel of a bitmap.

Sound maybe more of a challenge still I am not sure there is any one place where the various sound sources are all mixed together ready to record.

Another possible approach is to avoid changing B-Em altogether and see if you can do what you want with a screen recorder. I did a quick web search and found https://www.tecmint.com/best-linux-scre ... recording/ I have not tried any of those out but if that approach works it may be a lot less effort.

KaleviKolttonen
Posts: 5
Joined: Mon Apr 23, 2018 12:16 pm
Contact:

Re: B-Em

Post by KaleviKolttonen » Mon Apr 23, 2018 4:39 pm

Coeus wrote:
KaleviKolttonen wrote:I wondered whether the ORIC AVI RLE video encoder could be taken from Oricutron and placed into B-em source tree
...
My minimal code is here:

https://github.com/KaleviKolttonen/b-em ... eo-capture
I had a quick look at that, looking specifically where I'd expect you to grab the video output, i.e. pretty much the same place as a screenshot is saved and I found:

Code: Select all

if (do_video_capture) {
         /* How to feed data to avi_addframe() like Oricutron does??? */
         avi_addframe(&vidcap, &ram[0x3000]);
    }
and I think you will run into trouble with that approach. Even in the normal, Acorn-defined modes the BBC Micro memory is not a linear framebuffer where it is simply a case of working out how a pixel is encoded - instead it is in a non-linear format as determined by the order in which the M6845 CRTC generates addresses. There is some discussion on that and links to the data sheet in the Video Timing thread. Then there is the issue that some games re-program the CRTC partway through the frame, i.e. the whole screen is not necessarily in the same mode.

If you want to capture video frames from within B-Em you would do much better to save snapshots of the bitmap that B-Em blits onto the real screen in a very similar way to the screenshot code which is just above where you added your code. That means you can completely dodge the complexity of how the RAM on the BBC Micro is turned into a bitmap for display but it does then mean you need to understand the format of bitmaps in Allegro, the library B-Em uses. That is different between Allegro 4, which is used by the master branch, and Allegro 5, which is the new version of B-Em (branch sf/allegro5). In Allegro 4 a bitmap is basically an array of line pointers each of which points to an array of pixels. In Allegro 5 a bitmap is an array of pixels in some format with metadata to enable you to calculate where the pixel for a particular x/y position would be. To see this in action look at:

* TEXT CLIPPED FROM HERE *

Sound maybe more of a challenge still I am not sure there is any one place where the various sound sources are all mixed together ready to record.

Another possible approach is to avoid changing B-Em altogether and see if you can do what you want with a screen recorder. I did a quick web search and found https://www.tecmint.com/best-linux-scre ... recording/ I have not tried any of those out but if that approach works it may be a lot less effort.
Yes, I realized by myself that the screenshot taking place in the code would be a good start, but could not figure out how the struct BITMAP handling in Allegro 4 works. I am not too familiar with graphics or videos at all. By the way, VICE, Versatile Commodore Emulator, contains a whole video library in its source tree. I think they have their own, in-tree fork that is somehow modified so that it will work with VICE. Seems quite complicated.

If I could use about the same code as with screenshots, i.e. use the blitted screens for video encoder input, I have no clue whether the Oricutron RLE code would work or not. Would it be possible to use it at all, or would it need a proper, complicated video codec library? I don't know, this video capture feature is probably beyond my abilities. But in my opinion it would be good if B-em supported it.

Regarding sound, it is too bad if there is no central place in B-em for capturing sound samples.

Yes, a separate screen recording utility would work, but somehow the idea of B-em support for video capture is fascinating. In Oricutron, you press F10 and it just works beautifully.

I forgot to say many thanks for the info!

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 5:08 pm

KaleviKolttonen wrote:Yes, I realized by myself that the screenshot taking place in the code would be a good start, but could not figure out how the struct BITMAP handling in Allegro 4 works. I am not too familiar with graphics or videos at all. By the way, VICE, Versatile Commodore Emulator, contains a whole video library in its source tree. I think they have their own, in-tree fork that is somehow modified so that it will work with VICE. Seems quite complicated.
Bear in mind I cannot speak for everyone else who has contributed to B-Em, nor is it my place to tell other projects what they should do, but I think it is preferable to leave the complexities of development and maintenance of a video encoding library to people who have chosen to do that. If we did add video encoding support to B-Em my preference would be to choose an existing cross-platform library that already does that. The only snag is converting the bitmap from Allegro format into whatever the library expects. Interestingly Allegro has a video add-on but that is playback only. Existing cross-platform video encoding seems to be available from the ffmpeg project and from VLC (VideoLAN client, which also does screen recording and is a library dependency for OBS which is also in that list of screen recorders).
KaleviKolttonen wrote:If I could use about the same code as with screenshots, i.e. use the blitted screens for video encoder input, I have no clue whether the Oricutron RLE code would work or not. Would it be possible to use it at all, or would it need a proper, complicated video codec library?
Depending on what format that code expects as input it may be anything from straightforward to a mammoth effort. Assuming RLE means run-length-encoding and that is not is not, therefore, a standardised video format it would also mean having a tool that is run on the output afterwards to convert it to a standard format if you wished to distribute it and expect people to play it with commonly available software such as their web browser with suitable plugins. It used to be that all video encoding was done this way - a minimally compressed initial capture and then a separate proper compression step. At the time PCs could first typically be used for that a real-time MPEG2 encoder was the size of a washing machine with lots of custom hardware. These days a modern PC can encode real time into a distribution-suitable format by using a suitable library.

There would be no harm in logging this as an enhancement in github against the stardot B-Em. I can't promise to do it it depends on how various other things go, but at least it is logged. Another possibility would be to open an enhancement request on the Allegro 5 project (https://github.com/liballeg/allegro5) to add video recording of the output to the Allegro library. That would have the advantage of then being available to any other programs written for Allegro 5.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 5:21 pm

Coeus wrote:I am using MingW, though a slightly later version. I'll check out which when back home and have access to the Windows VM I have it installed on.
It's gcc version 7.2.0 (i686-win32-dwarf-rev1, Built by MinGW-W64 project)

KaleviKolttonen
Posts: 5
Joined: Mon Apr 23, 2018 12:16 pm
Contact:

Re: B-Em

Post by KaleviKolttonen » Mon Apr 23, 2018 5:34 pm

Coeus wrote: Bear in mind I cannot speak for everyone else who has contributed to B-Em, nor is it my place to tell other projects what they should do, but I think it is preferable to leave the complexities of development and maintenance of a video encoding library to people who have chosen to do that. If we did add video encoding support to B-Em my preference would be to choose an existing cross-platform library that already does that. The only snag is converting the bitmap from Allegro format into whatever the library expects. Interestingly Allegro has a video add-on but that is playback only. Existing cross-platform video encoding seems to be available from the ffmpeg project and from VLC (VideoLAN client, which also does screen recording and is a library dependency for OBS which is also in that list of screen recorders).
They have ffmpeg libraries in their emulator source tree, but there must be a good reason for their fork. They probably wanted or needed a feature that the ffmpeg maintainers would not accept. This is my guess, at any rate. There would be no point in the in-tree fork otherwise, it would be pretty crazy indeed.
Coeus wrote: Depending on what format that code expects as input it may be anything from straightforward to a mammoth effort. Assuming RLE means run-length-encoding and that is not is not, therefore, a standardised video format it would also mean having a tool that is run on the output afterwards to convert it to a standard format if you wished to distribute it and expect people to play it with commonly available software such as their web browser with suitable plugins. It used to be that all video encoding was done this way - a minimally compressed initial capture and then a separate proper compression step. At the time PCs could first typically be used for that a real-time MPEG2 encoder was the size of a washing machine with lots of custom hardware. These days a modern PC can encode real time into a distribution-suitable format by using a suitable library.
I see. Well, on Fedora Linux mplayer plays the Oricutron video captures without any problems. It is also possible to upload the Oricutron AVIs to YouTube, and they will work fine after YouTube has done whatever they do to videos. But on Fedora Linux Firefox, those YouTube videos look blurred and horrible, like with lossy compression. Using Safari on iPad Air 2, the YouTube videos look pretty good. I don't know why this is so.
Coeus wrote: There would be no harm in logging this as an enhancement in github against the stardot B-Em. I can't promise to do it it depends on how various other things go, but at least it is logged. Another possibility would be to open an enhancement request on the Allegro 5 project (https://github.com/liballeg/allegro5) to add video recording of the output to the Allegro library. That would have the advantage of then being available to any other programs written for Allegro 5.
Yeah, makes sense, thanks!

EDIT: I just asked the Allegro 5 maintainers whether it would be possible to include a video capture feature in their library. Having the library support it would be very nice and make it easy for the applications to use it.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em

Post by Coeus » Mon Apr 23, 2018 6:46 pm

tricky wrote:Is there a way to redefine the BREAK key?
There wasn't but I have introduced it in commit 9f4451d4d2807ed5097920f42d063ae5641d9636
tricky wrote:It doesn't recognise my joystick (HORI Fighting stick - PS3) and there doesn't seem to be an option to enable joysticks.
In my version of b-em, I support mapping joystick directions and buttons to keys so that even games without joystick support can work. I also allow a button to be mapped to exit to allow playing in a MAME cab etc. (I have a post somewhere about my launcher).
PS No flashing line here ;)
I have fixed an issue with failing to initialise the joystick driver so hopefully that should be better now. It would be good to get your joystick to keys enhancement included. When you implemented this on the Allegro 4 version what did you do for a UI to define the keys? Do you think something like the keyboard redefine UI would work?

KaleviKolttonen
Posts: 5
Joined: Mon Apr 23, 2018 12:16 pm
Contact:

Re: B-Em

Post by KaleviKolttonen » Mon Apr 23, 2018 7:27 pm

Coeus wrote: I have fixed an issue with failing to initialise the joystick driver so hopefully that should be better now. It would be good to get your joystick to keys enhancement included. When you implemented this on the Allegro 4 version what did you do for a UI to define the keys? Do you think something like the keyboard redefine UI would work?
I am not the person you replied to, but surprisingly my B-Em 2.2.2kk also includes joystick-to-keyboard mapping! I wanted to play Boulder Dash on a BBC Micro, and just could not get the downward movement to work with ANY key on my Finnish keyboard. So I implemented the joy-to-key mapping.

My solution to the actual mapping definition is pretty clumsy, but it works: I have a simple mapping file for each game and you specify the mapfile with -joymap command line option.

User avatar
tricky
Posts: 2558
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: B-Em

Post by tricky » Mon Apr 23, 2018 7:56 pm

I did something similar in my Launcher project where I have a config file with several layouts for each of several joysticks and then select the appropriate one with -joymap (snap!).
The code is DirectX (DirectInput) as I didn't get on with Allegro and wanted the same code for B-Em, and both versions of beebem that I regularly use.

Post Reply