Building B-em with Visual studio

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 6:25 am

I run Visual Studio 2017, predominantly for C# development but recently tried to get B-em building in that environment. Here is my story so far.

I cloned the master from GitHub using Visual Studio to create the solution/project on my machine. After doing so Visual Studio complained about the project being targeted to an older SDK and build tool chain studio that I install the 2010 build tools, SDK or Visual Studio 2010 itself.

Having 2017 I downloaded the 2010 build tools and attempted to install them but they complained that VS2010 was a prerequisite so I ended up installing the entire thing. VS2010 and VS2010 no longer complain about the build tools. Yay.

Next, allegro is missing. So read the info, go to Nuget and install Allegro 5.2.2.0 to avoid compatibility issues with the later versions.

Next, despite installing Allegro using Nuget, the linker can't find several files so I add the Allegro paths to the project.

Next, VS complains about inttypes.h being missing. Well, this one is fun. inttypes.h is included with VS2013 and above, so the code is definitely VS2010 build tool specific, this should be fine though as VS2017 is still set to use the 2010 build tools.

However, I can only find inttypes.h in a 2017 specific folder when I search my entire drive for the file.

If I configure the include paths to use that, I get over 3300 syntax errors during the build rooted in alplat.h but related to inttypes.h. Understandable because it's the 2017 inttypes.h file.

So clearly I need to include inttypes.h and related files that are suitable for the 2010 build tools but where from???

Any advice is more than welcome.

Paul

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

Re: Building B-em with Visual studio

Post by tricky » Thu Oct 11, 2018 7:29 am

There have been a couple of threads about building b-em with visual studio, and it wasn't straight forward.
If you don't get an answer, I can check tonight what changes I have that are to allow it to build, but thinking about it, it is probably based on an older version of b-em.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 11:19 am

tricky wrote:
Thu Oct 11, 2018 7:29 am
There have been a couple of threads about building b-em with visual studio, and it wasn't straight forward.
Yes, I've read through them but it seems that Visual Studio is somewhat unpredictable due to the level of configuration it allows in the environment. For my environment it's predominantly configured for the development of C# applications and I've had to retrofit the C/C++ build tools to VS 2017, then install VS2010 just to get the right version of the build tools for VS2017 to use. Just having to have two instances of VS on the machine is a pain as the machine only has a finite amount of SSD drive space and VS2010 plus its service packs just took another huge chunk of space :-o
tricky wrote:
Thu Oct 11, 2018 7:29 am
If you don't get an answer, I can check tonight what changes I have that are to allow it to build, but thinking about it, it is probably based on an older version of b-em.
Thanks, that would be great. I'm 90% sure that I've got all the right tools and parts installed now and that it's just configuration and availability of the correct pieces of source code to make it build-able it's just the setting up of a sound build environment that can reliably build an executable for me that I need so even if you're using an older version of the source, as long as it's Allegro 5 rather than 4, any configuration info should be helpful.

Paul

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

Re: Building B-em with Visual studio

Post by tricky » Thu Oct 11, 2018 11:28 am

I know that I tried the allegro 5 build, but I might have just ported the new emulator bits back to the v4 build.
At one point I removed allegro etc and moved evrything to directx, but I think I fixed my issue and never quite finished the port.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 12:40 pm

Well, it seems inttypes.h being an issue for Visual Studio is a known one...

https://stackoverflow.com/questions/132 ... ound-error

In fact, the issue is far deeper than just inttypes.h as other type definitions are also missing for VS2010 which are required by B-em.

This apparently stems from VS 2010 only supporting the C89 standard where these standard type definitions are part of the C99 specification which VS2013 and above should support but apparently, it still has issues :-/

Would it be a sensible idea to try to put together a VS2017 project/solution rather than restrict it to VS2010 to hopefully give B-em more of a chance of compiling under VS without all the faff? Certainly a simple re-targeting of the source to the latest C/C++ build tools under VS doesn't solve the issue of being able to build B-em under VS so more work would be required.

It would it be easier to install yet another compiler/build environment such as MinGW to be able contribute I guess.

Paul

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 2:00 pm

Bear with me because my C/C++ is mega-rusty at the moment :oops: :shock:

Just playing about with re-targeting the VS2010 project to VS2017 to get around all the C99 requirements reduces the number of errors significantly and the build only has a handful of errors left to deal with when attempting to build the project.

