Jump to content



5

Upcoming Virtual Jaguar 2.0.0 release

Started by Shamus, Jun 22 2011 8:51 AM

283 replies to this topic

#26 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Thu Jun 23, 2011 8:53 PM

View Postgoldenegg, on Thu Jun 23, 2011 8:39 PM, said:

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. :P 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

#27 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Thu Jun 23, 2011 9:01 PM

View PostShamus, on Thu Jun 23, 2011 8:53 PM, said:

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. :P 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?

#28 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Thu Jun 23, 2011 9:25 PM

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. :P

Edited by Shamus, Thu Jun 23, 2011 9:26 PM.

#29 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Thu Jun 23, 2011 9:29 PM

View PostShamus, on Thu Jun 23, 2011 9:25 PM, said:

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. :P

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.

Spoiler

#30 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Thu Jun 23, 2011 10:10 PM

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. :P

#31 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Thu Jun 23, 2011 10:35 PM

View PostShamus, on Thu Jun 23, 2011 10:10 PM, said:

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. :P

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 :)

#32 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Thu Jun 23, 2011 11:42 PM

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.

Attached Files


#33 Tyrant OFFLINE  

Tyrant

    Stargunner

  • 1,497 posts
  • Location:London, UK

Posted Fri Jun 24, 2011 1:21 AM

View PostShamus, on Thu Jun 23, 2011 8:38 PM, said:

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.

View PostShamus, on Thu Jun 23, 2011 8:38 PM, said:

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.

View PostShamus, on Thu Jun 23, 2011 8:38 PM, said:

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. :roll:
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.

#34 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Fri Jun 24, 2011 7:19 AM

View PostTyrant, on Fri Jun 24, 2011 1:21 AM, said:

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.

#35 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 7:28 AM

@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. :P

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. :)

#36 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Fri Jun 24, 2011 7:46 AM

View PostShamus, on Fri Jun 24, 2011 7:28 AM, said:

@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

#37 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 10:45 AM

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? :)

#38 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Fri Jun 24, 2011 11:02 AM

View PostShamus, on Fri Jun 24, 2011 10:45 AM, said:

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.freedesk...ebb47d2add5d836

#39 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 4:15 PM

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. :P

Edited by Shamus, Fri Jun 24, 2011 4:27 PM.

#40 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 6:01 PM

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?

View PostShamus, on Thu Jun 23, 2011 10:42 AM, said:

Laziness is its own reward, I guess. :D

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? :P

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? :D

Attachment vj-2.0.0-rayman1.png

#41 goldenegg OFFLINE  

goldenegg

    Dragonstomper

  • 518 posts

Posted Fri Jun 24, 2011 6:44 PM

View PostShamus, on Fri Jun 24, 2011 4:15 PM, said:

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. :P

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.

#42 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 9:10 PM

@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).

vj-2.0.0-aotmp-1.png

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. :P

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 by Shamus, Fri Jun 24, 2011 9:33 PM.

#43 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 9:26 PM

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. ;)

View PostShamus, on Fri Jun 24, 2011 9:10 PM, said:

@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. :)

#44 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 9:32 PM

View PostJagChris, on Fri Jun 24, 2011 9:26 PM, said:

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. ;)

#45 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 9:38 PM

View PostShamus, on Fri Jun 24, 2011 9:32 PM, said:

View PostJagChris, on Fri Jun 24, 2011 9:26 PM, said:

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? :D

#46 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 9:41 PM

Also will this emulator have debugging tools built into it? Or is it just going to be a straight emulator.

#47 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 9:46 PM

I noticed VJ is able to somewhat run NBA Jam TE. Thats impressive.

#48 Shamus OFFLINE  

Shamus

    Moonsweeper

  • 308 posts
  • Moo, er, Roar!
  • Location:Ur-th

Posted Fri Jun 24, 2011 9:52 PM

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. :D

#49 JagChris OFFLINE  

JagChris

    Stargunner

  • 1,594 posts
  • Location:Oregon

Posted Fri Jun 24, 2011 11:17 PM

A useful debugger? Well for C stuff probably something akin to GDB. And maybe whatever assembly programmers use for debugging. :)

#50 CyranoJ OFFLINE  

CyranoJ

    Dragonstomper

  • 767 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Sat Jun 25, 2011 1:56 AM

View PostShamus, on Fri Jun 24, 2011 9:52 PM, said:

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.
Back to Atari Jaguar


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

  1. AtariAge Forums
  2. → Atari Systems
  3. → Atari Jaguar
  4. Guidelines