B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
tricky
Posts: 3273
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: B-Em

Post by tricky » Wed Feb 22, 2017 8:16 am

I added x_open to win.c as I thought it was the windows specific functions, but it may not be; it can be added anywhere.

I have nothing against MingGW, apart from the time lost while I was a console games developer, but Windows should have a visual studio option.

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

Re: B-Em

Post by hoglet » Wed Feb 22, 2017 8:18 am

I guess that the user base is probably 75% Windows / 25% Linux, but that's just a guess.

It does feel we need to agree a standard way to build on Windows. Not necessarily the only way, but any code changes should be validated against this as a matter of course.

I can think of four options:
1 - the original MinGW environment, with a manually maintained Makefile.win
2 - the latest MinGW environment, that might support autogen/autotools
3 - the recent Windows 10 Bash shell (not sure this will actually work....)
4 - a standard Microsoft Visual Studio project

All of these have pain points, and for me the important thing is we agree on one and document it well so it's repeatable.

Dave

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 22, 2017 9:29 am

hoglet wrote:I guess that the user base is probably 75% Windows / 25% Linux, but that's just a guess.

It does feel we need to agree a standard way to build on Windows. Not necessarily the only way, but any code changes should be validated against this as a matter of course.
The wider point I'm making here is that if I need or want to change things, there is no way I can make the Windows side of this work -- not only do I not have the environment, but I don't have the knowledge, either. This means that anything which touches both Linux and Windows will suffer if I need to change it -- and right now, there's a high coupling between both Windows and Linux which means making changes is going to be one-sided.

I don't want to break things for the Windows users at all, but I'm not sure how I am going to go about solving this.

-- Thomas

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Wed Feb 22, 2017 11:29 am

ThomasAdam wrote:
I don't want to break things for the Windows users at all, but I'm not sure how I am going to go about solving this.

-- Thomas
If you are unable to test on windows then you will have to delegate that to another volunteer. Git makes it easy to work on branches and merge things.

The libraries used are cross platform so this should be manageable.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
BigEd
Posts: 2397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: B-Em

Post by BigEd » Wed Feb 22, 2017 11:33 am

If a person can't test on both platforms, perhaps they should use the pull request mechanism, and get a review from someone who can test on the other platform?

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 22, 2017 11:34 am

fordp wrote:
ThomasAdam wrote:
I don't want to break things for the Windows users at all, but I'm not sure how I am going to go about solving this.

-- Thomas
If you are unable to test on windows then you will have to delegate that to another volunteer. Git makes it easy to work on branches and merge things.

The libraries used are cross platform so this should be manageable.
It's not the testing, it's the development. There is going to come a point quite quickly, beyond the current code base, where changes will need to be implemented on both Windows and Unix. It's the Windows side of those changes which I cannot do. This makes development a real concern in trying to support two operating systems, but with only 100% of the knowledge in Unix.

User avatar
danielj
Posts: 6970
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: B-Em

Post by danielj » Wed Feb 22, 2017 12:00 pm

hoglet wrote:I guess that the user base is probably 75% Windows / 25% Linux, but that's just a guess.

It does feel we need to agree a standard way to build on Windows. Not necessarily the only way, but any code changes should be validated against this as a matter of course.
There's arguably a mac user base too - we're stuck with beebem at the moment simply because the version of Allegro that B-Em uses is so old it won't compile on 64bit Mac OS :(

d.

User avatar
fordp
Posts: 1000
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Wed Feb 22, 2017 1:19 pm

ThomasAdam wrote: It's not the testing, it's the development. There is going to come a point quite quickly, beyond the current code base, where changes will need to be implemented on both Windows and Unix. It's the Windows side of those changes which I cannot do. This makes development a real concern in trying to support two operating systems, but with only 100% of the knowledge in Unix.
There are changes that would need testing on all platforms. There are also many changes that should not be an issue between platforms. Dave's back porting of 32016 Copro is an example of a complex change that should just work on all platforms.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 22, 2017 1:32 pm