The first error is to do with concatenating defined strings:

Code: Select all

#define VERSION_STR "B-em v-" VERSION
This causes syntax errors throughout the rest of the code because it seems VS can't concatenate a string with a defined string. Removing "VERSION" fixes the issue but clearly misses the point of doing it in the first place!

The second error is a bit more problematic and regards code that looks like this:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    void *ptr = region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
        ptr += region->pixel_size;    
    }
}
data where referenced is declared as void *data;

There are two "errors" in this code according to the compiler which are:

Code: Select all

void *ptr = region->data + region->pitch * y + x * region->pixel_size;
and

Code: Select all

ptr += region->pixel_size;
Where ptr and region->data are essentially of unknown size and need to be cast to a type in order for the compiler to build. The original code is perfectly legal under GCC but VS clearly doesn't have a similar extension to allow it to build without modification. With that in mind, searching around reveals that the apparent fix for VS is to replace the code with the following:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    void *ptr = (char *)region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
	(char *)ptr += region->pixel_size;
    }
}
Are there any reasons why that wouldn't be a viable fix that allows GCC to compile as normal?

If I apply that fix where appropriate (6 places in the code) I'm left with just 6 errors to deal with, all of which are simple file not found errors for source code that is referenced but excluded/missing from the project because they're referenced but seemingly ripped our of the project, the files being:

Code: Select all

Severity	Code	Description	Project	File	Line	Suppression State
Error	C1083	Cannot open source file: 'win-keydefine.c': No such file or directory
Error	C1083	Cannot open source file: 'win-catalogue.c': No such file or directory
Error	C1083	Cannot open source file: 'ssd.c': No such file or directory	b-em
Error	C1083	Cannot open source file: 'soundopenal.c': No such file or directory
Error	C1083	Cannot open source file: 'adf.c': No such file or directory
Error	C1083	Cannot open source file: '32016.c': No such file or directory
Should any or all of these files be restored to the project or is it safe to rip the references out?

Paul

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

Re: Building B-em with Visual studio

Post by Coeus » Thu Oct 11, 2018 3:02 pm

paulv wrote:
Thu Oct 11, 2018 2:00 pm
The first error is to do with concatenating defined strings:
That is using the C compiler concatenation syntax rather than the pre-processor syntax and obviously the GNU pre-processor must be defining VERSION_STR to be both tokens and inserting both tokens as the replacment text wherever the macro appears, thus giving the compiler a chance to do the concatenation.

You could try:

Code: Select all

#define VERSION_STR ## "B-em v-" VERSION
using the pre-processor concatenation syntax but it may cause a problem is there is no space between the two parts. If that doesn't work it may be better to use VERSION wherever VERSION_STR appears and then change the script than generates the #define for VERSION to include the "B-Em".
paulv wrote:
Thu Oct 11, 2018 2:00 pm
The second error is a bit more problematic and regards code that looks like this:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    void *ptr = region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
        ptr += region->pixel_size;    
    }
}
...With that in mind, searching around reveals that the apparent fix for VS is to replace the code with the following:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    void *ptr = (char *)region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
	(char *)ptr += region->pixel_size;
    }
}
I'll see if that compiles on gcc. Hopefully it will. When you say six occurrences are these all in video.c? Are they six distinct cases or does the compiler just complain about this inline function everywhere it expands it?
paulv wrote:
Thu Oct 11, 2018 2:00 pm
If I apply that fix where appropriate (6 places in the code) I'm left with just 6 errors to deal with, all of which are simple file not found errors for source code that is referenced but excluded/missing from the project because they're referenced but seemingly ripped our of the project, the files being:

Code: Select all

Severity	Code	Description	Project	File	Line	Suppression State
Error	C1083	Cannot open source file: 'win-keydefine.c': No such file or directory
Error	C1083	Cannot open source file: 'win-catalogue.c': No such file or directory
Error	C1083	Cannot open source file: 'ssd.c': No such file or directory	b-em
Error	C1083	Cannot open source file: 'soundopenal.c': No such file or directory
Error	C1083	Cannot open source file: 'adf.c': No such file or directory
Error	C1083	Cannot open source file: '32016.c': No such file or directory
Should any or all of these files be restored to the project or is it safe to rip the references out?

