Supermodel Forum

juhuu,
got the Audio Fixed Version myself sorted with later tips in this thread.
here is the Link for the 32 and 64 Bit Version of R421:
https://mega.nz/#!OwcETRqb!oigwIimas9x8 ... bERQJnK5cA

Hi,

I was interested in looking at Supermodel's code so I thought I'd try to build it with the Visual Studio 2017 Community edition I had installed. It actually didn't take much effort to get it working.

After copying SDL and zlib, I opened the Visual Studio 2008 solution in Visual Studio 2017. It converted with no problems. When building I encountered an ambiguous symbol error for the "data" variable in the initialize_globals function in audio.cpp. I don't know why the compiler was giving me that error since it was only really seeing the declaration and its extern, but I figured it was clashing with another "data" variable somewhere. I renamed it ("getbits_data"), fixed up the affected areas and then it compiled and ran no problems.

thanks!
djcc

djcc wrote:Hi,

I was interested in looking at Supermodel's code so I thought I'd try to build it with the Visual Studio 2017 Community edition I had installed. It actually didn't take much effort to get it working.

After copying SDL and zlib, I opened the Visual Studio 2008 solution in Visual Studio 2017. It converted with no problems. When building I encountered an ambiguous symbol error for the "data" variable in the initialize_globals function in audio.cpp. I don't know why the compiler was giving me that error since it was only really seeing the declaration and its extern, but I figured it was clashing with another "data" variable somewhere. I renamed it ("getbits_data"), fixed up the affected areas and then it compiled and ran no problems.

thanks!
djcc

Has anyone else encountered this? If so, perhaps we could incorporate this into the code as a patch?

I've reported this problem almost year and half ago.

Kacperas wrote:I've reported this problem almost year and half ago.

I don't use MSVC. I wonder how Ian is compiling this? Is this an issue that is only present with the latest VS2017? If so, can you submit a patch with your solution of adding the anonymous namespace ::? I can easily apply that.

Bart wrote:

Kacperas wrote:I've reported this problem almost year and half ago.

I don't use MSVC. I wonder how Ian is compiling this? Is this an issue that is only present with the latest VS2017? If so, can you submit a patch with your solution of adding the anonymous namespace ::? I can easily apply that.

AFAIK he's using VM2013, which isn't affected by this issue. Only VM2015 and (it seems) newer are.
Regarding patch, I've switched to MSYS more like a year ago, so I no longer use any VM version. Maybe someone else can provide a patch?

Hi,
I think you talk about this
https://yadi.sk/d/gS0L40YX3MmvmF

It builds fine in visual studio 2013. I think the error in vs2015 is the same.

here is fix for vs2015 and newer

Code: Select all

Index: audio.cpp
===================================================================
--- audio.cpp   (revision 648)
+++ audio.cpp   (working copy)
@@ -190,7 +190,7 @@
  */
 void initialise_globals(void)
 {
-   append=data=nch=0;
+   append=::data=nch=0;
         f_bdirty=TRUE;
         bclean_bytes=0;
 
Index: huffman.cpp
===================================================================
--- huffman.cpp   (revision 648)
+++ huffman.cpp   (working copy)
@@ -47,12 +47,12 @@
 {
 unsigned int pos,ret_value;
 
-        pos = data >> 3;
+        pos = ::data >> 3;
         ret_value = buffer[pos] << 24 |
                     buffer[pos+1] << 16 |
                     buffer[pos+2] << 8 |
                     buffer[pos+3];
-        ret_value <<= data & 7;
+        ret_value <<= ::data & 7;
         ret_value >>= 32 - n;
 
         return ret_value;
@@ -60,8 +60,8 @@
 
 static inline void sackbits(int n)
 {
-        data += n;
-        data &= 8*BUFFER_SIZE-1;
+        ::data += n;
+        ::data &= 8*BUFFER_SIZE-1;
 }
 
 /* huffman_decode() is supposed to be faster now
@@ -228,8 +228,8 @@
    /*  set position to start of the next gr/ch
     */
     if (cnt != info->part2_3_length[gr][ch] - ssize ) {
-       data-=cnt-(info->part2_3_length[gr][ch] - ssize);
-       data&= 8*BUFFER_SIZE - 1;
+       ::data-=cnt-(info->part2_3_length[gr][ch] - ssize);
+       ::data&= 8*BUFFER_SIZE - 1;
     }
    if (l<576) non_zero[ch]=l;
    else non_zero[ch]=576;
Index: layer2.cpp
===================================================================
--- layer2.cpp   (revision 648)
+++ layer2.cpp   (working copy)
@@ -74,7 +74,7 @@
 
    /* layers 1 and 2 do not have a 'bit reservoir'
     */
-   append=data=0;
+   append=::data=0;
 
    fillbfr(mean_frame_size + header->padding_bit - hsize);


speaking in general - having variable "data" in .h file looks evil...

From what I can see, "data" and the other accompanying variables should really belong in the cpp file. But maybe there's a reason it's that way.