fordp wrote:
ThomasAdam wrote: It's not the testing, it's the development. There is going to come a point quite quickly, beyond the current code base, where changes will need to be implemented on both Windows and Unix. It's the Windows side of those changes which I cannot do. This makes development a real concern in trying to support two operating systems, but with only 100% of the knowledge in Unix.
There are changes that would need testing on all platforms. There are also many changes that should not be an issue between platforms. Dave's back porting of 32016 Copro is an example of a complex change that should just work on all platforms.
I don't think you're understanding me -- perhaps I'm not being clear, so I'll try again: Unless someone wants to maintain the windows-side of this project, I will be making changes whereby functionality either won't exist, or will be completely broken, or even removed, because I cannot work with Windows. I understand there's testing involved, sure, that's the least concern.

User avatar
pstnotpd
Posts: 393
Joined: Wed Jan 20, 2010 11:05 am
Contact:

Re: B-Em

Post by pstnotpd » Wed Feb 22, 2017 1:57 pm

In the past I often succesfully built windows executables from unix sourcetrees. I'll have to check my development laptop how but I can sure give it a go this weekend.

EDIT: I used cygwin at the time.

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

Re: B-Em

Post by Coeus » Wed Feb 22, 2017 3:19 pm

ThomasAdam wrote:I don't think you're understanding me -- perhaps I'm not being clear, so I'll try again: Unless someone wants to maintain the windows-side of this project, I will be making changes whereby functionality either won't exist, or will be completely broken, or even removed, because I cannot work with Windows. I understand there's testing involved, sure, that's the least concern.
It maybe worth elaborating on what it is you propose to do. If you are thinking, for example, of a revamped GUI then if you were to use a toolkit that works on both Linux and Windows (and BSD) then it could continue to be compatible. I know both GTK+ and Qt claim to work on Windows. SDl also supports Linux and Windows.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 22, 2017 4:53 pm

Coeus wrote:
ThomasAdam wrote:I don't think you're understanding me -- perhaps I'm not being clear, so I'll try again: Unless someone wants to maintain the windows-side of this project, I will be making changes whereby functionality either won't exist, or will be completely broken, or even removed, because I cannot work with Windows. I understand there's testing involved, sure, that's the least concern.
It maybe worth elaborating on what it is you propose to do. If you are thinking, for example, of a revamped GUI then if you were to use a toolkit that works on both Linux and Windows (and BSD) then it could continue to be compatible. I know both GTK+ and Qt claim to work on Windows. SDl also supports Linux and Windows.
I appreciate I am lacking the examples, but the best one I have right now is moving away from using liballegro to SDL. I say SDL because it has a number of features that would benefit the GUI on both Linux, Windows, etc., that frankly, allegro suffers to do across different platforms, and that I think an emulator like b-em will benefit from that GTK and QT don't offer (hardware acceleration, sound, etc). Furthermore, SDL is very well supported; the jump from allegro4 to allegro5 has some work, but there's the point that I don't believe it's the best library to keep using.