Paul
These modules can go. The definitive set for the Windows build are in Makefile.win. The win-keydefine.c and win-catalogue.c are re-placed with allegro versions of the same in order to get the same features on Linux. ssd.c and adf.c are both replaced by sdf.c which does everything they did plug double-density formats. 32016.c is replaced by a whole sub-directory of 32016 code. soundopenal.c is no longer used as Allegro 5 has sound support.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 3:37 pm

Coeus wrote:
Thu Oct 11, 2018 3:02 pm
That is using the C compiler concatenation syntax rather than the pre-processor syntax and obviously the GNU pre-processor must be defining VERSION_STR to be both tokens and inserting both tokens as the replacment text wherever the macro appears, thus giving the compiler a chance to do the concatenation.

You could try:

Code: Select all

#define VERSION_STR ## "B-em v-" VERSION
I'd already tried

Code: Select all

#define VERSION_STR "B-em v-" ## VERSION
which didn't work either but I'd not tried what you've suggested, unfortunately starting with a leading ## throws VS into fits!
Coeus wrote:
Thu Oct 11, 2018 3:02 pm
I'll see if that compiles on gcc. Hopefully it will. When you say six occurrences are these all in video.c? Are they six distinct cases or does the compiler just complain about this inline function everywhere it expands it?
There are four instances of the error in video.c and two in pal.c with the fix in pal.c as below

Code: Select all

static inline int get_pixel(ALLEGRO_LOCKED_REGION *region, int x, int y)
{
    return *((uint32_t *)((char *)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 *)((char *)region->data + region->pitch * y + x * region->pixel_size)) = colour;
}
Coeus wrote:
Thu Oct 11, 2018 3:02 pm
These modules can go. The definitive set for the Windows build are in Makefile.win. The win-keydefine.c and win-catalogue.c are re-placed with allegro versions of the same in order to get the same features on Linux. ssd.c and adf.c are both replaced by sdf.c which does everything they did plug double-density formats. 32016.c is replaced by a whole sub-directory of 32016 code. soundopenal.c is no longer used as Allegro 5 has sound support.
I thought as much and have already removed them from the "project".

After all that the project was referencing some lib files that are missing like "alleg.lib" instead of "allegro.lib" and "zlib.lib". Once I sorted out all the paths, I managed to progress quite a bit so I'm now dealing with some linker errors which seem a little odd to say the least... They're all essentially the same and of the ilk

Code: Select all

_timetolive already defined in 6502.obj	\src\6502.obj.obj
This error is documented here

https://docs.microsoft.com/en-us/cpp/er ... ew=vs-2017

Which seems to indicate that things are declared more than once and offers some solutions including
Declare the variable extern in the header file:

extern int global_int;

then define it and optionally initialize it in one and only one source file:

int global_int = 17;

This variable is now a global that you can use in any source file by declaring it extern, for example, by including the header file. We recommend this solution for variables that must be global, but good software engineering practice minimizes global variables.
Looking at timetolive in 6502.h and 6502.c this is exactly what is happening so I'm puzzled as to why it's throwing the error at all...

Paul

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

Re: Building B-em with Visual studio

Post by tom_seddon » Thu Oct 11, 2018 4:57 pm

String concatenation with #defines definitely works in VC++, as this is how inttypes.h operates. (See, e.g., https://github.com/tom-seddon/b2/blob/e ... 2.cpp#L156)

If VERSION is defined on the command line, might it be coming through not as a string? It looks like I had to stringize a command line #define in one place in my emulator (https://github.com/tom-seddon/b2/blob/e ... b2.cpp#L56), so I wonder whether this is something to do with how the compiler and/or IDE handles command line defines. I don't remember the exact details offhand though :(

--Tom
Last edited by tom_seddon on Thu Oct 11, 2018 4:57 pm, edited 1 time in total.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 4:59 pm

Looking at timetolive in 6502.h and 6502.c this is exactly what is happening so I'm puzzled as to why it's throwing the error at all...
Using /FORCE:MULTIPLE on the linker command line solves the issue with duplicate declaration which seem to be spurious errors looking at the code itself.

It seems that there have been a tonne of files added to the project since the VS project was last used in anger and put into source control.

I've purposely excluded any files starting with the filename "linux" but included all the files that were missing from the project definition so they now get built.

Doing this has revealed vdfs.c and tsearch.c as being problematic for VS with several "syntax errors" being present...

tsearch doesn't appear to have a header file in the project and the following variables it uses are undefined:

