Gens/GS Milestone 6

It is.

 

Code (Text):

1. ...:~$ ls -l /usr/bin/gens
2. -rwxr-xr-x 1 root root 2435832 2008-12-07 22:38 /usr/bin/gens
3. ...:~$ file /usr/bin/gens
4. /usr/bin/gens: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped
5.  

By the way, will a 64bit version be available soon?

 

It doesn't seem to be missing any dependencies. I'm not familiar with the details of x86 assembly, but shouldn't it be directly compatible with x86-64?

 

I don't know what happened, but it suddenly started working. Thanks anyway for the help, GerbilSoft.

 

Thank you so much to GerbilSoft for this! It's nice to not be left out, for running something other than Windows Anyway, regarding the OS X compilation instructions by sonicblur:

First, the lines 6-8 can all be combined into one command, "port install gtk2 libsdl libsdl_mixer". Second, a minor nitpick, but "sudo -s" is considered the "proper" way to use sudo for a root shell, rather than "sudo su". Doesn't actually matter much though, other than that "sudo -s" preserves your normal user's $PATH, $HOME, etc. settings. Third, in case anyone else did silly things with their $PATH variable like I did, if configure refuses to see GTK, make sure that /opt/local/bin is near the start of your $PATH, or at least before any other directory that has a pkg-search binary in it (such as /opt/kde4-deps/bin, for anyone using kde4 for mac). That screwed things up for me for ages til someone on an IRC channel helped me figure it out!

The other thing is, even though the ./configure script ran fine, make is giving me odd errors. http://pastebin.com/m7ae8f308 is the output from the compiler. I'm currently using sonicblur's Gens.app build (without a new binary), on OS X 10.5, and this version seems to run mostly OK except for the gameplay taking place in a seperate (seemingly non-X11) window to the X11 window which contains the menus (and a big blank space underneath, presumably where the contents of the separate window should be). I'm not sure if this would be affected by a newly compiled binary, but as I've said, I can't get it to "make" correctly. Still, the effort that's been put in here by GerbilSoft and sonicblur is great, thanks to you both!

 

Since Gerbil already mentioned the fix for this on the previous page in the post above, I'll just say that the separate window thing is an issue that I've mentioned and something I need to fix. Video is displayed in an SDL view, and he uses a hack to embed the SDL view into the window with the menubar which X11 for Mac OS X doesn't support. (Or maybe it's GTK's fault. Either way... same outcome.)
The solution would be to implement support for the Mac menubar natively and hide the window. It's something I was planning on doing, but temporarily got bored of this for awhile. If you know what you doing, feel free to take off every zig and save me the trouble of doing it myself. (I'm currently distracted with a port of something else right now.)

 

I think I may be doing something wrong with the patch. I pasted from "diff —git a/src/gens/macros/hashtable.hpp b/src/gens/macros/hashtable.hpp" onwards into a new file (replacing the elongated dash with a double dash - I'm still not sure what triggers the forum software to make that replacement), but when I run it, patch -p1 < hashtablepatch, the result is this:

patching file src/gens/macros/hashtable.hpp
patch unexpectedly ends in middle of line
patch: **** unexpected end of file in patch​

If I go to the last line, and add a newline to the end of it, I instead get the error of:

patching file src/gens/macros/hashtable.hpp
patch: **** malformed patch at line 26: // Standard std::map​

If patch is run without the -p1, it doesn't know where to find the files to patch. Sorry if I'm doing something obviously dumb, but I'm not all that familiar with patch, I've only ever used it a couple times. Alternatively, perhaps the already patched file could be put up somewhere to download? Or perhaps, for the convenience of others trying to compile from source, a new source package with this fix applied could be put up by someone - prevents the next person needing to download more separate files? I do appreciate all the hard work put in already, by the way, and don't want it to seem like I'm demanding extra work, I'd have patched it already myself if I could get it to work Unfortunately, my geek-powers seem to be failing me tonight...

 

I'm getting brand new errors now, from the assembler this time:
"plugins/render/hq2x/mdp_render_hq2x_16_x86.asm:2066: error: phase error detected at end of assembly", then recursive make errors.
I've googled this error, and from random advice found online, tried editing the Makefile to use -O999 and -O1 instead of -O3 (-O2 and -O3 apparently cause this error occasionally, or at least did in older nasm versions), but with no luck. I've looked up line 2066 in a text editor, it's one line before the last (blank except for a newline) line, and it says simply "ret". Not knowing much at all about assembly yet, this means very little to me (Is it similar to a C return?). I'm also writing up a revised version of sonicblur's instructions for when I've finished this, which includes instructions for applying the patch, putting it in sonicblur's app, etc, in the hope it may help others trying this

 

Upgrading nasm helped, thanks It seems what was on here by default was nasm 0.98. Anyway, I'm having one last issue with compiling Gens/GS, compiling fails when GCC is working on the final gens binary (g++ -O2 -Wall -Wextra -g -g -O2 -o gens emulator/gens-gens.o emulator/gens-g_main.o emulator/gens-g_input.o... etc). The error given is this:

Code (Text):

1. Undefined symbols:
2.   "Last_BUS_REQ_St", referenced from:
3.       M68K_Read_Byte_Misc_CD.z80_off in mem_m68k_cd.o
4.       M68K_Read_Word_Misc_CD.z80_off in mem_m68k_cd.o
5.       M68K_Write_Byte_Misc_CD.deactivated in mem_m68k_cd.o
6.       M68K_Write_Word_Misc_CD.deactivated in mem_m68k_cd.o
7.       M68K_Read_Byte_Misc_32X.z80_off in mem_m68k_32x.o
8.       M68K_Read_Word_Misc_32X.z80_off in mem_m68k_32x.o
9.       M68K_Write_Byte_Misc_32X.deactivated in mem_m68k_32x.o
10.       M68K_Write_Word_Misc_32X.deactivated in mem_m68k_32x.o
11.   "Last_BUS_REQ_Cnt", referenced from:
12.       M68K_Read_Byte_Misc_CD.z80_off in mem_m68k_cd.o
13.       M68K_Read_Word_Misc_CD.z80_off in mem_m68k_cd.o
14.       M68K_Write_Byte_Misc_CD.deactivated in mem_m68k_cd.o
15.       M68K_Write_Word_Misc_CD.deactivated in mem_m68k_cd.o
16.       M68K_Read_Byte_Misc_32X.z80_off in mem_m68k_32x.o
17.       M68K_Read_Word_Misc_32X.z80_off in mem_m68k_32x.o
18.       M68K_Write_Byte_Misc_32X.deactivated in mem_m68k_32x.o
19.       M68K_Write_Word_Misc_32X.deactivated in mem_m68k_32x.o
20. ld: symbol(s) not found
21. collect2: ld returned 1 exit status

I've tried with both GCC 4.0.1 and GCC 4.3.2, the same error occurs on both. I was also kinda hoping a new binary might fix the strange problem in the existing binary I have (in sonicblur's Gens.app), which seems to read mp3 versions of tracks as very long (30-50 minutes per track, ish) and crashes when attempting to play any of them

 

Actually, the default is 3 according to your configure script. The article he found was referring to the NASM optimization level.

Anyway, it's not building with —enable-asm=no anymore, so I think something's up.

 

These features will be in the SVN repository until the next Milestone I assume?

And I am sure that there'll be an OpenGL feature down the road too?