The transition from allegro4 to SDL, for instance, will mean that I might be able to put a "best guess" in terms of where I think the appropriate SDL library calls are meant to go on Windows (inferred by what's there now for allegro), but I would have no means to test this -- and even if that's OK, it's going to require someone with that knowledge to ensure the appropriate changes are made -- this is going to cause an amount of desync which I'm uncomfortable with.

But we'll see -- I am not there yet with such a change, but it's worth pointing out the risks involved.

-- Thomas

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: B-Em

Post by paulb » Wed Feb 22, 2017 5:00 pm

pstnotpd wrote:In the past I often succesfully built windows executables from unix sourcetrees. I'll have to check my development laptop how but I can sure give it a go this weekend.

EDIT: I used cygwin at the time.
I've rarely needed to build stuff for Windows, thankfully, but I did successfully use MXE on a Qt-based project a couple of years or so ago. That's a cross-compiling toolchain that runs on GNU/Linux and other Free Software platforms, so you don't even need to touch Windows for building purposes. Then, only testers are needed, which shouldn't be a problem if there is supposedly a demand for Windows versions.

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

Re: B-Em

Post by Coeus » Wed Feb 22, 2017 5:37 pm

ThomasAdam wrote:I appreciate I am lacking the examples, but the best one I have right now is moving away from using liballegro to SDL....I might be able to put a "best guess" in terms of where I think the appropriate SDL library calls are meant to go on Windows (inferred by what's there now for allegro), but I would have no means to test this...
In the case of port to SDL that seems perfectly reasonable. You would code to the SDL API and test on Linux/BSD and someone else can test that it also works on Windows and fix it if it doesn't.

That's a far cry from, for example, deciding to re-write the video output code to talk direct to a Wayland compositor and then hope that someone would produce a parallel, equivalent module that works with Direct X to do the same thing for Windows.

On the choice of SDL to replace Allegro 4 I had a quick look at the documentation and what is missing is the kind of thing usually provided by a GUI toolkit, i.e. things like menus, file selection dialogs etc. Unlike Windows, there is no built-in API for these things on Linux hence GTK+, Qt etc. There are others too and the BeebEm Linux port uses SDL and has a working GUI so it must be possible. It will be part of the task of porting from Allegro4 to SDL, though, because Allegro4 does provide the framework for the existing menus on Linux, though I don't particularly like it - it is ugly compared to a modern GUI and busy waits as soon as you click on a menu.

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

Re: B-Em

Post by Coeus » Wed Feb 22, 2017 5:47 pm

Coeus wrote:...the BeebEm Linux port uses SDL and has a working GUI so it must be possible.
And checking the BeebEm source it seems it uses GTK+2 for the GUI on Linux so it seems this will work with SDL. I wonder if the same is true of GTK+3.

User avatar
Rich Talbot-Watkins
Posts: 1420
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: B-Em

Post by Rich Talbot-Watkins » Wed Feb 22, 2017 6:16 pm

It's a constant source of annoyance for me that there's not a good lightweight cross-platform widgets library. SDL, GLFW and SDML don't attempt to go further than just provide a simple window with a canvas, so for me the next step up is something enormous like wxWidgets or Qt, which is just far too much for something like this, where the UI is incidental to the main application, rather than forming the entire foundation of it.

Incidentally I would go with something like GLFW + OpenGL, rather than SDL. If you go straight to OpenGL, this opens up the possibility to use shaders to perform various special effects, such as screen distortion, colour bleeding, that kind of thing :)

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 22, 2017 6:24 pm

It's something I'll evaluate.

tom_seddon
Posts: 261
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: B-Em

Post by tom_seddon » Wed Feb 22, 2017 6:56 pm

I've had good results with dear imgui (Emscripten-powered online demo) - it's got a slightly unusual programming model compared to the more traditional MFC/Qt/wxWidgets/etc. type of library, and it doesn't do native widgets, but I've found it to work well, and as non-native widgets go they're not objectionable. It's also deliberately coded to make it easy to integrate, which is nice - "proper" GUI libraries have a tendency to want to take things over somewhat...

You do need some way of rendering 3D data efficiently, though: it doesn't do any drawing itself, instead producing index/vertex data for submitting to a GPU. No problem if you can access D3D/OpenGL/etc. (Don't know about Allegro, but SDL, which I've been using, has rather inflexible accelerated rendering support. There's no official fix for this (yet?) but there's some DIY stuff available from the relevant bug report, that I've been using with no obvious problems: https://bugzilla.libsdl.org/show_bug.cgi?id=1734)

The only thing that really, super bothers me about non-native GUI libraries is non-native file dialogs, which are always amazingly lame. I'm using NOC to fix this - one of its components being a single-header native file dialogs library. (The link there is to my fork of it, which fixes a couple of bugs and adds support for folder browser dialogs on Windows.)

--Tom

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

Re: B-Em

Post by tricky » Wed Feb 22, 2017 7:01 pm

Would WINE work for testing the windows version? - I've not used linux in over 20 years.

I'm not saying use it, but Qt does have both sound and hardware accelerated graphics and has supported GL for at least 7 years.

I'm also not saying use it, but VisualStudio does offer a cross platform protect type which you program in GLes and on windows it uses an internal version of Google's ANGLE to convert it to DirectX.

I would say that a VisualStudio projects and solution is, in my opinion, by far the best way to develop on windows, but I have been using it for over 20 years (note the correlation ;))

Even though I spend quite a bit of time developing for the beeb, I still use VS and beebasm (BEst Ever Beeb ASseMbler), although I admit that VS is overkill here if you don't already use it.

Sorry, I'll try to contain myself.
Whatever you decide, I will still make a local VS setup for the quick debugging hacks that I need.

PS The beeb emulator that I wrote 23 years ago used DrawDibDraw, joyXXX and waveXXX, (before I ported it to java) and I would probably still use that if I rewrote it today :lol: That reminds me, somewhere I have a tiny games framework which uses that old code :lol:

User avatar
pstnotpd
Posts: 393
Joined: Wed Jan 20, 2010 11:05 am
Contact:

Re: B-Em

Post by pstnotpd » Wed Feb 22, 2017 7:13 pm

Wine worked fine for BeebEm windows but admittedly that was in ye olden XP days.

Using it as a verification platform would be stretching it in my view.
I used to have an Ubuntu development machine but switched to VM's on an OEM W7 laptop.

Actually I don't care either way. I was surprised that I got BeebEm compiling on VS that easily.

B.t.w. if I remember correctly DirectX under wine doesn't work.

User avatar
Rich Talbot-Watkins
Posts: 1420
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: B-Em

Post by Rich Talbot-Watkins » Wed Feb 22, 2017 7:19 pm

tom_seddon wrote:I've had good results with dear imgui (Emscripten-powered online demo)
I've tried imgui, but it's no good if you want real dialogs and so on, as it can only overlay your existing canvas. When I've wanted to be able to spawn separate windows for debuggers, disassemblers, etc, there just seems to be no better option than wxWidgets or Qt (and I've always gone for the former as it's totally native, and the latter is super intrusive, with its need for a custom build step). If anyone knows of a better option, I'd love to know.
tom_seddon wrote:The only thing that really, super bothers me about non-native GUI libraries is non-native file dialogs, which are always amazingly lame. I'm using NOC to fix this - one of its components being a single-header native file dialogs library. (The link there is to my fork of it, which fixes a couple of bugs and adds support for folder browser dialogs on Windows.)
Yep, that also totally gets me. I had hopes for FLTK until I saw its file dialogs :(

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

Re: B-Em

Post by Coeus » Wed Feb 22, 2017 7:46 pm

Rich Talbot-Watkins wrote:I've tried imgui, but it's no good if you want real dialogs and so on, as it can only overlay your existing canvas. When I've wanted to be able to spawn separate windows for debuggers, disassemblers, etc, there just seems to be no better option than wxWidgets or Qt (and I've always gone for the former as it's totally native, and the latter is super intrusive, with its need for a custom build step). If anyone knows of a better option, I'd love to know.
Except on Linux (and other Unix-like systems except MacOS), at a technical level, there really is no such thing as a native dialog or native widget. These started out as text-only OSes and graphics was implemented as a layer on top based around X11. GUI Widgets have always been client-side in X11, i.e. drawn by the application in whichever way it chooses. There have been various toolkits for providing widgets and dialogs over the years including the Athena widgets, the X toolkit (Xt) widgets, Motif, GTK, Qt, FLTK and probably others too.

What that means in practice is that what the user views as a "native" widget is one in the sytle he is used to seeing and that depends on what desktop environment he is using of which there are several choices: GNOME, KDE, LXDE, Cinamon, Xfce etc. There has been an effort between GNOME and KDE to develop common styles so that widgets from GTK+ apps and those from Qt apps look the same, even if implemented differently.

On Linux wxWidgets seems to be implemented on top of GTK+2.

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

Re: B-Em

Post by Coeus » Wed Feb 22, 2017 8:04 pm

On the question of toolkit "weight" how does vxWidgets weight-in?

Qt was menioned as heavyweight earlier but if you;re targetting the regular Linux desktop then both Qt and GTK+ are likely to be installed already and maybe even in memory already depending on what else is running. If people want to run B-Em on a Raspberry Pi, though, that may niot be the case and these may indeed be a bit heavy.

Back to the question of SDL for the emulated BBC screen and sound etc. with a separate GUI toolkit for the menus, file selections etc. it seems SDL and the GUI toolkits don't play that well together. There are two issues:

Visual Integration

What you'd ordinarily expect is an application which has the usual menu bar at the top and where the emulated BBC outputs to the usual content area below the menu with maybe the option of a full-screen mode where the menu bar disappears. That seems difficult to do with SDL and a GUI toolkit because SDL expects to own the window. Under X11 specifically that area of the screen may indeed be a separate window (a window within a window) and one can use a hack to feed that window ID to SDL but this isn't very portable.

This almost certainly explans why, on Linux, BeebEm does not adopt that style but instead has a separate GUI window that pops up when you press a key (F11?).

Input Events

Again it seems SDL and the GUI toolkit both expect to own the event loop. The approach BeebEm seems to take to this is that GTK (the GUI toolkit) gets to handle the events when the GUI is displayed. When the GUI is dismissed event handling returns to SDL.

tom_seddon
Posts: 261
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: B-Em

Post by tom_seddon » Wed Feb 22, 2017 8:36 pm

I used wxWidgets for model-b and I thought it was OK. A bit crufty in places, and it does expect to own your program, but it was easy to build from source, and they also seem to take long-term compatibility at least somewhat seriously. (In 2013 I got model-b building again, 10 years on, with updated wxWidgets, and while a few changes were necessary it didn't take long at all. Also looked like they'd done some work on making the wxWidgets container types - string, array, list, etc. - play nicely with the STL, which was something that annoyed me a bit about the older versions.)

Regarding using your own windows, SDL has SDL_CreateWindowFrom, but I've never tried to use it. The documentation is suspiciously brief, making me suspect that while you'll probably be able to make it work, you'll be spending a fair amount of time trawling through other people's code on your way there ;)