VISIT
leaf
preorder
postorder
endorder

VDFS is also missing definitions for

VISIT
postorder
preorder
tree_visit_del
tree_visit_cat

which makes sense as it depends on tsearch.

Paul

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Thu Oct 11, 2018 5:02 pm

tom_seddon wrote:
Thu Oct 11, 2018 4:57 pm
String concatenation with #defines definitely works in VC++, as this is how inttypes.h operates. (See, e.g., https://github.com/tom-seddon/b2/blob/e ... 2.cpp#L156)

If VERSION is defined on the command line, might it be coming through not as a string? It looks like I had to stringize a command line #define in one place in my emulator (https://github.com/tom-seddon/b2/blob/e ... b2.cpp#L56), so I wonder whether this is something to do with how the compiler and/or IDE handles command line defines. I don't remember the exact details offhand though :(

--Tom
The issue appears to be the concatenation of one #define into another #define that causes issues for VS.

Paul

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

Re: Building B-em with Visual studio

Post by tricky » Thu Oct 11, 2018 6:05 pm

I've just been looking at what I was doing and it was taking the pre2 version and converting it to DirectX (to remove allegro).
I was doing this because I want to build from a project and solution (not cmake) and only want it for windows.
I think the problem with VERSION is as suggested in that it doesn't exist, it should concatenate fine as long as it has "s around it.
If you don't use cmake, I think you will struggle with allegro unless there is a built version that I have missed.
Sorry, it doesn't look like I will be much help and will personally be sticking with my allegro4/VS version for local hacking.

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

Re: Building B-em with Visual studio

Post by Coeus » Fri Oct 12, 2018 12:21 am

paulv wrote:
Thu Oct 11, 2018 3:37 pm
There are four instances of the error in video.c and two in pal.c with the fix in pal.c as below
gcc was happy with the fix for the most part except casting a pointer to which += is to be applied - it complaint the cast pointer is no longer an lvalue. So, I tried this, which works in gcc, does it work in VS:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    char *ptr = (char *)region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
        ptr += region->pixel_size;
    }
}
i could only find one definition of timetolive in the code so I am not sure why VS should complain about that either but as the only references that have not been commented out are in 6502.c I have tried making it static instead and removing the declaration from 6502.h B-Em still compiles like that (with gcc on Linux) so see if that helps.

I had intended to push these changes to a branch but accidentally pushed to master.

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

Re: Building B-em with Visual studio

Post by tricky » Fri Oct 12, 2018 7:03 am

In nearly all cases, one type shouldn't be cast to another where the desired is to use the same bit pattern for two different things.
The "correct" way to do it is to have a union with both in and then use the member that does what you want when you want it.

VectorEyes
Posts: 165
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: Building B-em with Visual studio

Post by VectorEyes » Fri Oct 12, 2018 9:44 am

tricky wrote:
Fri Oct 12, 2018 7:03 am
In nearly all cases, one type shouldn't be cast to another where the desired is to use the same bit pattern for two different things.
The "correct" way to do it is to have a union with both in and then use the member that does what you want when you want it.
Or use reinterpret_cast!

EDIT: Actually ignore that, my memory was faulty. Apparently the only genuinely official way to take one object and reinterpret its bits as a different type is to either use std::memcpy of std::bit_cast. Which I'd never heard of before, presumably because it's very, very new (C++20)…. :)
Last edited by VectorEyes on Fri Oct 12, 2018 9:52 am, edited 1 time in total.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 12:10 pm

Given the latest build errors with VDFS at the moment and its dependency on GNU code libraries for certain things that VS refuses to build without significant modification, I'm beginning to think that the ability to build using VS is a non starter.

As such, I'm going to remove VS2010 because I don't need it for anything else (thereby recovering > 10GB of drive space) and install MinGW as the tool chain to allow me to build and contribute to B-em.

Paul

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

Re: Building B-em with Visual studio

Post by Coeus » Fri Oct 12, 2018 12:54 pm

paulv wrote:
Thu Oct 11, 2018 4:59 pm
...Doing this has revealed vdfs.c and tsearch.c as being problematic for VS with several "syntax errors" being present...

tsearch doesn't appear to have a header file in the project and the following variables it uses are undefined:

VISIT
leaf
preorder
postorder
endorder
The history behind this is that there is usually an implementation of a binary tree search in the standard C library on Unix-like systems and the declarations are in search.h. The local tsearch.c file got included in the project because one of our members was trying to compile it on BSD, which doesn't have the tdestroy function. tsearch.,c is conditionally included and is a complete implementation, rather than just the missing tdestroy function as all functions have to work with a consistent internal format. We didn't need to include the declarations for the enum and functions as these were still in search.h

So, for VS, i.e. a MS, rather than GNU, standard C library we'd need to include the missing enumeration:

Code: Select all

/* For tsearch */
typedef enum
{
  preorder,
  postorder,
  endorder,
  leaf
}
VISIT;
as well as function declarations if these are also not present.
Last edited by Coeus on Fri Oct 12, 2018 12:56 pm, edited 1 time in total.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 2:44 pm

That helped somewhat.

I'm now onto mapping some GNU functions to MSC versions

such as

Code: Select all

#ifdef _MSC_VER 
#include <intrin.h>
#define __builtin_ctz __lzcnt
#endif
and

Code: Select all

#ifdef _MSC_VER 
#define getc_unlocked _fgetc_nolock
#define putc_unlocked _fputc_nolock
#endif
Progress is slow but I think it's going in the right direction.

Paul

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 6:14 pm

Progress, I think.

It seems the linker is failing at the last stage now when trying to combine the object files with the resource file to build the exe.

When opening the b-em.rc file in Visual Studio, it gags because there are duplicates within the resource file.

Code: Select all

PUSHBUTTON "CLK", Button1+KEY_CAPSLOCK, 12, 56, 16, 15 , WS_TABSTOP
PUSHBUTTON "CTL", Button1+KEY_CAPSLOCK, 28, 56, 16, 15 , WS_TABSTOP
and

Code: Select all

PUSHBUTTON "CAPS", Button1+KEY_CAPSLOCK, 12, 56, 16, 15 , WS_TABSTOP
PUSHBUTTON "CTRL", Button1+KEY_CAPSLOCK, 28, 56, 16, 15 , WS_TABSTOP
and

Code: Select all

PUSHBUTTON "0", Button1+KEY_0_PAD, 284, 72, 16, 15 , WS_TABSTOP
PUSHBUTTON "#", Button1+KEY_0_PAD, 332, 24, 16, 15 , WS_TABSTOP
I think the two "CTL" and "CTRL" entries should be

Code: Select all

PUSHBUTTON "CTL", Button1+KEY_LCONTROL, 28, 56, 16, 15 , WS_TABSTOP
PUSHBUTTON "CTRL", Button1+KEY_LCONTROL, 28, 56, 16, 15 , WS_TABSTOP
In addition, should "CLK" and "CTL" be "CAPS" and "CTRL" for consistency.

As for the declaration of the Hash '#' key, I'm not sure what that should be set to. If I fix the CTRL key definitions and comment out the "#" key, I can open and edit the file in Visual Studio although it re-writes the thing entirely if you save it which makes life difficult...

On building though I get the following 2 errors:


Error CVT1100 duplicate resource. type:ICON, name:1, language:0x0809
Error LNK1123 failure during conversion to COFF: file invalid or corrupt

LNK1123 is a fatal error produced because the linker cannot find the COFF which is the file that should be created from the resource file. Clearly the resource file can't be converted to the COFF because there is a perceived duplicate.

If I re-order the resources in the res file, whatever declaration is first e.g. MAINMENU is the one that is cited in the CVT1100 error.

Clearly, there are no duplicates in the file so this is yet another VS config issue to dig into as even if I force the TypeLib Resource ID to be something other than 1 (e.g. /TLBID:2), the error occurs despite this being the answer on MS's own documentation about the error.

Paul

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 7:53 pm

More progress.

Going through the linker logs, I found that when the linker was running, the debug AND release folder paths were being passed to the linker so it was including *every* object file twice.

Excluding the debug and release folders from the project solved the duplicate issue and allowed me to remove the /FORCE:MULTIPLE command line parameter too.

The project now builds with just warnings and I can set breakpoints and trace through the code. At the moment, I've I run it without breakpoints, it gracefully dies but this is major progress in getting B-em to build under VS 2017.

:D

Paul

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

Re: Building B-em with Visual studio

Post by Coeus » Fri Oct 12, 2018 8:43 pm

