Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 I'm getting an error during compile on Snow Leopard. src/gui/configdialog.cpp:1: error: CPU you selected does not support x86-64 instruction set src/gui/generaltab.cpp:1: error: CPU you selected does not support x86-64 instruction set src/gui/about.cpp:1: error: CPU you selected does not support x86-64 instruction set src/gui/app.cpp:1: error: CPU you selected does not support x86-64 instruction set I have a 2011 Macbook Pro with a Core i7 processor (Sandy Bridge). Yeah, the Qt section is going to need some massive cleanup as there's lots of assumptions in the QT_* variables in the makefile, including a stupid CPU dependency in there. For now, you can try removing the text "-march=pentium-m" from the QT_CXXFLAGS definition. Sorry folks for the difficulty, those QT_* vars are tuned to my build system. I have to figure out how to fix it. In the meantime, the intrepid developers can cd into src/gui/ and do a qmake virtualjaguar.pro and scan the generated Makefile to get the proper environment variables for their build system. We Apologize For The Inconvenience Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 Yeah, the Qt section is going to need some massive cleanup as there's lots of assumptions in the QT_* variables in the makefile, including a stupid CPU dependency in there. For now, you can try removing the text "-march=pentium-m" from the QT_CXXFLAGS definition. Sorry folks for the difficulty, those QT_* vars are tuned to my build system. I have to figure out how to fix it. In the meantime, the intrepid developers can cd into src/gui/ and do a qmake virtualjaguar.pro and scan the generated Makefile to get the proper environment variables for their build system. We Apologize For The Inconvenience That fixed the CPU error, but now there's another In file included from src/gui/about.cpp:19: src/gui/about.h:11:17: warning: QtGui: No such file or directory In file included from src/gui/about.cpp:19: src/gui/about.h:14: error: expected class-name before ‘{’ token src/gui/about.h:16: error: expected `)' before ‘*’ token src/gui/about.h:19: error: ISO C++ forbids declaration of ‘QVBoxLayout’ with no type src/gui/about.h:19: error: expected ‘;’ before ‘*’ token src/gui/about.h:20: error: ISO C++ forbids declaration of ‘QLabel’ with no type src/gui/about.h:20: error: expected ‘;’ before ‘*’ token src/gui/about.h:21: error: ISO C++ forbids declaration of ‘QLabel’ with no type src/gui/about.h:21: error: expected ‘;’ before ‘*’ token src/gui/about.cpp:21: error: expected `)' before ‘*’ token Should QtGui already exist or is it created at compile time? Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 (edited) You can work around this by doing: cd src/gui qmake virtualjaguar.pro make and when it fails to link, change back up to the main virtualjaguar directory (cd ../..) and type make again. The problem is that the Qt includes in the main makefile are specifically for my machine. I'm working on a fix now. Edited June 24, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 You can work around this by doing: cd src/gui qmake virtualjaguar.pro make and when it fails to link, change back up to the main virtualjaguar directory (cd ../..) and type make again. The problem is that the Qt includes in the main makefile are specifically for my machine. I'm working on a fix now. I just worked around it by modifying all the includes to point to the headers on my system I'm getting a new problem with cdintf.o failing. MacBook-Pro:vj goldenegg$ make -e *** Checking compilation environment: -en SDL... -e OK -en ZLIB... -e OK -en LIBCDIO... -e OK -en OpenGL... -e *** GL CHECK NOT IMPLEMENTED *** -en Qt... -e *** QT CHECK NOT IMPLEMENTED *** -e *** Building Virtual Jaguar for Mac OS X... -e *** Preparing to make the Musashi core... -e *** Creating m68kops.h... Musashi v3.3 68000, 68010, 68EC020, 68020 emulator Copyright 1998-2000 Karl Stenerud (karl@mame.net) Generated 1962 opcode handlers from 503 primitives -e *** Compiling m68kcpu.c... -e *** Compiling obj/m68kops.c... -e *** Compiling obj/m68kopac.c... -e *** Compiling obj/m68kopdm.c... -e *** Compiling obj/m68kopnz.c... -e *** Compiling src/m68kdasm.c... -e *** Compiling src/gui/about.cpp... -e *** Compiling src/gui/app.cpp... -e *** Compiling src/gui/configdialog.cpp... -e *** Creating obj/moc_configdialog.cpp... -e *** Compiling obj/moc_configdialog.cpp... -e *** Compiling src/gui/generaltab.cpp... -e *** Creating obj/moc_generaltab.cpp... -e *** Compiling obj/moc_generaltab.cpp... -e *** Compiling src/gui/controllertab.cpp... -e *** Creating obj/moc_controllertab.cpp... -e *** Compiling obj/moc_controllertab.cpp... -e *** Compiling src/gui/filepicker.cpp... -e *** Creating obj/moc_filepicker.cpp... -e *** Compiling obj/moc_filepicker.cpp... -e *** Compiling src/gui/filelistmodel.cpp... src/gui/filelistmodel.cpp:27: warning: unused parameter ‘parent’ -e *** Compiling src/gui/filethread.cpp... src/gui/filethread.cpp: In member function ‘virtual void FileThread::run()’: src/gui/filethread.cpp:135: warning: unused variable ‘success’ -e *** Compiling src/gui/imagedelegate.cpp... src/gui/imagedelegate.cpp:90:2: warning: #warning "!!! FIX !!! Need to create properly scaled down cart/label images!" -e *** Creating obj/moc_filethread.cpp... -e *** Compiling obj/moc_filethread.cpp... -e *** Compiling src/gui/mainwin.cpp... In file included from ./src/jaguar.h:5, from src/gui/mainwin.cpp:37: ./src/memory.h:94:22: warning: byteswap.h: No such file or directory ./src/memory.h:95:20: warning: endian.h: No such file or directory src/gui/mainwin.cpp:50:2: warning: #warning !!! FIX !!! Figure out how to use this in GUI.CPP as well! src/gui/mainwin.cpp:80:2: warning: #warning "!!! Save/Restore window location for FilePickerWindow !!!" src/gui/mainwin.cpp:145:2: warning: #warning "!!! Set up a decent keyboard shortcut for Insert Cartridge !!!" src/gui/mainwin.cpp: In member function ‘void MainWin::HandleKeys(QKeyEvent*, bool)’: src/gui/mainwin.cpp:281: warning: comparison between signed and unsigned integer expressions src/gui/mainwin.cpp:283: warning: comparison between signed and unsigned integer expressions src/gui/mainwin.cpp:285: warning: comparison between signed and unsigned integer expressions src/gui/mainwin.cpp:287: warning: comparison between signed and unsigned integer expressions src/gui/mainwin.cpp:294: warning: comparison between signed and unsigned integer expressions src/gui/mainwin.cpp: In member function ‘void MainWin::ToggleRunState()’: src/gui/mainwin.cpp:492: warning: comparison between signed and unsigned integer expressions -e *** Creating obj/moc_mainwin.cpp... -e *** Compiling obj/moc_mainwin.cpp... -e *** Compiling src/gui/glwidget.cpp... In file included from ./src/tom.h:10, from src/gui/glwidget.cpp:17: ./src/memory.h:94:22: warning: byteswap.h: No such file or directory ./src/memory.h:95:20: warning: endian.h: No such file or directory -e *** Creating obj/moc_glwidget.cpp... -e *** Compiling obj/moc_glwidget.cpp... -e *** Creating qrc_virtualjaguar.cpp... -e *** Compiling obj/qrc_virtualjaguar.cpp... -e *** Compiling src/blitter.cpp... In file included from src/blitter.h:9, from src/blitter.cpp:23: src/memory.h:94:22: warning: byteswap.h: No such file or directory src/memory.h:95:20: warning: endian.h: No such file or directory src/blitter.cpp:3552:2: warning: #warning srcdreadd is not properly initialized! src/blitter.cpp: In function ‘void BlitterMidsummer2()’: src/blitter.cpp:4433: warning: unused variable ‘data_x’ src/blitter.cpp:4433: warning: unused variable ‘data_y’ src/blitter.cpp:4489: warning: unused variable ‘data_x’ src/blitter.cpp:4489: warning: unused variable ‘data_y’ src/blitter.cpp:2822: warning: unused variable ‘finneradd’ src/blitter.cpp:2822: warning: unused variable ‘inneradd’ -e *** Compiling src/cdrom.cpp... In file included from src/cdrom.h:9, from src/cdrom.cpp:16: src/memory.h:94:22: warning: byteswap.h: No such file or directory src/memory.h:95:20: warning: endian.h: No such file or directory -e *** Compiling src/cdintf.cpp... src/cdintf.cpp:29:74: warning: cdio/cdio.h: No such file or directory src/cdintf.cpp:93:2: warning: #warning "!!! FIX !!! CDIntfReadBlock not implemented!" src/cdintf.cpp:101:2: warning: #warning "!!! FIX !!! CDIntfGetNumSessions not implemented!" src/cdintf.cpp:109:2: warning: #warning "!!! FIX !!! CDIntfSelectDrive not implemented!" src/cdintf.cpp:116:2: warning: #warning "!!! FIX !!! CDIntfGetCurrentDrive not implemented!" src/cdintf.cpp:124:2: warning: #warning "!!! FIX !!! CDIntfGetDriveName driveNum is currently ignored!" src/cdintf.cpp:139:2: warning: #warning "!!! FIX !!! CDIntfGetSessionInfo not implemented!" src/cdintf.cpp:147:2: warning: #warning "!!! FIX !!! CDIntfTrackInfo not implemented!" src/cdintf.cpp:59: error: expected initializer before ‘*’ token src/cdintf.cpp: In function ‘bool CDIntfInit()’: src/cdintf.cpp:65: error: ‘cdioPtr’ was not declared in this scope src/cdintf.cpp:65: error: ‘DRIVER_DEVICE’ was not declared in this scope src/cdintf.cpp:65: error: ‘cdio_open’ was not declared in this scope src/cdintf.cpp: In function ‘void CDIntfDone()’: src/cdintf.cpp:86: error: ‘cdioPtr’ was not declared in this scope src/cdintf.cpp:87: error: ‘cdio_destroy’ was not declared in this scope src/cdintf.cpp: In function ‘const uint8* CDIntfGetDriveName(uint32)’: src/cdintf.cpp:128: error: ‘cdioPtr’ was not declared in this scope src/cdintf.cpp:128: error: ‘cdio_get_default_device’ was not declared in this scope make: *** [obj/cdintf.o] Error 1 rm obj/moc_controllertab.cpp obj/moc_configdialog.cpp obj/moc_filethread.cpp obj/moc_glwidget.cpp obj/moc_generaltab.cpp obj/moc_mainwin.cpp obj/moc_filepicker.cpp Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 What happens when you change #include <cdio/cdio.h> to #include "cdio/cdio.h" ? Also, is there a cdio/cdio.h under the directory printed out by pkg-config --variable=includedir libcdio ? If not, you can simply blank out the lines which declare HAVECDIO and CDIOLIB in the makefile. Then it should build for sure. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 What happens when you change #include <cdio/cdio.h> to #include "cdio/cdio.h" ? Also, is there a cdio/cdio.h under the directory printed out by pkg-config --variable=includedir libcdio ? If not, you can simply blank out the lines which declare HAVECDIO and CDIOLIB in the makefile. Then it should build for sure. There is a cdio/cdio.h under the directory printed out by pkg-config. I modified the include to link directly to cdio.h and got a ton more errors, due to includes in that header. So I just commented out the CD stuff from compiling. Still having problems though, but looks like we're almost there -e *** Linking it all together... Package QtGui was not found in the pkg-config search path. Perhaps you should add the directory containing `QtGui.pc' to the PKG_CONFIG_PATH environment variable No package 'QtGui' found Package QtOpenGL was not found in the pkg-config search path. Perhaps you should add the directory containing `QtOpenGL.pc' to the PKG_CONFIG_PATH environment variable No package 'QtOpenGL' found Looks like the QT problem from before. I pulled down clean source and tried your previous workaround, but it didn't help. Guess I'll have to wait until you address the QT path issue in the code. I'm off to bed. I'll be back for more compiling fun tomorrow Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 Okay ... nearly there I pulled down a fresh copy of the code and made the following changes to the MAKEFILE. 1 - Removed the processor reference 2 - Commented out the CD stuff 3 - Changed QT_INCPATH to the following QT_INCPATH = -I/usr/share/qt4/mkspecs/linux-g++ -I./src -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/usr/include/qt4 -I/usr/X11R6/include -I./obj `sdl-config --cflags` I then found that the pkgconfig path for QT on my system is /Users/goldenegg/QtSDK/Desktop/Qt/473/gcc/lib/pkgconfig/, so I set PKG_CONFIG_PATH manually to that directory. I now get two issues during linking. 1 - Warning that libz.dylib was built for i386 instead of x86_64. This is just a warning though, so I don't know the overall impact 2 - LD fails with 'symbol(s) not found', causing the linking to fail I've attached the output as a text file to this post, as it's too long to post in the thread. Now it's definitely time for me to get to bed Hope all this helps. linkerror.txt Quote Link to comment Share on other sites More sharing options...
Tyrant Posted June 24, 2011 Share Posted June 24, 2011 I'm really having a hard time understanding the difficulty here, if Qt installs itself and the environment is sane it should have includes and headers where the build system can find them. This "Mac Way" vs. "Unix Way" doesn't make the slightest bit of sense, again, if the environment is sane. The thing I think comes from your definition of "sane", which in turn relates to where libraries and headers are located, and how they can be located. On a typical linux system, they're all in /usr/local/lib (or /usr/lib) both of which are in the path, right? (been a while since I used linux, might be being forgetful, I never did any dev work under it). On a mac, they're generally installed in /Library/Frameworks and not in the path. You can open up a terminal and type qmake, right? Yes, I can. The makefile it spits out includes the following INCPATH = -I/usr/local/Qt4.6/mkspecs/macx-g++ -I. -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/usr/include/QtCore -I/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/usr/include/QtGui -I/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/usr/include/QtOpenGL -I/usr/include -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -I../../obj -F/Library/Frameworks LIBS = $(SUBLIBS) -F/Library/Frameworks -L/Library/Frameworks -framework QtOpenGL -framework QtGui -framework QtCore -framework OpenGL -framework AGL If I then try to build just the Qt parts (starting in src/gui and typing make) it complains that it can't find SDL (despite it being installed as both a framework and in /usr/local/lib) and aborts. The only thing that's going to make things any better is an open dialog between the two developer camps, not name calling and ire. There was no name calling or ire, just a little frustration late at night after being in dependancy hell for a little while. I always have this kind of trouble building linuxy apps on osx, having to manually install dependancies and do it in the configure/make/install way, rather than using the mac versions of things which come as frameworks. It gets very frustrating, and quite often doesn't work at all due to some linux only requirement that isn't supported. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 I always have this kind of trouble building linuxy apps on osx, having to manually install dependancies and do it in the configure/make/install way, rather than using the mac versions of things which come as frameworks. It gets very frustrating, and quite often doesn't work at all due to some linux only requirement that isn't supported. Honestly, it's just the difficulties of handling compiles cross-platform. Are you using MacPorts to install your dependencies? I've rarely found issues compiling when installing packages through MacPorts. The issues with QT when compiling Virtual Jaguar are a little different as it not available through MacPorts and installs differently depending on the platform. EDIT: Looks like QT is now available through MacPorts. I'm going to give that a try to see if that helps with anything. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 @goldenegg: If the rest of the objects built as 64-bit then a 32-bit ZLIB will definitely be a problem as VJ uses the ZLIB stuff for handling compressed files. Not 100% sure but the problem with missing symbols seems to be a C vs C++ namespace problem; I'll have to see if there's some way to let the linker know that it's linking C *and* C++ objects (strange that it doesn't work on the Mac as is!). @Tyrant: By "sane" I mean that the installer puts it in the usual place for libraries/headers on that system and makes sure than any binaries are in the path and executable, so there shouldn't be any need for "Unix" specific paths vs "Mac" specific on *your* system. If you have qmake then you should have sdl-config too; I just need to fix those parts of the makefile/.pro files to use them. As noted a few posts above, I put some hard dependencies on paths that exist only on my system and I shouldn't have. There should be absolutely no reason why you would need to install all that stuff from scratch (using configure, make, make install) if you've already installed them using a Mac native package and the installer put the libraries and headers on your system where your system expects them to be. Libraries and stuff should all be pulled in by the native linker by specifying them with -lfoo and the like. In other words, it looks like you're making it harder on yourself than it needs to be. If you bypass all the checks in the front end of the makefile and you have the dependencies installed in the usual way it should build (well, once I fix the Qt vars in the makefile). If it doesn't, then that's a bug and it needs to be fixed. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 @goldenegg: If the rest of the objects built as 64-bit then a 32-bit ZLIB will definitely be a problem as VJ uses the ZLIB stuff for handling compressed files. Not 100% sure but the problem with missing symbols seems to be a C vs C++ namespace problem; I'll have to see if there's some way to let the linker know that it's linking C *and* C++ objects (strange that it doesn't work on the Mac as is!). As the 32-bit ZLIB appears to be part of the OS, there's probably little that can be done about it (other than waiting to see if that's changed in Lion). Let me know if you want me to test anything if you update the linker. Now that I have my steps figured out, I can run compiles on VJ source in a matter of minutes. EDIT: I just noticed that MEMORY.H is including two headers which don't exist #include <byteswap.h> #include <endian.h> I came across this while using GCC45 to compile, as it completely errored out during the compile. Odd that GCC 4.2.1 (from current Xcode) only shows that as a warning and continues compiling. If I comment out the bottom section of MEMORY.H, the compile still fails with GCC45 at GLWIDGET.CPP. -e *** Compiling src/gui/glwidget.cpp... In file included from src/gui/glwidget.cpp:14:0: src/gui/glwidget.h:36:3: error: 'uint32_t' does not name a type src/gui/glwidget.cpp: In constructor 'GLWidget::GLWidget(QWidget*)': src/gui/glwidget.cpp:21:37: error: class 'GLWidget' does not have any field named 'buffer' src/gui/glwidget.cpp: In member function 'virtual void GLWidget::paintGL()': src/gui/glwidget.cpp:75:114: error: 'buffer' was not declared in this scope src/gui/glwidget.cpp: In member function 'virtual void GLWidget::resizeGL(int, int)': src/gui/glwidget.cpp:108:7: error: 'buffer' was not declared in this scope src/gui/glwidget.cpp:110:13: error: type '<type error>' argument given to 'delete', expected pointer src/gui/glwidget.cpp:114:3: error: 'buffer' was not declared in this scope make: *** [obj/glwidget.o] Error 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 uint32_t requires the <stdint.h> header. Add that and it should compile. Strange that <endian.h> and <byteswap.h> aren't in your system, they should be. Also, I noticed that ZLIB is in MacPorts, maybe you could try using that? Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 24, 2011 Share Posted June 24, 2011 uint32_t requires the <stdint.h> header. Add that and it should compile. Strange that <endian.h> and <byteswap.h> aren't in your system, they should be. Also, I noticed that ZLIB is in MacPorts, maybe you could try using that? I added stdint and it fixed that error! I modified the libs path in the MAKEFILE to use /opt/local/lib (MacPorts packages) instead of /usr/local/lib. That resolved the libz warning. Still getting the symbol error though during linking. Could the lack of those headers have anything to do with that? I ran a find on my system and found endian.h but not byteswap. EDIT: Apparently MacOS doesn't include byteswap. I found a replacement which seems to work. Still getting symbol error though. http://cgit.freedesktop.org/xorg/xserver/plain/GL/glx/glxbyteorder.h?id=415e49b940bba2d08870db410ebb47d2add5d836 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 24, 2011 Author Share Posted June 24, 2011 (edited) Yeah, the problem is that the C stuff isn't linking with the C++ stuff, presumably because the compiler is adding an underscore to the start of the labels. Don't know why that is, but I'm looking into it. And to those who were wondering: This is why it hasn't been released yet. There's still some wrinkles that need ironing. EDIT: It seems like some objects are not being built. What do you get if you grep for JaguarExecuteNew like so: grep JaguarExecuteNew obj/*.o ? If it isn't being found in jaguar.o, then that's the problem. Edited June 24, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 I'm not sure what is going on here. Are you working with SubQmod on Jagulator or are you doing an independent GUI like Belboz did for the Skunkboard GUI? Laziness is its own reward, I guess. I guess I'm spoiled, I have an excellent package manager that makes it dead easy to get dependencies. Maybe I should put links in the INSTALL file? ZLIB: http://www.zlib.net/ SDL: http://www.libsdl.org/download-1.2.php Qt: http://qt.nokia.com/downloads/ libcdio: http://ftp.gnu.org/gnu/libcdio/ (this is optional) Still, three dependencies (four if you want libcdio) isn't bad. The only one that would take time to build from source is Qt, and I think there are pre-built binaries for that. I guess I might as well put this out there, since the release is pretty close: Is there anyone out there willing and able to build win32 and Mac versions? If so, please post. Maybe a screenshot to entice you? Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 25, 2011 Share Posted June 25, 2011 EDIT: It seems like some objects are not being built. What do you get if you grep for JaguarExecuteNew like so: grep JaguarExecuteNew obj/*.o ? If it isn't being found in jaguar.o, then that's the problem. Looks like that's the problem goldenegg$ grep JaguarExecuteNew obj/*.o Binary file obj/mainwin.o matches Any idea why it's not fully compiling? EDIT: Figured it out! Looks like I had a hash floating around midway through the OBJ list. Not sure how it got there. But I have it fully compiled now! Haven't tried a game yet. That's next EDIT 2: I just tried VJ with Alien vs. Predator and Attack of the Mutant Penguins. First off ... the paths in the preferences must be full paths. Relative paths don't work. Also, the emulator doesn't appear to load the BIOS as I don't get the Jaguar splash screen. Attack of the Mutant Penguins won't load. It just sits at a black screen. AvP loads fine, but plays very slow. I'm guessing it's around 10fps or lower. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 25, 2011 Author Share Posted June 25, 2011 (edited) @JagChris: Virtual Jaguar is what I'm working on, and have been working on for the past several years. It's only fairly recently that I've decided to use a modern GUI toolkit for support functions that were only hinted at in the old VJ GUI. I think the move has paid some nice dividends; it remains to be seen if anyone else agrees. @goldenegg: Awesome! You got it to build! \o/ \o/ \o/ Not sure why it's not finding the BIOS, and it should be able to use relative paths just fine (as long as you prefix that rel path with a dot slash "./"). Also you might want to look through the log file that it makes (virtualjaguar.log) to see if there are any clues in there as to why it isn't finding stuff. A lot of games require the BIOS in order to work properly, some require both the BIOS and the DSP (Checkered Flag comes to mind). Attack of the Mutant Penguins is one of those that requires at least the DSP (maybe the BIOS too). The blitter is much slower than the older (less compatible) blitter, but it can and will be optimized. Any game that makes heavy use of it (like AvP) are naturally going to be slow at this point. Games that don't use it will be faster; Rayman plays at almost full speed (sans DSP) on my old 1.7GHz Pentium-M. The latest version (r344) has a rudimentary config dialog which lets you edit the paths at least. Still sorting out the rest and trying to figure out how to do it right. That and the Qt build system. BTW, how much of a pain was it to install pkg-config? Just wondering what is and isn't reasonable to expect from the build system. Edited June 25, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 lol ok sorry havent heard much about VJ at all really. And the almost simultaneous announcements of two Jag emulators both hitting version 2.0 status confused me. @JagChris: Virtual Jaguar is what I'm working on, and have been working on for the past several years. It's only fairly recently that I've decided to use a modern GUI toolkit for support functions that were only hinted at in the old VJ GUI. I think the move has paid some nice dividends; it remains to be seen if anyone else agrees. 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 25, 2011 Author Share Posted June 25, 2011 lol ok sorry havent heard much about VJ at all really. And the almost simultaneous announcements of two Jag emulators both hitting version 2.0 status confused me. Yeah, I thought I kinda funny myself, seeing how I had the 2.0.0 designation set upon almost a year ago. Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 lol ok sorry havent heard much about VJ at all really. And the almost simultaneous announcements of two Jag emulators both hitting version 2.0 status confused me. Yeah, I thought I kinda funny myself, seeing how I had the 2.0.0 designation set upon almost a year ago. A year ago? That eons in computer/software industry time. Time for VJ 3.0 isnt it? 1 Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 Also will this emulator have debugging tools built into it? Or is it just going to be a straight emulator. Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 I noticed VJ is able to somewhat run NBA Jam TE. Thats impressive. 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 25, 2011 Author Share Posted June 25, 2011 Naw, the next version of Virtual Jaguar will use descriptive adjectives instead of numbers--it'll be called "Alley Cat". The idea is to have a debugger available, probably in a separate build. But I don't really know what a useful one would look like; anyone who wants such a thing needs to show & tell me what you'd like to see & use. While we're slowly inching up the compatibility, there's still a few stubborn holdouts like Power Drive Rally. But we'll get 'em all eventually. Quote Link to comment Share on other sites More sharing options...
JagChris Posted June 25, 2011 Share Posted June 25, 2011 A useful debugger? Well for C stuff probably something akin to GDB. And maybe whatever assembly programmers use for debugging. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted June 25, 2011 Share Posted June 25, 2011 The idea is to have a debugger available, probably in a separate build. But I don't really know what a useful one would look like; anyone who wants such a thing needs to show & tell me what you'd like to see & use. This! The boiler room in Steem Engine (Debug Build) is possibly one of the best debuggers I have ever used. If you could do something similar for the Jaguar it would be a quantum leap forward for developers. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.