On Windows, at least, it looks like it does the right thing as far as subclassing the wndproc goes, but it still seems to push events to the SDL event queue - maybe they expect you to just disable all SDL events, or something? Maybe you still need to use the SDL event queue? (That's what the example code does. This is the sort of thing I mean about the overly brief documentation!) I suppose you'll need a bit of platform-specific code to set this up, but hopefully it would end up all fairly localized.

--Tom

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

Re: B-Em

Post by tricky » Wed Feb 22, 2017 8:52 pm

Does the Windows GUI need changing?

If anyone is building on windows, you may also like to:

I also changed the x_open to Abort/Retry/Ignore locally and changes the places where failing was already handled to fopen:

Code: Select all

\b-em-master\src\adf.c(32):        adf_f[drive] = fopen(fn, "rb+");
\b-em-master\src\adf.c(35):                adf_f[drive] = fopen(fn, "rb");
\b-em-master\src\adf.c(65):        adf_f[drive] = fopen(fn, "rb+");
\b-em-master\src\adf.c(68):                adf_f[drive] = fopen(fn, "rb");
\b-em-master\src\adf.c(88):        adf_f[drive] = fopen(fn, "rb+");
\b-em-master\src\adf.c(91):                adf_f[drive] = fopen(fn, "rb");
\b-em-master\src\arm.c(210):        f=fopen(fn,"rb");
\b-em-master\src\cmos.c(70):                f=fopen(fn, "rb");
\b-em-master\src\compactcmos.c(41):        cmosf = fopen(fn, "rb");
\b-em-master\src\csw.c(34):        csw_f = fopen(fn,"rb");
\b-em-master\src\disc.c(81):        f=fopen(fn, "rb");
\b-em-master\src\fdi.c(68):        fdi_f[drive] = fopen(fn, "rb");
\b-em-master\src\ide.c(41):                hdfile[0] = fopen(s, "rb+");
\b-em-master\src\ide.c(53):                hdfile[1] = fopen(s, "rb+");
\b-em-master\src\ssd.c(30):        ssd_f[drive] = fopen(fn, "rb+");
\b-em-master\src\ssd.c(33):                ssd_f[drive] = fopen(fn, "rb");
\b-em-master\src\ssd.c(50):        ssd_f[drive] = fopen(fn, "rb+");
\b-em-master\src\ssd.c(53):                ssd_f[drive] = fopen(fn, "rb");
\b-em-master\src\win.c(960):	if (!(fd = fopen(file, mode)))

Code: Select all

FILE * x_fopen(const char * file, const char * mode)
{
	FILE * fd;
retry:;
	if (!(fd = fopen(file, mode)))
	{
		switch (MessageBoxA(NULL, file, "Failed to open file:", MB_ABORTRETRYIGNORE))
		{
			case IDABORT : exit(1);
			case IDRETRY : goto retry;
//			case IDIGNORE: if (IsDebuggerPresent()) DebugBreak(); break;
		}
	}
	return fd;
}
And \b-em-master\src\b-em.rc

Code: Select all

   PUSHBUTTON "CTL", Button1+KEY_CAPSLOCK, 28, 56, 16, 15 , WS_TABSTOP
to
   PUSHBUTTON "CTL", Button1+KEY_LCONTROL, 28, 56, 16, 15 , WS_TABSTOP
and

Code: Select all

   PUSHBUTTON "CTRL", Button1+KEY_CAPSLOCK, 28, 56, 16, 15 , WS_TABSTOP
to
   PUSHBUTTON "CTRL", Button1+KEY_LCONTROL, 28, 56, 16, 15 , WS_TABSTOP
and finally

Code: Select all

   PUSHBUTTON "#", Button1+KEY_0_PAD, 332, 24, 16, 15 , WS_TABSTOP
to
   PUSHBUTTON "#", Button1+KEY_NUMLOCK, 332, 24, 16, 15 , WS_TABSTOP
\b-em-master\src\win.c
fixed the setting speed changes emulated platform

Code: Select all

                       emuspeed = curmodel = LOWORD(wParam) - IDM_SPD_10;
to
                        emuspeed = LOWORD(wParam) - IDM_SPD_10;

commented out the aluInit and aluExit as they don't seem to exist

Code: Select all

void al_init_main(int argc, char *argv[])
{
//        alutInit(0, NULL);//&argc, argv);
        check();
//        atexit(closeal);
//        printf("AlutInit\n");
}

void al_close()
{
//        alutExit();
}

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 23, 2017 8:11 am

tricky wrote:Does the Windows GUI need changing?

If anyone is building on windows, you may also like to:
Thanks, Tricky. Some of the changes you're suggesting look good, but rather than paste the code, can you please submit a pull-request or at least email me a unified diff? It's tricky (:-)) to handle code changes in the way you're suggesting, directly in forum posts.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 23, 2017 11:49 am