paulv wrote:
Fri Oct 12, 2018 6:14 pm
It seems the linker is failing at the last stage now when trying to combine the object files with the resource file to build the exe.
Paul I don't think much of the resource file is used. The menu is created via Allegro which presumably does so dynamically rather than use these resources.

Now you've got this far it is probably worth checking out the _DEBUG - see logging.h for a description. That should help to see why it has exited early. Also check out the b-emlog.txt file which is, IIRC, at c:\users\you\AppData\roaming\b-em.exe
Last edited by Coeus on Fri Oct 12, 2018 8:49 pm, edited 1 time in total.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 8:49 pm

VS-Bem-NOSOUND.png
Well, I've managed to narrow down the source of the Access Violation to an external dll that is only triggered if the sound sub systems are enabled.

If I comment out all the sound related initialisation routines in main_init() and also any calls to sid_reset(), music4000_reset() and music5000_reset() then I'm up and running.

The issue appears to be occurring in a thread that is started somewhere in the allegro components.

The exception is:
Unhandled exception at 0x773395A8 in b-em.exe: 0xC0000005: Access violation executing location 0x00000000.
When I trace through sound_init(), the code runs fine and al_attach_audio_stream_to_mixer succeeds in attaching the stream to the mixer so I'm not entirely sure why the access violation occurs as everything that should work is working...

Has anyone had this sort of issue with Allegro before? I've got 5.2.2.0 installed via Nuget.

Paul

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

Re: Building B-em with Visual studio

Post by Coeus » Fri Oct 12, 2018 9:02 pm

paulv wrote:
Fri Oct 12, 2018 8:49 pm
Unhandled exception at 0x773395A8 in b-em.exe: 0xC0000005: Access violation executing location 0x00000000.
That suggests to me that something in Allegro has implemented a plugin/driver architecture where function pointers are stored in a struct so that functions can be dispatched that way, a bit like vtables bt hand, but in the case of the function being called that member is NULL.

I wonder if this is specific to any one of the three sound sources as these use different sample rates and thus each send data to Allegro separately. They are:
1. Music 5000
2. disc and tape noises
3. everything else.

Does disabling these on the settings menu make any difference. You may need to edit the b-em.cfg to get them to be off initially:

Code: Select all

[sound]
sndinternal=true
sndbeebsid=true
sndmusic5000=true
snddac=false
sndddnoise=true
sndtape=false
i.e. set these all to false. Once you started it at least once, the current config file should be in your roaming profile as per the log location above.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 9:06 pm

Coeus wrote:
Fri Oct 12, 2018 8:43 pm
Paul I don't think much of the resource file is used. The menu is created via Allegro which presumably does so dynamically rather than use these resources.

Now you've got this far it is probably worth checking out the _DEBUG - see logging.h for a description. That should help to see why it has exited early. Also check out the b-emlog.txt file which is, IIRC, at c:\users\you\AppData\roaming\b-em.exe
Ok, here's the b-emlog.txt. As you can see sound_init() starts but no more logging after that so it's not a great deal of help with this one :-(

Paul
Attachments
b-emlog.txt
(2.84 KiB) Downloaded 6 times

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Fri Oct 12, 2018 9:36 pm

Coeus wrote:
Fri Oct 12, 2018 9:02 pm
Does disabling these on the settings menu make any difference. You may need to edit the b-em.cfg to get them to be off initially:

Code: Select all

[sound]
sndinternal=true
sndbeebsid=true
sndmusic5000=true
snddac=false
sndddnoise=true
sndtape=false
i.e. set these all to false. Once you started it at least once, the current config file should be in your roaming profile as per the log location above.
No difference when I change the config file although I can see the settings are being picked up in load_config().

If I comment out all the audio init functions apart from sound_init() I still get the exception.

Interestingly, I've just tried using the menu to change a setting and that too causes a similar access violation. It doesn't matter which menu or option I choose and looking at the code it should be routing to void gui_allegro_event in gui_allegro.c but if I breakpoint the switch statement, it never gets there which would suggest as you said that allegro hasn't been initiated correctly.

I'm going to turn in for the night now but I'll pick it up again over the weekend.

Paul

VectorEyes
Posts: 165
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: Building B-em with Visual studio

Post by VectorEyes » Fri Oct 12, 2018 9:38 pm

Just wanted to say massive thanks for doing this. Being able to build and run B-Em under VS2017 would be great!

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Sat Oct 13, 2018 7:16 am

Coeus wrote:
Fri Oct 12, 2018 12:21 am
So, I tried this, which works in gcc, does it work in VS:

Code: Select all

static inline void put_pixels(ALLEGRO_LOCKED_REGION *region, int x, int y, int count, uint32_t colour)
{
    char *ptr = (char *)region->data + region->pitch * y + x * region->pixel_size;
    while (count--) {
        *(uint32_t *)ptr = colour;
        ptr += region->pixel_size;
    }
}
I forgot to mention, yes, it still builds with this code in VS :D

Paul

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Sat Oct 13, 2018 8:02 am

Ok, it's building in VS 2017 with sound and the menu's are working :D

The issue was configuration of the environment again. I needed to exclude the debug lib files in the Allegro folder that Nuget created.

https://youtu.be/LpfSbp3o44I

EDIT: No errors, No warnings...
NoE-NoW.png
Paul
Last edited by paulv on Sat Oct 13, 2018 8:15 am, edited 1 time in total.

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

Re: Building B-em with Visual studio

Post by tricky » Sat Oct 13, 2018 10:43 am

Well done. =D>
I don't know about the allegro v5 version, but the resources were used for the keyboard mapping dialogs with the v4.
What I was last doing was extending the memory activity window for a dialog with extra debug info, but I found that using the dialog editor caused the resource.h to not have all the necessary #defines.
The fix for this was to go to the resource tab, right click on the b-em.rc and in the resource includes option, add:

Code: Select all

#ifndef APSTUDIO_INVOKED
//#include "targetver.h"
#endif
#include "afxres.h"
#include "verrsrc.h"
to the "Read noly symbol directives" text box.
I know this doesn't fit with using allegro, but I was only hacking for my own windows use.
Now yo have got this working, I night be tempted to move to the v5 version.

User avatar
paulv
Posts: 3728
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Building B-em with Visual studio

Post by paulv » Sat Oct 13, 2018 12:08 pm

VectorEyes wrote:
Fri Oct 12, 2018 9:38 pm
Just wanted to say massive thanks for doing this. Being able to build and run B-Em under VS2017 would be great!
Thanks. I was just doing it for a bit of fun really and it'd be nice to contribute to the project if only in small ways here and there once in a while so having it build in the DevEnv I'm used to is a bonus :D
tricky wrote:
Sat Oct 13, 2018 10:43 am
Well done. =D>
I don't know about the allegro v5 version, but the resources were used for the keyboard mapping dialogs with the v4.
What I was last doing was extending the memory activity window for a dialog with extra debug info, but I found that using the dialog editor caused the resource.h to not have all the necessary #defines.
The fix for this was to go to the resource tab, right click on the b-em.rc and in the resource includes option, add:

Code: Select all

#ifndef APSTUDIO_INVOKED
//#include "targetver.h"
#endif
#include "afxres.h"
#include "verrsrc.h"
to the "Read noly symbol directives" text box.
I know this doesn't fit with using allegro, but I was only hacking for my own windows use.
I haven't looked that closely at the resource file beyond making the change to it I needed to get it to compile so other than the application icon, I'm not sure what else is still required in the rc file. As stated previously, Allegro takes care of the menu now and the machine list is partially dynamically built from config so technically you could configure a "BBC Master 128 w/HMS" where the ROM's are pre-loaded into the right places and the sound config settings are pre-set correctly.

I'm thinking that the Music 5000 menu entry should really be "Hybrid Music System" now that all that work to get the 2000 - 5000 units has pretty much been done.
tricky wrote:
Sat Oct 13, 2018 10:43 am
Now yo have got this working, I night be tempted to move to the v5 version.
Well, it's mostly VS config. I've got to sort out some of the paths in the project so they're relative and then it'll be ready for a branch, pull request and review before eventually making it into the master at some point. The code changes are minimal reviewing what I've done and any VS specific includes that are needed I've added to a "vs-includes" folder in the root of the src so it can be safely ignored when building with other tool chains.

Thinking about it I want to re-check the conditional compiler directives to make sure that they're Visual Studio specific rather than Win32 specific so it can continue to be built using other tool chains.

I guess I'll have to request access to GitHub proper now so I can create a branch and move all my changes into it so I can undo the changes I've currently got outstanding on the "master" too.. at the moment, the Commit, History and Compare options in the VS context menu are way too close for comfort :shock:

Paul

Post Reply