Thanks all for your comments and ideas around different GUI toolkits, etc.

What I am surprised by is the direction the conversation has taken. It's nice to talk about UI toolkits, etc., but on the point about my not being able to support Windows development, no one has mentioned to me that they're concerned, or that they want to help maintain that, etc. In fact, what I'm hearing is that it's not a problem.

I find that rather interesting.

User avatar
davidb
Posts: 2334
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: B-Em

Post by davidb » Thu Feb 23, 2017 11:58 am

Throwing in a quick suggestion late in the discussion: I'd consider using something minimal and cross-platform for the core display, audio and I/O functionality, and add hooks to allow front-ends to be written in whatever toolkit/framework people want.

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

Re: B-Em

Post by Coeus » Thu Feb 23, 2017 1:03 pm

tricky wrote:I also changed the x_open to Abort/Retry/Ignore locally...
I notice in the code you have commented out the ignore case which is the right thing to do as ignoring the error and returning a NULL pointer to code that expects to carry out I/O on it will cause a crash.

The MessageBox function is Windows specific. The are a couple of ways round this:

1. Use an allegro messagebox function insteadm (assuming such exists).
2. Move your implementation of x_fopen into win.c so it is only compiled on Windows and put Thomas's implementation into linux.c so it is only compiled on Linux.
tricky wrote:and changes the places where failing was already handled to fopen:
Good idea.
tricky wrote:And \b-em-master\src\b-em.rc
Presumably it is not a co-incidence that the caps lock key, referred to in those keybindings, is in the same physical location as the control key is on a real BBC micro. I don't know for sure if you are changing things to the control key on the PC keyboard performs the control function or other other way round, i.e. making the caps lock key on the PC keyboard perform control. If the former I'd bet that someone set the bindings up that way deliberately so someone used to the BBC micro keyboard would be at home. BeebEm apparently has the option to switch between logical, i.e. functions match keycaps, and physical, i.e. keys perform according to the equivelent key on the BBC's keyboard, mappings.
tricky wrote:commented out the aluInit and aluExit as they don't seem to exist
Are they actually spelt that way? I think they should be alutInit and alutExit.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 23, 2017 1:16 pm

Coeus wrote:2. Move your implementation of x_fopen into win.c so it is only compiled on Windows and put Thomas's implementation into linux.c so it is only compiled on Linux.
Another way of handling this is to try and do away with #ifdef all over the place, and have a set of compatibility files between Windows/Linux/BSD which are detected at ./configure time. That way, we can build up a set of function calls which work for both as required. I'll add this to the TODO file.

Post Reply